#bzr 2008-06-30
<berto-> jelmer: no luck on figuring out my os x issues.  i'm going to work on it and when i have it working i'll report back.  i gg for now.
<berto-> ttyl.
<jelmer> ok
<jelmer> bye
<lifeless> jelmer: I've filed a bug
<jelmer> lifeless: k
<lifeless> jelmer: the item_keys_introduced_by function is the current failing thing
<ToyKeeper> jelmer: I have a working diff panel in bzrk, but I'm not happy with it and I've been too busy to fix it.
<jelmer> ToyKeeper: ah, ok
<ToyKeeper> jelmer: If you want it, it's at lp:~toykeeper/bzr-gtk/bzr-vis-enhancements
<jelmer> ToyKeeper: I'll wait until you're happy with it
<beuno> jelmer, lol, I was just about to send the same patch to the list  (minus the tortoise bits that sneaked into your patch)
<ToyKeeper> I probably need to fix some things in DiffWidget.  It doesn't like to have its contents changed after it gets displayed.
<mbp_> hello all
<ToyKeeper> Also, is there any existing way to save preferences, or should I make something up?
<jelmer> ToyKeeper: We generally just use the bazaar configuration infrastructure
<beuno> mornin' mbp_   (poolie-in-disguise)
<lifeless> hi mbp_
<jelmer> hi Martin
<jelmer> lifeless: I'm a bit confused about the use of iter_lines_added_or_present_in_keys()
<lifeless> jelmer: ignore that, look at the top of the frame
<jelmer> lifeless: would it be valid to just retrieve those keys' contents and yield their lines one by one?
<lifeless> top-frame
<jelmer> ahh
<lifeless> jelmer: :)
<lifeless> bug 243998
<ubottu> Launchpad bug 243998 in bzr "BzrDir.has_workingtree() raises NotLocalUrl" [Undecided,New] https://launchpad.net/bugs/243998
<lifeless> jelmer: this is by design; perhaps you could enlarge on why it affects you?
<jelmer> lifeless: I've got a plugin that registers a post-push hook
<jelmer> that hook will push a index.html page (with a quick description of how to check out the branch, and its history) if there is no remote working tree
<lifeless> jelmer: nice; you should catch NotLocalUrl
<jelmer> lifeless: that's what I'm doing at the moment
<jelmer> it does seem like something that the API could handle for me though
<jelmer> since it does have enough data to return a proper value
<lifeless> jelmer: it sounds like you want 'has_working_tree' or something; thats really a Look-before-you-leap style method though; I'd question its value
<jelmer> lifeless: that's what we're talking about here though
<jelmer> this function *is* called has_working_tree()
<jelmer> it's not open_working_tree() I'm referring to
<lifeless> hmm
<jelmer> I think it's perfectly sensible for *open_workingtree()* to raise NotLocalUrl if it's a remote URL
<baco> Hi, I am trying to run a smart server via inetd with this line Â«4155  stream  tcp  nowait  baco  /usr/bin/bzr /usr/bin/bzr serve --inet --directory=/srv/bzr/Â» and when I do telnet to the port I get Â«bzr: ERROR: unknown command "--inet"Â»
<baco> where is the problem?
<mwhudson> lifeless: have you looked at the btrees in the zodb?
<mwhudson> (i sort of doubt they're suitable, but probabyl worth a look)
<lifeless> mwhudson: I found something that looked like it was that; it uses marshall
<lifeless> mwhudson: / pickle
<mwhudson> there's a string/string version isn't there?
<lifeless> mwhudson: and wants to update - its a disk hash table rather than anything else
<mwhudson> yeah, the write-once stuff isn't part of its world
<mwhudson> anyway, just a thought
 * mwhudson wanders off for a bit
<lifeless> mwhudson: http://pypi.python.org/pypi/zc.dict/1.2.1 is what I looked at
<lifeless> and http://pypi.python.org/pypi/zope.bforest/1.2
<mwhudson> ah, i think i was thinking about bforest and had forgotten a lot of details
<lifeless> there is a ZODB.BTrees apparently
<lifeless> but I'm having trouble finding it :)
<lifeless> (in pypi that is)
<lifeless> also there isn't SSBTree, only I or O
<lifeless> (as far as I can tell to date)
 * lifeless considers running bzr search over zope, so he can find this damn code
<lifeless> davidstrauss: how did you go with loggerhead?
<davidstrauss> lifeless: haven't tried installing it yet
<davidstrauss> lifeless: i'll probably try tomorrow
<davidstrauss> lifeless: but thanks for asking
<spiv> baco: that's weird, it's like it isn't seeing the 'serve' part of the command line
<lifeless> davidstrauss: no probs; I think most people run loggerhead from source, but I may be wrong
<baco> spiv: I bet is the inetd server, I am changing it now
<baco> spiv: yeah, I was right, is wried anyways, but do not install inetutils-inetd, openbsd-inetd is the one that works
<lifeless> mwhudson: yeah, zodb.btrees is not suitable; two reasons - it pickles. and it pickles.
<lifeless> mwhudson: oh, and it is mutable, and complex.
 * spiv buys lifeless a Pickle-Me-Elmo
<lifeless> ewww
 * igc lunch
<StevenK> lifeless: Continuing from -devel, this is the worrying output:
<StevenK> Conflict adding files to libmokoui.  Created directory.
<StevenK> Conflict because libmokoui is not versioned, but has versioned children.  Versioned directory.
<StevenK> Conflict adding file libmokoui.  Moved existing file to libmokoui.moved.
<StevenK> (libmokoui is a directory, so 'Conflict adding file' is worrysome
<lifeless> StevenK: you add files to directories
<lifeless> StevenK: can you create a new branch of the one you were merging into
<lifeless> StevenK: and then repeat the merge from the one you were merging from
<lifeless> StevenK: (I want to eliminate the chance of local edits causing issues)
<StevenK> lifeless: There were no local edits, same behavior from a fresh branch
<lifeless> StevenK: ok, please file a bug
<lifeless> StevenK: 'adding files' could be clearer I guess, but something is almost certainly wrong if two well formed branches can't merge in that manner without the error about being unversioned
<StevenK> lifeless: I suspect the branches haven't seen each other before, but bzr should be able to merge them
<lifeless> StevenK: if they don't have a common parent it would error
<StevenK> Can I teach it the common parent? I don't see why it's adding files, either, file lists are the same.
<lifeless> StevenK: if they have a common parent, then they've seen each other before :). directories added to both sides should (and appear to have) cause a simple conflict - the 'Conflict because libmokoui is not versioned, but has versioned children.  Versioned directory.' is what is spurious and seems to have propogated
<lifeless> StevenK: does it say 'branches have no common parent cannot merge' ?
<lifeless> StevenK: or words to that effect?
<StevenK> Branches have no common ancestor, and no merge base revision was specified.
<StevenK> I suspect I "branched" this using cp
<lifeless> StevenK: ok. that says bzr thinks these are entirely separate projects.
<lifeless> StevenK: using 'cp' is fine, unless you then bzr init and add and give everything brand new identity
<StevenK> I may well have done that, I'm not certain.
<lifeless> StevenK: so. you know bzr has an inode concept right? files and directories have identity separate from path.
<lifeless> StevenK: 'bzr add' assigns identity to a file/directory
<lifeless> StevenK: bzr merge when two files/directories share a path but don't share identity -> conflict
<StevenK> Hm. Drat.
<lifeless> StevenK: so, every file that is in common between these two separate projects will conflict. This is appropriate - consider two separate projects with different COPYING contents.
<lifeless> StevenK: or even the same, but then one changes its mind; we shouldn't consider them to be the same file.
<lifeless> StevenK: there is a genuine bug here - the 'Conflict because libmokoui is not versioned, but has versioned children.  Versioned directory.' error is spurious AFAICT
<lifeless> StevenK: but you've also, almost certainly, made your life harder by doing 'bzr init' rather than 'bzr branch' at some point in the past.
<StevenK> Can I fix that?
<lifeless> StevenK: in some senses yes. Essentially, for every common path you need to pick one file id and choose it. That file id will keep its history, the other will show up as deleted at this point
<lifeless> StevenK: if there is an upstream/downstream relationship here, you should take the upstreams file ids.
<StevenK> lifeless: Okay, so how I pick/change the file ids?
<lifeless> StevenK: bzr st *should* show you foo and foo.moved for every conflicting path
<lifeless> StevenK: before we go further, can you file a bug with:
<lifeless> the two branches
<lifeless> the output of 'bzr version-info' in each branch
<lifeless> and the output of the merge; I'll clean it up into an actual bug report on the thing I think is going wrong
<StevenK> lifeless: Submitted, bug 244115
<ubottu> Launchpad bug 244115 in bzr "merge between two branches fails" [Undecided,New] https://launchpad.net/bugs/244115
<lifeless> StevenK: thanks
<lifeless> StevenK: so
<lifeless> StevenK: in your tree right after the merge
<lifeless> StevenK: if you do 'bzr diff -r branch:THINGYOUMERGEDFROM'
<lifeless> StevenK: we want to keep adjusting your working tree until that diff looks reasonable
<lifeless> StevenK: with no delete+add pairs etc
<lifeless> StevenK: (assuming the branch you merged from is your 'upstream'.)
<lifeless> StevenK: if you are the upstream, we'll use 'bzr diff' to do this test
<lifeless> StevenK: ping me when you are back
<StevenK> lifeless: I'm back
<StevenK> lifeless: I've adjusted the working tree so that the diff looks good already
<lifeless> StevenK: right, so does the above make sense?
<lifeless> StevenK: against -r branch:, or your local branch?
<StevenK> Local
<lifeless> StevenK: and which branch has more history ?
<StevenK> % bzr di -r branch:../trunk | diffstat | tail -n 1
<StevenK>  40 files changed, 5141 insertions(+), 4244 deletions(-)
<StevenK> Ah ha
<StevenK> lifeless: trunk
<StevenK> lifeless: The only changes in the ubuntu branch are under debian/
<lifeless> StevenK: try bzr st -r branch:../trunk
<StevenK> (trunk has no debian/)
<StevenK> lifeless: It has two headings: removed: and added: and both list every file
<lifeless> StevenK: right, you've resolve in the wrong direction :)
<lifeless> StevenK: can I ask, as you trying to do 'uupdate via merge' ?
<StevenK> lifeless: Basically, yes
<lifeless> StevenK: so, this is why james_w is working on mass conversions and history joining
<lifeless> StevenK: lets get you unblocked - bzr diff -r x..y ../trunk | bzr patch, is likely better
<StevenK> x..y being what?
<StevenK> Revision numbers, of course, but which?
<lifeless> StevenK: well whatever you passed the merge command to make it do something
<StevenK> lifeless: I essentially have that on my local branch as it is
<lifeless> StevenK: does 'st' show a pending merge ?
<StevenK> bzr: ERROR: Revision {('vcs-imports@canonical.com-20080410144539-rrh49m2mt78576ft',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x11ba350>".
<lifeless> StevenK: I'd bzr revert and do 'bzr diff -r x..y ../trunk | bzr patch' TBH
<StevenK> lifeless: I did
<lifeless> StevenK: merging across separate imports is not easy
<lifeless> StevenK: if you reverted, then you shouldn't be getting an error
<StevenK> lifeless: It was a new branch
<lifeless> StevenK: what was it
<StevenK> lifeless: Sorry?
<lifeless> StevenK: I have no idea what you're talking about anymore, read up and imagine you have only what you've told me to work off :)
<StevenK> lifeless: Okay, so I started with a fresh branch using 'bzr branch', and then ran 'bzr di ... | bzr patch'. 'bzr st -r branch:../trunk' gave that error I pasted above.
<lifeless> StevenK: ok.
<lifeless> StevenK: just 'bzr st'
<lifeless> no -r here, because we're not trying to produce a related branch
<StevenK> Two files modified
<StevenK> Which are the two files changed
<lifeless> StevenK: any pending merges ?
<StevenK> Nope.
<lifeless> StevenK: commit and move on :)
<StevenK> lifeless: But when trunk moves on, I can't just merge, I'll have this pain again?
<lifeless> StevenK: yes.
<StevenK> Can I make the pain stop? :-)
<lifeless> StevenK: yes, build from upstream rather than having an unrelated branch
<lifeless> 'bzr branch upstream; do stuff'
<mwhudson> beuno: are you here/awake ?
<StevenK> lifeless: Well, actually, if I could smush the two branches together, it would be ideal. ubuntu for everything under debian/ and trunk for everything else.
<lifeless> StevenK: so
<lifeless> StevenK: I described above what you need to do to sync up correctly
<lifeless> StevenK: but we have to do this on 13K branches, doing it adhoc is really not that useful - james_w will be doing toolchain support for this
<StevenK> lifeless: I've done bzr branch upstream, I'm just not sure what I can do to get the files from the existing ubuntu branch into the new one while preserving history
<lifeless> StevenK: bzr merge -r 0..-1 ../ubuntu/debian
<lifeless> StevenK: you did say that no changes were outside ./debian right ?
<StevenK> lifeless: Right
<StevenK> lifeless: -1 == HEAD isn't so intituive, either
<lifeless> StevenK: -0 is hard to represent
<StevenK> lifeless: The code can't have a constant set for HEAD?
<lifeless> probably can :)
<StevenK> Even if HEAD is a CVS-ism
<StevenK> Grumble. bzr log doesn't show history
<lifeless> StevenK: have you committed the merge?
<StevenK> lifeless: Yes.
<lifeless> StevenK: then it should
<StevenK> lifeless: bzr merge .... ; bzr ci -m "<msg>"
<lifeless> StevenK: bzr log --show-ids -r -1
<lifeless> StevenK: does it have one or two parents?
<StevenK> lifeless: It has one parent
<lifeless> StevenK: so, let me introduce you to 'bzr st'
<lifeless> its a great way of seeing what a commit will do
<lifeless> :)
<StevenK> lifeless: uncommit and then st shows added files, not a pending merge
<lifeless> StevenK: of course; do a revert
<lifeless> StevenK: then the merge again and see if st shows a pending merge
<StevenK> lifeless: No, just added files
<lifeless> abentley: is there some other way to join separate imports than 'merge -r 0..-1'? its not adding a pending parent for StevenK .
<abentley> lifeless: I can't think of one.
<lifeless> abentley: I am sure it used to, I think this is a merge regression - do you agree?
<abentley> lifeless: Also, the only reason it wouldn't add a pending parent is if one had already been set.
<abentley> ie the merge had been done in the past.
<lifeless> abentley: in that case though, merge wouldn't need a -r at all ;)
<lifeless> abentley: I think its still considering it a cherry pick
<abentley> in that case, the merge should be a no-op.
<abentley> My code certainly didn't do that.
<lifeless> abentley: yah, like I say I think its a regression
<abentley> I tried a merge -r 0..-1 and it behaved as expected.
<lifeless> abentley: oh, no I know
<lifeless> abentley: I know whats going on and why :)
<abentley> Was a file specified in the merge?
<lifeless> StevenK: ok, heres what to do
<lifeless> abentley: yes
<lifeless> StevenK: revert / uncommit etc until you have whats in trunk
<lifeless> StevenK: then:
<lifeless> bzr merge -r 0..-1 ../ubuntu; bzr revert . ; bzr merge -r 0..-1 ../ubuntu/debian; bzr st
<abentley> lifeless: There is "join", of course.  That's less general than you asked about.
<StevenK> Okay, bzr st now shows a pending merge, but there was a bunch of errors from the other 3 commands.
<lifeless> StevenK: thats ok
<abentley> lifeless: also the merge-into plugin.
<StevenK> And that's impressively counter-initutive :-)
<lifeless> StevenK: it should ahve your ubuntu files etc; and you can just commit now
<lifeless> abentley: yes, doing join and deleting and rearranging is probably the preferred ui
<StevenK> I wonder if I can remove the 'submit' branch shown in bzr info
<lifeless> StevenK: like I say, you're doing something that there is not much toolchain support for yet, and you can only do because you have the special case of no overlapping files
<StevenK> Ah. We're trying to outsmart bzr a little too, I suspect?
 * StevenK blinks. The merge works, but debian/ doesn't exist?
<lifeless> StevenK: its not listed in 'bzr st' ?
<StevenK> bzr st doesn't show anything. I've commited.
<lifeless> StevenK: log -v -r -1 ?
<StevenK> It shows the merge, and it that it added every file
<StevenK> s/and it/and/
<lifeless> StevenK: 'every file'?
<StevenK> lifeless: Well, added every file, such as AUTHORS, NEWS, README, etc
<StevenK> lifeless: I can pastebin the output, if you wish?
<lifeless> StevenK: sure
<StevenK> lifeless: http://paste.ubuntu.com/23876/
<lifeless> StevenK: looks fine to me
<lifeless> StevenK: lines 16 through 18
<lifeless> StevenK: etc
<lifeless> StevenK: what about 'bzr st -r -2..-1' ?
<StevenK> lifeless: No output
<lifeless> StevenK: ok, I think the last merge didn't quite do what we wanted
<lifeless> StevenK: uncommit :)
<lifeless> StevenK: repeat the 15:11 < lifeless> bzr merge -r 0..-1 ../ubuntu; bzr revert . ; bzr merge -r 0..-1 ../ubuntu/debian; bzr st
<lifeless> step
<lifeless> and make sure debian is present and everything ok before you commit
<StevenK> lifeless: bzr st still shows a pending merge
<lifeless> revert too
<StevenK> lifeless: Or revert and redo?
<StevenK> Done. And:
<StevenK> ls: cannot access debian: No such file or directory
<lifeless> uhm
<lifeless> bzr st
<lifeless> does it list debian etc?
<StevenK> It just shows a pending merge
<StevenK> % bzr st
<StevenK> pending merges:
<StevenK>   Steve Kowalik 2008-04-19 Add missing X[BS]-Python-Version fields.
<StevenK> ...
<lifeless> bzr merge -r 0..-1 ../ubuntu/debian --force ; bzr st
<StevenK> bzr: ERROR: Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x1349e10>".
<lifeless> argh
<lifeless> bzr revert
<StevenK> Okay
<lifeless> bzr branch ../ubuntu ./tempdir
<lifeless> bzr join tempdir
<lifeless> bzr mv tempdir/debian debian
<lifeless> bzr rm --remove tempdir
<lifeless> bzr st
<StevenK> bzr: ERROR: Can't join trees because KnitPackRepository('file:///home/steven/canonical/moko/libmokoui2/ubuntu/.bzr/repository/') doesn't support rich root data.
<StevenK> You can use bzr upgrade on the repository.
<lifeless> ugh
<lifeless> StevenK: that Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x1349e10>" is a bug
<lifeless> StevenK: what version of bzr do you have?
<StevenK> Woo, another one
<StevenK> lifeless: 1.4
<lifeless> StevenK: try 1.5
<lifeless> bzr merge -r 0..-1 ../ubuntu; bzr revert . ; bzr merge -r 0..-1 ../ubuntu/debian --force ; bzr st
<StevenK> Try that with 1.5?
<lifeless> yes
 * StevenK digs for the bzr PPA
<StevenK> lifeless: 1.5 still gives bzr: ERROR: Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xf979d0>".
<lifeless> StevenK: ok, file a bug I guess
<lifeless> or try 1.3
<StevenK> lifeless: 1.3.1 gives the same error
<lifeless> bleep
<lifeless> bugger a file for sure
<StevenK> lifeless: Not sure what the bug is. :-)
<lifeless> getting that error
<Suigintou> "My husband comes from a family where the men are always in charge. He was very nice to me when we were dating and after we got married he changed like he thinks he is my master. I feel like a slave sometimes and if I don't do what I am supposed to he yells and curses at me and he even spanks me. He doesnt usually hit me too bad but I am thinking that if we have a baby maybe he would be nicer with a child in the house. What do you peo
<Suigintou> ple think I should do."
<Suigintou> lol, stupid women
<lifeless> Suigintou: thats really not on topic for this channel
<lifeless> Suigintou: not to mention being offensive
<lifeless> mbp_: I have some initial figures on the B+Tree index approach
<lifeless> mbp_: looks like 2 IO's for up to 250K keys
<lifeless> mbp_: and 3 for up to 125M keys
<Suigintou> wrong channel, in fact, wrong network altogether, really sorry
 * igc dinner
<gour> hi, how is bzr with handling (bigger) binary files, e.g. movies
<gour> i tried to add (by mistake) some rendered files (*.ac3, +.m2v, *.mpg) where *.mpg is ~220MB and darcs was on knees using 1GB of memory + 1GB of swap :-/
<gour> it's my old video-project and i'll definitely migrate it from darcs
<beuno> gour, yeah, not so good. It uses about 3x the amount of memory of the file's size
<beuno> if you hace enough ram, you can pull it off, but, in general, it's probably not the best idea
<gour> bzr?
<beuno> yeah, bzr
<lifeless> gour: its improvable
<lifeless> gour: and sounds like better than darcs :)
<gour> hmm, 3x is till better than 2GBs for ~220MB file
<gour> *still
<gour> hopefully, it does not try to keep them all at once in memory
<gour> lifeless: good. let me burn & print DVD first, then i'll check how bzr does
<beuno> lifeless, what's improvable?
<gour> during that attempt my machine become totally non-responsible :-/
<lifeless> beuno: memory use
<beuno> lifeless, the estimate is still 3x the file's size though, right?
<gour> it's not very common use, but when doing video-editing it might be useful to be able to store files
<lifeless> beuno: we can do better
<lifeless> beuno: we don't today, but we can
<beuno> lifeless, right, that reminds me of some bug where the user asked if we could warn them before adding a file that would probably run out of memory while committing. Is that too difficult to do today?
<lifeless> beuno: its tricky
<lifeless> beuno: some people have 8GB RAM
<lifeless> beuno: some ave 8GB VM and 2GB ram
<lifeless> beuno: at what point is 'out of memory' is it thrashing? is it hitting swap? etc
<lifeless> using a non refcounting python would help too
<beuno> hm, yeah, may be worth working on the actual problem then
 * gour has 1GB only :-(
<beuno> gour, well, 1GB should be enough for 220mb files
<gour> darcs used 1GB + 1GB swap to add 15M + 180M + 222M
<gour> and machine was down
 * gour --> copy-shop to print DVD cover. bbl
<ToyKeeper> gour: For large files like that, you might find rsnapshot more appropriate...  at least, if you just want to be able to retrieve old versions.
<ToyKeeper> Or, perhaps rdiff-backup, if you make small changes to big files (like changing the ID3 tag in a mp3)...  could be more space-efficient.
<gour> ToyKeeper: well, when i work with cinelerra i keep its project (xml) files and some graphic files under vcs, so it was mistake to add those rendered files and interesting (darcs) result. now, when i finish with burning, i'll check how will bzr react
<mkanat> ERROR: Repository KnitPackRepository('file:///home/mkanat/projects/mw/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://control.trusthosting.net/var/www/html/everythingsolved.com/bzr/mingleware/.bzr/) ?
<mkanat> Is that telling me that I can't use bzr+ssh with a rich-root-pack repo??
<lifeless> mkanat: its telling you that one of repositories is rich root and one isn't
<lifeless> mkanat: really shoukld make the error clearer
<mkanat> lifeless: Hmm, I thought I made them both rich-root.
<mkanat> lifeless: They're both rich-root-pack, I just checked.
<mkanat> lifeless: At least, that's what .bzr/repository/format says.
<mkanat> What's the difference between .bzr/branch-format and .bzr/branch/format ?
<mkanat> Hmm, guess I need a newer bzr on the server side, that's my guess.
<lifeless> mkanat: possibly; what version is it?
<mkanat> It's 1.3 on the server, 1.5 on the client.
<lifeless> .bzr/branch-format is the control dir format
<mkanat> Ah, okay.
<lifeless> (before 0.8 we didn't have split out repository/branch/checkout objects)
<lifeless> so its named whackily, but backwards compatible
<mkanat> Ahh. :-)
<mkanat> Hmm, upgrading the server didn't help.
<mkanat> sftp checkout works fine, bzr+ssh doesn't.
<lifeless> mkanat: file a bug please
<mkanat> lifeless: Okay, will do.
<mkanat> Ah, it's already filed as bug 205579.
<ubottu> Launchpad bug 205579 in bzr "bzr checkout doesn't work with rich-root-pack" [High,Confirmed] https://launchpad.net/bugs/205579
<lifeless> mkanat: you sure its the same?
<mkanat> lifeless: Yep, identical problem.
<Pilky> I dunno if there are any other Xcoders in here but if there are then this may interest you: http://www.mcubedsw.com/blog/index.php?/site/comments/build_numbers_from_bazaar/
<jelmer> Pilky, nice
<Tsmith> after a branch merge, do you just delete the branch?
<beuno> Tsmith, a little more information may be needed to answer that question  :)
<beuno> you where working in a branch separate from the mainline
<beuno> and you merged that into, let's say trunk?
<guilhembi> abentley: hi! I wrote several posts on support issue 00002413
<abentley> guilhembi: Hi there.  I saw them.
<guilhembi> abentley: even the latest one?
<abentley> "I missed your comment?"
<abentley> I did see that.
<guilhembi> abentley: ok, thanks
<abentley> Right now, I'm looking into this tests directory conflict.
<guilhembi> abentley: uber-great!
<guilhembi> abentley: mysterious how mysys/tests/Makefile.am wasn't imported...
<abentley> If mysys/tests *was* deleted, possibly Makefile.am was deleted at the same time.  But I can't say whether that happened yet.
<guilhembi> abentley: and I don't know either if it was deleted. Looking for creation history when the file exists, is easy, but for deletion history when it's missing, is not, and it's not specific to bzr.
<abentley> Yeah.  I can do it, it'll just take a bit.
<guilhembi> abentley: after doing some grep somewhere, it looks like it was never deleted and never existed in 6.0-ndb
<abentley> So far, I've determined that the file was created in mysql-5.1-telco-6.2-merge revno 2555.13.2
<guilhembi> abentley: is that the same as sp1r-mtaylor@solace.(none)-20080425063223-04764 ?
<abentley> guilhembi: Yes.
<abentley> guilhembi: So it looks like my results match yours; 'tomas.ulin@sun.com-20080619094326-n15bh5klhd3yt83j' is not a descendant of 'ï»¿sp1r-mtaylor@solace.(none)-20080425063223-04764'
<guilhembi> abentley: uh, did I say that...
<abentley> Therefore the first didn't delete the directory created by the second.
<abentley> It doesn't have the directory because it never had the opportunity to get it.
<guilhembi> that I agree
<abentley> So now I have to find out why bzr thought it did.
<gour> heh, finally i found time to test how bzr handles binary files...i tried to add the same 3 binaries which put darcs on the knees (15M, 180M and 222M) and bzr handled them OK
<gour> sure, there is room for improvement for the memory usage, but it was workable, while with darcs my machine almost stopped responding using all of 1GB RAM as well as 1GB of swap
<NfNitLoop> so I'm doing a "push" to a remote (windows) filesystem.
<NfNitLoop> slooow. :p
<NfNitLoop> (The connection is just slow & laggy)
<NfNitLoop> I imagine a pull would go much more quickly...  but I'm not sure if I have rights to install bzr on that end.  >.<
<bpeterson> can I "clean out" a shared repo? can I get rid of the revision stored there that no longer have branches?
<jam> bpeterson: I believe there is a plugin for it (bzr-remove-revisions), but there isn't a core garbage collection command
<bpeterson> what does bzr pack do?
<jam> bpeterson: combines small packs into larger ones
<bpeterson> oh
<bpeterson> thanks
<bpeterson> are there plans to add some garbage collection type thing?
<jam> abentley: ping, a question on the _merge_names logic
<abentley> jam: pong
<jam> abentley: you have this logic:
<jam>         if this_name is None:
<jam>             if name_winner == "this":
<jam>                 name_winner = "other"
<jam>             if parent_id_winner == "this":
<jam>                 parent_id_winner = "other"
<jam> Which seems to say "if this wants to delete the file, switch and consider "other" to introduce it
<jam> Am I understanding that correctly?
<abentley> jam: If you have a conflict, and so you need a name for it, and there's no name in THIS, use the name in OTHER.
<jam> abentley: and if you don't have a conflict?
<jam> It only does something if the _merge_contents happens?
<jam> Is this just reserving a potential name?
<abentley> I believe that the name isn't used if there is no conflict.  I would have to double-check, though.
<jam> abentley: ok, it made it a bit harder to debug what was going on.. but if it is just reserving the name, it doesn't seem to be a problem
<jam> It uses "if changed: self._merge_contents()" and in this case changed == False
<abentley> jam: I believe this is the case that handles directory deleted in X, directory has files added in Y, merge X and Y.
<jam> sure
<abentley> It adjusts the path associated with the file, but is silent about whether anything is present at that location.
<jam> abentley: sure, it seems my lca_multi_way logic is giving the right result
<jam> but at a higher level I'm setting "changed=True" because the file is different versus *one* of the basse
<jam> bases
<jam> so it is picking OTHER for the filename, and then conflicting because of the other work
<jam> oh well, at least the multi-way logic is correct :)
<abentley> Ah well.
<abentley> jam: In other news, it seems that VersionedFile is dead, dead, dead in bzr.dev.
<jam> VersionedFiles is dead, long live the VersionedFiles
<jam> VersionedFile is dead, long live the VersionedFiles
<jam> I guess that works better :)
<abentley> So we don't need to hoist get_line_list into it.
<abentley> But iter_files_bytes looks to be efficiently implemented.
<jam> So does it have an "add_bytes" method then?
<abentley> No, just add_lines.
<abentley> PlanMergeVersionedFile is still a VersionedFile, though.
<abentley> We should probably fix that.
<jam> abentley: actually, when I look closer, it doesn't look like it is done efficiently across multiple versions
<Odd_Bloke> jelmer: I notice you've updated a few of your PQM branches recently.  Are those things I should be interested in?
<jam> abentley: it seems to extract the deltas needed efficiently
<jam> but then it does
<jam> record.get_bytes_as('fulltext')
<jam> for *each* record
<jam> And Knits seem to do
<jam>         if storage_kind == 'fulltext' and self._knit is not None:
<jam>             return self._knit.get_text(self.key[0])
<jam> unless the get_record_stream is smarter than I thought
<jam> still looking
<Odd_Bloke> thumper: You seem to have some relatively recent unmerged branches too, should I be interested in those?
 * Odd_Bloke notes that he will bug by email if he hasn't received a response by this evening (BST).
<abentley> Odd_Bloke: thumper has submitted at least some of those to lifeless for review.
<jam> abentley: it looks like if you pass "include_delta_closure" it then expands all the requested texts into fulltexts
<Odd_Bloke> abentley: Thanks, that's helpful to know. :)
<jam> abentley: so it looks like it might, indeed, be done properly, but man the layering makes it difficult to see
<jam> I suppose any time you pass "include_delta_closure" actually means that you always want fulltexts?
<abentley> Odd_Bloke: https://code.edge.launchpad.net/~lifeless/pqm/trunk (see list of proposed merges)
<Odd_Bloke> abentley: Cool, thanks.
<abentley> I have no idea what include_delta_closure would mean.
<Odd_Bloke> Pretty cool to see LP being used for this sort of stuff.
<jam> abentley: well it is get_record_stream(keys, ordering, include_delta_closure)
<jam> It seems to me that 'include_dellta_closure' would be a flag to include the deltas necessary to build everything into the record stream
<jam> but not necessarily unpack them into fulltexts
<abentley> jam: That's how I read the comment.
<abentley> or docstring, rather
<jam> abentley: yeah, but it seems all callers mean "give me fulltexts" and use it as such ...
<jam> fetch() passes False, callers that want fulltexts pass True
<jam> I'm guessing this is a case where Robert started thinking one way
<jam> ended up a different way
<jam> and didn't update all the places inbetween
<abentley> jam: Yeah.
<abentley> It seems he could trivially have done LinesContentFactory, and avoided the memory bloat.
<jam> except the trivial implementation would have to apply all the deltas for each fulltext
<jam> getting one which does the minimum amount of work before each request would be possible
<jam> but non-trivial to write
<jam> certainly it seems that the api would work with that situation, though.
<abentley> He's already calling get_content_maps, which ought to be efficiently returning lines.
<abentley> And it looks like he doesn't expect anyone to hold on to a ContentFactory, in which case there's no memory wasteage.
<abentley> jam: It looks like PlanMergeVersionedFile has become a VersionedFiles, so get_line_lists should probably hang off _PlanMerge.
<jam> Well... we could also just use get_record_stream() directly, since it seems to be on all VersionedFiles, record.get_bytes_as('fulltext') will return the lines.
<jam> At least, as I understand the structuring.
<abentley> jam: actually PlanMerge has get_lines, which returns lines for list of versions.
<abentley> So there's already a friendly multi-get method.
<jam> so... the 'get_lines()' api changed...
<jam> oh, I guess this is on PlanMerge
<jam> nm
<jelmer> Odd_Bloke, hi
<jelmer> Odd_Bloke, possibly - one replaces automake with setup.py
<jelmer> the other uses a python module for gpg signature verification rather than invoking gpgv directly
<jelmer> (the latter was causing breakage on my machine)
<NfNitLoop> "breakage"?
<abentley> jam: I posted the merge-delete-and-change tests to the list.
<abentley> jam: I don't really understand the remaining test you wanted.
<jam> The one for "ha_ndbcluster.cc"
<jam> abentley: The idea is to have a merge which cannot be solved by the first LCA analysis
<jam> nor by using just unique_lca + first lcas
<abentley> This is a text merge?
<jelmer> abentley, Is there any reason creating a merge directive requires write access to the repository?
<abentley> jelmer: Yes.  It fetches the head revision of the submit branch into the local branch.
<jelmer> abentley: Ah, that makes sense. Thanks!
<jelmer> Related to this..
<jelmer> Is there any easy way to upgrade read locks to write locks?
<abentley> jelmer: Only if you control the whole call stack.  If you might want a write lock, take a write lock.
<Odd_Bloke> jelmer: Is there any specific reason that the distutils one hasn't been merged, or has it just not been reviewed yet?  That'd make my life easier, because I just don't understand autotools.
<jelmer> abentley: hmm, ok
<Odd_Bloke> It would also reduce the number of files that are created in the root of the branch.
<abentley> jam: One thing I forgot to mention; the problem with using a non-unique LCA during criss-cross is that disputed resolutions get silently resolved in favour of one side.  But this is what MySQL wants, no?
<abentley> jam: I haven't been able to concoct a merge scenario for the last test.
<mwhudson> beuno: hello
<beuno> morning mwhudson!
<jam> abentley: I'm happy to have a test with "weave" that asserts that is what it does. I can't say for sure what they would prefer, as at this point we have bad graphs all over the place messing things up :)
<mwhudson> beuno: the new_theme needs a symlink icon
<jam> In *general* they feel like if "bzr gannotate" shows the line as in the history
<jam> they shouldn't be bothered by a conflict
<jam> and the criss-cross different resolutions is something that you can't detect
<jam> using gannotate
<mwhudson> beuno: i tried to say this in email yesterdary but sent it to poolie instead :)
<jam> So I think it is more of "If you can't answer 'why is this conflicted', don't show me a conflict".
<beuno> mwhudson, it should have one, I may of forgot to add it
 * beuno checks
<abentley> What is this responding to? "ï»¿I'm happy to have a test with "weave" that asserts that is what it does..."
<jam> abentley: That a mixmatched resolved conflict is silently ignored. You can write an XFail test or just a plain test for that if you want.
<jam> I *can* say that --lca as it is implemented now still conflicts more than --weave, and they are worried about the "silently unclean merge" bug.
<abentley> jam: I was trying to say that we might make them happy by writing a merge3 that uses a non-unique LCA.
<jam> maybe, but --weave does the job too
<mwhudson> beuno: bug #242580 is odd, and worrying
<ubott2> Launchpad bug 242580 in loggerhead "Current trunk tends to peg CPU at 100% after running a while, for no obvious reason" [High,New] https://launchpad.net/bugs/242580
<abentley> jam: --weave is making you do major surgery to the inventory code.  I'm not saying it's the wrong approach.  But I would be remiss in not pointing out the merge3 option.
<lifeless> moin
<beuno> mwhudson, is it related with what's happening in LP?
<mwhudson> beuno: well, hard to say!
<mwhudson> but he's only serving 18 branches
<beuno> mwhudson, yeah. I suppose if this was widespread, the gnome mirror would be on it's knees
<mwhudson> otoh, he does seem to be accessing branches over http
<mwhudson> well, some branches
<mwhudson> the name resolution failures could easily be running out of fds too, i'd guess
<mwhudson> beuno: in any case, i hacked up a branch to help with the LP issues last night, let me push it
<beuno> mwhudson, oh, cool. It closes the branch?
<lifeless> jam: what sort of bad graphs do we have?
<beuno> mornin' lifeless
<jam> abentley: bad paths are making me do it :) And if we picked the wrong lca, we would be in the same position
<mwhudson> beuno: it makes History objects ephemeral
<mwhudson> beuno: and caches the expensive to calculate stuff elsewhere
<jam> remember, we have (path1, None, None) for bases, and path2 for THIS, path1 for OTHER
<jam> So if you pick the None LCA, you get the wrong answer
<jam> if you pick the path1, you get the right answer for *this* file.
<lifeless> whats the None, None there?
<beuno> mwhudson, I'll take a peak at the branch.
<mwhudson> beuno: https://code.edge.launchpad.net/~mwhudson/loggerhead/dont-hold-branches-open
<mwhudson> there's some pretty nasty code in places, but i like the idea
<mwhudson> beuno: have you thought about a prettier file listing at all?
<beuno> mwhudson, this is related to the new theme?  Prettier the what we have now?
<beuno> now == new theme
<mwhudson> beuno: i haven't looked in the new theme...
<mwhudson> beuno: ah sorry, i was vauge
<mwhudson> vague
<mwhudson> beuno: i meant BranchesFromFileSystemServer.directory_listing
<beuno> mwhudson, ah, yes. I tried the other day, but my brain was fried and I was taking too many shortcuts  :)
<jam> lifeless: The 'path' in that base is None, because the file doesn't exist there
<beuno> I have 2 branches half-baked.  Proper setup.py, and template for directory listing
<jam> it was added in one of the LCAs
<mwhudson> beuno: both sound like good things :)
<beuno> mwhudson, for starters, I thought we could use the same that we use to navigate branches/projects, and see what can actually be improved later on
<mwhudson> beuno: mmm
<lifeless> jam: so its (id, revision, path) ?
<mwhudson> beuno: that sounds like it would be difficult because of shortcuts /i/ took in wsgi-ify :)
<jam> lifeless: no it is (path_in_base1, path_in_base2, path_in_base3)
<jam> we have 3 common ancestors
<jam> (least common ancestors)
<beuno> mwhudson, yes, that's what provoked less-then-acceptable hacks, and made me discard it  :P
<jam> if we go all the way back to the unique_lca, the path is None, because it didn't exist yet
<jam> So you see base = None, this = path2, other = path1
<jam> aka, conflict
<lifeless> and they want it to resolve to path2 no conflict?
<jam> For *one* of the LCAs, you can see base = path1, this = path2, other = path1, aka path2 wins
<jam> lifeless: yes, because that is *true* for the file in question
<jam> it is only because we can't see it for the criss-cross throwing off our base selection
<beuno> mwhudson, do you have any specific ideas for that bit?
<jam> if we picked the base from the per-file graph, we would do it "correctly"
<lifeless> jam: does the per file graph help? ok
<mwhudson> beuno: not really, but start from scratch :)
<lifeless> jam: and you've tried taking the per file graph an indexing from there back to the inventory contents?
<jam> lifeless: no, I don't want to have to extract the full inventory for every file
<jam> just to get the path, etc. each time
<mwhudson> beuno: tbh, what i generate already with the standard macros.pt stuff wrapped around it would probably be ok
<lifeless> jam: you don't have to though
<beuno> mwhudson, heh, good, that's what I did.  Those are the two remaining bits I think we need, apart from new theme, to release 1.6
<lifeless> jam: well, to be clear: you don't have to do full upgrading to Inventory to get the path out - from bzrlib.plugins.search.inventory import ids_to_paths
<mwhudson> beuno: i'd like to put a vote in for dont-hold-branches-open :)
<beuno> mwhudson, I can make it look better with the current approach then, generate it through python
<mwhudson> beuno: and see if that fixes mkanat's problem
<beuno> mwhudson, sure, I've got to go home and pick up some stuff, and I'll review/test it
<lifeless> jam: thats reasonably close to being tweakable to process lines through the regex just-in-time
<mwhudson> beuno: it's not really ready yet from a code clarity POV, but testing would certainly be appreciated :)
<lifeless> abentley: can you help me understand bug 244115 ?
<ubott2> Launchpad bug 244115 in bzr "merge between two branches fails" [Undecided,Confirmed] https://launchpad.net/bugs/244115
<jam> lifeless: except it won't work if we change serialization formats, etc. I think I have a reasonable solution using our current apis, that should even perform decently, I just have to implement it.
<jam> I can actually get the path correct using simple lca lookups
<jam> the problem is that the file shows up as "changed" because of the [path, None, None] stuff
<jam> so I need to do the same "is this actually changed" at a higher level
<lifeless> abentley: I don't understand why it sees libmokoui as unversioned
<beuno> mwhudson, I'll try and poke holes in it  :p   and, also, Peng is *really* good a poking holes
<mwhudson> :)
<abentley> lifeless: I don't really have time.  This is a cherrypick into an unrelated tree.  It adds a file to libmokoui, which doesn't exist, because this is an unrelated tree.  It doesn't add libmokoui because this is a cherrypick.
<lifeless> abentley: I'll double check, but I was pretty sure libmokoui existed in both trees
<lifeless> abentley: thanks, I get the cause now; I've commented back in the bug
<jelmer> Odd_Bloke, IIRC lifeless didn't see a good enough reason to switch over from automake
<lifeless> I didn't see the need to recreate all the existing automake support for docbook etc in setup.py and then maintain it
<lifeless> its 'create more work because we like work'
<Odd_Bloke> Yeah, I found the bug a while after asking and forgot to mention it.
<Odd_Bloke> Well, by the looks of it, jelmer has already recreated the existing support in his patch.
<lifeless> Odd_Bloke: its not a one time thing
<lifeless> Odd_Bloke: that is code, it has to be bugfixed and maintained
<jelmer> lifeless: Maintaining python code with automake has the same problems but the other way around
<lifeless> jelmer: I'm happy to chain into setup.y if the automake python support is going to give us grie
<jelmer> (the reason I ended up working on this was because I was looking into debianizing pqm but it was installing into the wrong directory)
<lifeless> f
<lifeless> jelmer: well, like I say, I just don't want the maintenance burden of reinventing automake + autoconf + make and all that dependency checking and correctness in setup.py
<lifeless> If I'm going to maintain a build tool; it will be something clean :)
<jelmer> heh
<lifeless> jelmer: so if you want to migrate the bits that are problematic for debian to a setup.py file, and have ./configure && make chain through to that - thats ok and I'll review and merge.
<jelmer> lifeless: the docbook stuff is the only bits that should remain in the end
<mwhudson> at least libtool isn't involved
<lifeless> mwhudson: well yes
<jelmer> lifeless, That still keeps the heavy dependency on automake and just complicates things by using more build systems
<jelmer> lifeless: My patch replaced 143 lines of automake+autogen with 162 lines of setup.py
<lifeless> jelmer: and it was correct? or does it build doco every run unconditionally etc etc?
<lifeless> jelmer: I think we're just not connecting here -
<jelmer> lifeless: yes, it is - even if it wasn't, that's a different issue
<jelmer> lifeless: sorry, I do indeed still don't see your point
<lifeless> jelmer: so my issue is about having a NIH build tool for docbook in pqm; I think its wrong
<lifeless> jelmer: I don't think that code belongs in the pqm tree
<jelmer> lifeless: it's not a NIH build tool - it's just a distutils wrapper that calls xmlto
<lifeless> I'll have to recheck the patch then
<jelmer> Should I sent an updated bundle to the list, ccing you?
<jelmer> I've just resolved some conflicts after merging trunk
<lifeless> jelmer: to the patch, sure
<mbp_> good morning
<jam> mbp_: good morning, didn't we a have a call today? (and what have you done with poolie? :)
<mbp_> hm
<mbp_> silly irssi
<mbp_> jam, i think we talked last week so i had it down for next weex
<jam> poolie: well, my gcal shows it as this monday, but we did have a separate call last week
<jam> I'm happy to bump it if you prefer
<poolie> i'm away next tuesday so how about if we talk either monday or wednesday
<jam> wed is good
<jelmer> lifeless, sent
<jam> poolie: hopefully the google calendar invite made it through properly
<jam> but that puts the next meeting as Tues July 8th US, Wed July 9th AU time
<jam> And for now, the next is Mon, Jul 20th / Tues Jul 21st.
<poolie> um
<poolie> do you mean the 21st/22nd?
<poolie> " Cross your fingers and try again in a few minutes, or talk to the person who set up this event." :-)
<poolie> i have it on paper anyhow
<lifeless> jelmer: to the bug?
<jelmer> lifeless, no, to the list
<lifeless> jelmer: could you please send attach it to the bug?
<jelmer> k
<lifeless> thanks
#bzr 2008-07-01
<igc> morning
<jml> with loom up-thread conflicts, do the *.THIS files refer to the lower of the two threads?
<lifeless> jml: IIRC, yes. Its switched because we use symmetry to make the operation faster
<jml> lifeless: ahh ok. how hard would it be to make them .UPPER and .LOWER, for example?
<lifeless> jml: patches appreciated
<lifeless> jml: (I don't know)
<jml> or .<thread-name>, I guess.
 * igc breakfast
<lifeless> poolie: ping
<lifeless> http://bundlebuggy.aaronbentley.com/request/<1214359843.1536.41.camel@lifeless-64> <- I'm blocked on that; igc has commented but neither as tweak or resubmit
<thumper> I use a shared repo with no trees
<thumper> and use cbranch most of the time
<thumper> however now I need to make a new checkout of someone else's branch
<thumper> and I want to use --hardlink
<thumper> what's the magic?
<lifeless> EPARSE
<thumper> checkout --lightweight --hardlink ??? <branch location>
<thumper> lifeless: did the last bit help?
<lifeless> thumper: is branch location on your local disk ?
<thumper> yes
<lifeless> uhm. I don't know that co --lightweight knows about hardlink
<thumper> but the branch has no working tree
<thumper> hm, ok
<lifeless> then there is no point
<thumper> I'll just use the lightweight
<lifeless> can't hardlink to files that don't exist
<lifeless> thumper: hardlink is only relevant for working trees, it doesn't hardlink history
<thumper> I was hoping that there would be some magic where it could link to trunk if it knew the file was unchanged
<lifeless> thumper: uhm
<thumper> I have a working tree of trunk
<lifeless> thumper: cp -al trunk foo; cd foo; bzr switch otherbranchname
<thumper> bzr col it is (another alias :-)
<thumper> ETOOMANYCMDS
<igc> lifeless: I'm just wrapping up that review now.
<lifeless> igc: thanks
<igc> lifeless: there were some questions buried in my comments. Can you reply to those please?
<lifeless> sure
<poolie> lifeless: pong
<lifeless> igc: done
<lifeless> poolie: nvm, igc is here today :)
<nandersson> What is the easiest way to see if plugin bzr-xmloutput is installed or not? Can I try something from the command line? bzr + ???
<Odd_Bloke> nandersson: bzr plugins
<nandersson> Odd_Bloke, Thanks! I see bzr_xmloutput in the list!
<Odd_Bloke> nandersson: No worries.
<poolie> lifeless: he'll be away in the afternoon but i'm trying to do reviews today
<nandersson> Am I able to checkout a bzr branch in Eclipse into my project? It seems that feature is not implemented
<nandersson> I'm using BzrEclipse that is
<lifeless> nandersson: you can, but its a bit weird, because of eclipse's project concept
<lifeless> beuno: do you know the trick?
<nandersson> lifeless, No, what's the trick?
<poolie> just what is the limit on transferring revisions between rich root and other repositories?
<nandersson> lifeless, I do it from the command line from within the project folder?
<poolie> (referring to Marius's mail)
<poolie> does it depend on the revision or is it blocked altogether?
<lifeless> poolie: subtrees -> rich root is blocked on subtrees being used I think; rich root->plain is full blocked
<lifeless> poolie: because we can't tell 'made here' from 'converted'
<nandersson> In Eclipse I select "New Project" - "Bazaar" - "Branch as a new Project". In the next dialog I choose "Use existing branch location" but then the "next" button is greyed out and I can't go further. Is it a bug? Using Eclipse 3.4 and most recent BzrEclipse.
<nandersson> Hrmm.... seems it work if I use "New branch"... *investigating*
<igc> lifeless: That review is complete now - I've voted tweak fyi. The email should come through soon.
<lifeless> igc: thanks very much
<jelmer> spiv, Thanks for that memory analysis
<spiv> jelmer: not a problem.  I just wish I had a clear idea of what we can do about it...
<jelmer> spiv: not just because of the bzr push analysis but also because it explains Python memory usage analysis a bit
 * spiv nods
<spiv> Yeah, I learned a bit while doing it.
<spiv> I'd like to be able to introspect CPython's memory management a bit more
<spiv> It shouldn't be hard conceptually for CPython to tell me about all the arenas its allocated and what their stats are.
<mwhudson> heh, the coloured diffs plugin for tbird does extremely strange things to that mail
<spiv> mwhudson: heh.
<mwhudson> spiv: have you trying compiling python --without-pymalloc ?
<spiv> mwhudson: I haven't, and I don't want to :)
<spiv> I think that is where I'm headed, though.
<mwhudson> why not, it shouldn't be hard
<spiv> (But not today, I have other things to do as well...)
<spiv> Admittedly the last time I compiled Python was around 1.5.2.  It's probably a little less icky than it was then.
<spiv> But I don't really fancy tracking down random C extensions and things.
<Peng> It's easy to compile it. The only problem is if you don't have all of its build deps installed, it'll lack readline, or bz2, etc.
<mwhudson> spiv: it _really_ isn't hard
<spiv> I'll probably be compiling it myself soon anyway, because I want to play with 2.6
<spiv> Anyway, why do you suggest --without-pymalloc?  To see if the fragementation is better/worse?
<mwhudson> yes
<lifeless> spiv- apt-get source
<lifeless> spiv: apt-get build-dep
<spiv> lifeless: yep
<spiv> mwhudson: Hmm, I'm not sure how that would help me, really
<lifeless> spiv: it would let us file bugs
<lifeless> :P
<mwhudson> spiv: it would be data
<spiv> I see.
<spiv> Well, I have data. :P
<mwhudson> spiv: i don't know that it would help with finding a solution necessarily
 * spiv nods
 * lifeless speeds up on the b+tree index
<meuserj> Is there any way to have a remote repository which you CAN update the working files by pushing (or similar) to it?  I have a project I need to work on which I don't have shell access and would like to be able to push to it to update it.
<meuserj> well, repository is the wrong term.. branch I guess
<Verterok> meuserj: maybe the bzr-upload plugin might be useful
<meuserj> Verterok: ah, that looks perfect, thanks.
<meuserj> quit
<Verterok> bye meuserj
<lifeless> poolie: ping
<lifeless> (Pdb) print original_size
<lifeless> 5308576
<lifeless> (Pdb) print len(contents)
<lifeless> 2564096
<poolie> pong
<beuno> mwhudson, poking at your dont-hold-branches branch now, while I pack
<mwhudson> beuno: cool, i'm still working on it a bit
<beuno> mwhudson, haven't looked into bzr.lru_cache, but does that cache automagically?
<mwhudson> beuno: it's like a dict
<mwhudson> that throws items out when it reaches a certain size
<beuno> well, code looks good, and from the looks of it, this should reduce RAM consumption a bit. Let's give it a spin...
<beuno> not a good start:
<beuno>   File "/home/beuno/bzr_devel/loggerhead.dont_hold_branches/loggerhead/apps/filesystem.py", line 48, in __call__
<beuno>     cached = self.root.cache.get(path)
<beuno> AttributeError: 'BranchesFromFileSystemRoot' object has no attribute 'cache'[A[A[A[A[AA[A[A[A[A
<beuno> right, serve-branches hasn't been tweaked yet
<mwhudson> beuno: try pulling maybe
<mwhudson> ?
<beuno> mwhudson, I'm on revno 191
 * spiv -> lunch
<mwhudson> hm
<beuno> start-loggerhead works though
<beuno> browsing the project has a small glitch: Exception: 'BranchWSGIApp' object has no attribute 'history'
<lifeless> spiv: when you return, I'd like to chat memory with you
<beuno> mwhudson, other than those two things, code looks sensible to me, and it *feels* faster, although I don't have any facts to back that up
<mwhudson> i'm working on the browse view now
<beuno> may be my head is working slower
<thumper> AfC: ping
<AfC> thumper: hello
<mwhudson> oh argh i hate the browse view
<mwhudson> beuno: try rev 194, just pushed
<beuno> mwhudson, fixed both issues, can't find more  :)
<mwhudson> beuno: ok, now see if the code makes sense :)
<mwhudson> (i guarantee config.py won't)
<beuno> I'm curious on to how this affects memory usage.  Where is Peng when you need him...
<mwhudson> it should be a bit better i guess
<mwhudson> not massively
<Peng> He's watching TV. :)
<beuno> ah, view_data_by_name is interesting...
<mwhudson> beuno: that's one word for it
<lifeless> oh
<beuno> it's not bad, maybe with some docstring slapped on it explaining a bit of the logic would work
<lifeless> that reminds me
<lifeless> bzr-search_integration?
<beuno> Peng, tv is bad for you  :p
<Peng> beuno: Yeah, I'm gonna die young.
 * Peng eats some potato chips.
<beuno> lifeless, well, that's in a mergeable-ish state. I'm not sure mwhudson is in a reviable-ish state though  :)
<beuno> Peng, you dare devil....
<mwhudson> maybe
<beuno> "reviewable-ish" state is probably what I meant, but since I'm already making up words...
<beuno> mwhudson, if this fixes the problem with too many branches open, some explanation in config.py should be good enough, IMHO
<mwhudson> beuno: ok, thanks
 * mwhudson writes some docstrings
<beuno> maybe even try to get the guy with the 100% CPU bug to give it a spin
<beuno> you know, make him break his server before you break LP  :p
<beuno> damn, still haven't started packing
<lifeless> igc: the pb thing is tricky
<lifeless> igc: passing it to the child - and each child will do 0..total
<lifeless> for total == what the child has
<igc> lifeless: yes, it's ugly
<igc> not passing it the child means the pb only shows the progress of local revisions
<igc> it's almost like you need to pass through an offset and total so the one pb can just keep stepping
<lifeless> igc: also, get_sha1s -
<lifeless> igc: its part of the overall 'VersionedFile is dead, long live VersionedFiles'
<lifeless> igc: agreed on the pb thing - thats the sort of tweak that would work
<igc> wrt no NEWS you mean?
<lifeless> igc: yes
<igc> ok
<lifeless> igc: we can list every single method if wanted, but its essentially everything that broke in that space; highlighting get_sha1s isn't very useful IMO
<igc> agreed
<lifeless> cool
<igc> my concern is always plugin authors
<lifeless> happy for me to land this?
<igc> yes
<lifeless> wooo
<igc> looking forward to it :-)
<igc> lifeless: well done on this, being able to stack across formats will be pretty magic when it all comes together
<lifeless> igc: it is :)
<lifeless> igc: I've been playing with it
<lifeless> igc: I'm pushing the latest shallow-branches loom too
<igc> cool
<lifeless> ok, with that done, I'm going to go write a parser/reader for BTreeIndex's
<igc> lifeless: I'm heading off to the doctors soon for most the afternoon so I probably won't get much more reviewing done today sorry
<lifeless> igc: thats cool; I'll sweet talk poolie
<igc> lifeless: yep, I'm hoping poolie can keep you unblocked
<lifeless> it is his job :)
<lifeless> now, where is that plumbers friend
<Peng> Eek, LH's memory usage is still going up a bit.
<thumper> Peng: where are you looking?
<beuno> Peng, even with mwhudson's new branch?  :)
<Peng> beuno: No, I haven't tried that. Want me to?
<Peng> beuno: Should it be reasonably stable? And does serve-branches.py work?
<beuno> Peng, https://code.edge.launchpad.net/~mwhudson/loggerhead/dont-hold-branches-open
<beuno> Peng, "yes" and yes  :)
<mwhudson> Peng: yes, just pushed revision 195
<Peng> Those are some ominous quotation marks. :P
<mwhudson> will probably merge to trunk soon
<Peng> How soon?
<mwhudson> in a few minutes
<Peng> Oh. I'll wait then.
<Peng> My Loggerhead setup uses a custom branch in ~/loggerhead, so I'm not sure how I'd try a different branch than trunk.
<mwhudson> man, 1221 lines of diff
<Peng> (And yes, it is a stupid reason not to try another branch, but I'm lazy. :D )
<lifeless> Peng: serve-branches ../differnet
<lifeless> spiv: pingish (refreshing scrollback)
<mwhudson> Peng: trunk revno 180
<mwhudson> it's landed
<Peng> Okay.
<mwhudson> Peng: when you said that the memory usage was going up, how much memory was it using?
<Peng> mwhudson: It had gone from 101 to 102 MB.
<mwhudson> Peng: oh
<mwhudson> that's not especially exciting :)
<Peng> I was surprised it hadn't stopped growing.
<mwhudson> (given that it routinely uses upwards of a gig on launchpad, though that's old old code now)
<Peng> Well, I'm on a 360 MB VPS, so it is concerning. :P
<mwhudson> ok
<Peng> Anyway, I'm using the latest trunk now.
<mwhudson> do you know what revno you were on before?
<Peng> The last one.
<Peng> So, 179, I guess.
<mwhudson> ok, so you had the streaming output
<Peng> Yeah.
<Peng> Streaming can't be used with compression, right?
<Peng> Because that would really reduce bandwidth use..
<mwhudson> um, don't really see why not
<lifeless> get apache to do it ? :)
<lifeless> (because compression is a great way to break buggy browsers, and the apache modules have the workarounds well noted)
<Peng> lifeless: I use lighttpd. 1.4 doesn't support compressing dynamic stuff, though 1.5 does.
<lifeless> Peng: there you go then :)
<lifeless> Peng: though, if they followed the spec, and didn't read mod_gzip etc from apache, expect problems :)
<mwhudson> hm, it looks like paste.gzipper will stop the streaming from streaming indeed
<Peng> lifeless: The only breakiness I know of is IE and CSS and JS?
<Peng> Woah.
<Peng> I'm still connected, right?
<lifeless> Peng: ye
<lifeless> s
<Peng> I thought I wasn't. I was about to reconnect everything when it started working again...
<spiv> lifeless: pong
<lifeless> spiv: memory usage; would a new index with an LRU cache help much do you think? (can we talk voice?)
<spiv> lifeless: perhaps (and yes)
<lifeless> is that you?
<spiv> it is
<lifeless> handset out of juice
<spiv> Ah.
<spiv> skype?
<lifeless> its a silly bug in the battery
<lifeless> yes skye
<igc> bbl
<lifeless> poolie: chatted with spiv; the memory from reading existing indices was a significant thing.
<lifeless> poolie: also - for my copy of python-in-bzr-packs:
<lifeless> Original aggregate index size:  39016345
<lifeless> B+Tree aggregate index size:    7585936
<lifeless> Difference:                     31430409
<lifeless> spiv: ^
<spiv> That's a huge improvement!
<spiv> I hope the improvement in memory consumption is as good :)
<lifeless> it will be different
<lifeless> I'll need some pointers on string interning etc
<mwhudson> wow
<spiv> Interning strings is easy, at least.  Just "intern(s)", it's a builtin.
<spiv> Oh, rather "s = intern(s)"
<lifeless> spiv: whats the overhead? (why isn't it the default)
<spiv> It's the default for string literals that look like python identifiers.
<mwhudson> the overhead is looking in and storing references in a big-ass global dictionary
<spiv> But Python doesn't automatically check every str you read from disk to see if it is already intern'd.  I assume the cost is roughly similar to checking a big dict.
<lifeless> I'm a little concerned about the cost of running millions of keys through that
<spiv> I am too, although from what I saw from my testing it wasn't a big cost.
<spiv> It's definitely worth benchmarking it more carefully though.
<spiv> The upside speed-wise is that string comparisons get slightly faster (s1 == s2 is quick if s1 and s2 are the same str, it's just a pointer comparison).
<spiv> It wouldn't shock me at all if it was less of a win with B+Tree indices...
<lifeless> spiv: an open question to think about is making index creation use less memory
<spiv> Hmm, yeah.
<beuno> mwhudson, I'm off to bed, have to catch a plain in a few hours. I'll probably be fairly unresponsive the next few days, especially on IRC, I may do better with email. Hopefully, long hours on the plane will get me to finish setup and directory-templates
<mwhudson> beuno: ok, sounds good, sleep well
<mwhudson> i'm stopping for the day too
<mwhudson> (no internet at home yet, should get connected tomorrow)
<beuno> mwhudson, ah, so we can expect less mwhudson_'ns?
<mwhudson> we shall see
<beuno> wish you luck with that  :)
<bob2> AttributeError: 'KnitPackRepository' object has no attribute 'weave_store'
<bob2> ah, fixed already
<lifeless> bob2: what plugin?
<bob2> ah, search
<lifeless> :)
<bob2> (doesn't happen with 3515)
<lifeless> bob2: 3515?
<bob2> r of bzr.dev
<lifeless> oh, revno of bzr.dev? VersionedFiles hath landed:)
<bob2> ah, piffy
<bob2> well, spiffy
<lifeless> bob2: yes, massive API breaks R us
 * spiv ducks out for a bit
<Peng> So far, I think the dont-cache thing improved Loggerhead's memory usage, but I can't really tell.
<Peng> At the least, it sent back a 490 KB page and is using less than 22 MB of memory.
<Peng> So the point of that branch was keeping branches open and stuff, but still, that surprised me.
<catsclaw> Anyone around for a quick question?
<catsclaw> Is anyone around for a quick question?
<RAOF> catsclaw: Generally it's a better idea to ask the question.
<catsclaw> I've never had much luck doing that.
<RAOF> You've obviously been in the wrong chanels :)
<catsclaw> At any rate, I'm hosted on Dreamhost and I'm trying to use Bazaar.
<Peng> How unfortunate.
<RAOF> I'm not familiar with dreamhost, but at worst you've got sftp access, right?
<Peng> Yes.
<catsclaw> Yes.  But then I have to define shell access for every one of my users.
<catsclaw> Correct?
<Peng> Isn't it possible to restrict a user to sftp with no other ssh access?
<bob2> yes
<sabdfl> even better, use bzr+ssh, restricted
<Peng> sabdfl: That would involve installing bzr on the server, which is more of a pain.
<catsclaw> At the moment, all access is generated from a database, which dynamically writes an .htaccess file and the svn access file dynamically
<catsclaw> I don't know of any way of doing the same with the ssh users and passwords
<catsclaw> And because the ssh usernames have to be unique across the server, I couldn't have easy logins to the site.
<catsclaw> Is there any way to share an ssh login, but keep the contributor's logins distinct?
<Peng> With bzr, commit authors and ssh users are not related in any way.
<catsclaw> Where do commit authors get set, and is that secure?
<Peng> ~/.bazaar/bazaar.conf, or by running "bzr whoami"
<Peng> And anyone can claim to be anything.
<catsclaw> There's no way to include validation?
<RAOF> Peng: And presumably the next statement is "but you can GPG sign your commits" :)
<Peng> Oh, right.
<bob2> are you using svn over ssh?
<catsclaw> I'm planning on using sftp
<Odd_Bloke> catsclaw: For SVN or for bzr?
<catsclaw> bzr
<Odd_Bloke> catsclaw: So what protocol are you using for svn?
<bob2> must be raw svn:// or you'd have the same spoofing potential as with bzr
<catsclaw> It's http
<bob2> how usable is the bzr webdav thing?
<catsclaw> Not, at the moment.  It requires 1.6.
<Odd_Bloke> I'm not sure, it's vila's thing (SUBTLE PING).
<catsclaw> How do I uninstall a plugin, btw?
<lifeless> catsclaw: reverse however you installed it
<lifeless> catsclaw: if you used the plugins setup.py, it will have installed to python_lib_prefix/bzrlib/plugins/NAME
<lifeless> catsclaw: but if you installed via apt, use apt to uninstall, if you installed by branching into ~/.bazaar/plugins/NAME, just remove NAME from there
<catsclaw> I did a bzr branch command from lp
<Peng> Where did you branch it to...?
<catsclaw> I don't know.  I was sitting in the Bazaar plugin directory, but it didn't put it there
<vila> bob2: webdav is usable, the 1.6 requirement is a bit artificial, I haven't the resources to test it against 1.5 and nobody will care in a few weeks. I'm just trying to minimize my entropy :)
<lifeless> catsclaw: if you ran 'bzr branch lp:FOO' then it made a basename(FOO) directory in the directory you were in
<catsclaw> Well, it did it in such a way that it doesn't show up in explorer or a command line
<lifeless> catsclaw: interesting :)
<Odd_Bloke> catsclaw: 'bzr plugins -v' will tell you where it is, if it's affecting bzr.
<drxnele> hi
<catsclaw> not installing http[s]+webdav:// support (only supported for bzr 1.6 and above)
<catsclaw> Unable to load u'bzr.webdav' in u'C:/Program Files/Bazaar/plugins' as a plugin b
<catsclaw> ecause the file path isn't a valid module name; try renaming it to u'webdav'.
<drxnele> can somebody help
<Peng> drxnele: Not without knowing what you need help with.
<drxnele> bzr push lp:~screenlets-extras-team/screenlets/screenlets-extras
<drxnele> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Escreenlets-extras-team/screenlets/screenlets-extras/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<Odd_Bloke> drxnele: 'bzr launchpad-login'
<Peng> catsclaw: You should do that then.
<catsclaw> C:\Program Files\Bazaar\plugins\webdav
<catsclaw> Only the only thing listed there is Launchpad
<drxnele> No Launchpad user ID configured.
<drxnele> how to do this?
<Odd_Bloke> drxnele: Sorry, I meant 'bzr launchpad-login <username>'.
<drxnele> meny thanks
<drxnele> it worked
<catsclaw> I just deleted the plugins directory.  I get the same error, and the same results from bzr plugins -v
<bob2> vila: awesome
<lifeless> catsclaw: run bzr --version
<lifeless> catsclaw: it will tell you where the 'log file is'
<lifeless> catsclaw: delete the log file, then run the command that is showing an error, then pastebin (e.g. to http://rafb.net/paste) the contents of the log, and the output bzr gave
<Peng> You shouldn't have deleted that directory...
<catsclaw> I can reinstall it
<catsclaw> http://rafb.net/p/7tqMoL85.html
<lifeless> catsclaw: so in C:/Program Files/Bazaar/plugins
<catsclaw> Yes?
<lifeless> catsclaw: you would appear to have a directory called 'bzr.webdav'
<lifeless> catsclaw: and bzr is telling you to rename that to 'webdav'
<lifeless> catsclaw: please do that, then try again
<catsclaw> Which I would do, if I had a directory "C:\Program Files\Bazaar\plugins"
<catsclaw> I don't.  I deleted it.
<Odd_Bloke> catsclaw: Are you on Vista, by any chance?
<lifeless> catsclaw: [ 6096] 2008-07-01 01:51:29.979 WARNING: Unable to load u'bzr.webdav' in u'C:/Pr
<lifeless> ogram Files/Bazaar/plugins' as a plugin because the file path isn't a valid modu
<lifeless> le name; try renaming it to u'webdav'.
<lifeless> catsclaw: that says that you do; please check :)
<catsclaw> There wasn't a subdirectory except for "launchpad" there before, either
<catsclaw> I am on Vista.
<Odd_Bloke> Right, it does some screwy stuff in Program Files.
<Odd_Bloke> All in the name of saving you from yourself, of course.
<catsclaw> There is no subdirectory named "plugins" in the Bazaar directory.
<Odd_Bloke> I'm not sure what to suggest, but I think you're right when you say you can't see anything and bzr is right when it says there is something there.
<luks> well, try to search for bzr.webdav on your disk
<luks> but first look to C:/Users/catsclaw/AppData/Roaming/bazaar/2.0/plugins
<catsclaw> Directory of C:\Users\catsclaw\AppData\Local\VirtualStore\Program Files\Bazaar\plugins
<catsclaw> 07/01/2008  01:05 AM    <DIR>          bzr.webdav
<luks> so there is a bug in bzr, which reports incorrect directory
<catsclaw> More to the point, when I ran the bzr branch command, why did it extract things to the VirtualStore?
<catsclaw> And not the directory I was sitting in?  And shouldn't bzr know about that, and warn you?
<Odd_Bloke> bzr _should_ be told about it.
<luks> I'm guessing it's Vista playig tricks on you
<Odd_Bloke> Whether it actually is or not is another matter.
<luks> bzr was probably not allowed to write to C:\Program Files or something like that
<RAOF> It looks like bzr is triggering some of the "don't break permissions-ignorant code" workarounds in Vista
<catsclaw> I'm sure that was it.
<RAOF> So you need to do whatever the vista equivalent of "sudo bzr branch ..." is.  Presumably it has one.
<catsclaw> I can launch a cmd window as an administrator
<lifeless> yay windows.
<lifeless> catsclaw: sorry, I didn't realise just how much Vista gets in users way :)
<catsclaw> But no point, since I can't use the webdav stuff without 1.6
<catsclaw> And if people can log in with different commit names under ssh, that works anyway
<Odd_Bloke> vila: Is there the chance for subtle bugs if the webdav stuff is used with <1.6, or will any problems be glaringly obvious?
<vila> Odd_Bloke: You tell me :-)
<vila> seriously, I'm not aware of any potential problem
<Odd_Bloke> Presumably it would be API mismatch, which'll ditch before anything could go wrong.
<vila> event there, the only API I use that may cause problems with old versions is test related only, the transport API is pretty stable
<vila> the last transport API break was requiring writable transport to implement list_dir and stat. This was the only reason I stop working on it for some months
<vila> Now, that plugin has of course not been widely used, so file bugs, file bugs, file bugs :)
<Odd_Bloke> catsclaw: You could try using the plugin with <1.6 if you want to.  Just change the 'minor < 6' on line 31 of __init__.py to something lower.
<Odd_Bloke> Of course, the SSH route is safer. :)
<catsclaw> bzr: ERROR: Permission denied: "/.bzr": [Errno 13] Permission denied
<catsclaw> That's when I try init-repo on the sftp site
<catsclaw> Login works, though, and I can manually upload files
<Odd_Bloke> catsclaw: Find the relevant part in bzr.log and that should help us out.
<lifeless> catsclaw: when I see that its usually a virtual vs absolute path difference
<lifeless> catsclaw: if you are doing 'bzr init-repo sftp://HOST/FOO', be aware that that is '/FOO' on the host, not '~/FOO' aka 'FOO'
<lifeless> catsclaw: if you want 'the current directory' you need 'sftp://HOST/~/FOO'
<catsclaw> Ah.  Sure enough.
<catsclaw> Final question tonight, I swear
<lifeless> the more the merrier
<catsclaw> There's nothing out there that allows you to edit bzr files from a web interface, is there?
<catsclaw> Edit text files stored in a bzr repository, I mean.
<Odd_Bloke> catsclaw: ikiwiki might do it.
<Odd_Bloke> Wait, do I mean ikiwiki.  *thinks*
<Peng> catsclaw: There are lots of programs to edit files from a web interface, but committing them with bzr afterwards is another story...
<catsclaw> Got any good ones to recommend?
<Peng> Odd_Bloke: I'm not sure if ikiwiki can use bzr as a backend.
<Peng> catsclaw: DreamHost has WebFTP set up.
<Odd_Bloke> http://jameswestby.net/bzr/ikiwiki.bzr/trunk/ suggests that james_w has looked at it at some point.
<lifeless> spiv, I have iter_all_entries workig
<lifeless> spiv: is there a simple test to check memory impact?
<spiv> lifeless: I included a simple script in my mail
<spiv> lifeless: want me to pastebin it for you?
<lifeless> you did? I'll grab it
<Odd_Bloke> Actually, that just looks like a conversion of ikiwiki's history to bzr.
<lifeless> spiv: (by simple I mean, no bzr needed :P)
<Peng> Odd_Bloke: I think I heard that bzr doesn't support one of the hooks ikiwiki sues.
<spiv> Or, just bzr push bzr.dev into /tmp and watch top ;)
<Peng> Odd_Bloke: That may have changed, of course.
<lifeless> spiv: I don't have a repo format using this
<lifeless> spiv: that needs iter_entries working
<lifeless> spiv: and possibly iter_entries_prefix
<spiv> Fair enough.  So, search my email for iter_all_entries
<Odd_Bloke> Peng: http://ikiwiki.info/rcs/bzr/
<aantn> hello
<Odd_Bloke> aantn: Hi.
<aantn> is it possible to uncommit one specific revision after other revisions have been made
<aantn> hey Odd_Bloke
<Odd_Bloke> aantn: Do you want to remove it from history, or just undo the changes it made?
<aantn> Odd_Bloke: remove it from the histroy
<aantn> it has an incorrect commit log :-[
<catsclaw> Ok.  I gotta jet.
<catsclaw> Thanks for the help.  I'll have more later, have no doubt.
<Peng> aantn: How incorrect? Most people learn to live with typos..
<aantn> Peng: I forgot to add files, so it picked up on a tiny minor change and missed the big change
<aantn> Peng: another developer ended up committing the big change
<lifeless> spiv: 117M vss, 58M res
<hsn_> anybody knows if bzr is installed on sf.net shell server?
<lifeless> spiv: http://rafb.net/p/zCpYDb71.html
<lifeless> spiv: thats for my bzr.dev's indices converted
<lifeless> spiv: robertc@lifeless-64:~/source/baz/integration$ du -sh --apparent /tmp/fo/
<lifeless> 5.5M    /tmp/fo/
<spiv> lifeless: interesting, that's vs. 61M res I get with bzr.dev and my original script.
<spiv> Although your vss is much higher.  But you have a 64-bit system, I think?  So the comparison isn't 100% fair.
<lifeless> spiv: I do
<lifeless> spiv: lets get a baseline
<spiv> That suggests your new stuff is a bit better, though.  That's a promising sign.
<spiv> Hmm, also your vss is double mine, which seems odd.
<lifeless> spiv: 16474 robertc   20   0 72804  11m 2800 S    0  0.6   0:00.20 python
<lifeless> spiv: thats before any indices are processed
<spiv> Ok, so the oddness is someone else's fault :)
<lifeless> 16474 robertc   20   0  117m  58m 2864 S    0  2.9   0:02.56 python
<lifeless> and thats after it finishes
<lifeless> now, the largest index is 2.5MB
<lifeless> and readv() does some interesting data slicing
<lifeless> oh, hmm, lets gc() too
<lifeless> 16565 robertc   20   0  117m  58m 2864 S    0  2.9   0:02.62 python
<lifeless> so, gc isn't freeing anything :)
<spiv> Yeah, I'd be a little surprised if you had reference cycles.
<spiv> Worth being careful with our measurements, though.
<lifeless> spiv: http://rafb.net/p/iDf7SP71.html
<spiv> So, what do you get on your system with my script (i.e. the current index format)?
<lifeless> spiv: thats what I've ended up with
<spiv> That script consumes memory?  It looks like it should be freeing everything before the final raw_input
<lifeless> spiv: thats right
<lifeless> spiv: strange huh
<spiv> Very.
<lifeless> 16825 robertc   20   0 91764  18m 2980 S    0  0.9   0:00.56 python
<lifeless> using bzr.dev
<lifeless> your script (well, nearly)
<lifeless> I'm buggered if I know where its going
<spiv> Try my countrefs hack?  (http://twistedmatrix.com/users/spiv/countrefs.py)  Getting the counts before and after might tell you something.
<lifeless> 16984 robertc   20   0 74368  13m 2860 S   48  0.7   0:03.74 python
<lifeless>         for item in index.iter_all_entries():
<lifeless>             pass
<lifeless> that tells me all I need to know :P
<spiv> Heh.
<lifeless> fragmentation anyone ?
<lifeless> seriously, I think I'm better off getting this code out there in a repo format for you to try
<spiv> Yeah, I'd like that.
<lifeless> I wanted to see if it was potentially useful :)
<hsn_> any work in progress on making commited log messages editable by other commits?
<berto-> jelmer: hello.
<lifeless> spiv: I'd be interested if chewing rather than listing the iterators affects your results
<lifeless> spiv: also, going down to the _indices attribute and doing each one might also be useful
<lifeless> hmm, 12 second test case. not good
<berto-> jelmer: i figured out my compilation issues on OS X.  it had to do with having MacPython installed on my system.  Once I cleaned that up, running make worked just fine.  I also updated the OS X instructions: http://bazaar-vcs.org/BzrForeignBranches/Subversion#mac-os-x
<berto-> is bzrsvn a good way to migrate over to bzr?  i noticed that bzrsvn uses SvnRepository; how different is that from the standard Bzr repository?
<gour> berto-: have you tried tailor?
<berto-> gour: no, what's that?
<gour> berto-: kind of universal migration tool
<Peng> berto-: bzr-svn stores the data in a regular rich-root-pack repository; I'd think SvnRepository is just how it communicates with the svn server.
<luks> berto-: bzr-svn uses SvnRepository only if you want a checkout
<berto-> thanks, everyone.
<Peng> Also, I dislike Tailor.
<gour> why?
<Peng> I only used it once, to convert from bzr to hg, and the result was a bit messy.
<Peng> Also, it might be a "jack of all trades, master of none" thing.
<berto-> more general, if i wanted to put a bunch of related codebases in a single bzr repository how would i go about doign that?  for example, i'm now converting an svn repo with bzrsvn, can i bzr init-repo and somehow move the contents over?
<gour> i found the recent version as the only tool able to migrate from darcs
<Peng> berto-: I think you have to "bzr branch" into the new repo.
<Peng> berto-: Note that all a shared repository is is a data storage optimization; it has no other meaning.
<berto-> Peng: because it keeps one copy of common stuff between branches, right?
<gour> berto-: right
<berto-> ok, cool.  i think i get it.  :)
<berto-> tailor may help me get stuff out of git.
<Peng> berto-: You should check out bzr-fastimport for git (and hg).
<berto-> peng: cool, checking it out.
<gour> berto-: pick latest tailor if possible, it improved in many ways
<Peng> berto-: (I'm not sure how production-ready it is, but in any case, it might work, and it's good stuff.)
<LarstiQ> vcs-fast{export,import} seems to be the way of the future
<gour> LarstiQ: with darcs, my experience of darcs-fast was darcs-SLOW-and-broken and that's why i used tailor
<gour> see https://bugs.launchpad.net/bzr-fastimport/+bug/232177
<ubottu> Launchpad bug 232177 in bzr-fastimport "Better darcs support needed" [Undecided,New]
<LarstiQ> gour: future, because things might not be there overall. The tailor author has lots of darcs experience, so I expect that to be rather good indeed.
<gour> ymmv, though
<LarstiQ> gour: interesting
<Peng> Yeah, Tailor seems to be good for Darcs.
<berto-> awesome, just got django via bzr.  :)
<berto-> finally got this working.  took me forever to track down problems on my system
<berto-> nite, all
<lifeless> ok, b+tree querying up and running
<lifeless> now for a repository format to use it
<lifeless> spiv: ^ pushed too
<jelmer> lifeless, ping?
<lifeless> hi
<lifeless> lp:~lifeless/+junk/bzr-index2
<lifeless> toy^ play ^ enjoy
<jelmer> lifeless, I've implemented item_keys_introduced_by()
<lifeless> jelmer: cool
<jelmer> lifeless, what branch of bzr-index should I try on a svn repo?
<lifeless> jelmer: bzr-search; trunk
<lifeless> jelmer: look for commits_only = True
<lifeless> jelmer: change it to False, and it will try for texts
<jelmer> lifeless: Hmm, bzr-index triggers svn to return new and interesting errors
<lifeless> jelmer: :)
<jelmer> visik7, ping
<weigon> how do I convert svn-tags into bzr-tags ?
<visik7> yes ?
<jelmer> visik7: Any chance you can try the branch from django again with the latest version of bzr-svn?
<jelmer> visik7: No hurry, I'm just wondering what is causing the breakage for you
<jelmer> visik7: Can't reproduce it here, so it's pretty hard for me to fix those two bugs atm :-/
<visik7> jelmer: I should upgrade bzr too latest bzr-svn doesn't work with 1.5
<jelmer> visik7: ah, yeah
<jelmer> weigon: How do you mean? After importing a svn repository using bzr-svn?
<weigon> yep
<visik7> actually I'm not setuped to keep bzr from bzr :)
<weigon> I would like to get rid of the tags/ folder afterwards and use bzr-tags instead
<jelmer> lifeless: bzr index completed >-)
<weigon> this shall be a one-time operation, the svn tree will be abonded afterwards
<jelmer> weigon: I believe somebody wrote a script to do that
<jelmer> weigon: Something like this should also do it:
<lifeless> jelmer: cool
<lifeless> jelmer: I shall remove the hack then tomorrow
<jelmer> lifeless: It was slow, but not unbearable
<jelmer> (290 seconds for gnome-specimen)
<lifeless> jelmer: bling bling
<jelmer> visik7, :-)
<weigon> jelmer: after branching from svn into bzr, applying the bzr-tags, removing tags/ and branches/ it makes sense to move trunk/ one level done into the basedir of the repo (like bzr move trunk/* .), right ?
<jelmer> weigon: Sure, though you wouldn't use "bzr mv" for that (since the root of the repository is not a branch)
<jelmer> lifeless: Now we only need tracker integration >-)
<lifeless> jelmer: I looked at that
<lifeless> jelmer: I'm not sure its a good fit. But openchange could use a search engine :P
<lifeless> jelmer: also, new index layer, half-size indices for bzr; will probably make bzr-search much snappier
<weigon> jelmer: you lost me: isn't $ bzr branch svn+ssh://.../ creating _one_ repo with 3 folders (tags/, branches/, trunk/) is in SVN ?
<weigon> or are they already in shared-repo with 3 different repos ?
<jelmer> weigon: You would use bzr branch on the trunk/ URL rather than on the repository
<uws> jelmer: heh. it seems gnome-specimen has become a bzr/svn playground for a bunch of people :)
<jelmer> weigon: "bzr svn-import" will import a repository (and create separate bzr branches for trunk, branches/*, tags/*)
<weigon> *doh* thanks
<weigon> that's what I was missing
<jelmer> uws: yeah :-) It's a nice fit for testing since it's not too big but contains some regular and some bzr-svn commits
<jelmer> weigon: I'll see if I can add a warning
<jelmer> lifeless; 9-:
<jelmer> s/9/(
<jelmer> lifeless: So, now that I have this index, how do I use it?
<lifeless> jelmer: 'bzr search'
<jelmer> lifeless: I indexed a remote URL
<lifeless> jelmer: or fire up loggerhead on this branch and then type in the search field (using a bzr-search integrated loggerhead of course)
<lifeless> jelmer: you did something like:
<lifeless> svn co foo bar
<lifeless> cd bar
<lifeless> bzr index
<lifeless> right ?
<jelmer> no, I did "bzr index svn://svn.gnome.org/svn/gnome-specimen/trunk"
<lifeless> jelmer: ok, its probably indexed in ~/.bazaar/bzr-search/svn-lookaside/UUID
<lifeless> jelmer: which is cool, I so didn't expect that to work :P
<lifeless> jelmer: do a svn co of trunk
<lifeless> jelmer: cd to it
<lifeless> and do 'bzr search foo'
<sabdfl> lifeless: where's the trunk of the search plugin?
<jelmer> lifeless: Too late, I already started working on "bzr search -d" :-P
<lifeless> sabdfl: lp:bzr-search
<lifeless> sabdfl: (where else ? :)
<sabdfl> it was the "bzr-search" bit I was looking for
<lifeless> sabdfl: ah
<sabdfl> we need bzr branch lp:+search/"bzr search plugin" ;-)
<lifeless> sabdfl: that would be fun
<lifeless> sabdfl: if you want something really shiny, run bzr index on launchpad
<lifeless> sabdfl: then run beuno's bzr-search integrated loggerhead locally
<lifeless> lp:~beuno/loggerhead/bzr-search_integration
<lifeless> it needs python-simpletal, python-paste and python-sqlite installed
<sabdfl> lifeless: it blows up on bzr.dec
<sabdfl> v
<lifeless> the serve-branches.py script is now used to run it - just give it the path to a branch
<lifeless> sabdfl: indexing bzr.dev?
<sabdfl> yes
<lifeless> sabdfl: let me try
<lifeless> sabdfl: are you running bzr.dev? or 1.6b2 ?
<lifeless> beuno: btw, loggerhead is definitely returning bogus revisions in searches still; we need to track that down
<lifeless> sabdfl: if you are running bzr 1.6b2, use lp:~lifeless/bzr-search/pre-1.6 instead
<lifeless> its 50% through indexing bzr.dev from scratch for me, no errors
<jelmer> lifeless: -d patch sent
<lifeless> jelmer: ! nice. (With test?)
<jelmer> lifeless: of course (-:
<lifeless> sabdfl: yeah, I think you are running bzr 1.6b2, I had no trouble indexing bzr.dev
<lifeless> sabdfl: let me know how you go, I'm crashing soon as this test completes; midnight!
<sabdfl> lifeless: ./bzr index worked in bzr.dev
<lifeless> sabdfl: ok cool
<jelmer> lifeless: lp:~jelmer/bzr-search/debian
<lifeless> jelmer: mail me I'm halt()ing
<lifeless> gnight all
<jelmer> lifeless: will do
<jelmer> lifeless, goodnight
<weigon> jelmer: the svn-import did the trick
<liminal> Hi, I'm having problems with svn-push: it gives me a C++ assertion error. Can anyone help me?
<liminal> Would the mailing list be a better place to get advice for this issue?
<LarstiQ> liminal: did you check the bzr-svn buglisting?
<liminal> I hadn't... just did a search for 'svn-push' and it doesn't seem to turn up anything
<jelmer> liminal: Please file a bug
<liminal> sure. in the meantime is there any other way to get a repo into svn?
<jelmer> liminal: Probably easiest to see first if we can fix this bug
<jelmer> Once you file the bug, I'll see how hard it would be to fix
<liminal> ok, thanks. Should I let you know the bug # or anything?
<jelmer> liminal, yeah, please paste it here
<liminal> jelmer, the bug # is 244583 -- thanks
<jelmer> bug 244583
<ubottu> Launchpad bug 244583 in bzr "Svn-Push Assertion Error" [Undecided,New] https://launchpad.net/bugs/244583
<jelmer> liminal, what version of bzr-svn is this?
<liminal> http://d5190871.u44.websitesource.net/bzr-svn/bzr-svn-0.4.10-svn-1.4.6-setup-0.exe
<jelmer> liminal: Ah, Windows..
<jelmer> liminal: Do you have a build environment available? If so, you may want to try the latest bzr-svn
<jelmer> which no longer uses the patched Python subversion bindings
<jelmer> I can't find that assertion that's being triggered in my copy of bzr-svn - it looks like yours has been patched
<jelmer> s/bzr-svn/subversion/
<liminal> do you mean the development version of bzr-svn? on the project page it lists 0.4.10 as the latest
<jelmer> liminal, yeah, the development version
<liminal> I used the precompiled installer because all the instructions for deploying from source seem to assume running from linux
<jelmer> yeah, compiling on windows may be a bit of a hassle
<jelmer> It'd be happy to help get it to work (also so the instructions for building on windows can be updated)
<liminal> ok, thanks for taking a look. It seems that this won't be simple to address. I'll work around this instead (commit latest version to svn and keep the current bzr repo in case I need past history)
<liminal> thanks for the offer, but a colleague just came in and we need to focus on other stuff. Thanks again.
<jelmer> k
<liminal> jelmer, I saw your comment about adding a backtrace to my bug. How would I do that?
<mrevell> james_w:  Hi are you around>
<james_w> hey mrevell
<mrevell> james_w: unping, sorry :)
<james_w> no problem
<awilkins> Verterok:
<guilhembi|pause> jam: hello! could you please post a progress note in support issue 2413?
<jam> guilhembi|pause: I'm having the guys test some win32 installers right now
<jam> Found a weird issue with a system lib getting bundled in the installer
<jam> I can post that to tracker if you want
<jam> I was waiting for them to give the "all clear" and post then
<Verterok> awilkins: hi
<awilkins> Verterok: Hi, I was going to discuss this SaveableEditorInput thing with you ; I'm going to see how Subversive does it first though
<Verterok> awilkins: Ok that would be great, I looked a bit how subclipse is doing it.
<awilkins> Verterok: Good to cover the bases :-)
<Verterok> :)
<Verterok> awilkins: it's ok if we start with this in a while, I'm not 100% available right now :( , maybe in a hour?
<awilkins> Verterok: Sure, no problem
<Verterok> awilkins: cool, thanks :D
<tolstoy> Anyone have any docs on bzr_access? I can't figure out if it's supposed to be used on the client side, or the server side.
<james_w> tolstoy: server side
<james_w> it's supposed to go as the command in the authorized_keys file on the server.
<tolstoy> james_w: Hm. Okay. I think I get you. I'll try that out.
<mkanat> mwhudson: I updated to tip, it's going fine so far.
<mwhudson> mkanat: awesome
<mkanat> mwhudson: I saw that you fixed webpath, too, and that seems to be working well.
<mwhudson> oh yes
<mwhudson> mkanat: the 100% cpu thing is still odd, i'd like to understand it
<mwhudson> but if it's stopped happening, good enough for me
<mwhudson> mkanat: is your loggerhead accessing some of the branches it's viewing over http?
<mkanat> mwhudson: Nope.
<mkanat> They're all local.
<mkanat> mwhudson: Well, I'm not entirely sure it's stopped. :-)
<mwhudson> heh, ok
<mkanat> mwhudson: I just upgraded recently, we'll see how it goes.
<mwhudson> please let me know either way
<mwhudson> how's memory usage?
<mkanat> Using 300m RES right now.
<mkanat> Which seems better for its uptime.
<mwhudson> good good
<Peng> Hmm, no-op pulls over bzr+http are a definite improvement. It's about a dozen <85 byte requests (not counting headers), vs. a couple hundred KB of index requests.
<mwhudson> oh, beuno is travelling isn't he
<bartt> Any advise/pointers for using bzr as a local client to CVS? I'd like to use bzr as a 2 way client to a CVS repository. bzr then allows me to branch locally, experiment and merge back when ready to commit to CVS.
 * mwhudson points at launchpad's code browsing, now running trunk loggerhead
<mwhudson> bartt: i'm not aware of anything like that
<Peng> It's running both trunk bzr and Loggerhead? Spiffy.
<mwhudson> Peng: well, it's not quite trunk bzr, it's r3508
<Peng> mwhudson: That's the trunk, just not the very latest.
<mwhudson> Peng: i guess so yes
<lifeless> moin
<berto-> hello.  i'm trying to build bzr-svn on a debian etch box using python2.4; i'm getting this error: http://paste.pocoo.org/show/78310/  any thoughts?
<lifeless> which branch of bzr-svn are you trying to build ?
<lifeless> berto-: I would unset your CFLAGS
<jelmer> berto-: looks like 2.4 doesn't have Py_ssize_t
<jelmer> I've added a typedef for it
<jelmer> berto-, should work if you pull current 0.4
<berto-> jelmer: that did it, thanks!
<berto-> jelmer: not sure if you saw my message to you last night; i got things working on os x and updated the bzrsvn wiki to reflect the new stuff.
<jelmer> berto-: Ah, nice - thanks!
<awilkins>  jelmer : You appear to have traded spaces for tabs on your indents
<jelmer> awilkins: yeah, in the c files
<berto-> jelmer: in commit.py, line 716; is that py2.5 syntax ?
<jelmer> probably
 * jelmer fixes
<berto-> jelmer: i can do that one ...
<berto-> jelmer: how do i send you a patch?
<jelmer> berto-: bzr send <0.4-url>
<awilkins> jelmer: Bah, you haven't changed that C99 syntax
<jelmer> awilkins: no, sorry - havent had time for that yet
<awilkins> jelmer: Is there a simple way of changing it that a C-idiot can grasp?
<jelmer> awilkins: Yeah, I think so
<jelmer> awilkins: look at object.h in the python development files
<jelmer> PyTypeObject is defined there
<jelmer> With C99 it's possible to assign a struct member using ".tp_<name> = foo,"
<jelmer> without C99, the members have to be specified in the right order
<jelmer> (preferably one on each line, with a comment at the end of the line with the name, to keep things maintainable)
<jelmer> I can convert an example one, if that helps
<awilkins> jelmer: So this is the struct ending on line 345 of object.h?
<jelmer> awilkins, yep
<awilkins> jelmer: Do you need all the members or just the ones you are using?
<berto-> jelmer: sorry, i'm *very* new to bzr.  i get this: bzr: ERROR: No mail-to address specified
<berto-> bzr send
<berto-> Using saved location: http://people.samba.org/bzr/jelmer/bzr-svn/stable/
<awilkins> berto-: bzr send [target] --mail-to
<jelmer> berto-: Please try again
<jelmer> berto-: I forgot I removed the child_submit_to setting
<jelmer> schierbeck, !
<schierbeck> jelmer!
<schierbeck> hi :)
<jelmer> awilkins: All members up to the last one we need to set explicitly
<jelmer> awilkins: The members in between need to be set to 0 or NULL (depending on their type)
<berto-> jelmer: ok, that worked.  so you changed something on the server side, eh?  where is child_submit_to set?
<awilkins> pointers NULL, ints 0
<awilkins> Righto (blech).
<jelmer> awilkins: yep, exactly
<jelmer> schierbeck, hi (-:
<jelmer> berto-: child_submit_to is set in .bzr/branch/branch.conf on the server side
<berto-> ok, cool.
<awilkins> jelmer: Some of these members sound like they need poitners but they are not declared with *
<schierbeck> jelmer: i see you've been busy working on bzr-gtk -- nice!
<lifeless> garh, needing too many keys for this test :(
<schierbeck> i've been way too busy at work recently
<awilkins> eg descrgetfunc tp_descr_get  : 0 or NULL  ?
<jelmer> awilkins: yeah, the various things ending in func would be NULL
<jelmer> the compiler will probably warn you as well if you try to assign 0 to a pointer or NULL to an integer
<awilkins> Righto, off we go.
<jelmer> schierbeck: yeah, among other things your signature work is enabled again now
<schierbeck> jelmer: nice :)
<schierbeck> although it doesn't seem to detect seahorse at all right now
<schierbeck> perhaps an issue with dbus activation?
<jelmer> schierbeck: yeah, I have to comment out the  "if BUS_NAME not in bus_names:" bit
<jelmer> otherwise it doesn't get activated
<jelmer> that line only seems to work if seahorse already was triggered by some process
<schierbeck> jelmer: i'm not sure what the canonical (hehe) way to do it is
<vadi2> How does one break a lock when bzr break-lock fails? we messed up our branch a bit and now can't access it: http://pastebin.com/m2480833e
<schierbeck> jelmer: we've been through quite a bit of different approaches...
<jelmer> schierbeck: yeah...
<berto-> found another py2.4 incompatibility; just used bzr send again.
<mcrael> vadi2: I am having trouble breaking a lock also. I hope someone here can point us in a good direction.
<jelmer> berto-: did you send an email earlier? I haven't received anything yet
<jelmer> schierbeck: sanest approach would probably be to just try to use seahorse and catch the possible exceptions that indicate it wasn't found
<berto-> jelmer: thought so: just ran "bzr send" and figured that had some magic.
<berto-> is there a file i need attach to an email somewhere?
<schierbeck> jelmer: yup, think that's best
<jelmer> berto-: bzr send should take care of sending the email for you
<jelmer> and launch an email client, etc
<berto-> hmm, might be the mail server on the machine i'm using ... 1 sec.
<berto-> is there a way to have bzr send just give me a file i can attach?
<jelmer> yeah, "bzr send -o <filename>"
<berto-> boo, relaying denied.
<berto-> ok, 1 sec.
<vadi2> ï»¿mcrael: I think I'll just delete branch and make it again in my case, since it's a relatively new one
<mcrael> vadi2: I may have to do the same.
<berto-> jelmer: sent.
<jelmer> mcrael/vadi2: try "bzr break-lock lp:~gufw-developers/gui-ufw/0.0.6"
<jelmer> berto-, thanks
<berto-> np.  let me know if there is some naming convention you usually use.
<vadi2> ï»¿jelmer, already remade the branch, but thanks for the reply
<jelmer> berto-, Still nothing received..
<schierbeck> jelmer: i'm off to bed, g'night
<jelmer> schierbeck: ok, see you later
<berto-> jelmer: that's odd; jelmer-at-samba.org ?
<jelmer> yep
<jelmer> never mind
<jelmer> looks like it was just slow
<jelmer> berto-, thanks, merged!
<berto-> how do i get the bzrsvn manual?  just tried bzr help svn but that doesn't give me much.
<lifeless> jelmer: ^ :P
<jelmer> berto-: see the FAQ
<lifeless> berto-: I believe much/all of it is on the wiki
<lifeless> jelmer: do you see my point about people trying the inline help system
<jelmer> lifeless: yes, I do get your point
<jelmer> I just don't want to add a verbatim copy of the current files in the py files
<lifeless> jelmer: sure, I got that
<berto-> so getting my changes into the svn repo is just a matter of using "bzr push"?
<jelmer> berto-: if you're pushing a new branch that isn't in svn yet, "bzr svn-push"
<berto-> no just changes to trunk, so that should work, i suppose.
<jelmer> yep
<berto-> jelmer: svn-push failed while "Obtaining username for SVN connection" on a file:/// transport ?
<NfNitLoop> berto-: is this a repo you checked out from SVN?
<berto-> yep.
<NfNitLoop> do bzr info.  find what it says for "parent branch".
<NfNitLoop> and just "bzr push" to that.
<berto-> same problem
<NfNitLoop> odd.
<berto-> NfNitLoop: it is a repo accessed via file://, wonder if that's the problem.
<NfNitLoop> try svn+file:// ?   (just brainstorming here... been a while since I touched bzr-svn)
<berto-> hmm, blew up another way.  :)
<berto-> SubversionException: ("Can't write to connection: Bad address", 14)
<NfNitLoop> berto-: and you can "bzr pull" from that location OK?
<berto-> yeah, just did about an hour ago.
<jelmer> berto-: haven't seen that error before
<jelmer> berto-: You're pushing to a remote location?
<jelmer> berto-: That doesn't look like file:// at all..
<berto-> jelmer: it's a file:/// transport on the same machine.
<berto-> jelmer: oh, right. that last one i used svn+ssh:// to come back to the same box.
<jelmer> berto-: Anything in ~/.bzr.log ?
<jelmer> berto-: Are you sure you typed the path correctly?
<berto-> almost certain.
<berto-> i grabbed it from bzr info
<berto-> parent branch: /home/dev/repo.svn
<jelmer> and you're pushing to /home/dev/repo.svn/trunk or something?
<berto-> jelmer: oh, i should specify trunk ...
<berto-> let me try that.
<berto-> in bzr i'm in the trunk branch, then i push to svn's trunk branch and i get a "diverged" error.
<berto-> i think i saw that one in the faq ...
<poolie> hello
<jelmer> berto-: You should push to the same location that you pulled from
<jelmer> hey poolie
<Verterok> hi poolie
<berto-> jelmer: hmm, i was trying that and it wsn't working.  merge is thinking right now, not sure what it's doing.
<jelmer> berto-, what error did you get exactly when you did that?
<berto-> jelmer: http://paste.pocoo.org/show/78324/
<jelmer> berto-: Any chance you can run that inside of gdb?
#bzr 2008-07-02
<berto-> jelmer: sure, i'll give that a shot.
<lifeless> jam: revno 8 has your patches with tests fixed
<berto-> jelmer: not sure this is what you're after:  http://paste.pocoo.org/show/78325/
<berto-> jelmer: i used this: gdb --args python /home/berto/local/opt/bzr.dev/bzr push /home/dev/repo.svn
<awilkins> jelmer: yegods this is tedious ; I now have it compiling (yay!) but not linking yet (Boo!)
<jelmer> awilkins: :-( What error?
<awilkins> Oh, it's normal for windows - totally different library finding. Let me patch my bits back in
<jelmer> berto-: interesting - no idea
<jelmer> berto-: Does the bzr-svn testsuite pass on your machine?
<awilkins> Bah, spoke too soon
 * awilkins goes back to hand-unrolling struct initializers
<jelmer> berto-: (make check)
<awilkins> jelmer: Yipes, it might have built
<jelmer> awilkins: Any chance you can send a bundle with the C99-removal stuff?
<awilkins> jelmer: Am I supposed to have a bunch of pyd files?
<awilkins> Aha
<awilkins> I have 4 pyd files
<jelmer> awilkins: no, those were removed a long time ago
<awilkins> client, ra, repos, and wc
<Odd_Blok1> Does abentley still host BB himself, or has it moved to a Canonical server?
<berto-> jelmer: ooh, aobrted!
<awilkins> jelmer: It's just built them
<jelmer> awilkins: Which branch are you using then?
<awilkins> jelmer: 0.4
<awilkins> pyd files are the intended output of a C extension, no?
<jelmer> awilkins: I'm pretty sure that doesn't contain any .pyd files..
<jelmer> Ah, this is windows of course..
<jelmer> awilkins: maybe :-)
<jelmer> they're also the extension pyrex uses for one of its file types, that's what confused me
<awilkins> They're in the build folder and marked 0015, I think that's a success
<jelmer> nice :-)
<berto-> jelmer: http://paste.pocoo.org/show/78326/  i can't gather anything interesting from that.
<jelmer> berto-: hmm, you may want to try "make valgrind-check" or "make gdb-check"
<awilkins> jelmer: Right, problem one, MSVC has no stdbool.h, so I've pasted a simple one and changed the includes from path-includes to -local-includes
<Odd_Blok1> lifeless: What are your thoughts on moving PQM to a team-maintained branch on LP, and using BB and PQM itself to do the development?
<jelmer> awilkins: Can you exclude those changes for now?
<awilkins> jelmer: Sure, let me shove them on a shelf
<berto-> jelmer: i'm thinking py2.5 might be the way to go and see if all this goes away.
<lifeless> Odd_Blok1: uhm, pqm implies a non team maintained branch :)
<lifeless> Odd_Blok1: I'm fine with the idea of BB, though we're using lp's review system at the momen
<Odd_Blok1> lifeless: Yeah, LP's review system is probably OK.  I'd quite like for PQM to be self-hosting though, so that I'm forced to get to grips with it as a user.
<awilkins> jelmer: Does vi put UTF-8 signatures at the front of files?
<jelmer> awilkins: nope, I do :-)
<awilkins> jelmer: Ah, so these are meant to be here?
<awilkins> jelmer: They're showing up as changes in shelve ; maybe that's a bug
<awilkins> +Â´../* Copyright .Â® 2008 Jelmer V
<awilkins> (the ".." are the unprintables for UTF-8 signature
<jelmer> awilkins: Probably some sort of bug on Windows
<awilkins> jelmer: Hmm. I'll test that in a bit
<lifeless> Odd_Bloke: I think I'd rather have the dependencies on baz etc really wound back before trying for that
<lifeless> Odd_Bloke: its not the friendliest thing to setup today
<awilkins> jelmer: 'tis ok after I strip them off in an editor that is aware of them
<Verterok> disconnect
<Verterok> disconnect
<Odd_Bloke> lifeless: Sure, that makes sense.  Removing the VCS stuff is first on my list, to save me having to accommodate it when I do anything else.
<awilkins> jelmer: That patch should be approaching your mailbox
<awilkins> jelmer: Alas, "Unable to load bzr-svn extensions - did you build it?"
<jelmer> awilkins: thanks
<jelmer> awilkins: hmm
<jelmer> awilkins: It build the extensions in the same directory as the .py files?
 * igc breakfast
<jelmer> hi Ian
<awilkins> jelmer: No, a subfolder, but I moved them into the same folder
<awilkins> jelmer: I may be over-linking
<awilkins> jelmer: I'm just cutting my linking to only required libs
 * lamont bemoans the lack of a bzr git-import
<Peng> lamont: bzr-fastimport?
<Peng> Maybe?
<jelmer> awilkins: If they're in the same folder and still failing, you may want to look at .bzr.log
<awilkins> jelmer: What's that thing where you filter a list with "for x in "  ?
<jelmer> list comprehension?
<jelmer> lamont: yeah, bzr-fastimport or bzr-git (which I'll be working on over the summer)
<jelmer> (not that helps you presently)
<lamont> jelmer: and I can continue to freshen from the git repo
<lamont> ?
<jelmer> lamont: with bzr-fastimport, I think you can as long as you keep the files with the mappings around
<lamont> being able to use the bzr UI with a git backend would be a big win for traction, I think
<lamont> even if it means the occasional impoirt
<lamont> more to the point, that would come in handy for creating a bzr branch of the git-core package....
<lamont> and can I push back to the git repo?
<jelmer> lamont: with bzr-fast-import ? Yes, you can export back to a git repo afaik
<lamont> nice
<lamont> jelmer: does that mean export back to a new-and-virgin git repo, or to the one that I imported from (as a push) ?  hopefully the latter
 * lamont should really read up on bzr fast import
<jelmer> lamont: bzr fast-import/export use a custom file format that is also understood by git fast-import/export
<jelmer> lamont: afaik you can continue exporting to an existing git repo
<lamont> nice - I'll do some reading
<lifeless> poolie: http://allmydata.com/
<lifeless> poolie: http://ceph.newdream.net/
<jelmer> berto-: more luck with 2.5?
<igc> hi jelmer
<igc> lamont: fastimport/export is designed for interchange
<igc> it does provide some limited incremental mirroring but it's not overly smart yet
<igc> lamont: Pieter has done some good work on improving it but I'm yet to incorporate all of his work into the trunk
<igc> if the trunk isn't flexible enough for you yet, try Pieter's branch
<jelmer> awilkins: still there?
<awilkins> jelmer: yes
<awilkins> jelmer: It seems to be loading them now, but I'm getting MSVCR80.dll errors
<awilkins> jelmer: I thikn it should be linked against MSVCR71 for Python 2.5
<awilkins> jelmer: GAH they stopped working again
<awilkins> http://pastebin.ca/1060099
<jml> how can I conveniently look at the log message for the last change to a file?
<jelmer> awilkins: I've merged your .C fixes
<jelmer> awilkins: hmm, no indication of what module couldn't be found?
<berto-> jelmer: got sidetracked, haven't checked yet.
<awilkins> jelmer: Looks like it can't find apr & co
<jelmer> awilkins: co?
<awilkins> jelmer: "and company"
<jelmer> awilkins: Copying all required dlls into the bzr-svn folder may work :-P
<awilkins> jelmer: Looks like it's not hunting through the path, I set a filesystem monitor on it
<awilkins> jelmer: It's weird, it's looking through SOME folders on the PATH but not all of them
 * awilkins copies the DLLs into the folder
<awilkins> MSVCR80.dll
<awilkins> Bah, looks like the wrong version to use
<awilkins> "The application has made an attempt to load the C runtime library incorrectly"
<jelmer> hmm
<awilkins> jelmer: I'm poring over the linker output to see if I am linking to bad versions of libraries
<awilkins> jelmer: I'm using the MSVC7 linker as far as I'm aware
<awilkins> jelmer: I think my LIB env needs a bit of a kick
<awilkins> jelmer: Et voila... bingo
<jelmer> awilkins: it works!?
<awilkins> THis is what you get for installing the Windows SDK
<awilkins> Let me try the selftest
<awilkins> Bugger
<awilkins> It got as far as "bzr plugins" withotu moaning this time though
<jelmer> what did it moan about?
<awilkins> jelmer: MSVCR80... I deleted it and I now have an ACTUAL STACK TRACE
<awilkins> http://pastebin.ca/1060108
<jelmer> awilkins: looks like your version of bzr is not new enough
<awilkins> jelmer: Could be, I'm on a self-build of 1.6b2
 * awilkins pulls his dev branch
 * awilkins snores
 * awilkins is running bzr.dev selftest svn
<awilkins> There are still far too many of these "unable to remove testing dir" errors on windows
<jelmer> ok, but at least it appears to be somewhat running?
<awilkins> jelmer: Yes, I so far have 101/925 14 err 2 fail
<awilkins> jelmer: I'll post you the STDOUT when it's done
<jelmer> awilkins: woot!
<jelmer> awilkins: That's a big improvement from not working at all already :-)
<jelmer> awilkins: How much local changes do you have?
<awilkins> jelmer: Quite a nasty patch to setup.py, a local stdbool.h, and the c files use it
<awilkins> jelmer: And by "nasty" I mean "totally hardcoded for adrian's filesystem"
<awilkins> As well as "may cause Posix builds to break, dunno"
<awilkins> The big stinker is the MS linker which insists on seeing every lib in the tree before it will link the ones at the top (I don't know if GNU link does this)
<jelmer> awilkins: so just setup.py and stdbool.h ?
<lifeless> ok
<lifeless> these are definitely slower to write:
<lifeless> GraphIndex: Wrote 92994 in 15.328
<lifeless> BTreeIndex: Wrote 92994 in 25.079
<jelmer> awilkins: I'd be interested in that patch
<jelmer> awilkins: Is there some way to find those paths automatically on windows?
<awilkins> jelmer: Unless they are in your LIB and INCLUDE env, probably not
<awilkins> jelmer: distutils uses those on Windows (I presume as well as Posix)
<awilkins> jelmer: It may be enough to insist they get put in LIB and INCLUDE
<jelmer> awilkins: there's no apr-config or svn-config utilities?
<awilkins> jelmer: They are bash scripts
<awilkins> Well, apr-config is, afaik
<jelmer> ah, right
<awilkins> jelmer: I think we demonstrated that GCC doesn't work very well for building Python extensions for Win32
<jelmer> yeah, guess we should amend the apr detection to just look for that header then
<awilkins> I put in a PosixBuildData and WindowsBuildData class
<awilkins> But I'm not 100% sure I left the Posix end compatible with Posix
<jelmer> ah, k
<awilkins> Ok, you have 87 err, 16 fails
<jelmer> Can you mail me the output?
<jelmer> and perhaps those changes to setup.py as well so I can verify the posixy bit still works
<jelmer> I'll see if I can trim that stuff down a bit tomorrow
<jelmer> that stuff == the failures
<jelmer> time for some sleep first :-)
<awilkins> I concur, it's 0240 here
<awilkins> jelmer: Ok, those files should be on their way, goodnight.
 * Odd_Bloke --> lunch (of a sort, it's nearly 3am here but I got up at 10pm...)
 * igc lunch
<Odd_Bloke> Could someone pastebin a sample bzr PQM submission email for me?
<lifeless> Odd_Bloke: install bzr-pqm-submit
<lifeless> Odd_Bloke: then do 'bzr pqm-submit --dry-run'
<mwhudson_> i guess it's not too surprising that the c extensions make bzr annotate faster
<mwhudson_> is the amount they make things faster generally known?
<lifeless> yes
<lifeless> we highly recommend using them
<mwhudson_> the answer in this case seems to be "20 times faster"
<lifeless> "we highly..."
<Odd_Bloke> Top. Men.
<pickscrape> Is this a new thing for 1.6?
<lifeless> pickscrape: no
<mwhudson_> or... something else is going on
<lifeless> woo
<lifeless> GraphIndex: miss torture in 343.138
<lifeless> BTreeIndex: miss torture in 41.803
<mwhudson_> so it seems doing revision_tree('..').annotate_iter() over http got waaaaaaaaaay slower somewhere between 1.6b2 and r3508
<mwhudson_> which is strange, as (a) that's not very long afaict and (b) i didn't think much had changed with either annotation or http
<mwhudson_> (i think the c extensions comment above was a red herring)
<lifeless> mwhudson_: I can't see anything indicating why
<lifeless> mwhudson_: are you getting a RemoteRepository or a FooRepository object?
 * mwhudson_ digs some more
<mwhudson_> lifeless: foorepository i assume
<mwhudson_> yeah
<mwhudson_> what bzr.dev revision roughly corresponds with 1.6b2 ?
<lifeless> not sure
<lifeless> 3468 is 1.6b1
<mwhudson_> ok, let me try that
<mwhudson_> bisect ftw
<mwhudson_> hmm
<mwhudson> so maybe the difference is running it uninstalled vs installed
<mwhudson> but that makes very little sense
<lifeless> mwhudson: I think you have confounding factors
<lifeless> mwhudson: how are you testing? via lh?
<mwhudson> lifeless: no, locally
<mwhudson> ah
<mwhudson> i bet it's c extension related after all
<mwhudson> 'make' uses 'python' to build the extensions
<mwhudson> and i've been running my tests with python2.4
<lifeless> yes
<mwhudson> ok, win
<mwhudson> man that was really starting to confuse me
<lifeless> igc: ping
<igc> hi lifeless
<lifeless> igc: I'm wondering if you want to usertest btree-plain repositories?
<lifeless> igc: real-world scale applications >> artificial benchmarks
<igc> lifeless: just looking over the email thread now
<igc> wondering when the best time to run some benchmarks was
<igc> :-)
<lifeless> let me quote worf
<lifeless> "Today is a good day to die"
<abentley> Odd_Bloke: Still on my own server
<igc> so lifeless, what baseline did you want to compare against? The latest bzr.dev?
<ja1> lifeless: moved
<lifeless> :)
<jam> I was here all along :)
<jam> just hiding
<lifeless> :)
<jam> lifeless: I thought that quote was Flatliners
<lifeless> so, adding first and last really depends on the ration of between-key misses
<jam> well, it wasn't so much adding first and last as it was changing the < first > last logic
<lifeless> and only gets that benefit for 2/child-nodes - basically every fencepost will get you one saving, but all the internal misses aren't saved
<lifeless> jam: perhaps I'm missing something
<jam> lifeless: sure, though it is easier to benchmark its value if we have it
<jam> I was trying to work out what we *might* get
<jam> but it is hard to instrument that
<lifeless> jam: right, me too. All my gedanken were not encouraging though, which is why I skipped implementing
<jam> lifeless: no, we only get 2/child-nodes, but it goes -infinity => start
<jam> versus  X => Y
<jam> it sort of depends heavily on the "evenly distributed"
<lifeless> right
<jam> whether that is true or not
<lifeless> but all it takes is a few adam's and zaphods
<lifeless> :)
<jam> A pack with only robertc@ will reject all of the john@ nodes very quickly
<lifeless> jam: 1 IO vs three though
<lifeless> jam: but the three with the smallest node in the cache will still be very quick
<lifeless> jam: a more interesting one is to consider .tix
<jam> lifeless: is that sorted (file_id, revision_id) or (revision_id, file_id) ?
<jam> former, right?
<lifeless> yes
<lifeless> jam: heh, you didn't write a from_bin ? :P
<jam> you mean bin_to_array ?
<lifeless> yes
<jam> yeah, it was mostly testing packing, not the other way around
<lifeless> question
<lifeless> why the power-of-2 constraint?
<jam> lifeless: so I could do & instead of %
<jam> I believe
<lifeless> anyhow, 2048 is one :P
<jam> as is 128, or 256
<jam> depending on where you want to go with that
<lifeless> yeah
<lifeless> I'll start with 256
<jam> lifeless: It is because I have to map from an integer into a bit
<jam> so I go to offset "X >> 4" bit "X & 4" sort of thing
<lifeless> jam: seems to me you could just work with any number of bytes
<lifeless> jam: by taking that much of the sha and being tricky
<jam> # This is used to take our 32-bit values, and mask off the high bits
<jam> # so that the integer offsets, always point within the final bit-array
<jam> # basically, 0 < (integer & self._bitmask) < self._num_bits for any
<jam> # integer. Because _num_bytes is always a power of 2, _num_bits is
<jam> # also a power of 2, and so a simple bit mask will do.
<jam> self._bitmask = self._num_bits - 1
<lifeless> jam: mmm, thoughts for a different day
<jam> lifeless: yes, you could do mod
<jam> I did & _bitmask rather than % length
<jam> lifeless: oh, for low bits / entry, MD5 is a bit better
<jam> it only sets 4 bits in the output, which means it goes "white" slower
<jam> The theoretical numbers are in the class docstrings
<jam> (note that in practice, I got worse than theoretical, and always better with sha1. But I wasn't testing <4 bits / e either)
<lifeless> jam: right. well ideally we won't be either :P
<lifeless> I'm going to add
<lifeless> :bloom:\nFILTER
<jam> ??
<lifeless> jam: just how I'm going to encode it in the internal node
<jam> ah, sure
<lifeless> a key of :bloom: which is illegal to generate from bzrlib, then the binary bytes
<jam> lifeless: interesting. at *each* internal node?
<lifeless> jam: yes
<lifeless> jam: higher internal nodes we may want to not have the filter
<lifeless> jam: but its clearly of most use down adjacent to leaves
<jam> other than giving you less work to do higher up :)
<jam> but it goes white pretty quickly
<lifeless> right
<jam> (or black, if your terminal is white background :)
<lifeless> the higher the layer the more bits needed for a useful filter
<lifeless> but the less IO needed to encounter a filter
<lifeless> so is array an array of bytes or bits
<jam> lifeless: a = array.array('B')
<jam> Bytes
<jam> self._array[offset >> 3] & Bloom.bitmask[offset & 0x7]
<lifeless> so, array(B, bytes)
<lifeless> why didn't you use array.write() ?
<jam> array(B, num_bytes)
<lifeless>     The constructor is:
<lifeless>     
<lifeless>     array(typecode [, initializer]) -- create a new array
<lifeless> initialized from the optional initializer value, which must be a list,
<lifeless>      |  string. or iterable over elements of the appropriate type.
<jam> lifeless: # stupidly, there's no good way that I can see of resizing an array
<jam> # without allocing a huge string to do so
<jam> # thus I use this, slightly odd, method:
<lifeless> jam: yes, I'm toing bin_to_array here though
<jam> lifeless: if you already have it as a string, just shove that into array.array('B', mystring)
<lifeless> jam: yes, thats what I said isn't it ? :)
<jam> lifeless: oh, by the way, what constraints are on your key values?
<jam> Isn't there something about being "no-whitespace , utf-8" ?
<lifeless> yes
<jam> this would be raw bits, so could take on any value
<lifeless> same as bzrlib.index
<jam> like \n
<lifeless> jam: indeed, I handle that already: P
<jam> The most efficient, "safe" encoding I've encounter is something like base85
<lifeless> jam: '\n'.join(content) - this is all encoded by zlib for us
<jam> lifeless: but in "_InternalNode.__init__() you use _parse_lines(bytes.split('\n'))"
<jam> or is this going in somewhere that isn't being compressed.
<lifeless> jam: nope, its at the end of that list
<lifeless> ok, array_to_bin is slightly broken
<lifeless> in that its got somehow different output vs .tostring()
<jam> lifeless: I think you miss what it is
<jam> array_to_bin => 0101101101110
<jam> as in the numerals
<lifeless> jam: oh!
<jam> ascii text :)
<lifeless> indeed, not what I thought
<lifeless> where is more caffeine :)
<jam> lifeless: I think you can just dump the array bytes as you asked earlier
<lifeless> I've just committed a round trip bloom support for the parser
<lifeless> now to hook up creating these for some nodes
<jam> lifeless: real quick, to figure out the position of a leaf node, you need the offsets for all the internal nodes added together?
<lifeless> no
<jam> node_index = offset + node.offset + pos
<jam> and
<jam> offset = offset + self._row_lengths[row]
<lifeless> sum (row_lengths before the row this internal node is in) + this_node.offset + pos
<jam> both seem to be 'accumulating'
<lifeless> you need the sum of the rows above
<lifeless> you need this nodes offset
<jam> oj
<jam> ok
<lifeless> and you need the offset (0 based) from the pointers in this node
<lifeless> this is constant whether you are looking for a leaf or internal
<jam> lifeless: so that is the row offset for the entry in the row you are looking up
<jam> so if I'm on the root node, I have a row_offset of 1 for the first layer of internal nodes
<lifeless> yes
<lifeless> off by one in my description
<lifeless> sum(row_lengths including this row) + internal_node.offset + pos_from_bisect_right(internal_node.keys)
<lifeless> jam: one trivial optimisation would be to precalculate the sums
<jam> meh... :)
<lifeless> jam: :P
<jam> lifeless: just to be clear, _InternalNode.keys is a sorted list, _LeafNode.keys is a dictionary, right?
<lifeless> yes
<lifeless> because bisect in the former and existence in the latter
<jam> lifeless: sure, though you can bisect in the latter, too
<jam> just bisect_left
<lifeless> its slower usually
<lifeless> but you could consider just plucking out the keys you want as it parses
<jam> interesting thought
<jam> anyway, I was confused by Node.attribute having a different signature
<jam> fixing
<jam> lifeless: I tend to get confused that you are ~lifeless on LP, but ~robertc on email and people.ubuntu.com
<lifeless> sorry :)
<poolie> actually i think he's robert@canonical, and  neither of the other two work there
<lifeless> robertc will
<lifeless> as well as first.last
<poolie> hm
<poolie> two of your patches are approved with tweaks
<jam> lifeless: was one of your "fixes" to the tests to bump up the number of nodes from 25k => 100k? Because that test seems to be excruciatingly slow right now
<jam> I'm not sure if I broke something, or if it just refuses to finish
<lifeless> 100K
<lifeless> its due to the extra packing
<lifeless> yes, it takes a lot of nodes to make a 3-level index.
<jam> well, then I guess I have to poke at that before I can test my iter_entries fixes :)
<jam> OK              215798ms
<lifeless> jam: its writing performance :)
<jam> Is a bit too long to wait
<lifeless> erm
<lifeless> it was 12 seconds for me
<lifeless> I lie
<lifeless> 90seconds
<lifeless> and yes, I was cursing
<lifeless> there are two of them
<jam> well, that has a bit of pdb time in there
<jam> ^| doesn't work on win32
<lifeless> :)
<jam> lifeless: 34480ms with my performance tweaks back in
<jam> but 3 test failures
<jam> because now it doesn't pack *quite* as efficiently
<jam> lifeless: is that just "pretend it is correct" ?
<jam> (specifically, "test_2_leaves_1_0")
<lifeless> jam: well, if you don't make them pass, I'll have to :)
<lifeless> jam: or are you asking 'how do I decide the new results are ok' ?
<jam> lifeless: right
<jam> I think I just need to decrease the number of nodes for test_2_leaves_1_0
<jam> since it seems specific about testing 2 leaves
<igc> poolie: thanks for the reviews. Please see my reply to the content filtering one.
<Odd_Bloke> Hacking bits out of PQM is fun. :)
<lifeless> jam: yes, I look and poke, and tweak
<lifeless> Odd_Bloke: cool
<Odd_Bloke> Seriously, I could do this all summer.
<Odd_Bloke> Oh, wait. :p
<lifeless> ok, in theory we have bloom filters now
<jam> lifeless: ugh, one of the failing tests is iter_all_entries_reads... aka the slow one
<lifeless> jam: I try to improve the resiliency each time I touch them, but fundamentally its a little hard to test some stuff without enough data to , well, test it
<jam> it seems a bit odd to be subject to the whims of the compressor
<jam> as it makes it a possible problem based on what zlib they have
<lifeless> the compressor is part of the format
<jam> lifeless: but you can be compatible with zlib and not give exactly the same output
<lifeless> jam: zlib is seriously stable
<lifeless> jam: this is true, and such folk can send patches :P
<lifeless> dang
<lifeless>   File "/home/robertc/.bazaar/plugins/index2/btree_index.py", line 93, in finish_node
<lifeless>     raise AssertionError("Not enough space for bloom filter.")
<lifeless> AssertionError: Not enough space for bloom filter.
<lifeless> ah, found the bug
<poolie> lifeless, can we talk briefly?
<lifeless> sorry, I'm dressed now
<jam> no talking while clothed.... hmm
<jam> sounds like a morning after issue
<fullermd> jam: You haven't done anything recently with FreeBSD trees, have you?
<jam> fullermd: not in a long time, no
 * fullermd nods.
<fullermd> Didn't think so.
<jam> you sound aggressive with that :)
<fullermd> Well, I've been paying very poor attention since April   :)
<fullermd> I just threw together that ShowStoppers page on it on a whim earlier today, and wondered if you had anything new to add to it.
<fullermd> But I guess "It's too damn big and too damn slow" is still a good first hurdle.
<jam> lifeless: unfortunately, your choice to pick the "middle" of the lexi-sorted nodes doesn't work well in my repo
<jam> search_from_revid in 0.877
<jam> After spending a lot of time setting it up
<jam> also unfortunately, the get_components_positions(2000) triggers the "unable to cache this many nodes" assertion
<lifeless> jam: lol :P
<lifeless> jam: that was written with your work in mind
<jam> lifeless: what do you think about splitting an internal-node cache from a leaf-node cache?
<lifeless> jam: neutral
<jam> for the new "iter_entries" I'll only hit the internal nodes 1 time
<jam> so they don't get priority over the leaf nodes
<jam> even if there are 100 keys hitting the node
<lifeless> jam: why not use _read_nodes then for the leaf nodes?
<jam> lifeless: well, do we *never* want to cache leaf nodes?
<jam> My idea with a 2 caches, is that both could be LRU's
<lifeless> jam: sure, that works too
<jam> lifeless: but for the "get it working" that is my plan atm
<jam> also, at this point I wish you wrote them as 'selftest --benchmark' so I could run some of them without running all of them :)
<lifeless> sorry :)
<jam> ^VI#
<jam> is my friend
<jam> I guess that is ^v<scroll>I# <enter>
<lifeless> hmm, how best to copy an in-progress bloom - copy.deep_copy ?
<lifeless> will array.array deep copy correctly?
<jam> lifeless: not sure, there are only 4 member variables aside from the array
<jam> __deepcopy__(...)
<jam>     copy(array)
<jam>     Return a copy of the array.
<jam> lifeless: ^^ it looks like array has a __deepcopy__ member
<lifeless> thanks :)
<jam> lifeless: anyway, sleepytime, its after 1am here
<lifeless> ok, I have bloom creation happ
<lifeless> jam: gnight
<jam> I have some code, for multi-way bisect, but it won't help randomly iterating one key at a time
<jam> so I'll look closer at that
<lifeless> ok
<lifeless> I'll have miss-avoidance in a few minutes, then go on to test annotate for that patch
<igc> lifeless: I'm running indexbench.py now. The moz one finished quickly; the OOo one (1.15M keys) took a long while for the 1st part and is up to the 2nd part now
<lifeless> igc: cool - latest version I presume ?
<igc> the only weird thing is that the last metric is 0.00
<igc> I *think* so
<lifeless> igc: note that a fully packed index is not ideal :)
<lifeless> igc: because we want to find out realworld (autopacked only) behaviour
<lifeless> igc: does it have miss_torture in the output ?
<igc> lifeless: hmm - my benchmarking repos are usually fully packed
<lifeless> igc: yes, I've pointed this out before :)
<igc> miss_torture is the one coming out as 0.00
<lifeless> (not to you specifically, but on the list)
<AfC> Looking for subjective opinions: how much should I worry about what `bzr gannotate` shows being correct? Is it a reflection of primary underlying relationships, or is it just a slash at the task of identifying things?
<lifeless> AfC: what do you mean by correct? It should give you a pretty good idea of the last change occuring on a line
<AfC> I have managed to contrive situations where the change is being attributed to a merge, not a source revision. This is a bit disturbing.
<lifeless> AfC: that occurs when eiher A) the merge changed the line, or B) the same change was made on both sides
<AfC> [resulting from the following: cherry pick something off of branch A onto B. No problem, although yes the new revision will claim to have invented these lines. Then merge B back into A, and suddenly gannotate shows not the original revision from A, *nor* the new revision on B, but the merge revision being the author of those lines]
<lifeless> AfC: right; it would be better to show *both*, but we show the point at which we can't decide.
<AfC> lifeless: well, having to choose one of the other, fine, but choosing the merge?!?
<lifeless> AfC: if you click on it, you can annotate both sources and see where it comes from
<lifeless> AfC: say it wasn't a cherrypick, but was some copyright claim or something
<AfC> lifeless: ok. My real question was whether this was something I needed to worry about and avoid creating.
<lifeless> AfC: no, its totally normal and we'll likely improve the UI further to give more helpful results
<AfC> Ok
<AfC> (it was quite worrying when I first saw it)
<lifeless> igc: 0.00 is expected
<lifeless> igc: there are no keys that are in the repository and not in a given index
<AfC> (I tried merge -r X..Y; I tried rebase; various permutations of branch creation order and [re]merge sequencing)
<lifeless> AfC: sounds like we need a page explaining what annotate *actually* does
<AfC> lifeless: I don't use it much, but I came to appreciate that (until now) it should real revisions being the source of things, not merges.
<AfC> showed*
<AfC> Jeesh. Time for a break, apparently.
<lifeless> AfC: right; and doing that implies handling origins(line) > 1 :)
<berto-> is there some way for me to save BZR_REMOTE_PATH for a given repository?
<gour> berto-: see bzr_remote_path config variable
<gour> "..This value may only be specified in locations.conf"...
<catsclaw> Oh, there we are
<berto-> gour where am i looking for the variable?  some documentation, the wiki?
<gour> berto-: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html
<gour> berto-: and http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
<berto-> gour: thanks!
<catsclaw> Quick question: loggerhead only works in two modes, server and proxy, right?  Not as a cgi?
<spiv> Also, "bzr help configuration", but you can read the same info in http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#configuration-settings
<berto-> gour: locations.conf works great!
<mwhudson> catsclaw: yes
<catsclaw> Well, great.
<mwhudson> catsclaw: you could probably make it work as a cgi well enough for small branches
<mwhudson> but anything more than a couple of thousand revisions would be pretty darned slow
<gour> berto-: that's not true!
<gour> berto-: bzr works great ;)
<berto-> haha
<catsclaw> Maybe so.  But I can't run servers or set the proxy path on my host
<gour> berto-: however, many like complicated things, although i'm not the one of them :-)
<catsclaw> So the lack of CGI support is extremely annoying
<gour> hmm, cannot say much about it...
<gour> catsclaw: what do you need?
<gour> maybe there is 'the other way'
<catsclaw> Ideally, I'd like a way to browse the repository from the web, and edit text files through a web browser
<catsclaw> I was hoping to find the "browse the repository" piece separately, and just hack it for the "edit text files" piece.
<mwhudson> catsclaw: it's just a wsgi thing these days
<mwhudson> if there's a cgi wsgi container, it should be a snap to set up
<luks> if you just want to browse the last revision of files (similar to svn's webdav listing), you can try http://bzr.oxygene.sk/bzrbrowse.cgi/bzrbrowse/trunk
<catsclaw> There's a cgi and Fastcgi wrapper for wsgi
<igc> lifeless: that's still running but some good news ...
<igc> iter_all_entries: 1037s -> 13s
<catsclaw> All right.  It's too late to bother with this right now.
<catsclaw> I'll have to figure out the FastCGI->WSGI stuff later
<catsclaw> Later
<berto-> is it possible to branch off a bzrsvn branch then merge between the two bzr branches?
<berto-> nm, just tried it, looks to work nicely.  :)
<igc> night all
<berto-> in order to push in local changes into bzrsvn i had to merge, then rebase, then use svn-push.  that seemed to work.  but, then i checked svn and all my changes were pushed in as one commit.  is there some way to replay all my commits?
<lifeless> igc: gnight
<berto-> looks like that happened because i had all the changes in a bzr repo then i merged them into my bzrsvn repo.
<berto-> jelmer: bzrsvn is working fine with py2.5.  looks like it's not too happy on py2.4, at least not on debian etch.
<jelmer> berto-: only mainline commits are pushed
<jelmer> berto-: Thanks for the info - any chance you can file a bug saying 2.4 is broken?
<jelmer> I'll see if I can fix that before the release, or at least warn people appropriately
<berto-> i updated the Requirements list on the bzrsvn wiki page.
<jelmer> I consider this a bug rather than a specific requirement
<berto-> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/244786
<ubottu> Launchpad bug 244786 in bzr-svn "BzrSvn does not work well on Python2.4" [Undecided,New]
<berto-> heh, gotta love mr. ubottu :)
<jelmer> berto-: thanks
<Odd_Bloke> Does anyone know where I can find the source for AfC's "There's A Branch Here" pages?  ISTR he posted on the list about it at some point, but I can't seem to find it from a (cursory) search.
<james_w> hey Odd_Bloke
<jelmer> Odd_Bloke: You mean this sort of thing: http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ ?
<james_w> http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/41665/match=
<Odd_Bloke> james_w: o/
<jelmer> ah, wasn't aware of that one, only of Michael Ellerman's htmllog plugin
<thekorn> 9hi, how can I resolve a conflict where a file was added?
<thekorn> I mean, if there are string conflicts, I get this '>>>>' marks and so on,
<thekorn> and edit this sections manually, then run bzr resolve
<thekorn> but what can I do if a file with the same name was added in the two branches
<james_w> thekorn: place the one you want at that path, with the content that you want, and then run "bzr resolve file"
<james_w> I believe if you want the one that got moved to .moved you "bzr rm file; bzr mv file.moved file"
<thekorn> james_w: ok, thanks, bzr is so easy :)
<james_w> this is one of the places that I think it's not that intuitive.
<james_w> if we get file joins then this case will be much better.
<james_w> thekorn: have you seen "bzr help conflicts"?
<thekorn> right, 'bzr resolve' without filename did not work
<james_w> any advice on improving it would be appreciated.
<thekorn> james_w: no, I've only looked for bzr help resolve
<thekorn> so maybe a hint there to also check bzr help conflicts would be cool
<thekorn> oh, nevermind, there is one
<Odd_Bloke> Is there a release schedule for 1.6 yet, or is it just "when it's done"?
<AfC> Odd_Bloke: I never published it.
<AfC> Odd_Bloke: 'cause no one actually asked me
<harobed> hi, in bazaar, can I modify one mistake in log message of last revision commit ?
<Odd_Bloke> harobed: 'bzr uncommit', then commit again.
<harobed> Odd_Bloke: I need to do one uncommit by revisions ?
<AfC> Odd_Bloke: it is, as you would expect, embedded in a [very very thin] template that is used to generate all those pages, but the logic looks like it could be lifted out without too much trouble.
<AfC> Odd_Bloke: bug me about it again in 3-4 hours and I'll send it your way
<harobed> example, I'm on revisions number 100 and my mistake is in revisions number 85 ? I need to uncommit to revisions 85 ?
<Odd_Bloke> AfC: I'll probably be in bed, but I'll bug you again at some point. :)
<harobed> I can't modify log message in .bzr file ?
<Odd_Bloke> harobed: Ah, sorry, I misunderstood your question.
<harobed> Odd_Bloke: hmm, first, my current revisions is 100
<matkor> harobed: revert only bad commit like: bzr merge -r 85..84
<AfC> Odd_Bloke: (ie, having explained that, I'm happy to email it to you, but it's not really general consumption, y'digg?)
<harobed> Odd_Bloke: I've mistake in log message of revisions 80
<Odd_Bloke> harobed: It is possible, but you'd be rewriting history which means that you wouldn't be able to collaborate with other people who've branched from you.
<Odd_Bloke> AfC: Cool, my address is D.M.Watkins at warwick.ac.uk. :)
<Odd_Bloke> AfC: Thanks!
<Odd_Bloke> harobed: Is the mistake in the commit message or in the data committed?
<harobed> Odd_Bloke: commit message only, not the code data
<Odd_Bloke> harobed: OK, have you shared this branch with anyone?
<harobed> Odd_Bloke: not
<Odd_Bloke> harobed: Then it is possible to do, but I'm not sure of the best way to do it.
<Odd_Bloke> Possibly rebase.
<harobed> rebase ?
 * mgedmin made bzr crash
<Odd_Bloke> mgedmin: How so?
 * mgedmin tried to do a bzr pull in a bound branch
<mgedmin> hm, I have 1.3.1 here... let's upgrade and try again
<Odd_Bloke> mgedmin: Could you pastebin the error somewhere?
<Odd_Bloke> ubottu: paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<nandersson> Where looks Mac OS X for the Bzr plugin-directory?
<james_w> nandersson: bzr --version should tell you
<mgedmin> Odd_Bloke: http://paste.ubuntu.com/24463/
<nandersson> james_w, Thanks! I'll that as fast as I found out how to get a command line :)
<Odd_Bloke> mgedmin: OK, I don't know enough about that part of the code to understand the error, but you want to 'bzr update' in a bound branch.
<mgedmin> I was trying to pull in changes from someone else's branch, not my bound branch's upstream
<mgedmin> bzr merge works, btw
<nandersson> james_w, there you go :) /Users/[username]/.bazaar/plugins - Thank you!
 * mgedmin reads bzr help checkouts now
<nandersson> Now I'll try to see if I can get BzrEclipse to work on Mac OS X :)
<lifeless> gnight everyone
<pygi> hi hi
<nandersson> Now got BzrEclipse running on Mac OS X 10.4 :)
<Tsmith> how expensive is creating a bzr's branch on a 186 MB codebase (text only)?  is it feasible to have hundreds/thousands of branches for each complex feature merge from one site to another?
<weigon_> Tsmith: are you using a shared repo ?
<Tsmith> i have no idea
<Tsmith> would a bzr info help?
<weigon_> yep
<Tsmith> $ bzr info
<Tsmith> Checkout (format: pack-0.92)
<Tsmith> Location:
<Tsmith>        checkout root: .
<Tsmith>   checkout of branch: /var/bzr/blinds.ca
<Tsmith> basically the same thing for /var/bzr/blinds.com, where the patch is coming from
<Tsmith> yes
<Tsmith> i believe it is a shared repo
<Tsmith> i may be "doing it wrong", but my team uses bzr much like svn; like bzr co from a remote repository, bzr up and every thing
<Tsmith> 100K    /var/bzr/blinds.com/branches
<Tsmith> 22M     /var/bzr/blinds.com
<Tsmith> hmm does it really only use 100 KB?
<Tsmith> that has to be impossible
<Tsmith> k i think i answered my question w/ your motivation
<Tsmith> thanks
<Tsmith> the answer is "Using a remote repo w/o trees, it is very inexpensive to branch."
<robsta> hi
<robsta> is there any way to hard reset a checkout? there is some stale lock and even "break-lock" can't fix it any more
 * mgedmin upgrades to bzr 1.5
<mgedmin> same error!
<mgedmin> yay
<mgedmin> my bug is https://bugs.launchpad.net/bzr/+bug/209689
<ubottu> Launchpad bug 209689 in bzr "KeyError in transport close _file_streams while pulling into a bound branch" [Undecided,New]
<mgedmin> why oh why bzr always punishes me for trying to start using it???
 * mgedmin unhappy
<nandersson> Is there I way to "Checkout from Bazaar" (launchpad) directly from BzrEclipse?
<nandersson> "a way to"
<jelmer> mgedmin: thanks for the bug report
<mgedmin> jelmer: no problem; have fun fixing it :-)
<NfNitLoop> nandersson: can't you "create a new project" and then choose bazaar -> branch or something like that?
<Tsmith> how do you comment in python?
<Tsmith> (trying to port svn hook to mantis)
<andrea-bs> Tsmith: # text
<Tsmith> thanks
<andrea-bs> you're welcome :)
<abentley> lifeless: ping
<jelmer> 'evening Aaron
<jelmer> abentley: Do you think it makes sense to move some of the code that figures out whether or not a revision has been merged to bzrlib?
<abentley> Code in BundleBuggy?
<jelmer> yeah
<jelmer> since I'm about to duplicate more of it in my plugin
<jelmer> and I suspect the launchpad merge request stuff has similar bits?
<abentley> It doesn't really seem like it.
<abentley> Too short to bother with.
<jelmer> abentley: No other objections though?
<jelmer> abentley: I'm looking at doing pattern matches seeing if .diffs have been merged
<abentley> Well, considering we've already got an implementation of missing, I'm concerned.
<jelmer> sorry, I think I'm not wording this very well
<jelmer> let me rephrase
<jelmer> abentley: Do you think it makes sense to move some of the code that figures out whether or not a merge directive has been merged to bzrlib?
<jelmer> e.g. as a MergeDirective.was_merged(branch_tip) function
<abentley> so basically b = Branch(); graph = b.repo.get_graph(); md.revision_id in graph.heads(md.revision_id, b.last_revision)
<mkanat> mwhudson: Still no 100% CPU. :-)
<nandersson> It seems I can not check out a Launchpad project directly from BzrEclipse, but I have to do a manual checkout first from the command line and then create a new project based on that branch in Eclipse.
<jelmer> abentley: Yes - for the current format
<nandersson> There is no thing like it's CVS counterpart "Create project from CVS"
<jelmer> abentley: regular patches or git merge directives (not sure how they call them) will be more complicated
<abentley> Well, I'm not clear whether heads is 100% trustworthy at the moment.  If it is, I guess it's okay.
<Pilky> does anybody know if anyone has done any sort of plugin for doing a --fixes thing that works with lighthouseapp.com?
<luks> Pilky: I don't think there is any plugin that touches external bug tracker based on the --fixes flag
<pickscrape> Can anyone point me at the steps I need to take to install loggerhead?
<Pilky> luks: isn't the launchpad integration done in a plugin, or does launchpad read the info from the branch when it's pushed up?
<luks> Pilky: launchpad reads it from pushed branches on it's own
<Pilky> ok
<Pilky> guess it's something I'll have to look into at some point in the future
<fog> I am trying to develop a bzr adding for MonoDevelop and calling bzr from the cmdline is quite slow. I'd like to write a little helper that communicated using stdio with the addin and answer simple queries like "whats the status of file xxx?". what's the best place to start? documentation or example code is available?
<LeoNerd> Maybe look at 'bzr shell' ?
<james_w> fog: jam had a plugin that was similar to this, bzr-service I think it was called.
<fog> thak you both
<jam> fog: and eventually bzr-xmloutput is supposed to turn into a full RPC for a service responding to bzr queries.
<jam> bzr-service spawns something that you communicate over (currently TCP sockets) eventually should be named pipes on windows / unix sockets otherwise
<fog> jam: I am currently using xmloutput but does not fit the monodevelop model well
<jam> though I haven't touched it in a long time
<fog> i need 3 different commands/outputs to just get the right information for a file
<jam> that may not change for bzr-service, since it is just a proxy for running "bzr foo"
<beuno> fog, Verterok has an xml-rpc client
<fog> file-id to see if a file is under version control, then status to get its status and then log to get extra information
<beuno> it uses the same concept of bzr-service, so it doesn't spawn a new bzr every time
<beuno> actually, it's going to be the new version of xmloutput
<beuno> fog, https://code.edge.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc
<fog> not spawning is fine, it is the spawning that is veeery slow.
<fog> beuno: thanks
<beuno> fog, np. He uses it for eclipse, and this made it *much* faster
<leandro_> hi all. I'm new (comming from cvs/svn) to bzr and I'd like to create a new repository for my project. I decided to used the svn layout MY-PROJECT/trunk. Should I create MY-PROJECT with --no-trees ?
<leandro_> I'm planning to store all branches under MY-PROJECT/
<james_w> leandro_: if you are planning to do your work there then you probably do not want --no-trees
<james_w> if you are setting this up on a server, and then you are going to use branches/checkouts locally to do the work then you probably do want --no-trees
<james_w> the second also applies if you are doing it in two places on the same machine, e.g. /var/repos/whatever and ~/devel/whatever for work.
<leandro_> james_w: I'm assuming all work will be done inside MY-PROJECT/trunk or My-PROJECT/branch-x
<leandro_> james_w: yes, I'm doing it on a server
<leandro_> but i will checkout MY-PROJECT/trunk, not My-PROJECT
<james_w> yep, then I suspect you want --no-trees
<leandro_> forget --no-trees then?
<leandro_> ah..ok
<leandro_> james_w: tks
<blueyed> I've asked a few days ago already about keeping local changes in a main.local branch (jam has helped me), but now it seems that every now and then I need to explicitly revert this "local" diff when merging.. the setup is as follows: "main" (dev branch) and "main.local", which has changes I don't want in "main", but for feature branches.. I've done reverse cherrypicking, but somehow bzr seems to forget about it, when I merge between those
<blueyed> branches now.
<abentley> jam: So the issue with iter_entries_by_dir is: given a, a/b, c, c/d, you think it'll give a, c, d, b instead of a, c, b, d?
<jam> abentley: correct
<jam> the last inserted was the last child of the previous directory
<jam> rather than the first
<jam> abentley: however, it may not show up in the children, but only in the grandchildren (underneath b and d)
<jam> nm, you already have grandchildren of ''
<abentley> jam: Okay.  That gives me a test I can use.
<NfNitLoop> blueyed: "reverse cherrypicking"?
<blueyed> NfNitLoop: well, not really.. but in general: merge the other branch, but drop the changes which should differ ("bzr revert ."), then commit.
<blueyed> basically, I want to have a (submit) branch from "main", with changes to "main", that should never make it into "main" (when merging from or into main)
<blueyed> NfNitLoop: "reverse cherrypicking" is described at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#reverse-cherrypicking
<blueyed> Is this not possible, because bazaar does not track cherrypick merges yet?
<abentley> jam: Are you satisfied with my email explanation of why we don't need to test the unchanged case?
<jam> abentley: for the other ones, yes
<jam> I wasn't sure if that was true, just was pointing out it didn't show in the changes
<abentley> Are there some that you think we *should* be testing that we're not?
<abentley> jam: I'm not sure what "for the other ones" means.
<jam> for things other than testing iter_entries_by_dir()
<NfNitLoop> blueyed: your answer seems to be in that document.   "Unlike a normal merge, Bazaar does not currently track cherrypicks."
<abentley> jam: Okay, I've added an iter_entries_by_dir test (using the example in tree.py) and an annotate-with-rename test, and plan to merge everything I've submitted in that series.
<blueyed> NfNitLoop: yes, that's what I've thought now.. I cannot believe though that this workflow (having a branch with permanent changes) is not supported..
<abentley> Thanks for your reviews.
<jam> I'm not sure that I got to everything
<jam> but I at least did a good amount
<NfNitLoop> blueyed: it's only when you cherrypick that it gets forgotten.  Usually you just branch off from main and then 'merge' (non-cherrypick) from main as you move forward.
<name> hey
<NfNitLoop> blueyed: there's also another plugin/workflow which you may find useful...
<NfNitLoop> weave?  thread?  I forget.
<name> how do i see which branches i have got in my working copy
<NfNitLoop> bzr switch?
<blueyed> NfNitLoop: but I want to merge from and to main.local to main.. that seems to be the problem.. loom? (which seems to provide threads)
<blueyed> name: "bzr info -v"?
<NfNitLoop> blueyed: aah, loom.
<name> ah bzr branching is kinda different than git ;)
<NfNitLoop> I'm not sure if loom is what you want.
<NfNitLoop> (blueyed)
<abentley> jam: You did everything directly related to PreviewTree that I've submitted.  Which is great.
<abentley> jam: When lifeless turns up, we can figure out what to do about get_parent_map
<name> now to my real question. what file in loggerhead shows the source of the file you are viewing? i am trying to implement syntax highlightning
<NfNitLoop> blueyed: I guess I'm not quite getting your workflow.   If you keep main and your branch separate and never merge in changes from main then eventually they'll diverge so that merging from branch into main becomes painful...
<blueyed> NfNitLoop: I merge changes from main to main.local (and the other way around): I'm merging another upstream branch (CVS/tailor) to main, which I want to have in main.local, too. But new features/fixes come through main.local (or another branch from main - "production").
<NfNitLoop> so, just continually merge in changes (non-cherrypick)  from main.local into your bugfix branches.
<NfNitLoop> I think I'm losing track of your original issue.  *reads scrollback*
<blueyed> NfNitLoop: sorry for causing confusion.. the problem appears to be when I merge from main to main.local or from main.local to main.. then the (cherrypicked) difference gets applied again.
<NfNitLoop> don't cherrypick differences.
<NfNitLoop> just merge them.
<NfNitLoop> if you cherrypick, bzr cant' track it.
<blueyed> Sure. But I need to cherrypick the differences (once).. but then when merging, they get applied again, I "bzr revert" them, but they keep on coming in..
<NfNitLoop> why do you need to cherrypick the differences?
<NfNitLoop> if you branch from main->main.local
<blueyed> Because when I do "bzr merge main.local" in "main" the first time, I get the local changes..
<NfNitLoop> that's... what that command is supposed to do.
<blueyed> So I "null merge" them, as jam called it..
<blueyed> yes.
<blueyed> But I don't want to revert the changes between those branches every time I merge them..
<NfNitLoop> it doesn't...
<NfNitLoop> or shouldn't.
<NfNitLoop> I still don't see any reason to cherrypick in your workflow.
<NfNitLoop> I think we may have a communication issue.  can you run some commands and paste them to a pastebin to show the behavior you're describing?
<blueyed> NfNitLoop: that's what jam recommended, but essentially "bzr revert [particular files]" is a synonym for (reverse) cherrypicking here, isn't it?
<blueyed> NfNitLoop: sure.
<NfNitLoop> blueyed: aaah.   Yes, if you did 'bzr revert .' and then 'bzr commit', then you have told that branch to merge in the changes, *and then* reverse them.  and commited that to history.
<NfNitLoop> so you'll never be able to merge them in.
<NfNitLoop> because it thinks they already are.  (and then have been changed back.)
<blueyed> NfNitLoop: so, am I doing something wrong? Maybe I need to add another intermediate branch?
<NfNitLoop> blueyed: yeah, I dont' think you need to 'bzr revert .', unless there were more details about that case that I mentioned.
<NfNitLoop> so, let's see what your use cases are.
<NfNitLoop> 'main' mirrros some remote repo? ]
<blueyed> NfNitLoop: well, I need to do "bzr revert [files that shouldn't have get merged]"..
<NfNitLoop> blueyed: that's not quite what that does.
<blueyed> NfNitLoop: main is bzr+ssh://blueyed@bazaar.launchpad.net/%7Eblueyed/b2evolution/dev/
<NfNitLoop> it should more read as 'bzr revert [file-changes taht should never get merged]'
<blueyed> NfNitLoop: yes.
<NfNitLoop> but if they should never get merged... how are you going to merge them in in the future?   why not just remove them from main.local?
<blueyed> NfNitLoop: well, they are in main.local, because they are changes like "$debug = 1" and other changes useful/needed for local development.
<blueyed> ..and therefore I want to have them in my feature branches, too.
<NfNitLoop> yeah...  I'm not sure you want to check those in to any branch...
<NfNitLoop> it really complicates your branching/merging scheme.
<NfNitLoop> IMO, only check in production code.  have other files or settings files to enable debugging.
<NfNitLoop> (Others?)
<blueyed> well, in the case of creating a new feature branch, it makes it easier (to have those changes there already)
<mwhudson_> hello
<NfNitLoop> blueyed: but any time you try to modify code that you've rejected from your main branch, the merge is going to barf.  (I think.)
<NfNitLoop> I'm speculating here, since I haven't tried this workflow.
<NfNitLoop> likewise, if you ever try to merge main->main.local, it'll try to delete your debug statements.
<blueyed> NfNitLoop: well, I'm not modifying those changes to main.local (in main or any other branch).. the problem is just that the changes come back "as-is".
<blueyed> NfNitLoop: exactly.
<NfNitLoop> right.  so, I would recommend against that workflow. :p
<blueyed> :D oook.. ;)
<NfNitLoop> you've read the bzr workflows page?
<NfNitLoop> You may find one there that works for you.
<NfNitLoop> Hmm... there's another one....
<blueyed> I've read it once, yes, but it seems to be more generic than this.
<NfNitLoop> what's the workflow that lets you table changes?
<NfNitLoop> is that loom, or another one?
<blueyed> I'll look at loom or something similar..
<blueyed> yes, with threads.
<blueyed> Read about it the other day, but it sounded quite complicated (was related to keeping the patch size limit for bzr patches)
<NfNitLoop> right.  so in your .local branch you could shelve those changes, merge from main, then re-import your dev changes.
<NfNitLoop> that way the bits without your .local changes merge cleanly.
<NfNitLoop> http://bazaar-vcs.org/BzrShelveExample?highlight=(shelve)
<blueyed> well, shelve is something different (which I've used already)
<NfNitLoop> Hrmm, actually, committing them to a loom/thread might be easier than hand-picking them each time.
<NfNitLoop> yeah.
<blueyed> It's not about conflicts in merges after all.
<NfNitLoop> Hmm.
<NfNitLoop> you could have main (remote), dev (new features) and debug(debug statements)
<NfNitLoop> merge from main->dev
<NfNitLoop> imlpement new feature.
<NfNitLoop> commit.
<NfNitLoop> merge that into dev
<NfNitLoop> er, into debug.
<NfNitLoop> test it in debug.
<NfNitLoop> if it works, push dev -> main
<NfNitLoop> and your debug statements never enter the rest of the branches.
<NfNitLoop> which I guess is sortof what loom would offer in a single branch.
<blueyed> well, I'd like to have "debug" in "dev" during development, of course.
<blueyed> I'll look into loom etc some more later, thanks for your help and feedback.
<lifeless> Ã±moin
<lifeless> abentley: hi
<abentley> lifeless: we have inconsistencies between VersionedFiles.get_parents_map and PlanMergeVersionedFile.get_parents_map, when it comes to parentless revisions.  Sometimes you get (), sometimes you get NULL_REVISION.
<lifeless> sorry!
<abentley> I'd like to unify them.
<abentley> Interestingly, at least some of the old calling code was expecting ().
<lifeless> heh. so the NULL_REVISION emitter was for code expecting the behaviour of a Graph created from a Repository which we needed to reused
<lifeless> we could push NULL_REVISION down to VersionedFiles
<abentley> lifeless: That's my favourite option, and I think John expects that.
<lifeless> +1 from me
<abentley> So to be clear, the ancestor of ('file-id', 'one') would be ('null:',)
<lifeless> using NULL_REVISION rather than a tuple is a little strange, but it works with all key-lengths, and with all the current graph code, which is why I did it back last year for pack repos
<lifeless> I'm happy for you to use NULL_REVISION or (NULL_REVISION,) - whichever you like
<lifeless> if you go for the latter, can I suggest a symbolic constant of NULL_KEY
<abentley> NULL_REVISION isn't an aribtrary constant, though.  It's just a paranoid way of writing the revision-id "null:".
<lifeless> yes
<abentley> So I prefer a tuple-- and NULL_KEY WFM.
<lifeless> jam: good catch on the bloom use
<jam> lifeless: howdy
<jam> lots of changes for you to pull :)
<jam> lifeless: so... I outlined it in an email, but I think the next best way to improve performance is a dynamic bloom
<jam> I think we can shrink a bloom with no loss
<jam> and we can expand with minimal loss, as long as the bloom isn't already full
<jam> (well, it has to be rather empty, but that can be controlled)
<jam> that would let us grow the bloom as we need to, without always allocating a 10MB bloom and then shrinking it
<jam> lifeless: and cache thrashing is 100% why iter_random_all performance sucks
<jam> If you make the node cache bigger, or start caching the individual lines, performance goes from 100s => 8 => 4s
<jam> versus Graph at 6s
<lifeless> jam: I think its worth investigating a root bloom vs leaf-1 bloom
<lifeless> I knew about the cache thrashing btw - it was in an early email :)
<jam> lifeless: sure, I just have hard numbers to show for it :)
<lifeless> jam: so did I :) (I tested 100 and 1000 page caches at the time) :>
<lifeless> jam: so, I'm going to commit my tweaks and merge
<lifeless> jam: we save nontrivally by only looking at the bloom adjacent to the leaf
<jam> aka the last one?
<lifeless> 2seconds out of 46
<lifeless> yeah, only probing once
<jam> lifeless: what benchmark?
<lifeless> random, ccompononents and miss
<jam> well, multiway is going to conflict with your changes
<jam> and brings in 20 => 10s for miss
<jam> and about the same for ccomponents
<lifeless> cool
<lifeless> does multiway bloom as well?
<jam> lifeless: yes
<jam> miss_torture 25.094 => 10.96
<jam> get_cc 28.4 => 14.5
<jam> search 2.5 => 1.2
<jam> though this is my code and not yours, so I might have down-performed some stuff
<jam> Also, my repository recently reset itself, going from 18+ packs to 12
<lifeless> :P
<jam> I must have rolled a digit
<lifeless> I don't commit in the same repo
<jam> but I was careful to test these on the same repo
<jam> lifeless: yeah, I just rsync'd mine out of the way
<lifeless> wheee
<jam> ?
<lifeless> yes iter_entries does 'conflict'
<jam> It wouldn't be hard to bring in your "only check the last row bloom"
<jam> though I also pre-compute all of the key => offset mappings
<jam> so I'm not sure if you would see the same savings
<jam> Your original code had to do N sha1sums at each row
<lifeless> is get_raw_offsets in the pybloom code?
<lifeless> or do I need to pull ?
<jam> lifeless: no it is in NodeBloom
<lifeless> cool
<jam> I haven't committed stuff to pybloom yet
<jam> Though if I did work on dynamic blooms, I would probably do it there first
<jam> abentley: ping
<lifeless> jam: Oh, I've replied to your analysis with some thoughts
<jam> lifeless: and I think I replied to your reply :)
<jam> I think bringing the leaf key cache up a level could be interesting
<jam> probably significantly more beneficial overall
<jam> plus, sharing a cache means less waste, etc.
<lifeless> jam: aah cool
<lifeless> jam: oh, you look for a branch now ?
<jam> lifeless: yeah, so I can get a proper ancestry to search
<jam> I kept getting nodes on a trivial plugin
<jam> and then search would be like 0.1s
<lifeless> :P
<jam> I changed the search as well
<jam> mostly because it was easier to assert correctness with
<jam> iter_ancestry(
<jam> though having to change from tuple keys => revision_ids sucked
<jam> especially because of the NULL_REVISION hackery in bzrlib
<lifeless> there is an adapter in bzrli
<lifeless> but yes
<lifeless> jam: I see iter_random_one at 113 seconds still ?
<lifeless> jam: is there some option I need to tweak?
<jam> lifeless: you need to enable the line cache
<jam> or increase the node cache
<jam> lifeless: line 391 in btree_index:
<jam> self._leaf_value_cache = None # lru_cache.LRUCache(100*1000)
<pickscrape> Is there any way to tell bzr init to ignore any shared repository it finds?
<pickscrape> Or would issuing bzr init-repo first have the desired effect?
<jam> pickscrape: not ATM, though you can 'bzr init-repo' in the inbetween
<pickscrape> jam: thanks :)
<jam> lifeless: I disable the line cache for testing other things, to see how much it helps/hurts, If you want to move the key cache into the combined index, I would recommend that :)
<jam> lifeless: I just saw this: self._page_size = transport.recommended_page_size() is that "future work"  showing its head?
<lifeless> jam: yes
<jam> I was a bit curious how you would handle page_size % _PAGE_SIZE != 0
<lifeless> jam: my very initial concept for write once index segments had a fixed size page with network hint
<lifeless> jam: round :)
<jam> lifeless: so the idea would be that if you push to remote, it would auto bloat the page size
<jam> well, auto increase at least :)
<jam> bloat is probably a bad term
<jam> abentley: If you get a chance, I'd like to chat quickly on how to pass parameters between the merge objects
<abentley> jam: sorry, on a call
<jam> np
<lifeless> jam: well two things
<lifeless> jam: you could read additional internal nodes optimistically
<lifeless> jam: and you could make a bigger page size if you think it makes sense
<jam> lifeless: yeah, I think the former is likely to be very good, I'm not sure if the latter gets you much
<jam> especially if your transport supports arbitrary reads
<jam> we really just want to cap the minimum size
<jam> rather than bloat every request
<jam> well, that is my thought at least
<jam> if I am already reading 64k across 16 disjoint pages, that seems fine
<lifeless> jam: if there is not much cost to do that; of course FTP has a huge cost ;P
<jam> lifeless: right, this is more for HTTP & bzr+ssh
<lifeless> but I'm not worried about FTP per se; but even http and sftp have some trouble with arbitrary readvs
<jam> and *maybe* sftp with pipelining
<jam> http does pretty good for most servers
<jam> except squid proxies :)
<jam> and the ones that don't support it at all (like BaseHTTP)
<abentley> jam: pong
<jam> abentley: so the first problem I'm facing... Merger is the class that find the unique_lca base, and detects a criss-cross, but Merge3Merger is the one that deals with paths, etc.
<jam> Do I just need to add a "supports_XXXX" member and then pass it in the __init__ like we do now?
<abentley> Not clear what we'd be passing.  The multiple LCAs in a criss-cross?
<abentley> Don't we want that on a per-file basis?
<jam> abentley: for the whole-tree-paths logic, I use the whole tree LCAs
<jam> but at a minimum, I want to pass the criss-cross flag
<jam> my merge3 code just passes it unconditionally, but certainly that isn't "compatible"
#bzr 2008-07-03
<abentley> So yeah, compatibility would suggest checking whether the class supports that parameter.
<abentley> like supports_reverse_cherrypick.
<pickscrape> This is weird. I'm trying to bzr rm a symlink to a directory, but it is complaining about the files in the directory the symlink links to
<pickscrape> An no, I'm not appending a slash to the end of the symlink name
<lifeless> pickscrape: I believe we have a bug :(
<lifeless> beuno: wb
<pickscrape> lifeless: passing the --force flag does the right thing (the target directory is not affected)
<pickscrape> Not the correct user experience though. I'll raise it in launchpad.
<tolstoy> Loggerhead! I'm going to see if I can even get CLOSE to setting it up..... ;)
<NfNitLoop> hrmm, does bzr version symlinks?
<lifeless> jam: why did you change it from using calltree?
<lifeless> NfNitLoop: yes
<NfNitLoop> Huh. cool.
<lifeless> pickscrape: thanks
<jam> lifeless: you mean callgrind?, because I don't have KCacheGrind on win32, you can change it back if you like
<NfNitLoop> I noticed a bug the other day re: operation on a case-insensitive filesystem.
<NfNitLoop> is that known?
<NfNitLoop> I tried adding file x, when it had already been added as X.
<jam> save('filename.callgrind') should give the same result, btw
<NfNitLoop> and it committed it a second time.
<NfNitLoop> and then complained that it was missing. :p
<lifeless> jam: parameterised it
<lifeless> NfNitLoop: oh, foo. File a bug ?
<lifeless> NfNitLoop: thats the sort of thing that makes usage for windows users (or FAT under linux) particularly painful.
<NfNitLoop> yes.  I'm all too familiar with file case issues and still was a bit confused as to what was going on.
<NfNitLoop> I'll try to create a sample and submit that tonight.
<jam> lifeless: latest version of PyBloom has a bloom.resize() function, so we can poke at it if we want.
<jam> I'm done for the night, though. Off to dance class
<jam> lp:~jameinel/+junk/pybloom
<lifeless> jam: tchau
<lifeless> jam: what dance style?
<jam> ballroom, aka latin, waltz, swing, etc
<lifeless> nice
<lifeless> I keep meaning to get back into that
<lifeless> so
<lifeless> parse_lines and string split make iter_random_one cry
<lifeless> a C parser would be substantially more efficient
<lifeless> (I'd like to drive the cost of random access way down, because it its a good total-cost proxy)
<tolstoy> Hm. I can't seem to install Paste 1.1.7
<Odd_Bloke> Moin.
<tolstoy> Er, 1.71.
<tolstoy> Make that Paste 1.7.1.   ImportError: No module named setuptools
<tolstoy> I wonder why all the other "python setup.py install"s I did?
<name> do easy_install setuptools
<pygi> somebody wanna raise their voice on the whole GNOME+DVCS stuff?
<Odd_Bloke> tolstoy: Or, better, use your package management system if you have one.
<james_w> hey pygi. I liked your post on the matter.
<name> which gnome+dvcs stuff?
<tolstoy> Odd_Bloke: This is on Solaris, all inside a user account.
<tolstoy> I don't think I have "easy_install" on there.
<pygi> james_w, thanks, I just wrote a big comment addressing concerns Jason raised
<tolstoy> Yes, yes, it feels like I've gone back in time decades by not having root on this box.
<pygi> name, the discussion of GNOME migration to DVCS
<Odd_Bloke> tolstoy: http://pypi.python.org/pypi/setuptools/
<tolstoy> Are setuptools not normally part of the Python? And not required for other versions of setup.py?
<tolstoy> (I'm so far away from Python culture these days, alas. Close as I can get is Groovy.)
<Odd_Bloke> tolstoy: I believe that most setup.pys use just distutils.
<Odd_Bloke> But I'm not sure.
<tolstoy> Okay. Cool. That makes sense.
<name> Odd_Bloke: yes they do
<james_w> pygi: thanks, just read it. Jc2k has raised some similar points to you, and I think it's very important, and not something that's being discussed at the moment. I don't have any voice in GNOME to try and steer the conversation, but I'd be happy to comment on a migration plan for bzr.
<james_w> pygi: are you a git fan, or is gitorious just very good for what you want? Would you prefer bzr, or is the abstraction of everything what you would like?
<pygi> james_w, as I've written in the post, I'm not a fan of either git or bzr
<pygi> I use both where I see fit
<pygi> (heck, I've even mentored two bzr students in 2006)
<pygi> james_w, currently, something like gitorious doesn't exist for bzr
<pygi> and no, you can't count LP, because it is not free
<james_w> pygi: ah yeah, I forgot that sorry.
<name> pygi: why is LP not free?
<pygi> james_w, the problem is people keep going in circles, rather then discussing important points
<james_w> pygi: yeah, that's what lp is trying to do, but it's obviously not going to work for GNOME.
<pygi> that's why I hope my post will bring at least put bug in peoples ear :)
<pygi> name, because its not Free by FSF definition :)
<pygi> james_w, if you wanna work with me, we could surely write a plan for bzr
<pygi> I'm all for it
<pygi> james_w, it the end, it all comes down to communication and collaboration, as I've mentioned
<pygi> these folks forgot what that is lately
<thumper> pygi: are you looking for somewhere to put bzr gnome branches?
<james_w> yeah, these tools are supposed to help with collaboration, not cause fights.
<james_w> pygi: there's a #gnome-bzr channel on gimpnet that may be more appropriate if we want to have longer discussions on this topic, there's a bunch of people there willing to work to make this happen.
<james_w> hey thumper
<thumper> james_w: hey
<thumper> james_w: getting kinda late where you are?
<lifeless> pygi: where is your post ?
<pygi> lifeless, moment :)
<pygi> lifeless, http://pygi.wordpress.com/2008/07/01/broken-by-birth/
<pygi> thumper, it
<pygi> thumper, it's a little more complicated then that
<pygi> james_w, ok, will come there (You have pm too, btw)
<james_w> thumper: aye, just finished a meeting.
<thumper> james_w: work style meeting?
<james_w> thumper: yup, platform team weekly.
<lifeless> pygi: are you aware that savannah, and alioth support bzr ?
<lifeless> pygi: (by which I mean, what is 'like gitorious' mean) ?
<pygi> lifeless, yes, I am aware that they support bzr
<lifeless> ok, cool
<pygi> lifeless, it's not only about supporting bzr per-se
<Pilky> pygi: if you're wanting the ability for people to use whatever DVCS they want, then wouldn't svn as the central repo work best?
<pygi> it's about making it easier for everyone involved
<Pilky> from what I understand the svn integration in bzr, git and hg is better than the integration between the 3
<james_w> night all
<pygi> Pilky, that's what people are currently doing mostly
<lifeless> night james_w
<pygi> but that means overhead
<Pilky> true
<pygi> Pilky, anyway, that was just a suggestion on how things *could* be handled
<pygi> what is important is for people to finally realize they're not going anywhere with useless arguments sometimes even on personal level
<Pilky> yeah
<Pilky> the unfortunately reality about we programmers is that when we start liking a tool we'll fight to the death over it ;)
<pygi> I know, but sometimes you have to think above tools
<pygi> If I was a new folk in the FOSS community, and read planet GNOME, I'd run away from the project as faster as possible
<pygi> because of the recent events
<lifeless> pygi: I think you make good points
<pygi> lifeless, any questions or critics perhaps? Those always help flesh out the idea :)
<Pilky> pygi: there's a reason I don't do a huge amount of open source stuff (or at least large stuff), it's far easier to get your own way when you're the sole dev ;)
<lifeless> pygi: well, one thing to note is that bzr itself has an abstraction system; it can natively talk about hg and svn and a number of bzr formats
<lifeless> pygi: (in a way that none of git/hg/svn try to do)
<pygi> lifeless, yep, am aware of that =)
<pygi> thanks for pointing it out ;)
<lifeless> for instance, pqm had a multi-dvcs abstraction
<lifeless> and now we're ripping it out to replace with bzr plugins
<pygi> Pilky, I prefer to stay out, and maintain a lot of stuff outside such projects (the only exception is xfburn (xfce project), but it was initially started there, so can't change it for the time being)
<pygi> lifeless, I should really look further into pqm branch then (I guess it's on LP as usual)
<Pilky> pygi: the only "major" open source project I've worked/am working on is BazaarX, everything else is my shareware apps
<pygi> Pilky, ah, no Mac here, sorry :)
<lifeless> well, pqm is not the cleanest code base. Yes its on lp. But the point there was just that /one/ approach would be to write admin toolchains in bzr, as a lingua franca
<lifeless> much as is being done with svn today, but being D aware
<Pilky> pygi: heh
<pygi> lifeless, understood
 * pygi is thankful for all the comments ;)
<pygi> lets hope I can put them to good use :)
<lifeless> I'd argue that gnome has a gitorious itself /already/
<lifeless> just called 'gnome-svn-orius'
<pygi> ehm, well, if you can call the current platform they use that way, yes
<lifeless> well
<lifeless> what is it about gitorius as a system that could save admin time
<lifeless> is it outsourcing - but gnome could have gotten a variety of sites to host the svn migration
<pygi> lifeless, ehm, no, its not about that
<pygi> lifeless, gnome would have its own instance ofcourse, and not *plain* Gitorious
<lifeless> right
<pygi> I've outlined some of the things that would save admins time in my latest comment
<lifeless> so why would it be easier for the admins :)
<pygi> but there are a lot of stuff we could change to make it even easier for them
<pygi> thats why I want the discussion
<pygi> which I managed to initiate at KDE (sadly I can't attend Akademy, but oh well)
<lifeless> pygi: right, so my point is 'what would make the sysadmins life easier' is a good discussion and quite orthogonal to changing vcs -except- insofar as different vcs's have different admin overheads
<pygi> lifeless, I definitely agree
<pygi> lemme c/p excerpt:
<pygi> "Maintainers of specific module could approve users for commit access to âmainlineâ or main repository, giving administrators less work. New modules/projects could be added by existing GNOME developers after their inclusion has been discussed. New translators and documentation writers could get their commit bits much easier"
<pygi> as an example ofcourse, I can't count all the use-cases
<lifeless> I think that thouse things are actually highly automated at gnome already?
<lifeless> I was thnking of things like bkor having to script some massive dump+load for all 520 svn modules to handle 1.5
<pygi> some things are, some things aren't
<pygi> lifeless, that's the part where I say whats needed prior to migration :)
<lifeless> K
<pygi> lifeless, we could have an interface that would allow upgrading all repos to say new bzr format
<lifeless> pygi: right; not to mention that bzr can do that it self remotely
<pygi> indeed
<pygi> I just gave that as an example
<lifeless> :)
<pygi> lifeless, I definitely agree that everything you mentioned should be discussed
<pygi> lifeless, but before that, we need to make people collaborate the way they can once again
<lifeless> we can't make them, we can only try to collaborate with them
<pygi> well, yes, and by collaborating with them change the way they think about collaboration =)
<lifeless> which is a little hard when you get told you're stupid or insane for making an informed design decision :)
<pygi> lifeless, eh, even though I doubt anybody will listen to whatever I wrote in the post, they'd listen even less if I actually argued technical reasons behind whatever DVCS they choose
<pygi> or if I accidentally mentioned that I prefer one over the others
<lifeless> pygi: sure, not suggesting you should get technical; I was noting that unpleasantness doesn't help collaboration - and there has been plenty in some of the previous months/years about DVCS
<pygi> lifeless, and not only DVCS ...
 * pygi should probably do some bzr hacking this summer if he gets the time
<lifeless> pygi: that would be cool
<lifeless> pygi: will you be at GUADEC? I'd be happy to point at internals face-to-face if you are
<pygi> lifeless, eh, sadly no :(
<lifeless> ah well
<pygi> but I'd be happy to learn more about internals over irc/mail/jabber/whatever :)
<lifeless> we've done a lot of scalability work since 2007
<lifeless> many more things that only look at small subsets of history
<lifeless> still need to fix inventories to not be full-tree-objects
<NfNitLoop> lifeless: Looks like someone beat me to it (by a year or so) reporting case insensitive fs issues.    https://bugs.launchpad.net/bzr/+bug/77744
<ubottu> Launchpad bug 77744 in bzr "win32 bzr is confused by filename case changes" [High,Confirmed]
<NfNitLoop> I pasted my test as well.
<lifeless> NfNitLoop: thanks
<mwhudson> *cough* bzr log *cough*
<NfNitLoop> mwhudson: eh?
<mwhudson> just carping at lifeless's "many more things that only look at small subsets of history"
<NfNitLoop> aaah.
<lifeless> mwhudson: *many* not all
<lifeless> mwhudson: if you compare what we _used_ to do
<mwhudson> yeah, it's much better, i'm just being annoying
<lifeless> go merge the loggerhead search integration branch or something
<fullermd> Boy, that's sad.  missing took 26 seconds.  pull took 9.
<NfNitLoop> heh.
<fullermd> Hm.  Are these location-based aliases documented somewhere I can't find?
<mwhudson> fullermd: which version of bzr ?
<mwhudson> i know missing got some love recently
<fullermd> bzr.dev local, 1.5 remote.
<mwhudson> hm
<mwhudson> should be new enough :/
<lifeless> bkor: ping
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> did you end up having time to look at the gnome hooks?
<AfC> lifeless: (I suspect Olav will be asleep)
<lifeless> AfC: so do I but it never hurts to try :)
<spiv> gnome hooks?
<fullermd> Sure.  You don't want 'em just wandering around the garden unsupervised...
<lifeless> spiv: yes - the ones they run on svn, which we'd need to support
<spiv> Ah, no, I hadn't looked.
<lifeless> could I entice you to look? You've done some server-hook stuff before..
<igc> morning
<lifeless> hi igc
 * spiv looks
<Odd_Bloke> lifeless: Apologies if I just spammed you with LP merge requests, I was playing around with the interface and didn't realise it generated emails.
<spiv> staging.launchpad.net is a handy sandbox for experimenting with.
<JamesB192> I am trying to misuse bzr as a versioned backup program, I have created the remote and local branches, and am running a server for the remote. Is there a tutorial for this type of misuse or do I have to RT(Entire)FM? ps using bzr send I get the error 'bzr: ERROR: No mail-to address specified.' how do I make it go away?
<Odd_Bloke> spiv: Well, the merge requests are valid, so it doesn't matter if they're in LP proper.  I just didn't intend to send lifeless a number of emails (which largely mirror on-list discussion anyway).
<lifeless> Odd_Bloke: :)
<lifeless> JamesB192: well bzr send is used to create emails, you probably want bzr push
<JamesB192> Ah, OK.
<Odd_Bloke> lifeless: Did you get a merge request (not via LP) that I sent a little while ago.  I CC'd the ML but haven't seen any sign of it and am wondering if it got through.
<lifeless> yesterday?
<Odd_Bloke> Hold on, I'll find a timestamp.
<lifeless> or earlier today, cause I saw one yesterday and one earlier today
<Odd_Bloke> lifeless: This one was sent, according to GMail, on the last hour (so around 40 minutes ago).
<Odd_Bloke> But I'm using GMail via IMAP, which can occasionally be a bit funky.
<Odd_Bloke> Subject was "[PQM/MERGE] Remove Arch-style naming from tests".
<lifeless> yes
<lifeless> uhm, I think its fine
<Odd_Bloke> OK, good.
<Odd_Bloke> The reason I asked was because I was going to reply to it to mention that it depends on my 'fix-tests' branch, but haven't had the chance to do so yet.
<Odd_Bloke> Then I started playing with LP. :p
<lifeless> :)
<spiv> lifeless: well, I've looked.  The post_change_branch_tip hook should be able to do the post-commit actions fairly straightforwardly I think.
<spiv> lifeless: (and thanks to my push work it turns out that that hook *does* get run server-side now!)
<spiv> lifeless: but we probably need to add a pre_change_branch_tip hook as well.
<spiv> lifeless: because there's a fair bit of checking of the commit before it is accepted (there must be a log message, PO files should be syntactically correct, etc).
<lifeless> spiv: I'm really sorry that I hadn't drawn it more visibly to your attention earlier; I think you were in protocol-3 space
<spiv> Yeah, I probably was at that time.
<spiv> I don't think adding infrastructure for a pre_change_branch_tip hook should be too hard.
<spiv> Also, pre-1.6 clients won't trigger that hook, because they will be using VFS RPCs to update the last revision info.  I'm not sure how much that will matter.
<lifeless> spiv: any chance for GUADEC? :P
<lifeless> spiv: well, we could add a version check policy on the server?
<spiv> If it does matter, we could probably hack up a plugin for the server that traps that VFS call and invokes the right hook(s).
<spiv> Hmm, we could do that, I suppose, by e.g. writing a plugin so that the server will reject non-protocol-3.
<lifeless> spiv: don't client give their verison now ?
<spiv> Probably no easier than hooking VFS calls that change */.bzr/branch/last-revision, though.
<spiv> They do, but as a string.
<spiv> That header was intended for logging rather than greater-than/less-than version comparisons.
<spiv> But protocol-3 happens to be new in 1.6, as is that verb.
<spiv> I'd rather not get into comparing strings like "1.6b3" and "1.7" and "1.10".
<lifeless> right
<lifeless> but isn't the string taken from the string made from the tuple ?
<spiv> It is bzrlib.__version__, yeah.
<spiv> I'd rather introduce a new header if we do that, though.
<spiv> So we keep the concepts of user-agent-label and protocol-level-I-speak separate.
<spiv> The current header is "Software version", and is intended to be the former.
<spiv> Maybe I should just rename it to "User agent" :)
<lifeless> right
<lifeless> but -
<lifeless> there are two levels of protocol
<lifeless> there is 'how I encode'
<lifeless> and there is 'what verbs I will try'
<spiv> We can add another header pretty painlessly, but we should think about how we want it to work and what use cases we want it to satisfy.
<lifeless> anyhow
<lifeless> I would like to be able to say to bkor: 'bzr X on server, bzr X or > on client, plugin Y on server'
<spiv> Ideally, we shouldn't need to rely on the client to indicate what verbs it will try, we should just DTRT based on the verbs they do try :)
<lifeless> and have : ported checks from svn run reasonably fast and appropriately, and reliably.
<spiv> Porting the checks from SVN will take a bit of effort.  Not gargantuan, but not trivial either.
<lifeless> yah
<lifeless> I'm sure bkor would be happy to do that bit
<spiv> Although "poke the viewcvs so that it knows about the new revision" bit will hopefully be unnecessary with loggerhead :)
<lifeless> (though perhaps not as happy as if we did it :P)
<lifeless> now for the argh! bit. the DVCS talk is on monday :)
<spiv> Well, I'd be happy to help port them.  Realistically it'll probably be easier for us to work with them than for either side to try port them alone.
<spiv> Ok, so you'd like the pre-commit capability done ASAP?
<lifeless> if its doable this week, then yes. otherwise no - we can say we know what it will take and its coming
<spiv> Well, I don't think it'll be hard.  I'll spend an hour or so on it to see if it really is feasible that quickly.
<lifeless> sweet
<spiv> I wouldn't be totally shocked if there's a couple of unexpected bumps between here and having it done, but I wouldn't be shocked if it's plain sailing either.  We'll see :)
<jam> lifeless: any updates on btree? I haven't seen any commits or posts since I left :)
<lifeless> jam: just doing C parsing for _leaf_nodes
<lifeless> jam: 60% of that 110 seconds is claimed to be in the parsing
<jam> lifeless: sure
<jam> If you consider... it takes 1s to read all nodes (iter_all)
<jam> and we get maybe 100-200 nodes per leaf
<jam> and we have a 50% cache rate
<jam> 200 * .5 * 1 = 100s
<jam> lifeless: pyrex or raw C?
<lifeless> pyrex
<lifeless> adapting _knit_load_data
<jam> :)
<lifeless> I'm not sure its wrong
<lifeless> but profilers -  meh
<lifeless> anyhow, finding out is relatively cheap
<lifeless> what dance did you do tonight?
<lifeless> its disconcerting that the three-level test kicks in before the progress bar debounce
<jam> we did rumba and waltz tonight, focusing on underarm turn and breakaway 5-something
<jam> 5position whatever, where your foot is crossed behind the other
<jam> lifeless: yeah, the "nothing is happening" is why I generally run with -v
<jam> lifeless: So I'm poking around at our bloom stuff, and I was noticing that our bottom level rows have more nodes than I think you give them credit for
<jam> I'm seeing bloom filters with 9,000 entries
<jam> I think the bottom level is < 100, but you have at least that many in the internal node
<jam> So to be useful, we would need bloom filters of ... 9000 bytes
<jam> Now, this is for the biggest pack in all packs
<lifeless> wheee thats quite some compression
<lifeless> oh right
<lifeless> yes, I was saying that only the bottom level of filter is really useful
<jam> lifeless:  that *is* the bottom
<jam> leaf nodes + 1 internal = 9000 records per internal node
<jam> Otherwise you only have leaf nodes
<lifeless> oh
<jam> and if you've already read them ...
<jam> so the *only* time these are useful is when you have 1 root node, because you didn't fill it all the way
<lifeless> eh, this doesn't make sense to me
<jam> lifeless: each internal node can map to 100 other nodes
<jam> right?
<lifeless> how many keys are in each leaf?, and how many leaves per internal node
<jam> And each leaf node can hold 90
<lifeless> so, 9K yes
<lifeless> but - we *are* seeing IO avoidance already
<lifeless> I don't know what our FPR is in practice
<jam> I get approximately the same values by just using "Num nodes / row_length" manually looking at the headers
<jam> lifeless: we aren't getting any hits on the big packs
<jam> it is only packs with < 9k records total
<jam> so you have a single root node
<lifeless> jam: ah, interesting theory
<lifeless> jam: making indexbench tell us this would be good
<jam> lifeless: -Dindex will print out the bloom statistics for every finalize
<lifeless> also, trying say a 512byte filter - which will push out some nodes from the internal
<jam> Finished node 1 with bloom filter <BloomSHA1 @ 0x3b3b690: 2048 bits, 3635 entries, 0.6 b/e, 100.0% gray>.
<jam> lifeless: the only problem is the finish_node() has no idea what level it is at, so I had to hack in another debug statement before it gets called
<lifeless> jam: yes, I added that :P. What I mean is at the external level, to tell us what the aggregate usefulness is of the bottom internal row
<jam> so, there is one other case that it slightly helps, which is the 'last added' node.
<jam> because that one is also not always full
<lifeless> still, minimal
<lifeless> ok, there is someting for you to play with
<lifeless> I shelved the pyx code contents pushed the rest
<lifeless> jam: ^
<jam> oh, and iix fits more than tix does into each leaf node
<jam> yeah, I saw the commit,
<jam> I bumped up the bloom to 1K, and we still get 7K entries, and 98.8% full
<jam> Wrote: 4710400 with 1K blooms instead of 4706304 with 256 byte blooms
<jam> so only added 1 page in all of that output :)
<jam> I guess we have some room to spare
<lifeless> still, 98% is not saving much
<lifeless> 2K?
<lifeless> (meep)
<jam> well, we have a few other ones that start hitting 45% full, which is "optimal"
<jam> I'll try 2K next
<jam> but I'm running the benchmarks first
<jam> meep?
<jam> lifeless: note the 'gray level' isn't == FPR
<lifeless> jam: its the number of bits on; 2% is the number that can possibly miss, and we get 5 chances at that per value
<jam> right
<lifeless> jam: so 10% on average, or 'not saving much' :)
<jam> sure, but 10% >> 2%
<lifeless> true
<lifeless> So, I wasn't translating all the way up to the FPR because we both know the maths :)
<jam> I'm going to give a shot at 2K when this test run finishes, I forgot to supply --no-graph
<lifeless> anyhow, meep was simply expressing dismay at 2K/4K being bloom
<lifeless> may also find the chunk code is starting to generate more slack space at that fraction too
<lifeless> yay gcc
<lifeless> _parse_btree_c.c:91: warning: Ã¢ defined but not used
<lifeless> _so_ not helpful
<jam> well, I just hit AssertionError: Somehow we ended up with too much compressed data, 4221 > 4096
<jam> with 2K bloom filters :)
<lifeless> jam: I think that my reserved hack is not quite solid enough
<jam> I'm not quite sure why, as I'm using "2*capacity"
<jam> I guess maybe we don't get our 2:1 compression with < 2K bytes to work with
<jam> dropping to 1.5
<jam> ultimately, I think we need to make blooms too big to really be useful, which was something I felt before
<jam> It might be a bit better with the md5 bloom
<jam> hard to say at these levels ...
<jam> lifeless: I can see that 2k blooms work "better" than 1k blooms for miss torture
<jam> 309k bloom misses, versus 282k bloom misses
<jam> and it saves ... 13.2s => 12.6s
<jam> search_from_revid is *slower* 1.597 => 1.639
<jam> get_components is faster 15.143 => 14.394
<jam> with 24.4k hits versus 19.8k hits
<lifeless> jam: well the bloom gets compressed
<lifeless> jam: but a grey one won't compress *that* well
<jam> well, a 100% grey compresses very well
<jam> all 1s :)
<lifeless> but is useless :)
<lifeless> also, 100% grey == black!
<jam> yeah, unfortunately optimal blooms don't compress well
<jam> lifeless: black ... or white depending on your terminal color
<jam> and whether you consider 1 whiter or blacker than 0
<jam> I'm seeing 90% grey at the level 1 nodes for the big packs, and we are down 13k => 8k entries for iix, and 9k => 4.6k for tix
<jam> with 75%  for tix
<jam> and a corresponding large increase in l1 nodes
<lifeless> so broadly
<lifeless> we can - not use a bloom
<lifeless>  - use a bloom for the entire table, and page it in <some sensible> size
<jam> I would say if we want to use a bloom, it needs to be on a page of its own *next to* the node mapping page
<lifeless> use blooms for the bottom row only (giving use better fan out high up the tree
<jam> 4096 bytes for 9k records would give us ~4 bits / entry
<jam> (3.64)
<jam> which is in the ~20% FPR range
<jam> lifeless: the one advantage of a whole-pack bloom is that you know what pages to read in, as soon as you know how big the bloom is
<jam> for as many keys as you want to check
<jam> so while you are right
<jam> that it would be 3-round-trips to get down to the almost leaf node
<jam> it is only 1 round-trip, but more total data
<lifeless> jam: actually, I was comparing against no-blooms :)
<jam> and for what we want, doesn't scale terribly well with number of keys
<lifeless> so aiming for very low FPR is one approach
<lifeless> another approach to analysing this is to say:
<lifeless> how much IO do we add (for each scenario) by having the bloom, whether it is a global, or bottom-internal-only, or whatever. And how much do we save?
<lifeless> 10% unset is around 50% FPR (more or less)
<lifeless> for halve the pointer count in the internal node
<lifeless> if we strip the bloom from higher nodes
<lifeless> we've doubled our bottom internal node row count
<jam> lifeless: but we don't have many intermediate nodes anyway
<jam> if we figure a bloom-less node is 1:100 fan out
<lifeless> jam: right, b+Tree structure for the win
<jam> and a bloom one is 1:50
<lifeless> its still waaay faster than bisection to locate an individual key
<jam> and the tips are... ~100
<lifeless> jam: anyhow, my point is to compare IO load, not to compare a specific FPR
<jam> you have to have 500,000 nodes before it starts getting interesting
<jam> lifeless: so... what is saves us is searching for missing keys in the bottom most layer
<jam> which helps 'miss torture' but not much else
<jam> hmm... you might consider using them for small packs
<jam> as you could even aggregate them if you wanted to
<lifeless> so miss_torture is trying to simulate something I think we see in real world
<lifeless> which the other tests don't yet show
<lifeless> anything with CompositeGraphIndex in there will start to show it
<jam> lifeless: I think 'search_from_revid' is a reasonable approximation
<jam> and it benefits more from having fewer internal nodes
<jam> and removing the CPU overhead of computing sha1s to compare against the bloom
<jam> I'm a bit curious about start+end keys at this point
<jam> It would be the same 50% overhead
<jam> but would we get better filtering than bloom
<jam> (10%)
<lifeless> I don't think so
<lifeless> also bloom will be getting nearly 50% filtering
<lifeless> (at 10% unset bits)
<lifeless> erm, well, 1-0.9^5 or something
<lifeless> 43%
<jam> lifeless: Well, removing the blooms entirely (page_size = 16 bytes), I get 10.550s for miss torture
<poolie> lifeless: can you help me work the glidepath for stacking?
<jam> which is down from 13s at 1k, and 12s at 2k
<poolie> afaics there is nothing no more needing review
<poolie> so i'd like to do some tweaks/merges
<lifeless> poolie: oh dang, I fgort to do the annotate performance test
<lifeless> jam: 16 bytes?
<jam> lifeless: just something to make them ignored
<jam> We don't have a way to just turn them off right now
<jam> the point is that they a) aren't being used during read, and b) aren't taking up much space
<poolie> lifeless: i don't mind doing that test
<poolie> but i'd like to know the overall map
<poolie> if i just work through from the bottom up and merge them will we be done?
<lifeless> poolie: yes, my shallow branch loom has them all except aarons policy work
<lifeless> poolie: working from bottom up will bring in the features
<poolie> ok
<poolie> any tips, or suggestions of anything better to do?
<lifeless> poolie: and the bug with 'bzr branch not-stacking-format --stacked localpath' is still something I need to fix (by changing the format on the fly'
<lifeless> poolie: for annotate, if its dog slow, undo the delete and do if(len(knit._fallback_vfs)) else: old_code
<poolie> right
<lifeless> poolie: other than that, no surprises that I know of
<mwhudson> jam: heh, your bzr-service c client looks pretty similar to mine in some ways
<jam> mwhudson: yeah, but i wrote that 2.5 years ago :)
<jam> just never caught on, I guess
<mwhudson> we must have similar levels of c (in)experience
<jam> probably win32 lacking os.fork() didn't help
<mwhudson> i guess doing something fancy with ptys would make some degree of sense
<mlh> how light could you make the client in python?
<mlh> never mind, I just noticed client.py :-)
<jam> mlh: pretty light :)
<jam> mwhudson: I remember the big off-put
<jam> gpg signing
<jam> It would prompt you for the signature in the original shell
<jam> not the one you were in
<jam> and fixing *that* wasn't worth my effort
<mlh> I guess all state has to be passed every request .. and the bze service would have to be changed likewise
<mwhudson> jam: i think doing the stdout/stderr overriding in a more unixy way might help there
<mwhudson> jam: but yeah, effort
<jam> mwhudson: gpg talks to the tty directly, just like ssh
<jam> I *think* you might be able to set GPG_TTY
<jam> but then you have to start passing env vars to the back end, etc.
<mwhudson> jam: forkpty, maybe?
<mwhudson> you can make another file descriptor the controlling terminal for your process *somehow*, i'm sure
<poolie> mwhudson: you must close the existing one then the next tty you open will become yours by default iirc
<poolie> or something like that
<poolie> you might need to change session group?
<poolie> i do have a book that describes this if you really care
<mwhudson> i have apue somewhere
<mwhudson> but i'm very unlikely to care enough to work on this
<poolie> 'linux application development' also has several bags of this crack
<poolie> or whatever crack comes in. tubes?
<mwhudson> i semi-enjoy unix-hackery on this level, but not really enough to put actual work in
<mwhudson> poolie: have you seen pyrepl?
<jam> right, poolie, play innocent
<jam> Anyway, => sleepytime
<jam> have a good evening
<lifeless> gnight
<poolie> night john
<poolie> mwhudson: no, i haven't, also python.net seems to be down
<mwhudson> yeah, it's some weird-ass virtual machine slice these days and doesn't work very well
<mwhudson> i guess i could put the bzrlib apidocs on people.ubuntu.com
<lifeless> ok
<lifeless> 7 seconds saved
<lifeless> by parsing just the key in C
<lifeless> clearly faster, I'll finish the conversion
<catsclaw> Hi all
<catsclaw> My last chance to get Bazaar working the way I need it before I give up and go back to SVN.
<gour> huh
<catsclaw> Does anyone know a way to get Loggerhead working though the fastcgi wrapper for wcgi?
<catsclaw> Or whatever TurboGears uses?
<bob2> you tried and it didn't work?
<catsclaw> I've got no idea how to do it.  The Loggerhead instructions assume you've got it running as a daemon
<catsclaw> There's no mention of any other way of doing it.
<mwhudson> some coding will be required
<mwhudson> from loggerhead.apps.filesystem import BranchesFromFileServer
<mwhudson> BranchesFromFileServer('/path') <- there's your wsgi app
<pygi> morning
<poolie> hello pygi
<Odd_Bloke> Whee, I've got automated bisection working.
<poolie> hello Odd_Bloke
<poolie> in pqm?
<Odd_Bloke> Nope, in the bisect plugin.
<Odd_Bloke> I've been tidying up my development directory and stumbled on some stuff I started at the London sprint.
<jamesh> Odd_Bloke: can it bisect a graph?
<lifeless> Odd_Bloke: cool
<Odd_Bloke> jamesh: I dunno, I'll test.
<Odd_Bloke> It's just hooking into existing bisect stuff.
<Odd_Bloke> The majority of this patch is a while loop. :p
<Odd_Bloke> It's not quick on bzr.dev.
<Odd_Bloke> Oh, and it's bombed with an encoding issue.
<Odd_Bloke> Probably Lukas' fault. :p
<Odd_Bloke> jamesh: It'll find a dotted revision, if that's what you meant by 'bisect a graph'.
<jamesh> Odd_Bloke: I guess what I meant was to use the graph when working out what revisions to test
<Odd_Bloke> jamesh: I don't know.  Jeff Licquia wrote most of it, I've just plugged in the necessary bits to get automation.
<jamesh> Odd_Bloke: if you keep the assumption that "one revision causes the breakage", each successful test indicates that the revision's entire ancestry is clean, and every failed test indicates that every other revision that includes this one in its revision history is broken
<jamesh> rather than treating it as a simple linear sequence of revisions you can cut in the middle
<Odd_Bloke> Right, I suspect it just cuts it, but I don't actually know either way.
<lifeless> I think cutting in the middle is fine for left-hand
<igc> hi pygi. Thanks for your blog encouraging more interop between the DVCSs. For large projects, dynamic interop will be slow but I think there's promise in using fastimport/export for keeping high-performing mirrors around and synched
<lifeless> so bisect (mainline), then bisect(new in branch)
<jamesh> how does git-bisect handle it?
<lifeless> not entirely sure
<lifeless> ok, saved 30/120 ish seconds
<poolie> spiv, ping?
<lifeless> spiv: so, are the hooks boom or bust?
<gour> pygi: my experience is that fastimport fails with darcs...
<spiv> lifeless: boom
<lifeless> cool
<lifeless> I have iter_random_one down to 78.722,
<lifeless> just by parsing faster
<Odd_Bloke> It looks like bisect does restart on the branch when it bisects to a merge revision.
<Odd_Bloke> What word can I use to refer to { trees, branches, repositories }?  Elements?
<luks> thingies?
<luks> :)
<lifeless> Odd_Bloke: objects? components?
<igc> that's it from me today. Night all
<lifeless> hmmm
<lifeless> night igc
<lifeless> I wonder what the gc does with swapped out pages
<beuno> howdy lifeless
<lifeless> hi beuno
<lifeless> lh search merged yet? (<am keen>)
<beuno> heh, I promise I'll review the current code today, and send it off to the list so mwhudson feels more pressured  :)
<beuno> I've showered and slept, so today should be more productive
<lifeless> lol
<lifeless> where are you?
<beuno> Canonical
<lifeless> London?
<beuno> 16 hour on a plane, went straight to the meeting
<beuno> yeap
<lifeless> cool, didn't even know there was a meeting ;)
<lifeless> you going to GUADEC?
<beuno> bzr-unrelated stuff
<lifeless> sounds fun :)
<beuno> I don't think so, I'm here for a few days (may end up staying longer though)
<beuno> it is!
<beuno> Guadec is in Spain, isn't it?
<lifeless> turkey
<lifeless> next week
<lifeless> monday !
<beuno> ah, then I'm sure I'm not going
<beuno> I do still have to make some things pretty for Jc2k
<lifeless> :)
<beuno> I hope I can get to that this weekend
<lifeless> lol
<lifeless> BTreeIndex: iter_random_one in 199.008,
<beuno> I don't have a backlog, how much is it without your BTreeIndex magic?
<lifeless> dunno yet
<lifeless> its new
<lifeless> its actually iter_random_one_reopen
<lifeless> and - much longer - still going
<beuno> oh, cool. mwhudson go the new version of LH back up again in LP
<beuno> and it's fast!
<mwhudson> still using mega ****wads of ram
<mwhudson> but at least that isn't affecting the rest of the codehosting any more
<beuno> mwhudson, more or less then before?
<lifeless> still going
<lifeless> GraphIndex: iter_random_one in 794.916,
<mwhudson> beuno: well, different
<mwhudson> beuno: it's probably growing more slowly
<mwhudson> beuno: if it was using this much on the old machine it would have been killed by now
<beuno> ah, not very encouraging
<lifeless> mwhudson: kudos
<mwhudson> beuno: still, the sysadmins are much happier :)
<beuno> mwhudson, is there some way you can get more information on what's eating up most of the ram?  if not, is there anyone in Canonical's office I can stalk to do so?
<lifeless> beuno: the sysadmins during london's day
<lifeless> beuno: elmo is the boss sysadmin
<beuno> right, but you threw hardware at the problem, which isn't ideal as we can't send free hardware with each LH download  :p
<mwhudson> beuno: probably not without adding some code
<mwhudson> beuno: no one else is running a site remotely like LP yet, fortunately
<lifeless> beuno: being *able* to throw hardware at it is a feature
<beuno> mwhudson, well, the guy that opened up the 100% CPU bug maybe
<Jc2k> hmmm pretty things :)
<mwhudson> beuno: the obvious suspect for ram-chewage is all the whole history data we store
<mwhudson> if it's that, and i guess one could add some code to estimate it, it probably wouldn't be hard to store it much more compactly
<beuno> Jc2k, :)   how's LH running on your server?  is it ram-friendly enough?
<Jc2k> indeed, its been fine
<beuno> that's good news!  also considering that you're using search too
<lifeless> yes, but search is good :)
<lifeless> (/me stops wanking)
<beuno> lol
<Jc2k> :)
<lifeless> I tried search with BTree
<lifeless> massively bigger index
<lifeless> but faster still
<lifeless> so there is room I think for having the last page not round to 4K
<lifeless> jam: ^
<lifeless> (search has _many_ very small indices
<pygi> igc, ;)
<pygi> gour, well, file a bug with them? :)
<gour> pygi: https://bugs.launchpad.net/bzr-fastimport/+bug/232177
<ubottu> Launchpad bug 232177 in bzr-fastimport "Better darcs support needed" [Undecided,New]
<spiv> lifeless: hooks patch sent to list
<lifeless> spiv: rocking!
<pygi> gour, isn't that a darcs problem with fastexport rather?
<gour> pygi: darcs-to-git and darcs2git, yes
<lifeless> spiv: I've approved; one thought though
<lifeless> spiv: perhaps the hook catpure logic could be pulled up
<gour> pygi: the point is darcs --> bzr conversion
<lifeless> poolie: ping
<spiv> lifeless: in the tests?  Yeah, I guess so.
<spiv> Some of the test methods are also identical.
<lifeless> spiv: I don't think a common base class is _that_ ugly
<pygi> gour, well, I understand. What I'm asking is: Is darcs fast-export implementation correct?
<spiv> If the common base class inherits from TestCase, and has tests methods, but is not meant to be run, it's a bit ugly.
<gour> pygi: dunno. tailor is atm the only tool capable of darcs{1,2} --> bzr
 * spiv goes for a swim
<poolie> lifeless: pong, off the phone now
<pygi> igc, we will see what happens, I'd certainly like if people would be able to collaborate even if they disagree on some stuff
<lifeless> poolie: feel like another call ?
<poolie> :-}
<poolie> let me get a cuppa and i'll call you
<lifeless> K
<gour> pygi: let'em choose whatever dvcs as long as it's called bzr :-)
<pygi> gour, hehe
<lifeless> spiv: is there a simple recipe for 'give me a 300ms local server'
<lifeless> spiv: ?
<lifeless> spiv: what we do there is not give it test methods, but helpers :P
<lifeless> spiv: add an intermediate class :)
<\sh> luks: ping qbzr ppa rebuild hardy ;)
<semslie> When merging branches, I have some duplicate conflicts where the same file was added to both branches individually, however the files are identical. Is there a merge algorithm that will take into account that the files are the same and not detect a conflict?
<james_w> semslie: unfortunately not, as file joins are not implemented yet.
<semslie> james_w: what are file joins?
<james_w> they wouldn't need to be to not have a conflict, but bzr currently errs on the side of safety.
<james_w> semslie: bzr uses file-ids to track file identity. If a file is added independently in two different places it will get two different file ids. When they are merged this causes the conflict.
<james_w> a file join would mark the file as having two file-ids in its history, so there would be no need to conflict.
<semslie> james_w: thanks
<james_w> resolving this conflict currently is just picking one file-id. You could have a merge algorithm that did that, and most users wouldn't care which was picked, so it's probably a safe thing to do.
<james_w> however, I'm not sure that there aren't issues with symmetry that could trip that up.
<james_w> semslie: there is a bug report open requesting this if you would like to subscribe.
<semslie> I'll take a look
<semslie> james_w: do you know where I could find a description of the different merge algorithms available?
<james_w> semslie: I don't, sorry.
<lifeless> semslie: jam is working on a plugin that accounts for this
<semslie> thanks lifeless
<lifeless> semslie: it doesn't address the root cause james_w mentions
<lifeless> semslie: http://bzr.arbash-meinel.com/branches/bzr/1.6-dev/merge3_per_file
<lifeless> (by plugin, I clearly mean branch)
<lifeless> http://bzr.arbash-meinel.com/plugins/per_file_remerge may be useful too
<lifeless> dunno how to make it jump etc, just saw it on the list
<lifeless> mtaylor: hey
<mtaylor> hi lifeless
<mtaylor> lifeless: I was in the middle of testing something for you, wasn't I...
<lifeless> mtaylor: dunno, were you ? ;)
<mtaylor> lifeless: ok. good! then no!
<lifeless> mtaylor: bzr-search has come a long way since your last attempt i think
<mtaylor> :)
<mtaylor> sweet. I'll pull again.
<lifeless> also there is now a new index layer under development
<lifeless> should help people with very large indices:). e.g. mysql.
<semslie> thanks for the tips. after playing around a bit I seem to be finding that bazaar detects conflicts in places where subversion does not, which is a bit puzzling. I dont think subversion is wrong here, but it would be nice to see a good descriptions of the different merge algorithms and why they might be detecting conflicts
<lifeless> semslie: well, the code is authoritative, but please do file a bug saying you couldn't get the info you needed
<lifeless> semslie: also, if you have a particular false-conflict, if you can describe it perhaps we can help you understand why you get it
<lifeless> mtaylor: lp:~lifeless/+junk/bzr-index2
<mtaylor> lifeless: should I pull that as a separate plugin then?
<mtaylor> or is that a branch of search?
<lifeless> mtaylor: adds a btree based format; if you wanted to give it a spin (in a new repository, obviously), and tell me how it goes I'd love the feedback
<lifeless> mtaylor: index2 is a new repository format
<lifeless> mtaylor: not related directly to bzr-search at all
<mtaylor> oh. so but will it go in in plugins? or is it a branch of bzr then?
<lifeless> plugins
<lifeless> as 'index2'
<mwhudson> lifeless: have you tried index2 on any bzr-svn repos?
<mtaylor> cool
<lifeless> mwhudson: haven't created a rich root variation yet
<mwhudson> lifeless: oh right
<lifeless> mwhudson: currently have a to-london test running though
<mwhudson> just thinking that bzr-svn indices tend to be 'rather large'
<mtaylor> ImportError: No module named pybloom.pybloom
<mtaylor> gah
<lifeless> mtaylor: oh, also pull
<mtaylor> :)
<lifeless> http://bzr.arbash-meinel.com/plugins/pybloom/ to plugins/pybloom
<mwhudson> lifeless: cool
<lifeless> mwhudson: its about 4 times faster at getting a single key out from 'go' to 'woah'
<lifeless> mtaylor: so concretely, in case I was unclear - I'm talking about doing 'bzr init-repo --btree-plain foo'; bzr branch mysql-6.0 foo/6.0; or similar
<lifeless> then do log etc
<lifeless> not about bzr-search on the btree format - that will be basically unchanged
<mtaylor>     raise KeyError('Key %r already registered' % key)
<mtaylor> KeyError: "Key 'btree-plain' already registered"
<lifeless> mtaylor: oh, one other thing - optional C extension
<mtaylor> right
<lifeless> in index2, do ./setup build_ext -i
<lifeless> mtaylor: did you pull the index2 plugin twice?
<mtaylor> nope. ImportError: cannot import name _KnitGraphIndex
<mtaylor> I get "foo" already registered sometimes when a plugin crashes spectacularly
<lifeless> mtaylor: ah! this will want bzr.dev
<mtaylor> :)
<mtaylor> do we have running new-package-on-push .debs for bzr.dev yet?
<mtaylor> because we need them
<lifeless> mtaylor: I don't think we do at the moment, I agree.
<mtaylor> kiko!!!
<lifeless> not kiko's problem :)
<mtaylor> ah... but how cool would it be to have a PPA auto-generate from a bzr branch, no?
<lifeless> mtaylor: indeed
<mwhudson> i think this idea has been mentioned once or twice over the years...
<Kinnison> lifeless: cache-hot, on my smallish project, that gives me a ca. 25% speedup on 'bzr log >/dev/null'
<Kinnison> lifeless: nice.
<mtaylor> PPA-from-bzr-branch++
<lifeless> Kinnison: without the C extensions?
<Kinnison> lifeless: I built the C extensions
<lifeless> Kinnison: cool
 * Kinnison tries on something bigger
<lifeless> Kinnison: should still be faster with
<lifeless> *without*
<Kinnison> lifeless: testing against my local copy of bzr.dev yields a 25% improvement in bzr log too
<Kinnison> lifeless: really cool work
<james_w> does anyone know what generates file ids like "x_Chris_Halls_<halls@debian.org>_Fri_Nov__4_10:34:47_2005_22857.16" ?
<lifeless> Kinnison: thanks
<lifeless> james_w: tla
<james_w> lifeless: ah, thanks.
<lifeless> Kinnison: is 25% good ? :)
<Kinnison> lifeless: It's a matter of a second on my smallish dev tree
<lifeless> so 4 to 3 ?
<Kinnison> lifeless: aye
<Kinnison> lifeless: and 8 to 6 on bzr.dev
<lifeless> Kinnison: try a cold cache comparison
<lifeless> erm
<lifeless> by which I mean
<lifeless> drop caches
<lifeless> run bzr info
<lifeless> then time bzr log
<Kinnison> how do I drop the caches?
<lifeless> $ cat bin/drop-caches
<lifeless> #!/bin/sh
<lifeless> # get written data to disk (not that its guaranteed)
<lifeless> sync
<lifeless> # (drop the unmodified pages)
<lifeless> echo 3 | sudo dd of=/proc/sys/vm/drop_caches 2>/dev/null
<lifeless> man, this network test is up to hours now
<lifeless> gunna be a long benchmark
<mwhudson> branching launchpad into an index2 repo is taking a good long while too
<Kinnison> lifeless: Irritatingly, the cold-cache time on the index2 tree is stable where it is wildly variable on the non index2 tree
<lifeless> mwhudson: index writing is a little slower
<lifeless> Kinnison: likely the non index2 tree is split more on disk
<Kinnison> lifeless: placing index2 on cold-cache anywhere from 25% slower to 50% faster
<lifeless> Kinnison: new repository single pull -> packed
<lifeless> Kinnison: strange
 * Kinnison times cold-cache on a new copy of my test branch
<Kinnison> on a fresh pull it's slightly more stable, and puts them on a par
<Kinnison> well within experimental error
<lifeless> mwhudson: did it finish?
<mwhudson> lifeless: yeah
<lifeless> mwhudson: is it faster?
<AnMaster> $ bzr log --short -rtag:0.0.1-release..
<AnMaster> bzr: ERROR: Selected log formatter only supports mainline revisions.
<AnMaster> what does that mean?
<AnMaster> -rtag:0.0.1-release.. was in same branch
<AnMaster> other branches have been merged and such to it of course but why doesn't it work then
<mwhudson> lifeless: yep, 20s vs 30s for log > /dev/null
<mwhudson> the btree one is better packed though ofc
<lifeless> mwhudson: 'bzr pack' in both :)
<mwhudson> lifeless: yeah, on that
<mwhudson> lifeless: they're about the same speed after the pack
<lifeless> mwhudson: hmm :P
<lifeless> mwhudson: the new index should degrade better, or thats the theory
<lifeless> mwhudson: you could try upping the cache too
<mwhudson> lifeless: i think i might try going to bed :-p
<lifeless> mwhudson: ciao!
<lifeless> mtaylor: did that work for you?
<mtaylor> lifeless: was at lunch... haven't tested yet
<lifeless> mtaylor: no worries
<mtaylor> lifeless: lp:bzr should get me bzr.dev, right?
<lifeless> uhm probably :P
<lifeless> (thats yes, yes it will(
<mtaylor> ok. good
<mtaylor> testing now
<lifeless> log isn't actually a great test, I think IO to get revisions rapidly outweighs indexing, except where the index blows :P
<mtaylor> well, what is a good test?
<lifeless> 'doing stuff' I think :)
<lifeless> log will show up obvious problems :)
<mtaylor> :)
<lifeless> log -r -400 or something
<lifeless> that should be faster
<mtaylor> lifeless: still branching in to the new repo
<mtaylor> lifeless: have I mentioned how much I enjoy copying 60k revs around ?
<lifeless> mtaylor: you enjoy it a lot
<mtaylor> yes.
<mtaylor> I'd really like to do it more
<lifeless> please sir
<lifeless> may I have another
<LarstiQ> yksi iso olut, olkaa hyvÃ¤.
<lifeless> LarstiQ: *blink*
<LarstiQ> lifeless: about the same in Finnish :)
 * LarstiQ practices a bit for his extended stay in Finland from the 11th onwards
<LarstiQ> lifeless: that translates "May I have one beer please"
<lifeless> LarstiQ: cool
<LarstiQ> big beer even
<lifeless> the only sort :P
<lifeless> but hang on, why are you practicing asking for beer?
<LarstiQ> lifeless: ah well, this was the phrase as listed in my dictionary ;)
<LarstiQ> would have to add the orangejuice lookup
<semslie> lifeless, james_w: turns out bazaar was doing the right thing by correctly finding the last common ancestor, while we were messing it up and checking against the wrong ancestor. problem solved, bazaar ftw :)
<james_w> cool, good to know.
<semslie> one thing I found was that I preferred the results of a weave merge to the default
<semslie> I'm not sure what the implications of that is
<lifeless> gnigt all
<pygi> hey hey folks =)
<vxnick> Hi all
<vxnick> I was wondering if anyone knows a good way to "push" a repository to a dev server? At the moment, I have a repository setup but would like to update a live version for testing without manually uploading the files
<vxnick> I read that using another working copy isn't the best solution, so wondered if there are any other solutions?
<beuno> vxnick, I can think od 2 ways
<beuno> there's a push-and-update plugin which will do that
<vxnick> oh, excellent
<beuno> and there's the bzr-upload plugin which will *just* upload the working tree
<beuno> no other revision information except the last revision uploaded, so next time you only uploaded what has changed
<vxnick> beuno: thanks a lot, I'll take a look at those :)
<beuno> vxnick, you're welcome
<abentley> jelmer: I'd be interested to talk about the bzr-gtk Bundle Buggy some time.
<vxnick> beuno: bzr-upload works great, thanks again!
<jelmer> abentley: Hi
<jelmer> abentley: Sure, what about it?
<abentley> I've moved trunk to use postgres, so you may be surprised if you just update blindly.  OTOH, BB is much more stable on postgres.
<abentley> So I would recommend switching at some point.
<jelmer> abentley: I already updated :-) Apart from the fact that I had to point the configuration at sqlite again it seems to still work fine
<abentley> Cool.  Sorry about that.  The sqlite-ness has always been assumed as part of the configuration.
<abentley> Frankly, I'm not sure what the right way to handle this is.
<abentley> I could do a local.conf, but a local-prod.conf and a local-dev.conf?
<jelmer> abentley: No worries, it was easy to deal with
<jelmer> abentley: Any particular reason pgsql is better than sqlite or just performance?
<abentley> jelmer: Stability.  TG interacts poorly with the way SQLite does locking.  PG and TG play better together.
<jelmer> abentley: ah, ok
<abentley> Also, schema migration is nicer.
<jelmer> So far locking hasn't been a problem for us, but I'll see if I can migrate it at some point anyway.
<abentley> jelmer: BB seems to crash for you occasionally.  I assumed it was that.
<pickscrape> locking granularity leading to improved concurrency is why we moved our trac from sqlite to postgres.
<jelmer> abentley: No, the main problem at the moment is DHCP leases expiring and DNS updating failing for some reason
<abentley> Oh, weird.
<abentley> jelmer: Okay.  So I'll try not to make any changes that require Postgres, but if I goof, please let me know.
<jelmer> abentley: Will do
<Laibsch> Hi, I am trying to merge some launchpad branches
<Laibsch> https://code.launchpad.net/~vcs-imports/subdownloader/trunk shall go into https://code.launchpad.net/~subdownloader-developers/subdownloader/trunk
<Laibsch> Here is what I did.  Check out the second branch and cd into it
<Laibsch> Then "bzr merge lp:~vcs-imports/subdownloader/trunk" which resulted in http://rafb.net/p/rCkYQS78.html
<james_w> hi Laibsch
<james_w> it sounds like https://bugs.edge.launchpad.net/bzr/+bug/177874
<ubottu> Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Critical,Fix released]
<Laibsch> Great
<Laibsch> james_w: thank you for the info
<tacone> hello, how can I print the revision number in my sourcecode ?
<andrea-bs> tacone: bzr revno?
<tacone> not. what shuold I write in my code, to make the current revision number appear inside that file ?
<james_w> tacone: that's not possible yet, sorry
<james_w> 1.6 might have it, if not then 1.7 I expect
<tacone> not a bit problem :-). thank you for your answer.
<vxnick> james_w: isn't there another command/program to do this? I could've sworn I saw something about this in the manual for printing revision info to source code
<vxnick> I was looking for it myself last night - it'd be nice to output the revision number to a PHP file
<tacone> vxnick: sed ? :-)
<vxnick> tacone: yeah I've done it with that, but it'd be nice to have a post-commit hook to do it, but I'm not familiar with Python
<james_w> bzr version-info
<james_w> you can hook that in to your build system to do it.
<vxnick> Actually, I used sed for subversion revision numbers, with a post-commit hook
<vxnick> james_w: that's the one :-)
<vxnick> any ideas for that though?
<vxnick> i.e. integrating into a build system
<james_w> I've never done it, sorry
<vxnick> fair enough
<vxnick> thanks anyways
<vxnick> found a reference: http://doc.bazaar-vcs.org/bzr.0.90/en/user-guide/version_info.html
<AnMaster> I didn't get an answer before
<AnMaster> <AnMaster> $ bzr log --short -rtag:0.0.1-release..
<AnMaster> <AnMaster> bzr: ERROR: Selected log formatter only supports mainline revisions.
<AnMaster> <AnMaster> what does that mean?
<AnMaster> does anyone around now know?
<AnMaster> the tag was in the same branch
<james_w> AnMaster: what does "bzr log -rtag:0.0.1-release" show?
<james_w> (no --short, no "..")
<AnMaster> a sec
<AnMaster> http://rafb.net/p/RQruyr60.html
<james_w> interesting
<james_w> and "bzr log --short" works fine?
<AnMaster> james_w, no it gives the error I gave above
<LarstiQ> AnMaster: without the ..
<AnMaster> when done for that tag
<james_w> even with no -r
<james_w> ?
<AnMaster> oh ok a sec
 * LarstiQ is suspecting the .. includes non-mainline revisions which --short doesn't like.
<AnMaster> without any -r short format works
<james_w> sounds like a bug to me
<james_w> one more to try "bzr log --short -rtag:0.0.1-release"
<AnMaster> I suspect corrupted repo on some way because the revision number from "bzr log --short -rtag:0.0.1-release" is different
<AnMaster> 449.2.20 Arvid Norlander        2007-11-13
<AnMaster>       Relase of envbot 0.0.1!
<AnMaster> why does revision number differ
<james_w> oh wow, that is odd.
<AnMaster> corrupted repo?
<james_w> is this a public branch?
<LarstiQ> AnMaster: I doubt that.
<AnMaster> james_w, well both branches are public, just sshed in to the server and there it works, server runs FreeBSD 6.3 with bzr 1.5
<AnMaster> python 2.5
<LarstiQ> AnMaster: what do you use locally?
<AnMaster> my desktop where it gives odd results runs Linux (arch linux currently), with python 2.4
<AnMaster> bzr 1.5
<AnMaster> however it is mounted over nfs from a gentoo box
<AnMaster> does that matter?
<LarstiQ> shouldn't.
<AnMaster> well let me check on the gentoo box (also bzr 1.5 and python 2.4)
<AnMaster> ok this is probably not a bug in bzr I guess...
<AnMaster> Reason.... the gentoo box now has two keyboard leds blinking (= kernel oops).... could be hardware issues on it I guess
<AnMaster> :/
<AnMaster> sigh
<LarstiQ> ah.
<AnMaster> well got to debug that, when I find out the cause of that I will get back to you (if it wasn't memory corruption simply)
<AnMaster> (or harddrive issues or whatever)
<LarstiQ> AnMaster: good luck
<AnMaster> LarstiQ, I *do* have backups
<AnMaster> daily to tape
<LarstiQ> still, faulty hardware sucks
<AnMaster> yes it does
<AnMaster> LarstiQ, anyway it could as well have been something else than hardware that crashed it, it runs X with binary nvidia driver (bleh I know, but I need 3D for various reasons)
 * AnMaster books into memcheck
<LarstiQ> AnMaster: we'll still be here when you've sorted it all out :)
<AnMaster> heh
<vila> did someone remember the url announcing mysql switch to bzr ?
<enobrev> vila, http://elliotmurphy.com/2008/06/19/mysql-converts-to-bazaar-and-why-it-matters/
<enobrev> oops... link's on that post, though (got that from planer bazaar)
<vila> enobrev: thks
<enobrev> http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
<kwk> Hello is somebody using the Bazaar plugin for eclipse?
<enobrev> kwk, i am
<enobrev> on win32
<enobrev> erm, xp
<kwk> enobrev. Ok, did you experience problems when trying to set the bazaar preferences? I'am using the plugin on ubuntu with Eclipse Ganymede and it doesn't work when trying to specify the bzr executable. A bug report is already filed (https://bugs.launchpad.net/bzr-eclipse/+bug/245136).
<ubottu> Launchpad bug 245136 in bzr-java-lib "Cannot use Preferences page to configure executable if existing settings are in error" [Undecided,New]
<enobrev> kwk, nope worked ok for me on both granymede and europa.  haven't tried it on my ubuntu system yet
<kwk> ubottu: exactly. enobrev, can you please send me you configuration file from YOURWORKSPACE/.metadata/.plugins/org.vcs.bazaar.eclipse.core(if such a file exists)? The bug report says that there has to be an initial configuration file that is working. Therefore I ask.
<ubottu> kwk: Error: I am only a bot, please don't think I'm intelligent :)
<kwk> bug 236162
<ubottu> Launchpad bug 236162 in bzr-eclipse "branch action is broken for absolute path " [Medium,Fix committed] https://launchpad.net/bugs/236162
<enobrev> nice
<enobrev> kwk, dir's empty
<kwk> enobrev, hmm, do have any clue where the settings are located?
<enobrev> (looking now)
<enobrev> kwk, not sure... not seeing it anywhere
<kwk> enobrev, OK thank you very much
<AnMaster> LarstiQ, still there? bad ram. I guess that caused it
<LarstiQ> AnMaster: that is, if you try what you did before now, the problem doesn't surface?
<LarstiQ> AnMaster: it is of course possible that the problems were unrelated, and there is a real bug inbzr.
<AnMaster> indeed that is the case
<AnMaster> anyway I shut it down now, still got warranty on this ram at least
<Laibsch> will "bzr get svn+ssh://rolf@svn.gnucash.org/repo/gnucash" check out all available branches?
<jelmer> Laibsch: no, you'd need to use "bzr svn-import" for that
<Laibsch> OK
<Laibsch> Thanks
<jelmer> abentley, is there info about the merge proposal email support somewhere?
<Laibsch> jelmer: Should I even check out all branches?  I want trunk plus 2 others.  I will likely want to try and merge and later rebase them.
<jelmer> Laibsch: In that case, I would recommend just retrieving those branches
<Laibsch> I was wondering if that would be impossible if I checked out the branches individually
<Laibsch> OK
<Laibsch> Thanks
<jelmer> e.g. "bzr get svn+ssh://rolf@svn.gnucash.org/repo/gnucash/trunk" ( I think)
<Laibsch> Yes, correct
 * jelmer wonders if the svn+ssh url means Laibsch is a gnucash developer
<abentley> jelmer: http://news.launchpad.net/cool-new-stuff/email-interface-to-code-review
<jelmer> abentley, thanks
<Laibsch> jelmer: partially
<Laibsch> I have partial rw access
<jelmer> abentley: What about submitting merge requests?
<abentley> jelmer: That's done through the web right now.
<jelmer> abentley: ok - should I file a wishlist bug for being able to do that over email or is it already pleanned ?
<abentley> We plan to support merge directives.  Is that what you have in mind?
<jelmer> abentley: Yeah, being able to "bzr send" to some lp address
<james_w> jam: hi, are you around? I have a question about the merge-into plugin.
<james_w> jam: I'm just trying it on a dummy branch, and "merge-into" set a merge revision, but didn't seem to import the text changes.
<vgeddes> I am having trouble setting up a dedicated smart-server, ...
<vgeddes> I set it up like this: bzr serve --allow-writes --directory=/home/vgeddes/src/nis ...
<vgeddes> but `bzr log bzr://localhost//home/vgeddes/src/nis/main'
<vgeddes> returns `bzr: ERROR: Not a branch: "bzr://localhost/".
<Peng> Maybe // is a problem?
<Peng> Also, you do know --allow-writes means there's no auth whatsoever, and anyone can write to your branches?
<Peng> Wait.
<LarstiQ> vgeddes: try bzr log bzr://localhost/main with that --directory
<vgeddes> yeah, thats not the problem, I tried it without the //
<Peng> Since you passed a --directory like that, bzr ser -- yeah, what he said.
<vgeddes> ha, thanks !
<Laibsch> http://rafb.net/p/iVSTU253.html Is that bug ï»¿177874?  How can I perform the merge?  The branches had completely separate directories, there should be no conflicts
<abentley> james_w: Are you testing with a branch that has commits?
<james_w> abentley: yeah, one commit in each
<jelmer> Laibsch, not sure, this looks like a bug
<jelmer> Laibsch: Can you try merging from a local copy of that branch?
<Laibsch> jelmer: How will that work?
<Laibsch> I'll check this out into $dir
<Laibsch> and then bzr merge $dir?
<Laibsch> Well, in any case, those steps lead to apparently the same failure
<Laibsch> Bazaar (bzr) 1.3.1 from ahrdy
<Laibsch> hardy
<pygi> bkor, I think you have your answer now :)
<jelmer> Laibsch, please file a bug
<awilkins> Verterok: Aha
<Verterok> awilkins: hey
<awilkins> I'm having trouble ; the plugin isn't initializing properly somewhere ; to get use it with a project you have to disconnect it and re-share it
<Verterok> awilkins: are you using a build of  the latest code?
<awilkins> Verterok: I was just going to pull ; I'm using a slightly patched build
<awilkins> Verterok: With the xmloutput fix I just mailed in
<Verterok> awilkins: yes, I meaned that :)
<awilkins> Verterok: Hmm, might not have revisions 163/162
 * Verterok checks what changes in 162-163
<awilkins> There's also (undecided)  	
<awilkins> #245136
<Verterok> awilkins: 163 is the BIG integration merge
<Verterok> :)
<awilkins> Still the same trouble
<Verterok> awilkins: revno 163 merge your plugin-dev branch and other improvements (allow selection of xmlrpc service port, etc)
<awilkins> I think I was on the integration branch ; I just merged it
<awilkins> Verterok: Alas, still same problem.
<Verterok> awilkins: steps to reproduce? a eclipse restart?
<awilkins> I was going to see if being a standalone over a repo branch makes a difference
<awilkins> Verterok: This is the plugin running in debug from another session which is how I typically run it until I think it's stable enough for normal use
<awilkins> I have no idea if it's linked to https://bugs.launchpad.net/bzr-eclipse/+bug/245136 at all
<ubottu> Launchpad bug 245136 in bzr-java-lib "Cannot use Preferences page to configure executable if existing settings are in error" [Undecided,New]
<awilkins> I just added a chunk of code that sets a reasonable default for Windows (well, reasonable for my personal config....)
<Verterok> awilkins: maybe it's related
<Verterok> awilkins: while in debug I encountered some problems when using and oldd workspace, all gone away once I reconfigured usign the new preference page
<awilkins> It springs the prefs page every time you use the share wizard ; would that be normal?
<Verterok> not at all
<awilkins> I'll trash the settings for the workspace
<Verterok> awilkins: I'll check the preference initializer
<awilkins> Hm, there are no settings
<awilkins> Should there be a file in .metadata/.plugins/org...core  ?
<Verterok> awilkins: I don't think so, but let me double check
<awilkins> Where does it store it then?
<Verterok> awilkins: ./org.eclipse.core.runtime/.settings/org.vcs.bazaar.eclipse.ui.prefs and ./org.eclipse.core.runtime/.settings/org.vcs.bazaar.eclipse.core.prefs
<awilkins> Ok, I've trashed those two files. Darn, should've kept them
<Verterok> I'll do the same here and see if I can reproduce the preference reset issue
<awilkins> I'm seeing it right now ; I changed the default preference for the UI, not the actual setting.
<awilkins> So it's displaying the .bat file and saying "cannot run program "bzr" cannot find file specified"
<awilkins> Or that last merge erased my changes
<Verterok> awilkins: you chanhed the preference initializer in the UI to point to the bzr.bat?
<Verterok> and keeps telling about bzr file
<Verterok> did I understood right?
<fbond> Hi.  I want to produce a patch for a changeset that removes a binary file and can be applied with the patch program.  With no VCS, `diff -Naur' would do this.  What do I use with bzr?
<awilkins> Yes, the preference says the bat file, the error message is as if it was just trying to run "bzr" like you would on posix
<awilkins> Aha, but if you summon the dialog AGAIN, it doesn't complain
<Verterok> awilkins: the core plugin also haave a preference initializer :P
<awilkins> Stills says "no client factory found" though
<Verterok> fbond: bzr diff ?
<fbond> Verterok: I assume you haven't tried it.
<Verterok> fbond: I used bzr diff but I don't know if it's the same as 'diff -Naur'
<Verterok> fbond: and I used the generated diff with patch
<fbond> Verterok: Then your binary file isn't being removed by patch.
<Verterok> fbond: oh, I missed the binary file part :P I never used it with binary data
<Verterok> awilkins: that means the bzr-java-lib can create a IBazaarClient
<Verterok> awilkins:  commandline or xmlrpc
<awilkins> Verterok: Ok, I patched the core initializer with the same default value ; now the projects are connected but no overlays
<fbond> I've tried bzr diff -r X..Y --using diff --diff-options '-Nau' but that produces funny output that I can't blame patch for not accepting.
<awilkins> Verterok: They were previously in the "Connected/Error" state where only the disconnect operation was available
<awilkins> This is XMLRPC
<Verterok> awilkins: if you trashed all the preferences, you should enbale the decorators again
<awilkins> Verterok: The status decorator is enabled in the defaults
<Verterok> awilkins: jusst disable/enbale it
<awilkins> Verterok: But only shows after you visit the property page, it seems.... must be in the UI defaults
 * awilkins restarts workspace again
<awilkins> Ok, workspace restarted... now the projects are in the same state
<awilkins> (Connected/Error)
<awilkins> No stack traces in the console of the calling workspace
<awilkins> (host workspace)
<awilkins> Verterok: Suddenly starts working after visiting the main preferences page (and not touching anything)
<Verterok> awilkins: ohh, I see...
<awilkins> Verterok: Let me see if that is also true when you cancel it
<Verterok> awilkins: I think it's only doing the setup of the client when you enter the pref. page
<awilkins> Verterok: The prefs being a singleton isn't going to work either ; I think that holds on both posix and windows, you just haven't run into it on posix because the default config is valid for posix
<awilkins> Verterok: If you visit the prefs and cancel, it doesn't show decorators
<awilkins> Verterok: Not for "OK" either
<awilkins> Verterok: Or "Apply" ...
<awilkins> Aha,
<awilkins> To get decorators, you have to visit the decorators prefs and "OK"
<Verterok> awilkins: yes
<awilkins> To get functional team menu I think you have to visit main prefs and OK
<Verterok> awilkins: I'll try to reproduce that problem
<awilkins> You don't get decorators if you visit/ok decorators WITHOUT having functional Team menu
<Verterok> awilkins: actually I don't fully agree with the non-singleton preferences :) but this problem have more priority
<awilkins> Verterok: How does the prefs dialog check to see whether it holds valid prefs if the prefs are a singleton, and not set until the prefs page is valid?
<Verterok> awilkins: the bzr-java-lib preferences are setup when the core plugin is started (valid or invalid)
<Verterok> awilkins: in the prefs. dialog when apply/Ok the prefs are stored with the eclipse preferencestore
<Verterok> awilkins: and applied to the BazaarClientPreferences singleton
<awilkins> Verterok: Yes, but the validity check in the prefs page uses the prefs to start the client - the old prefs, not the prefs in the page
<Verterok> awilkins: ups, I missed that :P
<awilkins> So if the old prefs are invalid, it's impossible to set new ones
<awilkins> Verterok: So by all means have a default static prefs instance but you need to be able to create a new one in the prefs page for validation and use it
<Verterok> awilkins: heh, I forgot about the preference listener
<Verterok> awilkins: PreferenceStoreChangeListener
<Verterok> awilkins: that updates the preference store of the core
<awilkins> Verterok: Is that the bit which loads them in the first place?
<awilkins> Verterok: Or is it that the UI prefs are never being stored in the core?
<Verterok> a bit of both, I think I missed the update of the client when the core/ui are updated
<Verterok> but the core prefs are used in the core start to update the client preferences
<awilkins> Verterok: The prefs are not being saved either (but they haven't changed from the defaults)
 * awilkins changes them
<awilkins> If I can iron this out, I'll do some more testing and deploy it to my users (minus the SaveableEditorInput).
<Verterok> awilkins: basically I missed a call to EclipseBazaarCore.updateClientPreferences() in PreferenceStoreChangeListener
<Verterok> I think that adding a call to that should make the trick :)
<mgedmin> did anyone ever already suggest bzr diff --color?
<awilkins> mgedmin: I think there is a plugin for it
<mgedmin> okay, then, did anyone ever suggest bundling it with bzr so that users could get pleasurable experience right out of the box?
<Verterok> awilkins: I can add a prefs. change listener to the core and fire the client prefs. update when the core preferences changes
<awilkins> Verterok: I added the core-from-UI-prefs update line
<awilkins> Verterok: It fixes the prefs page but not the (Connected/Error) state on init
<Verterok> awilkins: ok, let me know if that fixes the issue
<Verterok> awilkins: I don't fully understand what "(Connected/Error) state on init" means
<Verterok> :P
<awilkins> It means that when you start, the project thinks it's connected to a bzr repo, but is in an error state so only the disconnect menu item is available
<awilkins> This goes away after visiting the Team/Bazaar p[refs page
<awilkins> The decorators remain absent until you visit the decorators pref page
<awilkins> By the way, there is a difference between defaults, and your settings happening to BE the defaults
<Verterok> awilkins: ok, the problem can be that a client can't be created, let me debug it a bit
<awilkins> If you explicitly duplicate the default settings for decorators, the prefs file vanishes
<awilkins> It should not ; an upgrade may change the defaults and you may not want that
<awilkins> (IMHO)
<Verterok> awilkins: I'm thinking in remove the executable related prefs from UI, and store it only in the core
<Verterok> (to avoid this weird errors, and ease the manteinance)
<awilkins> Verterok: I would agree ; my UI prefs file is empty/absent anyway
<Verterok> awilkins: I can confirm the error state at init
<awilkins> Verterok: You have a windows box ATM?
<Verterok> awilkins: nope, testinng on Mac OS X 10.4
<Verterok> awilkins: but I borrowed vnc access to a win XP box from beuno office (/me waves beuno)
<Verterok> awilkins: I still need to configure bzr, Java, eclipse, but having an box with XP is a start :)
<awilkins> Heh, it's good that not everyone is using Ubuntu for bzr (although I like it, and it's the primary OS of the wife and her sister)
<awilkins> I'm using Vista ; I ran into a lovely issue with shelve ; apparently, Vista thinks that gnu patch needs admin rights because it's called "patch.exe"
<awilkins> If you try and run it it either crashes or spams a UAC box
<awilkins> Until you hand-edit a manifest resource into the file that tells Vista it doesn't really need Admin rights....
<Verterok> awilkins: useful trick to know, did you added it on the wiki, your blog?
<Verterok> awilkins: Indeed, Ubuntu is quite nice, but I primary use OS X 10.4 (my Gentoo box died a few weeks ago)
<awilkins> Verterok: I added it to the sourceforge bug which already described it but the solution didn't work immediately (I think it caches manifests, I had to rename the file a few times)
<Verterok> awilkins: great :)
<awilkins> If nothing else, putting solutions to things online is always a good idea because sooner or later I run into the problem again and forget how I fixed it
<Verterok> hehe, sure
<Verterok> awilkins: I think error state at init can be solved by calling EclipseBazaarCore.checkClient() in EclipseBazaarCore.start
<awilkins> Righto, back in 1 hr
<Verterok> awilkins: seeya
<fbond> So, `bzr replay -r 821.. foo' should replay commits 822, 823, etc., but not revision 821, right?
<indigo> If i've moved a directory containing a repository and some checkouts to a different path, what can I do to fix the link from the checkouts to the repository?
<indigo> guess i have to manually frob .bzr/branch/location
<indigo> it's a little annoying that a trailing newline in that file breaks stuff
<lifeless> indigo: bzr switch NEWPATH
<indigo> i already mangled location manually; is that a problem?
<indigo> it seems to be working..
<lifeless> hi bkor
<bkor> hey lifeless
<lifeless> indigo: no problem, just letting you know the easier way :)
<Odd_Bloke> Moin.
<indigo> ah, thanks
<indigo> too bad there isn't a bzr fix-bug-in-this-old-code :(
<lifeless> indigo: hmm, I wonder :)
<indigo> or even bzr get-this-old-code-to-compile
<lifeless> jam: poing
<bkor> indigo: $ moap code --help
<bkor> commands:
<bkor>   develop  develop code
<jam>  lifeless: boing boing
<jelmer> bkor, moap?
<bkor> jelmer: http://thomas.apestaart.org/moap/trac
<bkor> I use it for ChangeLog generation
<lifeless> jam: what do you think of running with the new index format?
<lifeless> jam: I have a network stress test still running overnight :X
<jelmer> bkor, ah
<schmichael> does bzr have what Hg calls "named branches"?
<lifeless> schmichael: all of our branches are named
<schmichael> hm... i don't think i'm using the right terms
<Peng> schmichael: You can't have multiple branches in one directory.
<schmichael> Peng: ah, thanks
<lifeless> schmichael: hg has a single directory with multiple heads
<lifeless> schmichael: and the ability to name some revisions with movable labels which they then call named branches
<lifeless> schmichael: such things being useful because they reuse the working tree and repository
<lifeless> schmichael: we allow working tree reuse and repository sharing, but we do it by doing:
<lifeless> bzr init-repo --no-trees REPO
<lifeless> bzr branch THING REPO/NAME
<lifeless> bzr checkout --lightweight REPO/NAME WORKINGTREE
<lifeless> cd WORKINGTREE; bzr switch NAME2; bzr switch NAME3 etc
<schmichael> bzr switch?
<schmichael> i'm not familiar with what that does...
<jam> new this-week: http://jam-bazaar.blogspot.com/2008/07/this-week-in-bazaar.html
<lifeless> schmichael: it switches a checkout from one branch to another
<schmichael> lifeless: great!  thanks!
<lifeless> schmichael: no problem :)
<Peng> hg's named branch aren't really moving labels.. They're tied into the revision's meta data.
<schmichael> Peng, lifeless: thanks!
<Peng> branches*
<lifeless> Peng: you can commit to a named branch right?
<lifeless> (in hg)
<Peng> I dunno. I think it might just be that when you commit, if the parent is a named branch, the new revision inherits the name.
<lifeless> Peng: I thought it was a list of names that pointed at revision hashes
<schmichael> lifeless: yes
<schmichael> well actually i'm trying to learn the details of named branches in hg
<lifeless> Peng: because otherwise you can't delete them
<schmichael> they're new and kind of awkward
<Peng> lifeless: Correct, you can't delete them.
<lifeless> Peng: oh, I didn't realise that. ouchies.
<Peng> I think git's named branches are basically automatically-moving tags.
<lifeless> way to make the cost of using them permanent
<lifeless> Peng: they are
<lifeless> Peng: they are reasonably sensible, except for the all-in-one-place aspect
<lifeless> (I have a bzr repo with 13K branches; don't really want that in a plain text file thanks(
<Peng> Heh.
<Peng> Does bzr perform well if you have thousands of tags?
<jam> lifeless: well, at one point hg's named branches was a simple 'tag' that said "and follow decendents until you have no more". And it was actually committed into the repository, I don't know if they have moved away from that yet or not.
<lifeless> Peng: not terribly well; but tags are per-branch, not per-repository, so they are cappable and trimmable without losing history
<jam> I think our scaling for N branches in a shared repository is quite good. I don't know that we have tuned the tag support as much
<jam> lifeless: as for running with the current btree stuff.... we certainly can
<jam> I was hoping to have one more poke at a whole-pack bloom filter
<jam> Since I worked out resizing, etc.
<jam> It would be a single global one, so the code gets to be a bit simpler as well
<lifeless> jam: sure, I think we can spend our respective fridays tweaking
<lifeless> jam: I want to  validate that networking doesn't blow
<jam> lifeless: yeah, though we have a pretty good idea that it won't
<lifeless> did you see iter_random_one_reload ?
<jam> the only thing I might add is speculative reading of extra pages over a network link
<jam> lifeless: not specifically
<jam> I think I saw you performance testing it
<lifeless> does iter_random_one
<jam> with what 800s => 200s ?
<lifeless> but reloads the index on each key
<lifeless> so its testing raw 'key a get' speed
<lifeless> (e.g. no cache for either index)
<jam> sure
<lifeless> its been running for 12 hours now over the network :P
<jam> lifeless: but if you really wanted to be mean, you should run "drop_caches()" inbetween
<jam> lifeless: ouch...
<lifeless> jam: network - what cache :P
<lifeless> jam: (and I do)
<jam> lifeless:  of course, that makes your machine pretty useless while it is running :)
<lifeless>         for key in order:                                                                                 |from bzrlib.repository import format_registry as repo_registry
<lifeless>             index.iter_entries([key]).next()                                                              |repo_registry.register_lazy(
<lifeless>             if reload_index:                                                                              |    'Bazaar development format - btree-rich-root (needs bzr.dev from 1.6)\n',
<lifeless>                 index = factory(index._transport, index._name, index._size)                               |    'bzrlib.plugins.index2.repofmt',
<lifeless>                 drop_cache()                                                                              |    'RepositoryFormatPackBTreeRichRoot',
<jam> um, some weird side-by-side pasting there
<lifeless> yes, wrong vim copy command
<lifeless> :)
<mwhudson> hmm, we need 'bzr unpack' to test btrees better :)
<jam> lifeless: so... whose to blame for 12 hours worth of pain?
<lifeless> well
<lifeless> 99704 keys
<lifeless> say 3 IO's per key on btree for the larger index
<jam> Is btree better/worse than graph at that point (I fully expect it to be better)
<lifeless> 0.3 seconds per IO -> 1 sec per key
<jam> and is this what, you to Chinstrap?
<lifeless> yes
<jam> that's about 1 day
<lifeless> yes
<jam> 1.15 days
<lifeless> I didn't think it out in advance you see :)
<lifeless> so I'm going to stop it :)
<jam> lifeless: hence why we should be doing speculative reading of extra pages
<lifeless> and do 20 keys
<jam> a round-trip should never be < 64k, or something like that
<lifeless> jam: so there are two things I'd like to see
<lifeless> I'd like the last page to be allowed to be truncated
<lifeless> so that a small index is, well, small
<jam> sure
<jam> I saw that in the backlog
<jam> what you need is tail recursion, or whatever it was called :)
<lifeless> and I'd like to read more internal nodes
<jam> Otherwise if they are separate, you're going to get the same disk space regardless
<lifeless> they are laid out as they are to allow the read-more-than-one optimisation
<jam> lifeless: you mean internal nodes up front ? yeah
<lifeless> jam: for instance, reading 64K on a > 64K index in the first read
<lifeless> and then any read covering internal nodes do the same
<lifeless> but only read 4K for leaf node requests
<jam> I would just try to spread it out, such that if we request 16 4k disjoint pages, we don't actually try to get 16-64k pages
<lifeless> e.g. do range(node, node+16)
<jam> more of a "if there is some more room, grab these as well"
<lifeless> jam: sure
<lifeless> in fact
<lifeless> the single key workflow is probably best kept at 'minimise IO'
<lifeless> but when you have two or three keys being asked for you can see graph walking happening, so start being aggressive
<jam> lifeless: interesting thought
<jam> and probably quite reasonable
<lifeless> jam: next thing I'm going to do though, is to write a in-place upgrader for these repository formats
<jam> lifeless: not very hard, right? Just write the indexes to upload, rename into place?
<lifeless> jam: roughly yes
<jam> Have you ever considered packing indexes without packing the data?
<lifeless> jam: create a new indices dir with the right contents, save the old format, remove the format marker, pivot the indices dirs, write the final format marker, remove the saved format marker
<lifeless> jam: well, we didn't have indices that could be anything other than optimal. or do you mean one index N packs ?
<jam> lifeless: right
<jam> The idea is to get the benefit of 1 index
<jam> without the cost of moving the data around
<jam> Just an idea that came up
<jam> I haven't thought about it in-depth
<lifeless> one index N packs would make ensuring integrity and so on quite a bit harder
<lifeless> is citeseer working for you?
<jam> lifeless: http://citeseer.ist.psu.edu/ is down
<lifeless> dang, was going to point you at LSM trees
<lifeless> and re-read it myself
<jam> Well, there was also something about CSB+ trees that were supposed to be cache sensitive
<jam> but that was more for in-memory DB
<jam> lifeless: http://www.google.com/search?q=lsm+trees&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
<jam> First link is a postscript file on www.cs.umb.edu
<lifeless> lets run some arbitrary postscript over the web
<lifeless> yah thats it
<lifeless> a bunch of similarities with what we do
<jam> well, we run arbitrary pdf all the time, right?
<lifeless> :)
<jam> lifeless: what key is best for Andrew Bennetts?
<lifeless> spiv
<jam> he seems to have 3 registered with subkeys.pgp.net
<jam> oh, sorry, that is michael hudson who has multiples
<jam> mwhudson: ^^^??
<jam> And it seems he doesn't have any of them in *my* web of trust
<mwhudson> jam: ah right, i kept losing hard drives with private keys on them :(
<mwhudson> jam: the one on lp.net is right
<lifeless> I was thinking of http://www.freenet.org.nz/python/embeddingpyrex/
<lifeless> for startup speed
<jam> lifeless: except you still have to "import bzrlib" which is the whole cost
<jam> now if we could get pyrex to compile bzrlib....
<jam> that would be interesting
<lifeless> jam: right, thats the point
<lifeless> I'm pretty sure a single .so can provide > 1 modules
<lifeless> with a little love
<jam> lifeless: well, you could have 'bzrlibmodule.so'
<jam> and that would clearly be able to have "bzrlib.foo"
<jam> I'm not 100% sure about "from bzrlib.foo.bar.baz import bing"
<lifeless> loading is left to right
<lifeless> so it should work
<jam> well, standard attributes would confuse the __import__ stuff, but if you tricked it into thinking they were modules
<lifeless> jam: types.ModuleType
<lifeless> jam: by 'trick' I hope you mean 'make them modules' :)
<mwhudson> the fact that 'from os.path import join' works means this isn't too hard
<mwhudson> (os not being a package, and os.path being around from before there _were_ packages)
<jam> mwhudson: it sure does make it hard to track down where to find the *code* for os.path.foo though :)
<mwhudson> jam: not as hard as pyrexing it all up :)
<jam> Especially when the function is "nt.lstat()" but the code for it is found in 'posixmodule.c'
<mwhudson> oh yes, that is a good trick
<lifeless> jam: design thought
<lifeless> jam: how does this sound: 'to convert repository instance Y into a Z, we use an InterRepositoryRepositoryFormat instance'
<jam> to simplify all cut&paste you do each time?
<lifeless> well currently we do a full fetch
<lifeless> so this is new code
<lifeless> I'm proposing that as the design/lookup
<jam> I thought we already had upgrade/downgrade infrastructure
<lifeless> we do
<lifeless> MetaToMeta does
<lifeless> if repo._format != desired_format:
<lifeless>    init_new
<lifeless>    new.fetch(repo)
<jam> ouch
<lifeless>   pivot()
<lifeless> which is fine, it works and is very generic
<lifeless> and until now we haven't had a meta format which would benefit from special casing
<lifeless> (except perhaps plain -> richroot). anyhow:
<lifeless> what do you think of the approach.
<jam> lifeless: well, interestingly enough, you already have:
<jam> # TODO: conversions of Branch and Tree should be done by
<jam> # InterXFormat lookups
<jam> But not a comment for Repository
<jam> so... I'm okay with it, though it is a layer of abstraction, which I don't think will see a lot of benefit
<jam> as we won't have tonnes of Repo<=>Repo converters that benefit
<lifeless> its pluggable though, which is a win I think
<jam> versus the work that has to be done anyway to make 'fetch()' work well.
<lifeless> sure
<jam> so, I'm fine with the idea, though I wouldn't work terribly hard to write the code just yet myself
<jam> I like being able to have plugins provide special tools for their customizations
<jam> it is just code to support, and maintain, and etc.
<jam> For 1 plugin which is going to be core RSN
<lifeless> jam: well, I've written several before that would have benefited
<lifeless> and I'm expecting we'll keep hacking on index2 for a while; its just going to be a code dump to get the first generation in to core
<jam> lifeless: reasonable enough, if you've seen a need for it, it is reasonable to bring in
<jam> <== is a big fan of plugins
<jam> having written the original import code :)
<jam> and a slew of plugins myself
<lifeless> :)
<jam> lifeless: so, would it be reasonable for me to strip out the per-internal-node bloom code
<jam> I don't think we'll see much benefit there
<jam> though I can leave it if you want
<lifeless> jam: I'd kind of like to see network impact of 50% blooms, that sort of thing
<jam> ok
<jam> I'll leave it if you are still poking at it
<lifeless> jam: so unless its in the way, I'd rather leave it - but o course make it not cost [much] when not using
<jam> I was going to change how blooms get generated, but I can do so compatibly
<lifeless> don't worry about disk layout compatibility, anyone using this today can convert back :P
#bzr 2008-07-04
<mwhudson> poolie, lifeless, et al: how close is the branch that introduces branch7 to landing?
<spiv> lifeless: http://bazaar-vcs.org/SmartPushAnalysis1.4
<pygi> bkor, more answers :D
<name> hi
<Odd_Bloke> name: Hey.
<name> hm does bzr auto merge whitespaces? like foo(bar, x) == foo(bar,x)
<Odd_Bloke> name: No, those two statements would not be equivalent.
<spiv> No, it won't.
<name> damn. to i can't fix whitespaces without risking conflicts
<LeoNerd> bzr makes no assumptions about the content of the files it protects
<LeoNerd> Some types of file that may be a big significant change.
<lifeless> jam: do mysql use --fixes ?
<lifeless> name: you could write a merge plugin to handle that
<name> lifeless: is it easy?
<lifeless> name: I'm not entirely sure :)
<lifeless> name: shouldn't be too hard if you are familiar with python though
<name> i am
<name> i am
<name> sorry
<name> any guide you would suggest?
<jelmer> that reminds me
<name> of?
<jelmer> Odd_Bloke, what's the state of per-file merge algorithms?
<Odd_Bloke> jelmer: Currently all in my head.
<jelmer> Odd_Bloke, Heh, ok
<name> so any tutorial on writing merge plugins?
<lifeless> jelmer: jam wrote a branch
<lifeless> name: I can point you at an example
<lifeless> name: http://bzr.arbash-meinel.com/plugins/per_file_remerge might be useful to examine
<lifeless> name: but I'm not aware of a tutorial as such
<name> The requested URL /plugins/per_file_remerge was not found on this server.
<lifeless> oh
<lifeless> jam: ^
<igc> morning
<Odd_Bloke> igc: Morning.
<igc> hi Odd_Bloke
<lifeless> hi igc
<Odd_Bloke> igc: What's the preferred way to refer to members the set { working tree, branch, repository } documentation-wise?  Is there one?
<igc> hi lifeless. Want any benchmarking done on OOo today?
<igc> Odd_Bloke: control directory?
<lifeless> igc: please
<lifeless> igc: I'd love usertest run with --btree-plain
<lifeless> igc: also, is there a dc machine with usertest that I can tweak myself?
<lifeless> Odd_Bloke: do you mean 'tree, branch,repository are all X' or 'tree is X, branch is Y, repository is Z'?
<Odd_Bloke> Yeah, that was a terrible explanation on my part, let me give context.
<Odd_Bloke> I'm trying to say "If none of { branch, tree, repository } were specified" (for check's help) but that seems a bit clunky.  Is there an accepted word in the docs to refer to those?  I went for elements first, then lifeless suggested objects.
<Odd_Bloke> But I'd like to stay consistent with the rest of the docs (if there's anything to be consistent with).
<lifeless> Odd_Bloke: why do you feel the need to specify that much detail?
<lifeless> Odd_Bloke: specifically:
<lifeless> Odd_Bloke: tree is an object in a control dir
<lifeless> ditto branch and repository
<lifeless> but I think you mean 'If the url given does not have any of <list>'
<lifeless> ?
<lifeless> and the general thing that hosts these objects is a control directory. So - 'if no control directory was found' ...
<Odd_Bloke> Nope, I mean if the user hasn't specified which of <list> to check, bzr will check all plural(<list>) that it finds.
<Odd_Bloke> And it's not necessarily limited to a single control directory, as if a shared repository location is given, we now check that all of the contained branches are also consistent.
<lifeless> Odd_Bloke: 'By default check will check all the bzr data found at the supplied URL. If any limits such as --repository are given, then only the named thing is checked.'
<igc> poolie: what dc machine is running usertest again?
<poolie> igc, i think that is orgadas
<poolie> orcadas
<lifeless> jml: bzr branch lp:mysql
<lifeless> jml: please try this, and suggest where I should file the bug
<jml> lifeless: file it on launchpad-bazaar.
<jml> lifeless: and set it to High, Confirmed.
<lifeless> jml: bombs away
<jml> lifeless: I'll get mwh to have a look at it when he gets back.
<jelmer> woot, svn 1.5 will now recognize and show bzr merges \o/
<jelmer> now if bzr only had merge tracking support...
<jelmer> *cherry*
<poolie> wow nice
<lifeless> jelmer: congrats
<lifeless> jelmer: when do you finish uni ?
<lifeless> :)
<jelmer> lifeless: end of the year hopefully
<poolie> but for now you're on vacation already right?
<jelmer> yeah, yesterday was my last exam for the semester
<spiv> jelmer: sweet
<mark1> poolie: you free now?  that number better than skype?
<poolie> markh: either is fine
<poolie> skype is a bit cheaper if that suits you
 * igc lunch
<poolie> igc, i got your annoyance mail, will print it now :)
<poolie> and even read it :)
<igc> thanks poolie :-)
<jam> lifeless: lp:~jameinel/+junk/per-file-remerge, that is just the stock "public location" for everything that you saw in the commit messages
<jam> lifeless: afaik mysql does not use --fixes
<igc> poolie: I also need confirmation that I can merge content filtering as an experimental feature after tweaking
<lifeless> jam: there is a blog post about how launchpad's bug references are wrong
<lifeless> jam: if they did use --fixes, we could be right :)
<poolie> igc, are you confident it won't hurt anything if it's not activeL
<poolie> ?
<igc> poolie: let me check that and get back to you
<Odd_Bloke> jam: Just resent that email.
<lifeless> man
<lifeless> writing correct code takes thought
<mneptok> writing *correctable* code takes an eye on job security.
<lifeless> thanks mneptok
<mneptok> anything for you, dear.
<poolie> that's why they call it support :)
<lifeless> I don't want mneptok supporting me :)
<lifeless> thats what I have underpants for!
<mneptok> i wish *i* had underpants ...
<poolie> ok, my annotate measurements were incorrect
<poolie> i didn't have extensions built in one of the branches
<mwhudson> :)
<mwhudson> that's a factor of 10-15 right there
<jml> how can I view the log message for the last revision of a file?
<lifeless> jml: hmm, bzr log FILE | less
<jml> lifeless: :(
<mwhudson> otherwise, programming i guess
<jml> programming is hard.
<jml> if programming were easy I wouldn't care about the last log message in the first place :)
<mwhudson> this programming isn't hard
<jml> yeah.
 * jml makes a note to write the relevant patch / plugin
<mwhudson> b.repository.get_revision(b.repository.get_inventory(b.last_revision())[mumble].revision) or something
<lifeless> what
<lifeless> tree = b.repository.revision_tree(b.last_revision())
<poolie> jml, maybe we should make an lp faq for things like this
<poolie> or something in the developer docs
<lifeless> wt.paths_to_fileids(PATH, other_trees=[tree]) (something like that, its a UI call)
<jml> poolie: hmm.
<jml> poolie: A FAQ's probably a good idea
<jml> poolie: particularly if the understanding is that some of the items actually represent missing features :)
<lifeless> mwhudson: generally, revision_tree is better than get_inventory
<mwhudson> lifeless: oh right, yes
<lifeless> mwhudson: as revision_tree is richer, but ~= to create
<mwhudson> lifeless: someone should teach loggerhead this at some point :)
<poolie> jml, actually maybe a rst document would be good
<poolie> because it could turn into a doctest and then be accurate
<jml> poolie: I like text files.
<poolie> lifeless: i'm trying to come with a name for that method i said could be separated from annotate
<lifeless> poolie: ok
<poolie> knit.get_parent_map_for_present_ancestors ?
<lifeless> what does it do?
<poolie> http://pastebin.ubuntu.com/24904/
<poolie> is that method name a fair description of what it does?
<lifeless> sure
<lifeless> note that it gets both local and remote ancestors
<lifeless> also note that if I wrote that I should have used iter_ancestry, and then captured the parents as I went rather than two API calls
<igc> spiv: were you planning to merge your InterRemoteToOther patch today? pqm is free fwiw :-)
<lifeless> jelmer: ping
<lifeless> some error handling needed:
<lifeless> bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_fetch_dir_upgrade
<lifeless>                                                                                                                                                                                       Command terminated
<lifeless> bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_fetch_dir_upgrade
<lifeless> Command terminated
<jelmer> lifeless: what version of python are you running?
<jelmer> try "make gdb-check"
<lifeless> 2.5ish
<lifeless> jelmer: where
<jelmer> in the bzr-svn dir
<mwhudson> quick poll:
<mwhudson> what should 'bzr get lp://dev/Ã©' do?
<lifeless> slap you
<mwhudson> (i'm assuming "what it does now" isn't really acceptable)
<mwhudson> lifeless: heh
<lifeless> jelmer: its in gdb
<jelmer> lifeless: sorry, try: "make gdb-check TESTS=bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_fetch_dir_upgrade"
<jelmer> then run
<lifeless> Program received signal SIGABRT, Aborted.
<lifeless> [Switching to Thread 0x2ae68f153cf0 (LWP 6033)]
<lifeless> #0  0x00002ae68ee23095 in raise () from /lib/libc.so.6
<lifeless> #1  0x00002ae68ee24af0 in abort () from /lib/libc.so.6
<lifeless> #2  0x00002ae692539d89 in ?? () from /usr/lib/libsvn_subr-1.so.1
<lifeless> #3  0x00002ae69276c629 in apr_palloc () from /usr/lib/libapr-1.so.0
<lifeless> #4  0x00002ae6918beddd in ?? () from /usr/lib/libsvn_delta-1.so.1
<lifeless> #5  0x00002ae692bb096f in ?? () from /usr/lib/libsvn_fs_fs-1.so.1
<lifeless> #6  0x00002ae69149722f in txdelta_call (self=0x18e51b0, args=<value optimized out>, kwargs=<value optimized out>) at editor.c:103
<lifeless> if you want more, I'll pastebin
<jelmer> thanks, that seems similar to the issues berto- was seeing earlier
<lifeless> let me update then
<lifeless> jelmer: pulling is slow from your repo
<lifeless> I wonder if rich root pulls are using the pack optimiser :(
<jelmer> I suspect not
<lifeless> they are not
<jelmer> pushing is veeeery slow
<lifeless> far out
<lifeless> its doign install revisions
<lifeless> ahha!
<lifeless> (Pdb) source._format
<lifeless> <bzrlib.repofmt.pack_repo.RepositoryFormatKnitPack4 object at 0x185a390>
<lifeless> (Pdb) self._format
<lifeless> <bzrlib.repofmt.pack_repo.RepositoryFormatKnitPack3 object at 0x1650a90>
<lifeless> which is to say
<jelmer> what's the difference between those two exactly?
<lifeless> your repository is subtrees
<lifeless> and my repo is rich root packs
<jelmer> ah, it probably predates the rich-root formats
<mlh_> hah hah: http://gould.cx/ted/blog/Bazaar_Power_Management
<lifeless> so
<lifeless> jelmer: align it up, it should be faster:P
<lifeless> jelmer: still dies
<jelmer> :-(
<lifeless> stack looks the same
<jelmer> lifeless: What exact platform/python/subversion versions?
<jelmer> (Since I can't reproduce it here)
<lifeless> amd64
<lifeless> 1.4.6dfsg1-2ubuntu1 svn
<lifeless> 2.5.2-2ubuntu4
<lifeless> python
<jelmer> thanks
<Verterok> Hi
<lifeless> hi Verterok
<Verterok> lifeless: hi :)
<Verterok> I'm playing a bit with the integration of bzr-search ;)
<lifeless> cool
<Verterok> and I have quick question: how can I get a revno from a revid
<Verterok> ?
<lifeless> have a look at revspec
<Verterok> ok, thanks
<lifeless> also there is some stuff on Branch
<Verterok> lifeless: FileTextHit are hits in the working tree or also includes text hits in the history?
<lifeless> only history
<Verterok> oh, I see... it would be great if I can integrate that just like the text search provided by eclipse
<Verterok> is there a way I can get the line, length and/or offset of the text hit?
<lifeless> not at the moment
<lifeless> its why the summaries are a little kludgy
<lifeless> mlh_: lol
<Verterok> lifeless: ok, thanks. to put you in context, I'm working to allow "double click" on FileTextHit and open a read-only editor, (and trying to figure out how to present the mixed results (path/file/revision hits) to the user)
<lifeless> Verterok: nice
 * Verterok still needs to learn a thing or two about eclipse search API
<lifeless> Verterok: I demoed it last friday
<lifeless> Verterok: had trouble with eclipse and workspace locking and stuff
<lifeless> :(
<Verterok> oh, that's bad :(
<lifeless> the search bit worked
<Verterok> cool
<lifeless> ok, real world data
<lifeless> which which is the new index:
<lifeless> real    0m13.602s
<lifeless> user    0m13.053s
<lifeless> sys     0m0.200s
<lifeless> or
<lifeless> real    0m17.347s
<lifeless> user    0m15.173s
<lifeless> sys     0m0.352s
<spiv> igc: Hmm, I thought I merged that yesterday... I wonder where the success/failure from pqm went?
<mwhudson> oh hey, pqm does that you you guys too?
<igc> spiv: it's not there as best as I see.
<igc> (using log --short on bzr.dev)
<lifeless> at the moment its teh autopack bug doing that
 * spiv resubmits
<spiv> igc: thanks for noticing :)
<igc> spiv: the credit belongs to BB, not me! http://bundlebuggy.aaronbentley.com/?selected=mine
<lifeless> igc: so, ooo ?
<AfC> Aren't trees like Mozilla and OpenOffice long and linear? That they're big is great, but that they lack much if any branch concurrency would seem to make them less than ideal for your performance tests, no?
<AfC> ï»¿[I realize the search for the ideal test case has long been a topic]
<igc> lifeless: I'm working on it. My first run fell over earlier today so I'm fixing the problem (on my end) and trying again
<igc> AfC: you're right.
<igc> there are multiple dimensions ...
<igc> lots of files
<igc> deep history
<igc> complex history
<igc> my OOo and moz trees cover the first 2 well
<AfC> igc: sure
<AfC> The only public projects I'm aware of with all three would be the Linux kernel and MySQL
<igc> I'm grabbing a copy of mysql now fwiw
<AfC> Nice
<rockstar> I've got a dirstate-with-subtree format repo (from bzr-svn) that is Thor knows how old.  What's the safest way to upgrade it?
<lifeless> rockstar: bzr upgrade --pack-0.92-subtree
<lifeless> wheee
<rockstar> lifeless, what if I want to lose the subtree support?
<lifeless> 28609 robertc   18   0 2111m 1.8g 1468 D  0.3 89.6   7:34.69 python
<Peng> You might be able to upgrade to rich-root-pack, right?
<lifeless> rockstar: 'bzr pull svn://'
 * Peng goes to bed.
<lifeless> rockstar: (you can't downgrade model data, subtrees store more data than rich roots)
<lifeless> poolie: you back ?
<lifeless> spiv: know of a python module to parse proc/pid/statm ?
<lifeless> crap! holy!
<lifeless> robertc@lifeless-64:~/source/python/python-btree$ du -sh .bzr/repository/indices/
<lifeless> 4.6M    .bzr/repository/indices/
<lifeless> robertc@lifeless-64:~/source/python/python-btree$ du -sh ../python-packs/.bzr/repository/indices/
<lifeless> 38M     ../python-packs/.bzr/repository/indices/
<poolie> lifeless: back now
<poolie> igc: wow that's really good!
<igc> poolie: thanks
<spiv> lifeless: I don't, unfortunately
<spiv> lifeless: although I think jam maybe had code to read it?
<poolie> i have some more feedback, will send mail
<igc> looking forward to it
<lifeless> spiv: read it is easy :).
<lifeless> spiv: I just need to figure which like is vss
<spiv> lifeless: actually...
<spiv> lifeless: http://www.pixelbeat.org/scripts/ps_mem.py
<spiv> lifeless: that code isn't really structured for importability, but it might be a useful reference
<lifeless> so, python via svn
<lifeless> 149M packs + 38M indices -> 149M packs + 4.6M indices
<lifeless> 187 -> 154
<spiv> That's a much nicer data:index ratio.
<lifeless> 33/187 shrink in repo size
<lifeless> 17%
<igc> lifeless: awesome
<lifeless> log time was indisinguishable
<lifeless> but they are fully packed so meh
<lifeless> howeveer, I'm now going to try to get a peak VSS reading
<AfC> lifeless: maybe you should write a scriptlet that breaks a repository into chunks each of a random number of revisions
<spiv> You could call it "bzr unpack" ;)
<AfC> spiv: probably better than `bzr randomize`. If (incorrect) word got out that there was a command that would arbitrarily scramble data in a repository we'd never hear the end of it. :)
<lifeless> spiv: I could
<lifeless> spiv: or
<lifeless> spiv: I could just use my 22G presplit test repo :)
<lifeless> spiv: ahh!
<lifeless> spiv: /proc/pid/status
<lifeless> spiv: http://rafb.net/p/EbcdpJ48.html
<lifeless> spiv: give that a spin.
<lifeless> VmPeak:   296680 kB
<spiv> That looks like a handy patch.
<lifeless> and
<lifeless> VmPeak:   300408 kB
<lifeless> so
<lifeless> I'm amazed how much memory log uses up
<spiv> I'm not sure that VmPeak is the most useful number.  I think it might report values much higher than the highest resident memory size, because it's the peak of the virtual size?
<lifeless> this is true
<lifeless> so the question is when is high VM and low resident good
<lifeless> answer - never :)
<spiv> I wonder if VmHWM is any better?  Pity my man proc(5) doesn't describe these fields.
<lifeless> so
<lifeless> I put a pause in there
<lifeless> I see this:
<lifeless> 15212 robertc   20   0  299m  88m 5856 S    0  4.4   0:27.62 python
<lifeless> VmPeak:   300576 kB
<lifeless> VmSize:   298116 kB
<lifeless> VmHWM:     93068 kB
<lifeless> VmRSS:     90508 kB
<weigon> lifeless: if you can use valgrind there is the massif plugin
<weigon> lifeless: it tracks heap-allocations over time
<lifeless> weigon: we can
<lifeless> weigon: I wanted something incredibly lightweight though
<weigon> http://developer.gnome.org/doc/guides/optimisation/Massif.html ... k
<lifeless> weigon: just a 'does BTreeIndex peak higher'
<AfC> You know, with all the smart people hacking on Linux, you'd think that procps would have found a way to output useful numbers by now.
<spiv> lifeless: that seems to tally (90508/1024 ~= 88.3)
<lifeless> spiv: yes :)
<spiv> AfC: http://lwn.net/Articles/230975/ sound promising
<lifeless> spiv: so I think the VmHWM is probably the immediately interesting thing
<spiv> Agreed.
<lifeless> spiv: however, keeping VmPeak low is good too
 * spiv nods.
<lifeless> here's another one I prepared earlier
<lifeless> 28609 robertc   18   0 2182m 1.9g 1432 D  0.7 97.3   8:18.83 python
<lifeless> spiv: r=spiv on that patch btw ?
<lifeless> should I NEWS it? add a guard for windows (but will it work on bsd ?)
<spiv> lifeless: Just add a guard on the file existing, I think.
<spiv> lifeless: I'm happy to have that merged, I think.
<lifeless>             try:
<lifeless>                 status_file = file('/proc/%s/status' % os.getpid(), 'rb')
<lifeless>             except:
<lifeless>                 pass
<lifeless>             else:
<lifeless> sufficiently ugly ?
<spiv> Yeah :)
<spiv> Well,
<spiv> Not a bare except.
<lifeless> bare except
<spiv> No, just IOError
<spiv> That should cover all reasonable exceptions, rather than e.g. KeyboardInterrupt.
<spiv> Python's docs are pretty clear that "If the file cannot be opened, IOError is raised. "
<lifeless> committing
<lifeless> so anyhow
<lifeless> that 4G process
<lifeless> Virt + res is pretty high :)
<lifeless> weigon: the other problem is we need python backtraces on allocation pressure; and python allocates arenas no objects
<weigon> lifeless: you can't disable for debugging ?
<weigon> but yeah, that doesn't help with the python stacktraces
<lifeless> I really like to have a toolchain that can debug in production
<lifeless> it makes it a lot easier to fix something a user reports
<spiv> You can rebuild python to use plain malloc rather than its "pymalloc", but then you have to rebuild all extension modules you use too.
<igc> lifeless: those test results are still some time off. I'll email them to you overnight. Off to the hospital for a short visit now and dinner after that so I'll be offline for a while
<lifeless> igc: ok, see you online in weird timezones :)
<weigon> glib2 also uses "slices" but you can disable that at runtime with G_SLICE="always-malloc"
<spiv> (I wonder if it's possible to override that with an LD_PRELOAD hack?)
<jelmer> ToyKeeper, ping
<ToyKeeper> 'lo
<ToyKeeper> jelmer: yes?
<jelmer> ToyKeeper, Do you still have that sawfish branch around?
<ToyKeeper> Yeah.
<ToyKeeper> I was actually just looking again at how best to convert svn to bzr without losing tags...
<jelmer> ToyKeeper: If you try to push that to a remote location using the bzr smart server protocol, does it also use this much memory?
<ToyKeeper> I'll check...
<jelmer> ToyKeeper: Try the latest bzr-svn revisions, it sets real bzr tags now
<jelmer> (although it doesn't pull in the revisions they point at yet)
<ToyKeeper> Well, it's running.  I'll let you know.  :)
<ToyKeeper> It works with a fresh dir, though when I tried a new branch in a fresh repo, it wasn't too happy.  "ERROR: Repository KnitPackRepository('srcURL') is not compatible with repository KnitPackRepository('destURL')"
<jelmer> you need a rich root repo
<ToyKeeper> jelmer: BTW, are you wondering about memory use on the sender or the receiver?
<jelmer> ToyKeeper, both, actually (I'm wondering if the high memory use is in bzr itself as well)
<jelmer> spiv, ping
<ToyKeeper> jelmer: Okay.  3 minutes.  88 MB on the client, 24MB on the server.
<jelmer> ToyKeeper, Hmm, so at least that's not the problem. Thanks.
<ToyKeeper> (client was the same bzr.dev which spiked in the bug report...  server was bzr 1.5)
<ToyKeeper> I doubt it matters, but 'bzr serve' was proxied through bzr_access.
<Laibsch> I am trying to check an svn repo into bzr
<Laibsch> I am seeing some strange issues
<Laibsch> http://rafb.net/p/Y0s6oC57.html
<Laibsch> svn itself works fine, though
<Laibsch> any idea?
<LarstiQ> Laibsch: does something like mtr actually reach that host? It seems more like general networking problems.
<Laibsch> ping does
<Laibsch> and svn itself can check out fine
<Laibsch> iptables -L lists nothing
<LarstiQ> Laibsch: and it wasn't a transient error?
<Laibsch> no
<LarstiQ> Laibsch: the fact that telnet experiences the same problem..
<LarstiQ> Laibsch: in fact, I get the same error.
<Laibsch> Well, maybe the telnet command is not correct
<Laibsch> Can you try the bzr get command?
<LarstiQ> same problem
<LarstiQ> Laibsch: I'll look further into it after I handle some other stuff.
<ToyKeeper> Laibsch: That host appears to return 'no route' for blocked ports instead of the usual reject (or just no response at all).
<LarstiQ> Laibsch: you're sure that's the correct url though?
<ToyKeeper> I can talk to it via ping and ssh, but not svn.
<ToyKeeper> nmap might reveal some other ports, but it takes a little while.
<luks> Laibsch: 'svn co' doesn't work for me on that URL
<luks> fails with the same error
<luks> looks like a server issue to me
<Laibsch> svn checkout http://cvs.gnucash.org/repo//gnucash/branches/aqbanking3
<Laibsch> works
<ToyKeeper> http != svn  :)
<Laibsch> Maybe I was mistaken in replacing the http with svn
<LarstiQ> Laibsch: http:// != svn://
<LarstiQ> Laibsch: yeah :)
<Laibsch> OK
<Laibsch> Sorry for the noise
<LarstiQ> Laibsch: well, thank you for showing me a host that acts weird like that :)
<Laibsch> hehe
<Laibsch> The checkout with bzr still fails
<Laibsch> $ bzr get http://cvs.gnucash.org/repo//gnucash/branches/aqbanking3
<Laibsch> bzr: ERROR: Transport error: Server refuses to fullfil the request
<Laibsch> s/bzr get/svn checkout/
<Laibsch> and it works
<ToyKeeper> I get the same error for both.
<luks> `bzr branch svn+http://cvs.gnucash.org/repo/gnucash/branches/aqbanking3` works for me
<luks> or, well, attempts to work :)
<Laibsch> As an infrequent bzr (I used monotone extensively) I have to say that bzr used to start fine with a clean interface
<Laibsch> now it has so many weird and inconsistent switches :-(
<Laibsch> It would be awesome to streamline that in the future
<luks> what specifically do you mean?
<Laibsch> Just one example
<Laibsch> bzr get
<Laibsch> bzr pull
<Laibsch> bzr branch
<Laibsch> More or less the "same thing"
<luks> get, branch and clone are aliases for the same thing
<luks> pull is something completely different
<ToyKeeper> In any case, it looks like the admin for cvs.gnucash.org is too clever for his own good.
<Laibsch> could be
<Laibsch> what is the specific problem?
<Laibsch> I'll raise the issue
<ToyKeeper> The ICMP 'host unreachable' response may be a neat trick, but it's not supposed to be used for port blocking.
<ToyKeeper> Tell the admin to drop unwanted packets instead of returning a host-unreachable error.
<ToyKeeper> A 'port unreachable' response works too, and should be the default behavior from iptables REJECT (but many prefer DROP, which is fine).
<Laibsch> so, this is an iptables configuration?
<ToyKeeper> Probably.
<ToyKeeper> I didn't even try to guess what OS the server/router is running, but if it's Linux, it would be an iptables config problem.
<jelmer> Laibsch: The "bzr: ERROR: Transport error: Server refuses to fullfil the request" bit is a bug that'll be fixed in 1.6
<ToyKeeper> hrrm.
<ToyKeeper> I don't suppose there's any way to do per-branch aliases, is there?
<ToyKeeper> (or per-repository)
<ToyKeeper> ... looking for a way to name URLs, basically, to be able to "bzr push backup" or "bzr push public" from the same branch.
<lifeless> ToyKeeper: I believe that landed yesterday in bzr.dev
<jelmer> lifeless: is there some easy way to store non-versioned revision metadata?
<jelmer> (trying to fix bug 161830)
<ubottu> Launchpad bug 161830 in bzr-svn "log should show subversion revision numbers as well as branch/bzr revision info" [Wishlist,Triaged] https://launchpad.net/bugs/161830
<lifeless> jelmer: so you need to associate a svn number with a bzr after creating the bzr revision ?
<jelmer> yeah
<jelmer> ideally something that always propagates with the branch
<lifeless> sounds like a tag in principle
<jelmer> but I realize there isn't something like that
<jelmer> I'm not sure the tags infrastructure is made for storing 10s of thousands of entries atm :-)
<jelmer> although in concept, yeah it does sound like a tag
<lifeless> its not made for that
<lifeless> as usual I have some ideas here
<jelmer> commit log alteration would need a similar store I think
<jelmer> lifeless: What are your ideas?
<lifeless> commit log alteration is entirely different
<lifeless> because thats distributed database integrity you're facing
<jelmer> lifeless, Depends on how you implement it
<lifeless> jelmer: well its 'versioned' vs 'nonversioned'
<jelmer> lifeless: I wasn't thinking of actually modifying the revision object, rather keeping extra metadata per revision of modifications
<jelmer> lifeless, Anyway, getting sidetracked.. what about the revision number metadata?
<lifeless> jelmer: so, to scale to huge tag counts
<lifeless> I'm thinking of an updatable pack like store
<lifeless> the key point being that a key in the store can be replaced (unlike pack stores)
<lifeless> and deletes are done by replacing with a special marker
<lifeless> however
<lifeless> a difference for svn revno is that they are repo global, unlike tags
<lifeless> so this would live in the repo
<lifeless> and fetch would need some efficient query to get new journal items from such a store for already fetched revisions
<hypest> hello. Does anyone know how to setup bzr (1.5) diff to pass the actual current file (not a copy of it) to the external diff program?
<lifeless> we'd want this to be generic and usable for other things too
<jelmer> lifeless: makes sense
<jelmer> hypest: Hi
<jelmer> lifeless: Separate files per function though?
<jelmer> lifeless: The problem with keeping things in .bzr/ is that they're not kept when cloning
<jelmer> with keeping *custom* things
<lifeless> jelmer: one store. hints on things in it for locality of reference as needed.
<lifeless> jelmer: hooked into the system so that fetch knows what to copy even if a plugin is missing - but conflicts require the plugin to resolve
<jelmer> lifeless: that sounds ideal
<jelmer> lifeless: I have considered keeping part of the bzr-svn cache in .bzr/ but this is what stopped me
<jelmer> lifeless: It could make e.g. "bzr branch http://bzr-mirror.gnome.org/svn/gnome-specimen/trunk; bzr push -d trunk svn://svn.gnome.org/svn/gnome-specimen/trunk" very quick
<hypest> my goal is to be able to use the external diff program as editor. My scenario: using winmerge, I can inspect the file's changes, (want to) revert some of them, and save the file. Since bzr passes a copy to winmerge, saving is "destroyed"...
<jelmer> hypest: i remember there was something changed in that regard recently
<jelmer> hypest: On POSIX systems, a symlink is used rather than a file copy
<lifeless> hypest: I'm not sure
<jelmer> lifeless, Is any of this specced on the wiki btw? Or just in your head?
<lifeless> in my head
<hypest> jelmer: haven't found it yet... ofcource I'll keep looking. I'm on WinXP by the way, so the symlink way I assume does not apply.
<jelmer> bug 81689
<ubottu> Launchpad bug 81689 in bzr "Branches with symlinks can't be checked out on Windows" [Medium,Confirmed] https://launchpad.net/bugs/81689
<jelmer> hmmno, that's different
<jelmer> No, I can't find it either, maybe it didn't get mentioned in NEWS
<hypest> so, should I post a bug report, a feature request, or nothing?
<jelmer> hypest: please file a bug
<hypest> jelmer: thanx ;)
<hypest> done: filed the bug report: https://bugs.launchpad.net/bzr/+bug/245481
<ubottu> Launchpad bug 245481 in bzr "current file name passed via a copy to external diff, under Windows" [Undecided,New]
<lifeless> Pieter: what git window and depth do you use for best compression?
<lifeless> man
<lifeless> http://63.246.7.136/articles/dvcs-guide is so biased
<lifeless> 'Bzr pretends to hide complexity by keeping a clean User Interface while ...'
<Pieter> lifeless: 200 for both is about the max
<Pieter> lifeless: but if your repository is small (< 100k commits) you can take a smaller window and have a faster repacking
<lifeless> Jc2k: why does the viewvc link http://bzr-mirror.gnome.org/cheese/trunk/ point to svn ?
<luks> lifeless: because ViewVC doesn't support bzr?
<lifeless> luks: there is loggerhead running on the same machine
<lifeless> luks: http://bzr-mirror.gnome.org:8080/cheese/trunk/changes
<lifeless> luks: try the search box :P
<matkor> hmm what they mean by "Directories versionable" ?
<james_w> beuno: hey, you about?
<beuno> james_w, hey, yup
<james_w> hey lifeless
<james_w> beuno: any news on next week?
<lifeless> hi james_w
<beuno> james_w, yeah, I'm here next week for sure  :)
<james_w> beuno: great, I'll see about popping down for a day.
<lifeless> james_w: you're not at GUADEC?
<james_w> lifeless: nope, sorry.
<james_w> are you flying out tomorrow?
<lifeless> james_w: yes. guadec, then london, then LRL
<james_w> are you speaking at LRL?
<lifeless> yes
<beuno> james_w, cool!  I'll be mostly working with mpt, so I'll probably be on a desk somewhere
<beuno> lifeless, when are you coming to london?
<lifeless> beuno: after GUADEC
<lifeless> 13th
<beuno> lifeless, ah, I will probably leave the 12th  :/
 * jelmer will also be at LRL again
 * beuno wonders what LRL is
<lifeless> lug radio live
<jelmer> LUGRadio Live, http://www.lugradio.org/
<beuno> ah, so I'm leaving when everyone is coming...  meh
<lifeless> beuno: you should have chatted to us, could have coordinated: )
<beuno> lifeless, yeah, I wasn't expecting to cross half the globe. I got asked on friday and was on a plane tuesday
<jelmer> is there any sort of sprint planned near LRL?
<jelmer> I hadn't realized there would be more bzrers there
<lifeless> jelmer: don't think so
<lifeless> jelmer: I'm heading home sunday, but perhaps we can just make some time
<lifeless> abentley: around ?
<abentley> lifeless: hi
<lifeless> abentley: do we have a sequence matcher style thing in bzrlib that can report AB -> BA as a move of A or B rather than a delete/add ?
<lifeless> abentley: I have an idea I'd like to toy with
<abentley> lifeless: No, we don't have anything like that that I know of.
<lifeless> K, I guess I'll write it :)
<abentley> But when I talked with John about it, he suggested doing multiple passes.
<abentley> With the existing sequence matcher.
<lifeless> this is for text reconstruction
<lifeless> I suspect a dict + single pass is all I need
<lifeless> though range output would be cheaper to represent
<lifeless> how would multiple passes work ?
<abentley> Do a sequence match.  Then do a sequence match against all lines that didn't match from the previous pass.
<lifeless> I see
<lifeless> so the first says A gone, B matched, A' is new, the second says A' matches
<abentley> Right.
<lifeless> so what I'm going to trry
<lifeless> is to write a VF implementation that uses single linear delta chains
<lifeless> given texts A, B, C it will serialise this as A, A->B, (A+A->B)->C
<lifeless> which will give the same compression as multiparent I believe
<lifeless> and the same IO as current knit chains, but in a single contiguous block
<lifeless> and only one delta to apply on reconstruction
<lifeless> (reading will require 3 pieces of information: basis start, basis length, basis end
<lifeless> erm, that last one is delta length
<lifeless> abentley: what do you think?
<abentley> I don't understand how you can reconstruct C with a single delta.
<lifeless> to make the delta for C
<lifeless> take the lines for A and the lines for the delta A->B, combined
<lifeless> then delta that combined text against C to make the delta
<abentley> I see.
<lifeless> you probably see the implications
<abentley> I didn't quite grok your notation at first.
<lifeless> but to spell it out and answer your question :), to get C back, read A and the A->B delta into a lines list, then read and parse the delta to C and apply it
<abentley> So you're trying to solve the problem of repeated delta application?
<lifeless> it will delete all the metadata about A and the A->B delta, and reorder some of the lines from the A->B delta  etc, and possibly also add lines
<lifeless> abentley: I'm sick and tired of repository size being raised as an issue
<lifeless> abentley: and this came to me today
<lifeless> it seems to balance out most everything we've previously discussed about getting good compression/reconstruction etc
<lifeless> (clearly you can get A and B etc out concurrently if desired
<abentley> What's the advantage over multiparent?
<lifeless> abentley: linear IO with capped depth
<abentley> you're only going to get linear IO in an optimized pack, and only for some revisions.
<Jc2k> lifeless: because i don't consider 8080 'live' yet, even though it got blogged about
<Jc2k> thats not that i don't think its ready
<abentley> You can also get linear IO in an optimized pack for some revisions with multiparent.
<Jc2k> just that i havent had time to hide it behind apache proxy redirects and update the templates and stuff
<lifeless> abentley: so, my theory is that if its fast enough (for instance, unlike gits approach it won't need to test N different texts), we can just redelta on auto pack
<abentley> And you can certainly cap the number of revisions required to generate a multiparent diff.
<abentley> sorry "cap the number of deltas required to reconstruct a fulltext from a multiparent diff"
<lifeless> I know we can cap the number of deltas, but it seems to require either multiple fulltexts, or fulltexts at dominators
<abentley> I'm not sure I follow.  You just count the number of deltas required, and if that exceeds X, you generate a fulltext.
<lifeless> for linear IO, multiparent seems quite a bit worse at that because only the simplest of graphs will have uninterrupted runs 100's of deltas long without bifurcation
<lifeless> abentley: say I have a graph A:[], B:[A], C:[A], F[chain back to B], G[chains back to C], H:[F, G]
<lifeless> abentley: the 'chain back to B' - imagine thats (say) 50 texts in a row
<lifeless> if H is not a fulltext, and A is further back than our threshold, we have to have two fulltexts read in to reconstruct H
<lifeless> one on the F leg, and one on the G leg.
<abentley> lifeless: Are we saying linear vs random, or linear as "uninterrupted"?
<lifeless> abentley: uninterrupted adjacent
<abentley> So both, then.
<lifeless> yes
<lifeless> I want to remove the build-graph logic entirely from text building
<lifeless> or at least, to make it the uncommon case
<abentley> But if A is not further back than our threshold, we can't get linear access to both F and G.
<lifeless> with MP diffs, no.
<abentley> In fact, we can't get linear access to both B and C.
<lifeless> nor with knits
<abentley> How is it different with yours?
<abentley> How can your do linear access to reconstruct B and linear access to reconstruct C?
<lifeless> changing notation to avoid typing as much... the compressor I'm talking about might compress this as A,->B,->C,-D,-E,...->F,->G,->H
<lifeless> where each ->FOO is 'delta the previous output to FOO'
<lifeless> we can to a certain extent do this with stock MP by just interlacing the diffs and sucking up any overlap
<abentley> I thought you were drawing the build graph.
<lifeless> abentley: I was drawing the text graph, which is what I understand MPDiff to compress against
<lifeless> abentley: a way to express it in MPDiff terms would be to have A be a NewText, B be a diffagainst A; C be a diff against A,B; D be a diff against A,B,C
<abentley> lifeless: That's the way current generators do it, but MPDiff doesn't require the build graph to reflect the history.
<lifeless> abentley: I clicked to that :)
<jelmer> grrr @ overheating intel hardware :-(
<jelmer> lifeless: Yeah, I'd be up for some sprinting if there is time
<lifeless> abentley: the different though is that that would require compression-depth sequence matches to output each additional diff
<lifeless> abentley: whereas what I'm proposing only requires one match
<Pieter> where there's a match, there's a flam
<Pieter> e
<lifeless> abentley: so its using the knowledge gained during each diff's generation to keep the overhead on generating the next diff capped
<abentley> That's interesting.
<lifeless> abentley: anyhow, I'll give it a spin and compare it against bundles, which I figure are about optimal in size (but have no fulltexts), and compare insert/extraction speed
<lifeless> in theory, if gzip was perfect, this is equivalent to:
<lifeless> gzip(A+B+C+D+E+F+G+H)
<lifeless> and I plan to profile that too :)
<lifeless> man, why doesn't evolution do full text indexing.
<lifeless> WTB featurs
<abentley> lifeless: So, to solve your original issue, it might be practical to run a sequence match against the lines from each input diff.
<lifeless> abentley: right, diff is small
<lifeless> abentley: so many diffs, but we expect them to be very fast
<lifeless> good idea
<abentley> So if we have A, B, C and we're generating D, you match (lines-from-A) against current, then match (lines-from-b) against unmatched-in-current.
<lifeless> I'll see how badly something naive pans out
<abentley> Cool.
<lifeless> if I'm right it will show serious promise on extraction and size and we can tune the compressor to our hearts content once the point is proven
<abentley> Because all of the previous diffs will have been generated by the same process, you probably won't get redundant matches.
<lifeless> abentley: can't get - we'd be stripping matches out anyhow
<sabdfl> where's the best place to get the loom plugin?
<abentley> One thing I think we lose vs MP is the ability to extract a sequence match vs X directly.
<abentley> sabdfl: lp:bzr-loom
<sabdfl> thanks abentley
<johan> Hi, I've been having some problems setting up pqm, is there a tutorial available somewhere?
 * johan looks at lifeless 
<lifeless> abentley: we would definitely lose that. We can look at storing the line indices for that concurrently
<abentley> sabdfl: np
<lifeless> Odd_Bloke: johan: meet each other :)(
<lifeless> its midnight, and I have to halt() or I won't be packed for GUADEC
<johan> oh
<lifeless> johan: Odd_Bloke is in UK time and hacking on pqm at the moment
<lifeless> johan: there is a full docbook manual for pqm FWIW.
<lifeless> anyhow, I'm off
<lifeless> sabdfl: see you on the flipside
<Laibsch> I am back to my problem of importing gnucash svn ï»¿http://rafb.net/p/ig6EvE25.html
<Laibsch> What can I do?
<Laibsch> The admin is now online
<Laibsch> If there is anything to do from his side, I can talk to him
<Laibsch> But he thinks the host blocking is what he wants
<johan> lifeless: thanks, I'll ask him about my troubles (mostly related to merges, configuring branches)
<lifeless> johan: oh, also Kinnison runs a pqm last I heard :)
<lifeless> really gone
<Laibsch> jelmer, ToyKeeper, LarstiQ: Can you help me?
<Kinnison> Aye, I do run a pqm
<Kinnison> but it's ages since I set it up
<Kinnison> johan: what seems to be the problem?
<LarstiQ> Laibsch: that pastebin looks like a different problem than admin configs
<Laibsch> LarstiQ: yes
<Laibsch> The question is, what kind of problem
<LarstiQ> Laibsch: one I hope to find in bzr-svn bugs, just a secx
<LarstiQ> sec
<johan> Kinnison: I get an error message when doing the merge, saying Sender not authorised to commit to branch xxx
<jelmer> Laibsch: which version of bzr-svn is this?
 * Laibsch hopes that the bug LarstiQ will find doeshave a fix ready
<Laibsch> jelmer: latest hardy
<Laibsch> 0.4.9 IIRC
<Kinnison> johan: Have you prepared a gpg keyring with your keys in it?
<jelmer> Laibsch: if it's 0.4.10, this is an issue that's fixed in the development branch
<Kinnison> johan: and associated that with the branch?
<Kinnison> e.g. with keyring=/home/dsilvers/websites/digital-scurf.org/bzr/pqm-home/permitted-keys.pu
<Kinnison> b
<Laibsch> jelmer: Actually, I was lying.  This was on a remote debian sid box and indeed it was 0.4.10
<johan> Kinnison: keyring=/home/pqm/.gnupg/pubring.gpg this is what I have
<jelmer> I'm I guess I have to release 0.4.11 rsn if subversion 1.5 has hit sid
<jelmer> s/I'm//
<Laibsch> yes, it has
<Kinnison> johan: And that keyring contains the pubkey that you're signing your merge request with?
<johan> user: "Johan Dahlin <jdahlin@async.com.br>"
<johan> 1024-bit DSA key, ID 3F370F9A, created 2006-02-21
<johan>  is being printed when I call gpg
<Laibsch> jelmer: ii  subversion                1.5.0dfsg1-2              Advanced version control system
<johan> Kinnison: and gpg --list-keys includes a key called 1024D/3F370F9A, so yes that should work
<Kinnison> hmm
<johan> Kinnison: I'm not sure how I associate it with a branch, isn't enough to have keyring in the [DEFAULT] section of the configuration file?
<jelmer> Laibsch: Yeah, that combination is known broken :-(
<Kinnison> I have my keyring=... in [DEFAULT] yes
<jelmer> Laibsch: You can either try 1.4.6 with 0.4.10 or 1.5.0/1.4.6 with 0.4.11 (0.4 branch)
<Laibsch> jelmer: Do I need to compile stuff or can I just apply a patch?
<Kinnison> johan: In your section for the locations, do you have a committers= line?
<Laibsch> I'll try subversion 1.4
<johan> Kinnison: nope
<Kinnison> hmm
<Kinnison> try this...
<Kinnison> in [DEFAULT] add
<Laibsch> But IIRC there were other issues
<Kinnison> groups=johan
<Kinnison> then underneath the [DEFAULT] section add:
<Kinnison> [johan]
<johan> Kinnison: it doesn't work even if I set verify_sigs to 0
<Kinnison> members=jdahlin@async.com.br
<Kinnison> then in the [file:///....] section add:
<Kinnison> committers=johan
<Kinnison> commit_re=.*
<Kinnison> then you'll have everything I have, associated with committing permissions
<Kinnison> It's possible you have to have the committers=... bit regardless of signatures
<Kinnison> As I say, I set this PQM up several years ago
<Laibsch> jelmer: yes, right. I remember now: http://rafb.net/p/oTdfdg66.html.  God, I really loathe debian for its brokenness.
<johan> Kinnison: okay, thanks I'll try that
<Kinnison> good luck
<johan> is there a way to make .bzr/branch/branch.conf persistent?
 * Kinnison shrugs and points at the bzr devs :-)
<johan> heh
<johan> do I need to edit the branch.conf file for each branch I want to use to submit to pqm?
<jelmer> Laibsch: Did you keep python-subversion installed?
<jelmer> Laibsch: (Since I assume you downgraded subversion?)
<Laibsch> yes, but it still is 1.5
<Laibsch> I'll downgrade it, too
 * Kinnison uses the pqm-submit plugin which can specify it on the commandline
<johan> Kinnison: that's what I'm using as well
<johan> merge http://async.com.br/~jdahlin/bzr/kiwi/ file:///home/pqm/branches/kiwi/
<johan> Command failed!
<johan> All lines of log output:Sender not authorised to commit to branch file:///home/pqm/branches/kiwi/
<johan> still the same thing
 * jelmer meanwhile prepares 0.4.10-2
<Kinnison> johan: Can you pop your pqm.conf on a nopaste for me to look at?
<johan> Kinnison: http://pastebin.com/f3e8965ce
<vgeddes> how does one add a working tree to a branch? I have forgotten the command
<Kinnison> johan: OOI, is your pqm.conf in the right place relative to the rest (I.E. are you confident it *IS* being read?)
<johan> Kinnison: yes, it's read, otherwise I'd get other error messages
<johan> I pass in -c filename.conf when I run the command
<Linnk> Hi :) How do I view a file as it was at a specific revision? Is it possible?
<jelmer> Linnk: bzr cat -rREVISION FILENAME
<Linnk> Ah, thanks!
<vgeddes> anyone?
<jelmer> vgeddes: "bzr co"
<Kinnison> johan: I'm at a loss, I'm really sorry
<johan> Kinnison: okay, thanks anyway!
<johan> I'll ask Odd_Bloke when he's around.
<jelmer> Laibsch: Any luck with 1.4 ?
<Laibsch> it looks like it is slowly importing
<jelmer> Laibsch: I'm about to upload 0.4.10-2 which will fix compatibility with subversion 1.5
<Laibsch> great
<Laibsch> I'll put it in my ppa, I guess
<vadi2> I've told bzr to checkout a launchpad branch, but it's just sitting here doing nothing (and giving no message) at all for quite a while now.. any reason this can happen?
<vadi2> (it only made the folder but with nothing inside it)
<rockstar> Is it a big branch?
<vadi2> I don't know how to tell. It's this one: https://code.launchpad.net/~chris-scutcher/colony/devel
<vadi2> It's not even giving me the progress bar though
<rockstar> I know that rather large branches take a while to display a status bar.
<rockstar> What version of bzr?
<vadi2> 1.5
<vadi2> I'm subscribed to the bzr ppa, so should be latest available
<fdv> uhm.. copy isn't supported, right?
<fdv> is there any way to retain history if I need to make a copy of a file?
<rockstar> Yea, it's still got the issue.  It's a known problem, and there is a patch, but it apparently didn't get into 1.5
<fdv> ah
<fdv> I saw some talk about it for 1.0 :p
<rockstar> fdv, not you, vadi2
<vadi2> oh
<fdv> rockstar: ah, ok :)
<vadi2> ï»¿rockstar: so do I just wait or wait for a bzr upgrade?
<rockstar> vadi2, it'll branch eventually.  I suggest you make a shared repo so when you branch again, it won't be so bad.
<vadi2> ok
<fdv> hm. come to think of it, I need to do my copy in svn eventually anyway, and I guess it's just as easy (or easier) to just do it there and update to bzr
<james_w> beuno: I'll be in on Tuesday
<beuno> james_w, cool!  you coming in to work all day?
<james_w> yep
<sabdfl> i have a loom on another server that I want to branch on my own machine, into an existing repo
<sabdfl> bzr branch seems to lose the loom info
<sabdfl> any suggestions?
<jelmer> I don't have much experience with looms, but maybe upgrading your repository to the loom format will help?
<jelmer> hmm, but looms use regular repositories..
<jelmer> sabdfl: apparently this is intentional
<jelmer> what may work is just creating an empty branch locally, loomifying that
<jelmer> and then pulling into it
<james_w> sabdfl: have you run "bzr record" ever?
<james_w> I think there may be a bug about this though.
<sabdfl> james_w: where would i run "bzr record" ?
<james_w> sabdfl: in your loomified branch. It records the state of the whole loom so that it can be branched, pulled, merged, etc.
<Maslowski> Hello! I work on windows and I try to create a branch from the SVN repository "https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk", but I have the error : Not a branch.  I have the SVN plugin installed. Any help will be welcomed.
<james_w> I'm not sure why it's not done on every commit, I think it might be that the command is only temporary until it is automatic.
<jelmer> Maslowski: Please try prefixing the url with svn+
<jelmer> Maslowski: e.g. svn+ "No instance for Monad (Either ParseError)" =/
<jelmer> whoops
<jelmer> svn+https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk
<Maslowski> I did it and still have "bzr: ERROR: Not a branch: "svn+https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk".
<jelmer> Maslowski: does "bzr plugins" list the svn plugin?
<Maslowski> yes, launchpad and svn 0.4.10
<jelmer> Maslowski: Any warnings when you run bzr that the bzr-svn plugin can't be loaded?
<jelmer> Maslowski: If not, can you pastebin the contents of your .bzr.log file?
<Maslowski> Pastebin considers the log file as spam
<Maslowski> do you want me to open a bug and attach the file to it?
<jelmer> Maslowski: pastebin.ubuntu-nl.org ?
<thekorn> hi all, 'bzr commit' is creating bzr_log.* template files in my current working directory, is there a way to avoid creating such files or creating them in /tmp ?
<Maslowski> jelmer: http://pastebin.ca/1062382
<james_w>     tmp_fileno, msgfilename = tempfile.mkstemp(prefix='bzr_log.',
<james_w>                                                dir='.',
<james_w>                                                text=True)
<james_w> hey thekorn
<thekorn> hi james_w
<thekorn> hmm, so it does not look like ;)
<thekorn> I've used bzr commit for a few weeks now and have 30 bzr_log.* files in my working directory
<james_w> "commit now can invoke an external editor in a non-ascii directory.  (Watkins)"
<james_w> bug 84043
<ubottu> Launchpad bug 84043 in bzr "commit fails to invoke external editor in non-ascii directory" [Medium,Fix released] https://launchpad.net/bugs/84043
<james_w> hmm, no, that's not right
<thekorn> I don't understand how this bugreport is related
<james_w> no, he removed the '.' while fixing it, and then put it back
<james_w> thekorn: I'm not sure why the '.' is there. You can probably file a bug about it.
<thekorn> james_w, ok, thanks for your help, I think I will file a bug because this really annoys me
<jelmer> Maslowski, Does svn work on that url?
<Maslowski> bzr branch http:... (without the 's' works. I'll try later with svn.
<Maslowski> thanks a lot for your help
<thekorn> james_w, sorry false alarm, I only have files like bzr_log.fZ2PE2~ which are created by my editor, so bzr is working as expected and removes the template file
<Stavros> hello
<Stavros> i've hit upon the "pop(): dictionary is empty" bug, does anyone know how to resolve it?
<james_w> thekorn: ah, great, did you close the bug?
<thekorn> yes
<james_w> thanks
<vadi2> ï»¿rockstar: how long is eventually? I left it over and hour and it hasn't moved :(
<rockstar> vadi2, dunno.  I know one branch took about two hours, but it has almost 7K of revisions and all the merge revisions
<vadi2> mk
<bkor> 6 lines of Python, and it has a bug
<Jc2k> lol :)
<lifeless> hola
#bzr 2008-07-05
<Peng> Ack!
<Peng> Paste's CLF-like log lines don't go in the log file either.
<Peng> Paste--
<Peng> I should just use 'tee'.
<Peng> That actually worked.
<lifeless> tee is love
<lifeless> abentley: around?
<lifeless> abentley: I think that what I'm proposing can be done using 'mpdiff' at least in part; if the accumulation of A,->B,->C etc is done without including the diff instructions - just including the new lines
<lifeless> then I can hold  basis line #->(parent #, line #), and output mpdiff instructions; reconstruction will only ask for the lines included in that set so we can avoid creating intermediary objects beyond creating a ParentText object that has a view on the aggregate basis lines.
<lifeless> this will mean that one of the incremental deltas is a well formed mpdiff delta, and we can grab it own its own and reconstitute it locally (the first in such a chain we'd need to do scatter-gather IO to put together its base texts, but after that we'd be laughing)
<lifeless> the only problem is that the parents list will grow, so I wouldn't really want to include it per se with each diff, I'd want to have it at the front of some region
 * Peng replaces sys.stdout and sys.stderr with a file. Beat that, Paste!
<mwhudson> Peng: os.write(1, ...) ?
<mwhudson> Peng: which log lines are you complaining about?
<Peng> :(
<mwhudson> (oh, and you're using some prehistoric paste anyway, right?)
<Peng> mwhudson: The ones formatted like an Apache log file.
<Peng> mwhudson: Probably.
<mwhudson> Peng: they should go to the 'wsgi' logger by default
<Peng> I'm using Ubuntu Hardy's Paste 1.6-2.
<mwhudson> oh
<mwhudson> no then really
<Peng> Should I upgrade?
<blueyed_> I was just using bzr-builddeb (from trunk; with bzr 1.5.0) and did "merge-upstream". This caused a "ConflictsInTree" error (basically because of a wrong, empty upstream file). So, I did "bzr revert" to get back to the old state, but this reverted the tree back to revision 1! (I just had committed r8 before).
<lifeless> james_w: ^
<mkanat> Isn't there some idiom for "copy this file"?
<blueyed_> "bzr info -v" says "8 revisions" in "Repository", but only "1 revision" in "Branch history"
<lifeless> mkanat: we don't support copies-with-history yet
<mkanat> lifeless: Ah, okay.
<mkanat> I was thinking of svn, which has the reverse idiom (one for mv).
<lifeless> mkanat: so 'cp + bzr add'
<mkanat> lifeless: Fair 'nuf.
<lifeless> mkanat: unless its between branches, then we can treat it as a mv after all ;)
<mkanat> Heh.
<mwhudson> Peng: no, the messages should go to the 'wsgi' logger
<Peng> mwhudson: What about exceptions?
<mwhudson> Peng: dunno, sorry
<mwhudson> utsl? :)
<Peng> Heh.
<Peng> So...logging.getLogger('wsgi')?
<mwhudson> yeah
<mwhudson> look at what start-loggerhead.py does for one approach
 * mwhudson is no longer here
 * lifeless pokes mwhudson 
<Peng> Hmm.
<Peng> mwhudson: Thanks for the help.
<blueyed> lifeless, james_w: I've filed bug 245718 about the issue above
<ubottu> Launchpad bug 245718 in bzr-builddeb ""merge-upstream" + ConflictsInTree + "bzr revert" reverted to r1" [Undecided,New] https://launchpad.net/bugs/245718
 * blueyed should not use "bzr revert" anymore.. ;/
<blueyed> Any chance that the data can be restored (from the "8 revisions" mentioned for the repository)?
<lifeless> usre
<lifeless> bzr heads
<lifeless> its a plugin
<blueyed> displays nothing
<lifeless> try -a
<lifeless> erm --all
<blueyed> ..this displays the revision, which I've committed last.
<lifeless> so
<lifeless> I have to go catch a plane
<lifeless> what you need is 'bzr pull -r revid:XXXX --overwrite .' - this will reset you to an arbitrary revision id
<lifeless> you just need to figure out what that id is
<lifeless> bye!
<blueyed> lifeless: thx, bye.
<blueyed> I guess the revid would be the one displayed by "heads --all"?
<blueyed> yes, it worked. phew.
 * Peng crosses his fingers.
<nnutter> Can anyone link a (graphical) benchmark comparison of recent versions of bzr and hg? Everything I'm finding seems to be pretty ancient.
<nnutter> Well, thanks anyway. Bye.
<awilkins> _damn_, bzr is faster on Linux
<beuno> *way* faster  :)
 * awilkins goes to try out the 34,000 file tree that is usually quite sluggish on Windows
<awilkins> Hmm, that seems to be slightly more challenging for it
<awilkins> real1m8.739s
<awilkins> I suppose it was off a USB stick
<awilkins> Whee, cold status, 4 seconds, hot status, 0.9
<awilkins> I almost feel like going in on Monday and claiming that Windows has a fatal data corruption error in it
<Laibsch> hi
<Laibsch> bzr-svn does not save the location to pull from for an import via "bzr get $URI"?
<james_w> blueyed_: yeah, sorry, it's the result of a silly decision in the past.
<savvas> How do I change file permissions in bazaar? I've changed the file permissions from -rwxr-xr-x to -rwxr--r--, tried to remove and re-add the file, but the file is still there with the 755 permission. Is there another way to do it?
<jelmer> Laibsch: Not in earlier versions
<Laibsch> OK
<awilkins> savvas: AFAIK it tracks the x bit but not the other permissions
<awilkins> savvas: And not group permissions, from the look of things
<savvas> hmm thanks
<awilkins> savvas: If you remove the public "r" access, then I presume they can't execute it?
<savvas> awilkins: so if I remove the file, commit, (wait a bit), re-add and commit, it won't change it?
<savvas> let me try it again, doesn't hurt heh
<awilkins> savvas: I think the permissions are the default ones for your folder, except the x bit, which is either set or unset for all three groups or
<savvas> ah
<awilkins> savvas: It's not entirely unreasonable behaviour ; if you can read the file, you can copy it to a location where you have permission to set the x bit, and run it there, so it possibly doesn't make it very much more secure
<awilkins> .. to be able to set the x bit on a per-group basis
<savvas> ok thanks
<savvas> awilkins: so if I got it right, I can add or remove the x bit, but not group-specific? either the file is executable for all groups or it's not, correct?
<savvas> well.. I tried removing the file and re-added it with no x bit
<savvas> better this way, at least during development :)
<savvas> thanks a lot for your help!
<vgeddes> is anyone having problems with `bzr log bzr+ssh://...' with bazaar 1.5?
<vgeddes> bazaar terminates with a lot of debug messages after I run that command
<vgeddes> here's the error: http://paste.debian.net/9426/
<Peng> All I can say is that it WFM with bzr.dev.
<vgeddes> WFM?
<pygi> works for me
<vgeddes> ah
<vgeddes> hmm
<pygi> tried 1.6b2?
<vgeddes> no, i haven't
<pygi> try it :)
<vgeddes> hmm, is it stable enough?
<Peng> The Bazaar developers do a very good job of making sure it always works.
<vgeddes> ok
 * pygi is using it :)
<Peng> "WFM" isn't widely-known, but I just got lazy, and it's not like I make sense anyway. ;P
<vgeddes> yup, 1.6 works for me :)
<pygi> vgeddes, great
<tacone> hello, wha't's the best way for a 1-time import of a svn repo into bzr ?
<lifeless> tacone: bzr-svn has a svn-import command tat works well
<tacone> I am manually installing right now, the repo version doesn't supporto bzr 1.50 and seems not to be present in bzr ppa
<tacone> Unable to load plugin 'svn' from '/home/tacone/.bazaar/plugins'
<tacone> mh, pysvn bindings :-)
<lifeless> tacone: I'm told that 0.4 is the right branch of bzr-svn to use; it has its own bindings and is faster and less problematic
<lifeless> tacone: jelmer here is the author, and the FAQ has info
<lifeless> I have to catch the next leg of my flight; ciao :)
<tacone> I'll check the faq
<tacone> I am using 0.4.10
<tacone> from the tar.gz which is likely to be the problem
<tacone> I'll try to check out from the branch. thanks
<leo2007> hi folks, I am trying to migrate from tortoisesvn to bazaar. One nice feature of tortoisesvn is that it can diff .doc files. any similar feature for bzr?
<ScottK-laptop> I am trying to push local changes back to launchpad using bzr and get this error: "bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ekubuntu-members/guidance/powermanager-ubuntu/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()".
<tacone> ScottK-laptop: looks like you need authentication
<ScottK-laptop> Would someone please point me in the right direction for how I do this?
<ScottK-laptop> OK. That makes sense.
<tacone> have you registered an ssh key for that laptop ?
<tacone> otherwise no https, so fallback to http happens and bla bla bla
<ScottK-laptop> No.  Are there alternative methods?
<ScottK-laptop> Right.
<tacone> with launchpad, not to my knowledge, but I asked the same question here some day ago :-)
<ScottK-laptop> OK.
<ScottK-laptop> Thanks.
<tacone> np
 * ScottK-laptop marks bzr + lp off as still to hard and figures maybe next year.
<Stavros> hello
<Stavros> how can i check which revision my WC is in?
<tacone> bzr revno ?
<Stavros> ah
<Stavros> thanks
<mathrick> ahoy
<mathrick> word on the street is that bzr-git is back from the dead
<mathrick> is that true?
<Peng> I heard that too.
 * mathrick hopes it is
#bzr 2008-07-06
<leo2007> does the windoes installer require python to work properly?
<Verterok> leo2007: there is a standalone bzr.exe and a installer that needs a python installation
<Verterok> leo2007: bzr-setup-1.5.exe is the standalone installer, and bzr-1.5.win32-[py2.5/py2.4].exe needs a python install
<leo2007> Verterok: trying to push a local branch to a remote machine through sftp, it didn't succeed
<Verterok> leo2007: any error msg?
<leo2007> Verterok: it looks like it succeeded but no files were actually uploaded.
<Verterok> leo2007: a push don't create/update a remote workingtree
<Verterok> leo2007: in the remote location you should have a .bzr/ dire
<Verterok> s/dire/dir/
<leo2007> Verterok: yes. but my local repo has versioned files
<leo2007> they weren't uploaded
<Peng> leo2007: Push doesn't create a working tree. All of the history is in .bzr.
<Peng> leo2007: If you just want to push and pull from that location, you don't need a working tree.
<Peng> leo2007: If you really do need one, check out the bzr-upload plugin.
<Verterok> leo2007: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#push
<Verterok> leo2007: check the "Description" section, or bzr help push ;)
<leo2007> Peng: Thank you. That resolved my confusion. I thought the files were being left out
<leo2007> what tool do you use to manage bzr repo in windows? I have been using the dos window and it is quite inefficient.
<Verterok> leo2007: I don't use windows, but take a look to qbzr, bzr-gtk and tbzr (tortoise-like)
<Verterok> leo2007: http://bazaar-vcs.org/QBzr , http://bazaar-vcs.org/bzr-gtk
<Verterok> leo2007: and http://bazaar-vcs.org/TortoiseBzr
<leo2007> Verterok: thank you very much. I will take some time to read the doc properly.
<Verterok> leo2007: y'r welcome :)
<leo2007> Verterok: good night;)
<Verterok> leo2007: seeya
<rockstar> james_w, are you around?
<alencool> hello
<alencool> is there anyone in here that could help me?
<skavez> is there an easy way to install bzr-svn on os x? or is recompiling svn still the only way?
<RAOF> Newer bzr-svn has it's own subversion bindings; you'd need to build bzr-svn, but you shouldn't need to rebuild subversion.  I think.
<lifeless> ola!
<lifeless> so
<lifeless> who wants to hear some good ne
<lifeless> ws
<RAOF> lifeless: Oooh!  Oooh!  Me!
<lifeless> RAOF: on the plane I wrote a new compressor that is (unoptimised) 10% slower than knits, but generates data 10% of the size: smaller than git-repack --window 200 --depth 200
<RAOF> My my.
<RAOF> That _is_ impressive.
<lifeless> am now ingensting caffeine and grease
<lifeless> and will try to make it end user accessible/fix some glaring inefficiencies
<RAOF> I hope you're rounding that meal out with the other 2 food groups (starch and burnt crispy bits).
<lifeless> git  200, 200        638227   0.6MB
<lifeless>  patience all:
<lifeless> 16665951 25.320 197 164 0-mbp%40sourcefrog.net-20050323055643-668814a4d6478235
<lifeless> after zlib 599036
<lifeless> and - thats getting some stuff whackily wrong ecause sequencematcher is not designed for relocations
<lifeless> so am rewriting the match logic entirely
<lifeless> RAOF: oh, I don't do any of that whacky try-N diffs and pick one stuff either.
<RAOF> You're not using the rsync compression algorithm, either :)
<lifeless> no
<lifeless> its broadly speaking just sliding window with references to the output
<RAOF> Is this possibly going to improve initial-branch-from LP speed?
<lifeless> but line orientated and entropy coded post processor
<lifeless> well, downling 10% of te total data -> should be faster
<lifeless> but there is a ways to go from here to production
<RAOF> Right.  Initial-branch is basically the only bzr operation that takes an apreciable and annoying time for me, so that's the filter I view bzr improvements through.
<RAOF> I should really learn a little more compression theory.  I'm only familiar with huffman encoding.
<lifeless> so huffman is probabilistic encoding:
<lifeless> build a tree weighted by the probability of a symbol, and to emit something you name a path in the tree; the deeper the tree the more things you can output with a short path
<RAOF> Right.
<lifeless> I'm reasonably sure I have http://www.amazon.com/Data-Compression-Book-Mark-Nelson/dp/1558514341 first edition around at home somewhere
<lifeless> or a t least, I have *a* textbook on dc
<lifeless> anyhow dictionary based compression you have a dictionary, and the compressor outputs keys in the dict
<lifeless> most compressors are dynamic these days - turning the state with the symbols rom the input stream, and the decompressor mirrors that
<RAOF> Ok.
<lifeless> anyhow, what I do is:
<lifeless> output the first text
<lifeless> diff the next against that, output the diff
<lifeless> dif the next against the total output so far
<lifeless> and so on
<lifeless> so the output is a combination of refernces to the output stream so far, and new symbols
<lifeless> which is basically an infiinte window  dictionary cmopressor
<lifeless> the only reason to do this in preference to e.g. lzma is that I know I don' need the intermediate texts
<lifeless> so decompression is basically one read, split the bytes into 'text before the delta we want, and the delta w want'
<lifeless> pasrese the delta
<lifeless> apply
<lifeless> also, typign from London; excuse the spellink
<RAOF> :)
<RAOF> Right.  So, nice and quick unpacking.  Cool.
<lifeless> yah, typical dictionary decompressiors need to care about the entire input stream
<lifeless> whereas my references are not to an internal symbol able, but to the actual output
<lifeless> less efficient,. but for some work sets I'm seeing 200:1 compression *before* zlib is applied
<RAOF> I suppose revision data is likely to be an ideal candidate for compression.
<lifeless> one insight the git devs had that is very useful is that decreasing size makes most patches a series of deletes
<lifeless> (or more deletes than adds)
<lifeless> I *think* I can make that largely irrelevant, but until I finish replacing the 'does this work' sketch with something that handles moves it will bite
<skavez> argh! does "bzr: ERROR: exceptions.ImportError: cannot import name make_file_factory"  sound like something i can fix? i'm getting it while trying to branch an svn repo with bzr-svn 0.4.11 and bzr 1.6b2
<lifeless> skavez: you need bzr.dev for that version of bzr-svn I think
<BjornT> do i need any special configuration for using 'bzr send'? when i try 'bzr send --mail-to=email@example.com', all that happens is that a terminal with mutt is opened (listing my inbox), and no mail is sent
<skavez> lifeless: ah ok. i'll give that a shot
<lifeless> BjornT: the hlep should describe it BjornT ; its trying to use mutt as your mailer; perhaps you have misconfigured xdg-utils or something?
<BjornT> lifeless: well, i'd love to use mutt :), as long as it would allow me to send the e-mail.
<lifeless> BjornT: poke at the help, and the mnual, failing that file a bug
<BjornT> lifeless: at least it works if i specify mail_client=mutt
<BjornT> xdg-email email@example.com doesn't work either, so i guess that's where the bug is
<lifeless> BjornT: I would guess so
<lifeless> RAOF: lp:~lifeless/+junk/bzr-groupcompress
<lifeless> -<> gate A18 now :)
<j^> is it a common problem that the trac plugin gets really slow for the /timeline view?
<j^> when i started a new repos it was ok, but it seams it gets slower with each commit i make
<jetto> hello
<jetto> I come from cvs and Clearcase(base not ucm), and I'm looking to use a more advenced scm tool.
<jetto> I'm very confused with bzr concept I want to do some test one a real work
<jetto> I try to hack a game : rrgbis. I got sources from SF and do some fix. then upstream release a new version than include some of my fix. I would like merge then continue to hack.
<jetto> How can I do this on bzr ? I mean having something like a vendor branch on CVS
<Odd_Bloke> jetto: What SCM tool are they using on SF?
<uws> cvs :)
<Odd_Bloke> Hmm, I'm not sure of the best way to deal with CVS is.
<bigdog> good morning
<bigdog> is this the place to ask about a problem I am having pushing a branch up to launchpad?
<bigdog> I am using windows
<uws> bigdog: yes, or #launchpad
<bigdog> I am using bzr 1.5
<bigdog> uws: I will start here, If I describe my problem, and I should go to #launchpad, let me know
<bigdog> When I was using bzr 1.2, on windows, with ssh key,  I was able to push branches with no problem (a couple of months ago)
<uws> bigdog: i'm not the one who can help you I'm afraid
<bigdog> uws: ok
<uws> but usually the people in this channel are quite responsive and helpful
<uws> so do proceed
<bigdog> thanks
<bigdog> So everything worked a couple of months ago.  windows + pagaeant  .
<bigdog> yesterday I had some time to push a new branch.  I noticed there was a new version of bzr, so I grabbed and ran the installer
<bigdog> H:\launchpad\txcomputegrid>bzr launchpad-login -v  bigdog
<bigdog> bzr: ERROR: The user bigdog has not registered any SSH keys with Launchpad.
<bigdog> I have the same ssh key, that is registered with paegent
<bigdog> same response for set BZR_SSH=plink
<bigdog> and set BZR_SSH=paramiko
<bigdog> any insight?
<bigdog> uws: Sunday morning is busy day for people,  I will try #launchpad
<Odd_Bloke> bigdog: That'll probably be a result of the Debian SSL issues.
<Odd_Bloke> bigdog: Check that you actually _do_ have a LP key registered.
<bigdog> Odd_Bloke: thanks
<Tim3393> Hello,
<Tim3393> I have a question regarding the way bazaar does handle duplicate files when storing them in a repository.
<Tim3393> In my project there are often a number of identical files in different locations of the working tree.
<Tim3393> As I do not want the repository to be unnecessarily blown up I would like to know if bazaar is so smart that it will detect the identical copies and actually only store their content once?
<clemente> Bazaar stops when doing some operations (ex: branch) and starts running again after I press ENTER four times...
<clemente> In fact it's doing read(0,...) according to strace
<clemente> Do you also get this behaviour? I can always reproduce it
<clemente> Both with 1.5 and with latest version from today
<clemente> It is probably related to dbus...
<antoranz> hi guys! Do you know when 1.6 is commign out?
<leo2007> how to set up emacs to use bzr in windows?
<clemente> (I submitted bug 246052 for that problem of halting on STDIN)
<ubottu> Launchpad bug 246052 in bzr "Bazaar halts and silently expects input from STDIN" [Undecided,New] https://launchpad.net/bugs/246052
 * Foskasse âââ ââ¬â â âââ
<Kinnison> How delightful
 * Foskasse ââ¬â â
<Kinnison> My god it's expensive to convert from weave to btree-plain
<kgoetz> hi hackers! i seem to have exploded bzr :( http://paste.ubuntu.com/25500/ i installed python 2.5 recently. could this be the cause?
<gour> Kinnison: when is btree supposed to go into trunk?
<Odd_Bloke> kgoetz: That error looks familiar, but I can't remember what causes it. :(
<kgoetz> Odd_Bloke: incase it helps: i merged from the repos default branch, then realised i had no local changes, then pulled, and you see the result there.
<Kinnison> gour: no idea
<Odd_Bloke> kgoetz: I'd recommend looking through LP for bugs and looking at the ML.
<kgoetz> Odd_Bloke: i'll try and give LP a trawl.
<kgoetz> this bug looks similar, but seems totally unrelated. https://bugs.launchpad.net/bzr-gtk/+bug/237205
<ubottu> Launchpad bug 237205 in bzr-gtk "error starting webbrowser.GenericBrowser in python2.4" [Medium,Fix committed]
<mwhudson> any devs awake?
<abentley> mwhudson: I'm not *really* awake...
<mwhudson> abentley: so bzr get nosmart+<http url that redirects> bombs out pretty messily
<mwhudson> abentley: any obvious ideas for places to look?
<mwhudson> oh
 * mwhudson finds a fixme
<mwhudson>             # FIXME: If 'transport' has a qualifier, this should
<mwhudson>             # be applied again to the new transport *iff* the
<mwhudson>             # schemes used are the same. Uncomment this code
<mwhudson>             # once the function (and tests) exist.
<mwhudson>             # -- vila20070212
<abentley> mwhudson: I haven't see the actual traceback...
<mwhudson> sorry
<mwhudson> abentley: http://pastebin.ubuntu.com/25504/
<abentley> Yeah, so I think you've already found the relevant bit.
<mwhudson> though the exception is from before the comment
<mwhudson> but yeah, it seems the problem is somewhat known
<mwhudson> i guess vila is the man to hassle about this
<abentley> mwhudson: So what's being done there is a bit bogus.
<abentley> Because there's no reason to assume that it's a relative path.
<mwhudson> right
<abentley> It could legitimately be on a different host, for example.
<mwhudson> indeed, in http its really really not supposed to be
<abentley> So it should probably be using urlutils.relative_url instead.
<mwhudson> something a little funky is happening, because http redirects do actually work most of the time
<abentley> That operation doesn't error when the urls are unrelated.
<abentley> Okay, here's what I think happens.
<abentley> relpath is being used in a check.
<abentley> specifically, if I try to get foo/bar/baz, I should get redirected to */baz
<mwhudson> right
<abentley> And there's a discrepancy between what e thinks the url was and what the transport thinks it was.
<mwhudson> hm hm
<mwhudson> abentley: i think the problem is more basic:
<mwhudson> abentley: http://pastebin.ubuntu.com/25513/
 * mwhudson winds up a poking for spiv when he wakes up
<abentley> mwhudson: How does that contradict me?
<mwhudson> abentley: it doesn't
<abentley> Oh.  Okay.
<mwhudson> well, hm
 * mwhudson thinks
<abentley> I think that it is correct to not treat http://foo/bar as a child of bzr+http://foo
<mwhudson> p = '...'; get_transport(p).relpath(p) shouldn't fail though, should it?
<mwhudson> this is tripping up the puller where we force all http: urls to be nosmart+
<mwhudson> maybe there's a better way to do that
<abentley> mwhudson: Yes, it's legitimate for that to fail.
<abentley> get_transport may canonicalize the url, and it may do a lookup.  e.g. lp:bzr
<mwhudson> hm
<abentley> transport.base will give the the final value the transport used.
<mwhudson> so yeah, this stuff in redirected() does look a bit bogus then
<jetto> hum bzr looks like too hard form me :-(
<mwhudson> jetto: ?
<jetto> I would like to do some thing very simple and it's not clear how to do it :
<jetto> I get source as a tgz from upstream. I hack a little, then the upstream release a new version. I merge and continue to hack. How to do this ?
<mwhudson> jetto: i think the 'bzr import' command can help with this
<jetto> I mean I would like to follow pure upstream change (maybe in a branch) and do my change in another
<mwhudson> jetto: something like bzr init-repo repo; bzr init repo/upstream
<mwhudson> cd repo/upstream; bzr import ~/release-0.1.tgz; bzr add; bzr ci -m 'relese 0.1'
<mwhudson> cd ..
<mwhudson> bzr branch upstream
<mwhudson> bzr branch upstream my-branch (sorry)
<mwhudson> cd my-branch
<mwhudson> hack hack hack
<mwhudson> cd ../upstream
<mwhudson> bzr import ~/release-0.2.tgz; bzr add; bzr ci
<mwhudson> cd ../my-branch
<mwhudson> bzr merge ../upstream
<mwhudson> (disclaimer: i haven't done this)
<jetto> well I'll test this, thanks.
<jetto> It's hard for me to adapt to decentralized SCM
<jetto> even choosing one is very hard ;-)
<jetto> do I need to do a init-repository ?
<mwhudson> you don't need to make a repository no
<mwhudson> it's just a way of sharing storage, it takes up less disk space and makes making new branches quicker
<mwhudson> but i guess in your case, history is going to be pretty shallow
 * Foskasse  1:20 para fazer anos!!!
<jetto> mwhudson, your pocedure rocks, thanks
<mwhudson> jetto: glad i helped
 * Foskasse quase quase quase a fazer anos!!! :D :D :D
<Pilky> jetto: if it helps at all you can use bzr as a centralised VCS, with all the improved branching/merging benefits
<Pilky> in some ways bzr is one of the best centralised VCSs out there ;)
<jetto> Pilky, I think I'll do this but not for home work
<luiss> hola
<luiss> hola
<luiss> hola
<poolie> hello
<Verterok> mornin' poolie
#bzr 2009-06-29
<mwhudson> hmm
<lifeless> mwhudson: ?
<mwhudson> lifeless: nm :)
<poolie> good morning bzr!
<lifeless> hi poolie
<igc> morning
<kingos> lifeless: thanks for your help so far with my bug 356028. Where do we go from here?
<ubottu> Launchpad bug 356028 in bzr "bzr check fails with KeyError" [Undecided,New] https://launchpad.net/bugs/356028
 * igc continues reviewing the check patch from lifeless
 * igc lunch
<lifeless> igc: what -Dprogress changes?
<lifeless> igc: oh, I see it.
<igc> lifeless: ui/text.py + some doc in debug-flags & NEWS
<lifeless> yah
<lifeless> I can split it out if needed, but it seems like make-work
<rockstar> lifeless, around?
<lifeless> yes
<rockstar> lifeless, scenario: I have a working tree with changes in it from a merge.  How can I get the revisions that are being merged into this tree?
<lifeless> cli or lib?
<rockstar> lifeless, lib
<rockstar> lifeless, it looks like WorkingTree.changes_from(WorkingTree.basis_tree).modified will give me a list of tuples in which index 1 is a rev id.
<lifeless> tree.get_parent_ids() returns a vector
<lifeless> 0 is the tree's commit (which may not be the branch tip if the tree is stale)
<lifeless> 1 is the first merge
<lifeless> etc
<lifeless> then use tree.branch.repository (or some other repo if needed) to get a graph - r.get_graph()
<rockstar> Hm.  That's a bit sub-optimal.  The WorkingTree is a checkout, both branches are remote branches (on Launchpad)
<lifeless> if you want all the 'new revs' you can use one of the difference functions in the graph object (pydoc bzrlib.graph.graph) to get the new revs
<lifeless> the tree doesn't store or cache the new revs details
<rockstar> Yea, all I want is the revs that will be merged in the merge.
<lifeless> if you want the revs that will be the parents of the new commits, it is precisely tuple(tree.get_parent_ids())
<lifeless> assuming this is for tarmac; it sounds like you're reproducing some aspect of bzr core - is there some higher level functio that isn't quite right?
<rockstar> Well, ideally, I want all the revs that will be part of the merge, i.e. the source branch may have 10 revisions with 3 different authors.  I want to find those 3 authors.
<lifeless> ok, then do the graph bit I referenced above
<rockstar> You mean bzrlib.graph.Graph ?
<lifeless> tree.branch.repository.get_graph(), and then one of the functions there can give you the difference data
<lifeless> bzr status -v does precisely this
<lifeless> in terms of performance; firstly lightweight checkouts over the internet are slow.
<lifeless> I don't recommend that lightweight checkouts ever be used over the net
<lifeless> but even so - you need the revision graph, so there really isn't anyway around it: you either have it locally, or you don't :)
<rockstar> It's not lightweight.  It's similar to what PQM does, if I'm not mistaken.
<rockstar> Although Tarmac is pretty worthless if the net goes away.
<lifeless> if its a heavyweight checkout then you have the revision data locally
<rockstar> Okay.  That's good.
<rockstar> But that local revision data is still gotten through tree.branch.repository, correct?
<lifeless> yes
<lifeless> the branch oobject will be a local bound branch
<rockstar> Ah, that's nice.  I always wondered what the difference was between lightweight and heavyweight checkouts.
<vila> hi all
<poolie> hey vila
<poolie> spiv, how did you go today?
<spiv> poolie: good so far.  A little bit of API friction but nothing serious.
<spiv> I have StreamSource producing inventory delta records and StreamSink consuming them successfully in-process, I think.  I haven't done a full test suite run yet though.
<lifeless> spiv: I'm inclined to have it in the normal SS and SS
<lifeless> spiv: rather than subclasses; what do you think?
<lifeless> spiv: (your text implies you agree, just putting it out there for explicit consideration)
<spiv> lifeless: yes, that's definitely my preference, and how it's implemented so far.
<spiv> The only real impediment to that I think is making sure it can operate compatibly with network sinks/sources that can't take inv deltas, I haven't poked much at that yet but I'm sure it's not going to be too bad.
<lifeless> spiv: I think we should define them as all taking them
<lifeless> its why I made this a critical bug, so it would be in place for 2.0 and not need bumping then
<poolie> well
<spiv> Sure, but there are 1.16 and earlier servers (and clients) that can't.  Possibly we can just make RemoteStreamSink/Source translate delta->fulltext before passing to the network serialisation layer.
<poolie> ^w
<lifeless> spiv: on a missing verb condition? yes, for push. pull will get the missing verb asking for the stream.
<spiv> (iff the network layer knows that the other end can't cope with inv delta recods)
<spiv> Right.  Like I said, I don't think it's too hard to deal with.
<lifeless> agreed
<lifeless> EOD
<poolie> spiv, so when you say in process you mean it works doing a cross-format local pull?
<poolie> or push
<spiv> poolie: right.
<vila> spiv: do you know how to bind a class method into an instance method explicitly ?
<vila> spiv: re-reading my question I now have doubts about the means :) The need is: I want to decide at load_tests() time what method will be called inside setUp. I don't want to have a test in setUp, I want a single raw call
<spiv> vila: I don't quite follow your question.
<spiv> Or what problem you are trying to solve :)
<vila> spiv: I want parametrized tests to call a method during setUp. I want to define that method in load_tests. I refer to that method by its name, so I get the class attribute,
<vila> If I make a call with attribute, it's an unbound method
<vila> If I make a call with that attribute, it's an unbound method
<vila> spiv: my current workaround is to do:         self._do_changes(self)
<vila> and that's ugly :)
<spiv> I don't understand why it would be an unbound method in that case.
<spiv> There's some part of this picture I don't see :)
<spiv> if you do "x = object.method", then "x" will be a bound method (assuming no wacky descriptors like property, staticmethod, etc)
<vila> spiv: because the test object is created and then self.do_change receive class.method because the test instance doesn't exist when load_tests is called
<lifeless> vila: ?!
<lifeless> vila: pastebin your code
<lifeless> vila: you're doing something special
<spiv> vila: so you're doing "x = klass.method", because you don't have an instance of the object yet?
<spiv> (why?)
<spiv> In that case, yes, you should do what you're doing.
<spiv> There's probably a way to bind it post hoc, but I'd avoid the magic.  This sounds like a strange thing to be doing, though.
<vila> http://paste.ubuntu.com/206061/
<poolie> i'm going to stop soon...
<vila> spiv, lifeless: I realize I shouldn't run into that, that's why I ask where I went wrong :)
<vila> poolie: g'night
<spiv> vila: so I think that's as clean as you can make that approach with current APIs
<vila> spiv, lifeless : An other way to do what I want is to use the *name* of the method, but it's not very elegant either :-/
<lifeless> so to paraphrase
<lifeless> you want to run a set of tests in a class, twice
<spiv> vila: because multiply_tests doesn't give you any way to read attributes off the test cases you are multiplying, just assign to them.
<lifeless> changing one function call from A to B
<vila> spiv: yes
<vila> lifeless: yes
<spiv> vila: (and you really would want to make sure that if it did it that the bound methods were bound to the right TestCase instance!)
<lifeless> vila: file a bug on testscenarios if you would; this is interesting :)
<spiv> vila: personally I think I would have gone with the name of the method and a getattr
<spiv> getattr at call time, that is, obviously.
<vila> spiv: Yeah, that's what I thought, thanks
<spiv> Because "here's the name of the method" is a very clear indirection point.
<vila> lifeless: will do, thanks too :)
<spiv> And also because that would consume less memory I think ;)
<vila> spiv: and can be explicitly checked at setUp time, right
<spiv> Creating methods via assigning callables to instances is pretty cool, but it's easy for it to be confusing.
<vila> spiv: well, the same can be said about any technique you don't practice often
<lifeless> def do_dirty_tree:
<lifeless>     getattr(self, change_method)(self)
<spiv> Well, yes, but particularly with dynamic features where you can't e.g. look up _do_changes in your tags file an get taken to the method definitino.
<vila> spiv: I don't think cricket rules are so confusing since my last trip to Australia for instance :-D
<spiv> vila: do you remember how many ways there are to get out? :)
 * vila looks behind him, but no, lifeless isn't reading above his shoulder :)
<vila> spiv: no. But I think I could understand when it happens when watching a game...
<spiv> (http://en.wikipedia.org/wiki/Laws_of_cricket#Ways_to_get_out has the answer)
<vila> 42 laws... now, *that's* says a lot about H2G author :-)
<vila> err HG2
<poolie> vila, having what looks like a test class but only exists to provide those mixin bits seems not quite right
<poolie> hm
<vila> lifeless: https://bugs.edge.launchpad.net/testscenarios/+filebug :-P
<lifeless> vila: bah humbug
<vila> poolie: creating a mixin just for creating a mixin ?
<poolie> using the word mixin loosely
<lifeless> vila: one way would be to write those mutators as standalone functions that take a test case object
<vila> poolie: Right, I see your point
<lifeless> vila: testscenarios has a functional feel
<poolie> in parts...
<poolie> not so much in
<poolie> +    tests.multiply_tests(changes_tests, changes_scenarios, result)
<lifeless> using the word functional loosely :P
<poolie> that line was just annoying me
<lifeless> vila: fixed
<poolie> it's a shame it doesn't return a thing for you to use
<vila> poolie: so that I can assign the right method there you mean ?
<vila> I'm quite happy with getattr(self, self._do_changes)()
<vila> I'ts clear, light and robust
<poolie> so i was going to theorize thatn
<poolie> if you want more power in your test multiplication stuff
<poolie> you're probably doing it wrong
<poolie> as they say
<poolie> like, trying to test too many combinations
<poolie> presumably the effects of strictness are separated in the code from the determination of whether we're strictly ok or not?
<poolie> vlia, what i was going to say about the mixin class is, why not put do_uncommitted_changes and do_pending_merges into the TestPushStrict class
<poolie> if they're only used there
<poolie> and then, um
<poolie> getattr(self, self._type_of_changes)
<jml> vila, rugby union also has laws
<vila> poolie: it seems we all agree about getattr(self, self._do_changes)()
<vila> jml: well, the point is, I once watched a cricket match, and when one team burst out in joy, I was puzzled about why :)
<vila> jml: at least in rugby you get some understanding that when the ball pass the line, points are scored :)
<poolie> > Results 1 - 10 of about 1,210,000 for rugby scandal
<spiv> vila: depends on which line :)
<poolie> vila: :) my new bit, maybe, is suggesting you fuse the classes
<poolie> also, i think _do_changes is not such a good name
<poolie> because it actually sounds like a method
<poolie> but you can't _do_changes
<poolie> i mean, you can't _do_changes()
<spiv> Sometimes the ball passes a line and then they stand in a funny formation and just toss it back over the line ;)
<poolie> oh like basketball? :)
<vila> poolie: I may be overtesting here, but yet, the full test suite reveals at least one bug when I make --strict the default for push (push can be used without tree and I wasn't testing that)
<spiv> Yeah, a variable name that clearly indicates "this variable is the name of a method" rather than "this variable is a method" would be good I think.
<poolie> vila: nice one
<poolie> and fair enough
<poolie> on further consideration
<poolie> i think one reason to put the methods in their class is to make it clear how much stuff they apply to
<vila> spiv: but they are having some kind of discussion when they stand in that funny formation, not a single team piling up with joy :)
<poolie> parameterization is kind of action-at-a-distance
<poolie> which can be confusing
<poolie> so the more you do to reduce the distance and make it clear, the better
<spiv> poolie: right
<abeaumont_> vila: i'm playing with bzr-upload testsuite, i'm trying to add a test for my branch, but i've seen that many tests are disabled due to not having FtpServer feature, i installed test_local_server but even with the plugin (and installing anon proftpd) it didn't work, looking at the code i'm not sure it should work... should it?
<vila> poolie: yes,
<vila> abeaumont_: short: you want to install muddleftp
<vila> abeaumont_: long: local_test_server is used to *inject* real ftp servers into the test suite
<spiv> poolie: and also it helps make clear what facilities the methods can use (i.e. a method on a TestCaseWithTransport can obviously use self.make_branch, a free function somewhere less clearly so).  "Action at a distance" is a key part of the problem, I think.
<vila> spiv: I agree with that
<vila> poolie: my intent in defining more classes here is that it's better than a single one for clarity. It may not be pure enough for application code, but the classes are final here, so any reader can focus on trivial test code without the need to  read more classes
 * igc dinner
<abeaumont_> vila: ah, ok, i'll look at muddleftp. Thanks!
<vila> abeaumont_: eerk, memory playing tricks, I meant: http://code.google.com/p/pyftpdlib/
<vila> abeaumont_: bzrlib supports medusa and pyftplib, but medusa is bogus starting with python2.6
<vila> abeaumont_: look at bzrlib/tests/ftp_server directory for all the details
<abeaumont_> vila: ok, thanks again :)
<abeaumont_> vila: i was surprised to see that my broken code didn't cause any test to fail, until i used verbose :D
<vila> abeaumont_: hmm, but even the non verbose mode should tell you about skipped tests no ?
<abeaumont_> vila: yes, but i didn't take it too seriously (FtpServer? my trivial test doesn't need such a thing :)
<vila> abeaumont_: :)
<nil1> Hi
<nil1> Is the encrypted repository format already usable?
<jml> hmm.
<vila> lifeless: ./bzr selftest '(?i)loom' => FAILED (failures=3, errors=6)   :-}
<vila> lifeless: no offence intended, just a data point :-D
<\sh> lifeless: bug #81689 , well this could be a nice workaround, but in general I would like to see that behaviour fixed on MS Windows :)
<ubottu> Launchpad bug 81689 in bzr "Branches with symlinks can't be checked out on Windows" [Medium,Triaged] https://launchpad.net/bugs/81689
<TheJosh1337> Hi
<TheJosh1337> Does anyone know of a tool that I can use to generate merge graphs for a bzr repo?
<TheJosh1337> like 'bzr visualise'
<TheJosh1337> I wan't to show a commit history graph on a web page
<vila> TheJosh1337: bzr qlog
<vila> ha, that's different, I thought you wanted bzr viz for all branches in a shared repo
<TheJosh1337> What I want is a generated image file which I can dump onto a website
<vila> You want to ask again to beuno maybe, or garyvdm (but he's off-line right now)
<TheJosh1337> showing the commits and merges made to trunk
<TheJosh1337> or become friendly with the PHP gd commands
<TheJosh1337> beuno, is there a program that is similar to bzr viz, but which generates an image file appropriate for embedding on a web page?
<asabil> TheJosh1337: I think bzrtools has something like that
<asabil> it generates a graphviz file iirc
<TheJosh1337> cool
<TheJosh1337> sweet that's perfect thanks!q
<TheJosh1337> asabil, Thank you that was perfect. The tool generates .pngs native, so it's perfect.
<TheJosh1337> im off now, going to bed
<beuno> vila, hi!
<vila> beuno: good morning ;-)
<beuno> vila, good afternoon
<beuno> how are you?
<vila> beuno: fine, you ?
<beuno> vila, pretty good as well
<beuno> want to help me out with a small OSX issue?
<beuno> I need bzr 1.16 working on 10.5  :)
<vila> let's try
<vila> beuno: let me guess, you have the C files for the extensions ?
<beuno> vila, I haven't done anything, the guy always uses the installer
<beuno> and there's only one available for 1.14
<vila> oh, damn, phanatic where are you ? :-/
<vila> hmm, wait didn't someone create an installer for 1.16 ?
<beuno> and I impulsively upgraded all branches at the office to 2a
<beuno> and I left out one of the guys who uses 10.5
<verterok> beuno: just use 1.16 from source
<beuno> verterok, how do I tell him to do that?  :)
<vila> verterok: can't you 10.4 installer be used on 10.5 ?
<vila> verterok: can't youR 10.4 installer be used on 10.5 ?
<verterok> vila: no :( becuase 10.5 defulat python installation is in a different directory than the MacPython install in 10.4 :p
 * vila cries
 * verterok joins vila
 * beuno cries
<vila> http://bazaar-vcs.org/MacOSXBundle/Prepare
<verterok> beuno: curl <url to tar.gz> > bzr-1.16.1.tar.gz &&  tar -zxf bzr-1.16.1.tar.gz && cd bzr-1.16 && make; ./bzr
<vila> verterok: excellent ! Update the wiki :-P
<verterok> vila: heh
<beuno> verterok, will try that, and continue crying about the installer
<beuno> thank you  :)
<vila> http://straussd.fourkitchens.com/bzr-1.16-osx-10.5.zip
<beuno> oh
<vila> http://straussd.fourkitchens.com/bzr-1.16-osx-10.5-2.zip
<verterok> beuno: or I can build a bzr-only package in my 10.5 machine...but you 'll need to wait bit
<vila> eerr, forget the first link
<verterok> ohh, nice!
<beuno> OH
<beuno> even nicer  :)
<vila> I thought that one found its way to the right place though, I'll try to poke the list
<beuno> perfect, now I feel less bad about upgrading everything without talking to anyone
<beuno> thank you  :)
<verterok> vila: btw, I'm doing a bit of research to automate the 10.5 installer build, looks like it's possible as 10.5 use an xml descriptionto build the installer, with 10.4 I'm still stuck with the manual build (damn binary formats!)
<vila> verterok: that would be a signigicant step for 10.5 and maybe you may find a way to use that installer for 10.4 too....
<verterok> vila: I hope so...
<beuno> vila, installer worked great
<vila> beuno: please reply on the list and keep david in CC :-P
<phinze> so i've got local changes in a branch i need to move to another local branch, which i would usually cheat with cd ~/right.place; bzr diff ../wrong.place | patch -p0
<phinze> but this time it has file moves
<phinze> which diff/patch won't pick up... is there a way to pull this off with shelves or something?
<phinze> or is it just easiest to replay the moves and then diff/patch (which i imagine may very well be the case)?
<jml> phinze, cd right.place; bzr merge --uncommitted ../wrong.place
<phinze> aha... will give it a shot jml
<vila> jml, phinze: will work if both branches are at the same tip
<phinze> "All changes applied successfully.
<phinze> beautiful; thanks :)
<jml> phinze, yeah, it's one of my favourite features.
<phinze> vila: actually wrong.place was a large feature branch and right.place was trunk, and it work without problems...
<phinze> so i guess today i got lucky :)
<vila> phinze: oh, it will always work, the question is will it do what you think :)
<vila> phinze: merge --uncommitted will get the uncommitted changes but also the missing revisions
<jml> vila, !
<phinze> hah; yeah looks good for this case, though the code in question was in a plugin that is kept in sync between the two branches, so that probably helps
<phinze> the merge didn't look like it was any more than what 'bzr st' showed
<vila> phinze: most of the time I use it to apply a work in progress on a remote-but-accesible-vis-mounted-file-system machine where I want to run tests before committing
<vila> s/vis/via/
<phinze> yeah i was in a fixing-bug-on-feature-branch-caused-by-plugin-code-kept-in-trunk situation
<vila> jml, phinze: bah forget me, I misread the command as (cd ~/wrong.place; bzr diff) | (cd ~/right.place; patch -p0)
<trondn> Hi.. How do I update the content of a sandbox to a given version ?
<trondn> or do I need to create a new clone to do so?
<trondn> (I'm thinking of the equivalent of just doing: hg up -r <rev> )
<dash> 'bzr revert -r xxx'
<trondn> dash: thanks
<ingenthr> quick question based on trondn's; if i bzr revert -r previous-rev-no
<ingenthr> bzr revno still shows the current revno
<dash> right. revert only affects your working copy, not your branch.
<ingenthr> this is why i thought revert wasn't doing it's thing...  how can see what the state of my current branch is?
<dash> which part of its state?
<ingenthr> oh, okay, how can i see my current working copy
<dash> it's the files you've got :)
<ingenthr> use case is as follows: i need to go back and work on an older, tagged version
<ingenthr> so i used bzr tags to find the revno
<dash> ok
<ingenthr> then the correct thing to do is revert to that revno and do whatever work i need to do?
<ingenthr> thanks for the help by the way dash
<dash> np
<dash> well it depends
<ingenthr> do i have the right workflow for my use case?
<dash> you want to create a new version based on modifications to the version at that tag, and not including the changes since the tag?
<ingenthr> in this case, probably not
<ingenthr> but i can see other cases where i may
<ingenthr> i.e. a "sustaining tail"
<ingenthr> i guess that'd be it's own branch then?
<dash> yes
<dash> you can do 'bzr branch -r <revno>' if you only want to get the history up to a certain point
<dash> when creating a branch
<ingenthr> but in the case i'm not making changes, i can just revert -r revno and do my build with alternate parameters, right?
<dash> yep.
<ingenthr> okay, thanks.... spent a lot of time with the docs on this...
<ingenthr> i didn't find much in the docs with what to do with a tag once you've got one :)
<ingenthr> and i'm obviously new to bzr
<dash> it's just a name for a revision
<ingenthr> yeah, it's the larger workflow issues
<ingenthr> i.e. going back to a tag, working from there, issuing a patch, etc.
<ingenthr> i think i'm in good shape for now though, thanks dash!
<dash> :)
<dash> ingenthr: bzr itself, for example, has separate branches for each major version
<dash> so if there's a problem in 1.15, changes can be made in lp:bzr/1.15 and 1.15.1, 1.15.2, etc., versions can be released from there
<ingenthr> where 1.15 is a tag, right?
<ingenthr> not a revno
<dash> it's a branch name
<dash> they may use tags, I don't remember.
<Chuck__> Hi all. I appreciate bzr for its ease of use. I am currently worked with just one colleague on a paper in latex and we want to use bzr. I have my own repository and I sent it to him via e-mail. Now what is the most straightforward way to send him a patch which he may merge (eventually getting conflicts)? I want the result to be that we have the same revisions
<Chuck__> I tried to use bzr submit -o file
<Chuck__> using as a public branch a branch with the exact revision I sent
<Chuck__> and then merge works, but does not commit a new version, so the log message is not the same for example. I want instead to see the same log message and author of the commit on both sides.
<luks> the original revisions are still there
<luks> but if there were no modifications on the other side, he could use pull instead of merge
<luks> then the branch would look identically on both sides
<Chuck__> aha just use pull
<Chuck__> and if there are conflicts it will work as usual
<Chuck__> he will get conflicts, then send a patch to me, isn't it?
<luks> if there is a possibility for conflicts, pull will refuse to work
<luks> pull will only work if there are no changes at all
<Chuck__> hmm conflicts always lead to confusion. So if we both change the repository what are the options to get synchronised?
<Chuck__> without both having r/w access to a repository?
<luks> well, the easiest option is to use merge and not worry
<luks> bzr log will still show you the original revisions
<Chuck__> luks: you mean, use merge, and then commit?
<luks> but it will have one new revision, the merge commit
<luks> yes
<Chuck__> but if I happen to have both repositories, will bzr be able to tell that the two seemingly different commits are the same?
<luks> as I said, there are situations when you can use pull instead of merge
<Chuck__> He could pull on a clean copy of the last synchronisation point
<luks> Chuck__: I think you are misunderstanding how merge works
<Chuck__> and then merge with his own, that would work?
<Chuck__> luks please explain me if you have time
<Chuck__> I always get confused by VCS in general
<luks> sure
<luks> let's assume you have two branches, both with two commits A B
<luks> now if you commit C to one of them, you can use bzr send to generate a patch and use bzr pull on the other side to apply it
<luks> then you end up with identical branches on both sides
<luks> now let's say you commit C to one of them, and send him the patch
<luks> but before he gets the patch, he commits D to his branch
<Chuck__> luks wait a sec. I am already lost
<luks> now you have "A B C" and he has "A B D"
<Chuck__> ah ok
<Chuck__> yes this is the situation
<luks> and in this situation you need to merge
<Chuck__> aha ok
<luks> so after merge you end up something that is not really a line
<luks> one sec
<Chuck__> yes this is clear, it's like a diamond sort of
<luks> ok, so I'm not doing to "draw" it :)
<luks> the point is that bzr knows where each revision is from
<luks> and it knows the original ordering of the revisions
<Chuck__> ok
<Chuck__> so the merge is actually a new revision
<luks> so your revision C is still there, but there is a new revision, under which your original revision is merged
<luks> yes
<Chuck__> yes but will I see C in the changelog?
<luks> of course
<Chuck__> hmm then I did the wrong experiment, let me redo it
<luks> you will see it "indented" under the new revision
<Chuck__> aah so only when I finally commit the merge. So the merge status is special. I have the conflicts and then I can commit, but it will actually commit 2 revisions
<Chuck__> did I get it?
<luks> technically, it will commit only 1 revision
<luks> your original revision will be copied when you run merge
<Chuck__> my original revision="C"
<Chuck__> ?
<luks> and the new revision will be added when you merge
<luks> yes
<Chuck__> but after merge if I do bzr log I still don't see C, right?
<luks> Chuck__: are you on windows by a chance?
<luks> Chuck__: you should see C
<Chuck__> luks: no way, I left windows for good 12 years ago :)
<Chuck__> aha ok I will retry now
<Chuck__> ok I see C
<Chuck__> whatever it is
<Chuck__> I was just wrong earlier.
<luks> if you have bzr-gtk or qbzr installed (bzr plugins), you can use bzr viz or bzr qlog
<luks> that should make it much more obvious what's going on
<Chuck__> so it's very clear now. I just prepare a patch with "bzr something" which I already forgot, and then "bzr merge" on the obtained file. What is something btw :) I'll write this down
<Chuck__> bzr send
<luks> something is send :)
<luks> yea
<Chuck__> you've been patient and helpful. Thanks. A last question though: is there any sane reason why I should prefer the hassle to find a shared sftp service instead of sending patches via e-mail in such a simple scenario?
<luks> it might be easier for you than sending emails
<luks> but no technical reason
<luks> the result will be the same both ways
<Chuck__> the result is the same, that's what it seems, ok.
<luks> yes
<Chuck__> *very* good. This will become popular among my friends :)
<Chuck__> because until now we had two options: a centralised server, which always was a pain, because of passwords, and firewalls, or send all the files by e-mail every time, which is a pain when the directory grows
<Chuck__> now we will use bzr :)
<Chuck__> thanks again and bye
<luks> bye :)
<Chuck__> luks sorry there is still a "very last one" :) Previously I did bzr diff using as a "public branch" just the result of "bzr branch -rLAST_REVISION_SENT" on my repository. Is there a more convenient way than re-creating a branch every time?
<dash> diff takes an -r argument
<luks> dash: but send doesn't (in an useful way)
<Chuck__> bzr send I meant
<luks> Chuck__: unfortunatelly, there isn't
<Chuck__> luks the pqm extension seem in topic but I do not dare :)
<dash> hm
<luks> you can bzr pull -rLAST_REVISION_SENT in the pseudo-public branch
<dash> can't you use 'bzr diff -rsubmit:'?
<luks> dash: you can't merge from that
<luks> send is useful because it sends a bundle
<luks> but it insists on a public branch
<dash> oh, sorry, he meant send. :)
<Chuck__> ok no problem so I will have two repositories. One will be the most up-to-date idea I can have of the "other" repository, that is the "pseudo public repository". The other one will be my working copy.
<luks> I think bzr send with -r or -c will start doing cherry-picks
<luks> which are not the desired result
<Chuck__> luks yes -r applies to the "local" revisions
<Chuck__> I think it would be possible to implement this behavior in bzr itself
<luks> yeah, there were some discussion what should send do in such situations
<luks> the use case was very similar actually
<luks> for now you will have to run pull in the public branch every time you send a patch
<Chuck__> luks not sure: I will have to wait for the possible merge, and either pull or merge myself no?
<Chuck__> no sorry, always pull
<luks> Chuck__: no, you don't have to wait for the merge
<Chuck__> yes I do, I want the other person's changes :)
<luks> well, they will send it to you
<luks> but that should not block the workflow (from bzr point of view)
<Chuck__> and I will apply these at least in the working copy. But what about the "pseudo public"
<Chuck__> ah yes I know
<Chuck__> but then the notion of synchronisation point is becoming fuzzy again
<Chuck__> so when I get the merge from the other party, I have to pull it in the public repository
<Chuck__> and then this is my new public repo
<luks> if you send a patch, and after that update the pseudo-public branch to match your working branch, it will work
<luks> merging from somebody else is just "working on the branch"
<Chuck__> I will probably send redundant versions including the other person's own merge in the future, but it will work.
<luks> yes, exactly
<luks> you can look at the log he sent, and update the pseudo-public branch to the right revision
<Chuck__> ok now I got the complete picture I hope. Pull in the pseudo-public, merge in the working copy
<luks> but that might be too much work
<Chuck__> this must be automatised
<Chuck__> ok bye for now I wish I had the time to help a bit.
<dash> Hm =/
<dash> does loggerhead 1.10 not work with bzr 1.16?
<dash> https://bugs.launchpad.net/loggerhead/+bug/382765 suggests it does not
<ubottu> Ubuntu bug 382765 in loggerhead "history.py uses deprecated (and deleted) ProgressBarStack" [Critical,Triaged]
<jenred> hello! Having a very frustrating problem with bazaar +launchpad maybe someone could help?
<jenred> I'll ask anyway ;>
<jenred> despite having what looks like a good local setup -- I have a GSoC student who keeps getting permission denied when she tries to push to her branch
<jenred> as far as I can tell her key-pair is set up correctly
<Tak> anyone have thoughts about the design for a gui for interactive conflict resolution?
<beuno> Tak, something that shows me the code that I have, and the code that's coming it clearly and let me decide which one to keep, for starters, would be fantastic
<Tak> beuno: well yeah, those are the essential ingredients
<beuno> exactly, essential is a fantastic start!
<Tak> but I'm hoping to come up with something a little less clumsy than, say, the tortoise ui
<luks> jenred: it's hard to say what's wrong without knowing details
<jenred> luks is there somewhere better to ask?
<jenred> she's running Intrepid and has regenerated her keys multiple times
<jenred> -Dhpss did give her a  "report a bug" with a traceback -- I think she's opening a bug
<luks> well, the obvious problems might be missing "bzr launchpad-login"
<jenred> we already tried that ;>
<luks> or not uploaded key on launchpad
<jenred> yep key is there
<luks> or wrong key on laynchpad
<jenred> that's what I was thinking but she's double-checked
<luks> can she use sftp to connect to bazaar.launchpad.net?
<jenred> not sure if she's tried sftp ... we'll give that a try
<luks> that might give some more useful error message
<dash> "interactive conflict resolution"?
<dash> is that the new euphemism for a fight in the parking lot
<jenred> luks thanks
<luks> jenred: btw, just to be safe, when I said sftp I meant actual sftp client, not a sftp url for bzr
<jenred> ohhh
<jenred> right
<jenred> she's getting a bzr: ERROR: Unable to connect to SSH host launchpad.net; EOF  during negotiation
<jenred> using sftp url
<luks> bazaar.launchpad.net
<luks> not launchpad.net
<jenred> right
<jenred> no luck but a better error message
<jenred> i think there is a mismatch problem between her UID locally, and her lp login
<kanika_vats> luks, Hi there I am the one getting this error jenred is talking about.....
<kanika_vats> I have tried everything what you have said.....also I feel that I have my right ssh public key registered with launchpad...and that my launchpad-login registered with bazaar is also correct
<luks> "sftp YOUR_LAUNCHPAD_IS@bazaar.launchpad.net"
<luks> *ID
<kanika_vats> alright...let me see
<kanika_vats> ohk...i have got an sftp> prompt
<luks> so it's working
<kanika_vats> yea...it is
<luks> what's your launchpad ID and what's the project/branch you want to push to?
<kanika_vats> launchpad ID: kanika-krikan
<kanika_vats> branch:lp:~systers-dev/systers/orm
<luks> ok, try bzr push with this URL - bzr+ssh://kanika-krikan@bazaar.launchpad.net/~systers-dev/systers/orm/
<kanika_vats> i am getting the error:
<kanika_vats> Permission denied (publickey).
<kanika_vats> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<luks> well, that's strange
<kanika_vats> I know it is.....have tried many things...and have also checked everything is right multiple times
<kanika_vats> I am able to do a local commit...an update..checkout everything except commiting or pushing to my launchpad branch
<luks> can you please run "bzr push -Derror bzr+ssh://kanika-krikan@bazaar.launchpad.net/~systers-dev/systers/orm/" and pastebin the error?
<kanika_vats> ohk...yea sure
<luks> ideally from ~/.bzr.log
<kanika_vats> there is no log file....in ~/.bzr
<kanika_vats> wheni do ls
<kanika_vats> i get
<kanika_vats> branch  branch-format  branch-lock  checkout  README  repository
<kanika_vats> these files
<kanika_vats> but the error that i am getting on running the above cmnd is:
<luks> on in ~/.bzr, "less ~/.bzr.log"
<luks> btw, having a .bzr dir in your home directory is probably not a good idea
<kanika_vats> I am not having .bzr dir in my home directory
<kanika_vats> I am having it another directory /usr/local/mailman where i checked out my code from the launchpad branch
<kanika_vats> Permission denied (publickey).
<kanika_vats> bzr: ERROR: bzrlib.errors.ConnectionReset: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<kanika_vats> Traceback (most recent call last):
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 857, in run_bzr_catch_errors
<kanika_vats>     return run_bzr(argv)
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 797, in run_bzr
<kanika_vats>     ret = run(*run_argv)
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 499, in run_argv_aliases
<kanika_vats>     return self.run(**all_cmd_args)
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 802, in run
<kanika_vats>     use_existing_dir=use_existing_dir)
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/push.py", line 47, in _show_push_branch
<kanika_vats>     dir_to = bzrdir.BzrDir.open_from_transport(to_transport)
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 798, in open_from_transport
<kanika_vats>     return format.open(transport, _found=True)
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1725, in open
<kanika_vats>     return self._open(transport)
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 2605, in _open
<kanika_vats>     return remote.RemoteBzrDir(transport)
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/remote.py", line 76, in __init__
<kanika_vats>     response = self._client.call('BzrDir.open', path)
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/smart/client.py", line 111, in call
<kanika_vats>     result, protocol = self.call_expecting_body(method, *args)
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/smart/client.py", line 124, in call_expecting_body
<kanika_vats>     method, args, expect_response_body=True)
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/smart/client.py", line 72, in _call_and_read_response
<kanika_vats>     expect_body=expect_response_body)
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/smart/message.py", line 258, in read_response_tuple
<kanika_vats>     self._wait_for_response_args()
<kanika_vats>   File "/usr/lib/python2.5/site-packages/bzrlib/smart/message.py", line 224, in _wait_for_response_args
<kanika_vats>     self._read_more()
<kanika_vats>   
<kanika_vats>  File "/usr/lib/python2.5/site-packages/bzrlib/smart/message.py", line 247, in _read_more
<kanika_vats>     "(and try -Dhpss if further diagnosis is required)")
<kanika_vats> ConnectionReset: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<kanika_vats> this is what i get on running the command
<luks> kanika_vats: I'm afraid I don't know what's the problem :(
<luks> you can try asking in #launchpad
<luks> they will be probably more helpful
<kanika_vats> hey never mind .....thanks a lot for your time and help
<kanika_vats> I will ask the launchpad people about the bug....
<kanika_vats> ;>
<kanika_vats> thnks
<spirov92> hey, there's no example on using feature branches. How do these work?
<dash> it's a branch
<dash> you write a feature
<dash> then later, you merge it to the mainline.
<spirov92> sounds simple
<spirov92> to use a feature branch, do I have to copy the files?
<luks> no, you have to create a branch
<luks> using "bzr branch" :)
<beuno> mwhudson, hi
<beuno> I feel like releasing loggerhead again
<Lo-lan-do> Yay
<mwhudson> beuno: ah yeah, good idea :)
<Lo-lan-do> Will you be at debconf?
<beuno> there are 2 blockers I can think of:  we need to ship with a daemonized version of serve-branches
<beuno> and, we need to fix the Critical bug that breaks lh and bzr 1.16
<Lo-lan-do> So we can discuss how best to integrate with fusionforgeâ¦
<beuno> Lo-lan-do, I won't this time  :(
<Lo-lan-do> Blah
<beuno> Lo-lan-do, there may be other developers like lifeless
<beuno> he's a DD, but I'm not sure if he plans to go
<Lo-lan-do> I think jelmer will be there.  But anyway, I'll poke you on IRC when the release is done.
<beuno> mwhudson, bug 382765
<ubottu> Launchpad bug 382765 in loggerhead "history.py uses deprecated (and deleted) ProgressBarStack" [Critical,Triaged] https://launchpad.net/bugs/382765
<beuno> I have *no* idea how to fix it
<beuno> mind if I assign it to you?  :)
<mwhudson> beuno: i can't in any way make the code fail
<mwhudson> so i guess we should delete it
<beuno> yay!
<beuno> easy fix
<mwhudson> beuno: the bug about loggerhead not working as a plugin should be fixed i guess
<beuno> mwhudson, agreed. Target whatever you feel needs to be fixed before release. I'm going to tackle some of the bugs, and start brushing up on the release process
<beuno> Lo-lan-do, do you have the code you use to daemonize serve-branches?
<Lo-lan-do> Um, I thought you merged it alreadyâ¦
<beuno> did I?
<Lo-lan-do> http://bzr.debian.org/loggerhead/users/lolando/loggerhead/daemonise
<Lo-lan-do> Drop the first "loggerheadd/" for the branch URS
<Lo-lan-do> L
<beuno> thanks Lo-lan-do
<Lo-lan-do> bzr missing --other http://bzr.debian.org/users/lolando/loggerhead/daemonise
<Lo-lan-do> You might need to rebase and/or port to current code :-)
<jam> poolie: ping
<poolie> hi jam
<poolie> jam, want a chat?
<jam> yep
<beuno> mwhudson, any ideas why even though I have python-paste installed, I can't import it from any version of python?
<mwhudson> beuno: that sounds fairly broken
<beuno> mwhudson, it's a fresh install from 2 weeks ago, after setting up Launchpad
<mwhudson> beuno: is /var/lib/python-support/python2.6/paste/ there?
<beuno> mwhudson, yes, and has files
<mwhudson> beuno: and what happens when you import paste in python2.6 ?
<mwhudson> beuno: is /var/lib/python-support/python2.6 on sys.path?
<mwhudson> (if not, then everything would be broken i guess
<mwhudson> )
<beuno> >>> import paste
<beuno> Traceback (most recent call last):
<beuno>   File "<stdin>", line 1, in <module>
<beuno> ImportError: No module named paste
<beuno> I do have it in sys.path
<beuno> >>> import sys
<beuno> >>> print sys.path
<beuno> ['', '/usr/lib/python2.6', '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload', '/usr/lib/python2.6/dist-packages', '/usr/lib/python2.6/dist-packages/PIL', '/usr/lib/python2.6/dist-packages/gst-0.10', '/var/lib/python-support/python2.6', '/usr/lib/python2.6/dist-packages/gtk-2.0', '/var/lib/python-support/python2.6/gtk-2.0', '/usr/local/lib/python2.6/dist-packages']
<mwhudson> beuno: this is impossible :)
<mwhudson> beuno: try running python -v
<mwhudson> and then import paste
<mwhudson> (there will be heaps of output, pastebin it)
<beuno> mwhudson, https://pastebin.canonical.com/19122/
<mwhudson> ??
<mwhudson> beuno: maybe the same with -vv ?
<beuno> mwhudson, https://pastebin.canonical.com/19123/
<mwhudson> beuno: does /var/lib/python-support/python2.6/paste have an __init__.py file?
<lifeless> ls /var/lib/python-support/python2.6 for us
<beuno> lifeless, https://pastebin.canonical.com/19124/
<beuno> mwhudson, it does not
<mwhudson> beuno: well there's the problem then
<lifeless> I think you need to run 'sudo update-python-modules /usr/share/python-support/python-paste.public'
<lifeless> or sudo update-python-modules python-paste.public, if the former complains about the argument
<rellis__> How do you pass in username with bzr+ssh:// ?
<lifeless> bzr+ssh://USERNAME@host/...
<rellis__> bah i thought i tried that
<beuno> lifeless, https://pastebin.canonical.com/19125/
<beuno> mwhudson, I've reinstalled the package thrice!
<mwhudson> beuno: i guess you need to find someone know knows something about ubuntu
<mwhudson> (that's surely not me :/)
<mwhudson> beuno: have you tried searching for similar bugs on launchpad?
<lifeless> beuno: karmic ?
<beuno> lifeless, jaunty
<beuno> mwhudson, searching...
<lifeless> beuno: run the second command I gave you
<beuno> lifeless, I did
<beuno> that's the pastebin
<lifeless> please include the actual command run when pastebinning, it will avoid confusion
<beuno> yeah, sorry  :)
<beuno> both commands give the same output
<lifeless> I can't tell if you did 'sudo update-python-modules /usr/share/python-support/python-paste.public' or 'sudo update-python-modules python-paste.public'
<beuno> lifeless, both gave me the same output
<lifeless> ok
<lifeless>  ls /usr/share/python-support/python-pas* -d - I get  '/usr/share/python-support/python-pastedeploy.public  /usr/share/python-support/python-paste.public  /usr/share/python-support/python-pastescript'
<beuno> beuno@beuno-laptop:~$ ls /usr/share/python-support/python-pas* -d
<beuno> /usr/share/python-support/python-paste  /usr/share/python-support/python-pastedeploy  /usr/share/python-support/python-pastescript
#bzr 2009-06-30
<lifeless> ok
<lifeless> sudo dpkg -P python-paste
<lifeless> or in your favourite front end, choose 'purge'
<beuno> lifeless, launchpad-dependencies
<beuno>  is yelling at me when I try to do that
<beuno> -f?
<lifeless> yes
<beuno> lifeless, done
<lifeless> now install it
<beuno> lifeless, no luck
<beuno> ImportError: No module named paste
<lifeless> dpkg -L python-paste
<beuno> lifeless, https://pastebin.canonical.com/19126/ is all I did
<beuno> lifeless, https://pastebin.canonical.com/19127/ for the above command
<lifeless> uh
<lifeless> have I mentioned I hate eggs
<lifeless> you'll need to check that the namespace package contents are correct, and dig into the egg info
<beuno> ew
<lifeless> does zc.buildout use eggs? if so, chalk another ugh up for it
<beuno> it does
<beuno> which is why I suspect that installing LP first is to blame
<beuno> beuno@beuno-laptop:~$ cat /usr/share/python-support/python-paste/Paste-1.7.1.egg-info/namespace_packages.txt
<beuno> paste
<lifeless> the pth files is the namespace path info
<beuno> beuno@beuno-laptop:~$ cat /usr/lib/python-support/python-paste/python2.6/Paste-1.7.1-py2.6-nspkg.pth
<beuno> import sys,new,os; p = os.path.join(sys._getframe(1).f_locals['sitedir'], *('paste',)); ie = os.path.exists(os.path.join(p,'__init__.py')); m = not ie and sys.modules.setdefault('paste',new.module('paste')); mp = (m or []) and m.__dict__.setdefault('__path__',[]); (p not in mp) and mp.append(p)
<mwhudson> wow that's *beautiful*
<mwhudson> (mine is the same)
<beuno> looks like perl
<mwhudson> "the problem with setuptools is that people use it"
<mwhudson> (unlike other pje creations, which managed to inspire saner alternatives before they took off in their own right)
<lifeless> so
<lifeless> check your import hook list too
<lifeless> uhm
<lifeless> and mwhudson - is python-support in your python path?
<lifeless> (fooding and picking up mail from the post office, be 15)
<mwhudson> lifeless: yes
<cdecarlo_> hi, kinda embarassed to ask, but I grabbed bzr-gtk from apt (ubuntu) but I'm unser of how to run the gui?
<lifeless> beuno: one thing you could try is to add python-support to your path by hand
<lifeless> beuno: and see if that works, if so that would be useful data
<beuno> lifeless, ok, I'll ask mwhudson for the command or from you when you get back  :)
<mwhudson> lifeless: python-support is on beuno's path
<beuno> cdecarlo_, you have new commands now. Try:  bzr help commands
<cdecarlo_> oh, tricky
<mwhudson> lifeless: the problem is that /var/lib/python-support/python2.6/paste/__init__.py doesn't exist
<mwhudson> (afaics anyway)
<beuno> mwhudson, does it exist for you?
<mwhudson> beuno: yes
<mwhudson> (it's an empty file)
<beuno> I can try creating it, but it feels wrong
<mwhudson> yes yes it does
<mwhudson> my limited understanding is that something in python-support is supposed to create these files after installation
<beuno> mwhudson, creating the __init__.py file fixes the import problem
<lifeless> mwhudson: it's not in the package forme
<beuno> I've removed it so we can figure out what's breaking it though
<mwhudson> lifeless: me neither
<mwhudson> if you mean what i think you mean
<mwhudson> mwh@grond:dont-test-self-stacking$ dpkg -S /var/lib/python-support/python2.6/paste/__init__.py
<mwhudson> dpkg: /var/lib/python-support/python2.6/paste/__init__.py not found.
<lifeless> its likely meant to interpret the namespace-packages.txt file or something
<lifeless> I couldn't find quick docs on that
<lifeless> really -> post, now
<mwhudson> beuno: what version of the python-paste package do you have installed?
 * mwhudson stares at a debian/rules file
<beuno> mwhudson, apt-cache says 1.7.1-1ubuntu1
<mwhudson> beuno: and python-support?
<beuno> mwhudson, 0.8.7ubuntu5~launchpad
<mwhudson> same as me
<mwhudson> wtf is going on
<beuno> gat
<beuno> garrrr
<beuno> I'd blame myself, but it's a fresh install
<beuno> the reason I did a fresh install is to avoid these things  :)
<lifeless> look at update-python-modules
<lifeless> def post_change_stuff
<mwhudson> beuno: ok
<mwhudson> sudo update-python-modules  python-paste
<mwhudson> creates that file for me
<mwhudson> i see lifeless is chasing the same tails as me :)
<mwhudson> however
<mwhudson> that command is in postinst
<beuno> mwhudson, same here
<mwhudson> so if removing and installing the package doesn't create the file, something odd is going on
<mwhudson> (well, it's in postinst if i debuild here...)
<mwhudson> /usr/sbin/update-python-modules is not the finest example of python coding i have ever seen
<SamB> mwhudson: what might be?
<poolie> hello beuno, all
<beuno> heya poolie
<lifeless> back
<thumper> poolie: got a few minutes?
<poolie> thumper: for you, always
<thumper> :)
<poolie> lifeless: what do you think of https://pastebin.canonical.com/19067/
<poolie> nm i added the traceback to bug 390563
<ubottu> Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,In progress] https://launchpad.net/bugs/390563
<poolie> beuno, how's 2a going for you?
<james_w> I've had a few instances of AbsentContentFactory related exceptions
<james_w> I believe that is the bug that is fixed in 1.16.1 though
<poolie> james_w: hi! robert says, in 390563, that we haven't closed all cases
<poolie> but most seem to be fixed
<james_w> would you like me to open a new bug report with the backtrace I have?
<james_w> it's one in autopack
<poolie> hm
<lifeless> james_w: upgrade your bzr
<james_w> *I* can't
<lifeless> poolie: we have several bugs with the same bottom line but different intermediate stack traces
<james_w> if it's a released version then a friendly sysadmin will
<lifeless> james_w: its fixed in newer bzr
<james_w> great, good to know
<lifeless> autopack failing in 2a is fixed in dev, nightlies and 1.16.1
<lifeless> james_w: as a workaround, you can pack the repo that is failing
<lifeless> james_w: that will defer autopacking
<james_w> I've only hit it twice so far, so implementing a workaround will be more work than just retrying the import when a fixed bzr is available on that machine
<james_w> thanks for the tip though
<beuno> poolie, doing great, flawless up to now. All ~120 branches converted, and just one very odd problem, which jam helped me resolve, and that a bug in bzr 0.13 or so introduced
<beuno> speed has increased so much I don't even recognize the process  :)
<beuno> space savings aren't something to write home about in my case
 * SamB wonders how jelmer expects people to check out dulwich from git ...
<SamB> ... and how he pushes to it
<mwhudson> he pushes to it with bzr-git of course
<SamB> that's funny given what the launchpad page for bzr-git says: https://launchpad.net/bzr-git
<mwhudson> SamB: he uses dpush
<SamB> mwhudson: oh, yuck :-(
<SamB> what does the d even stand for?
<SamB> ... and why can't he at least push a repository that git can checkout?
<mwhudson> i guess you should ask him :)
<SamB> but, but, he's not here :-(
<mwhudson> gasp
<SamB> or maybe he fixed that
<spiv> The d stands for destructive/devilish/deviant or something ;)
<RAOF> SamB: git clone  git://git.samba.org/jelmer/dulwich.git works fine here?
<SamB> RAOF: yeah, he must have fixed it
<SamB> or git has changed
<SamB> one of those
<SamB> used to have a .git directory in there that git really didn't like
<poolie> spiv, are you aroundL how's stuff?
 * igc lunch
<KhaZ> Hey!  My tree is out of date, and if I do bzr update, it requires a merge.  Fine so far, except it's trying to rename a directory that has OS proteciton on it.  Is there a way I can tell bzr to update without moving the directory?
<lifeless> KhaZ: no; its moving the directory because it got replaced on trunk
<KhaZ> lifeless: Nuts.  I suppose that makes sense, but I was hoping I could have a work around so I could merge them manually in the meantime.
<lifeless> KhaZ: why does it have os protection
<lifeless> SamB: ping
<SamB> yeah?
<lifeless> SamB: bug 393694 is odd
<ubottu> Launchpad bug 393694 in bzr "bzr internal error: AttributeError: 'module' object has no attribute 'builtins'" [Critical,Fix released] https://launchpad.net/bugs/393694
<lifeless> the code looks correct to me
<lifeless> in 1.16
<KhaZ> lifeless: Well, I'm probably a dolt for doing it, but I version my home directory.  On eof the directories was 'Documents', which MacOS protects.
<KhaZ> For a work around I'll repair it on my Linux box by moving it to a data/Documents directory or some such, I suppose.
<SamB> lifeless: okay, well, I'm using version "1.16.1-1"
<lifeless> SamB: same same
<SamB> it could be a bug in Debian, I guess ...
<lifeless> possibly
<lifeless> I've put a question in the bug tracker
<SamB> is there a way to check that the .pyc and .py match?
<lifeless> no
<lifeless> you can remove the pyc
<lifeless> or move it out of the way
<SamB> I guess I'll sudo that, then
<lifeless> I can't see any obvious leads to pull on
<SamB> ... and reinstall the package
<lifeless> so I'm limited to suggesting things to do to debug
<lifeless> as I don't see it myself
<SamB> is there a way to get a bzr to use cgitb?
<poolie> SamB: in loggerhead or otherwise?
<mwhudson> what the crap, why is "import bisect" in btree_index importing the bisect plugin?
<poolie> i think the answer is no, but it's probably a trivial patch
<poolie> mwhudson: python relative import fail
<SamB> otherwise
<poolie> mwhudson: that's only a guess
<poolie> samb, actually i'd love a patch that would put cgitb-like data into the traceback
<mwhudson> poolie: maybe if you ran it from within /home/naesten/.bazaar/plugins
<poolie> would improve our bug reports
<mwhudson> maybe
<poolie> mwhudson: yeah
<poolie> there's a bug that we should strip . off the path
<SamB> poolie: you just use cgitb.enable(format='text'), don't you?
<mwhudson> SamB: can you run python -vv /usr/bin/bzr rocks and pastebin the result?
<mwhudson> SamB: there will be quite a lot of output
<SamB> mwhudson: figured
<lifeless> mwhudson: oh well spotted
<SamB> I already tried running python -v /usr/bin/bzr ;-)
<lifeless> SamB: is there a bisect directory in /usr/lib/python2.5/site-packages/bzrlib/ ?
<mwhudson> it's a circular import
<SamB> lifeless: nope
<poolie> igc, if/when you're back give me a call?
<lifeless> SamB: is there a ./bisect?
<lifeless> directory that is
<SamB> lifeless: oh, yeah
<SamB> there is
<lifeless> SamB: and is there a __init__.py in the current directory?
<SamB> ... no
<lifeless> ok
<lifeless> so '.' is in your python path
<SamB> lifeless: it often is
<lifeless> its causing the problem
<SamB> maybe bzr should take it out?
<lifeless> I don't think thats a good idea
<lifeless> because its needed sometimes too
<SamB> when?
<lifeless> it would be like setting PATH in an application; bad idea
<SamB> I mean, when bzr doesn't detect that it's running out of it's source tree
<SamB> lifeless: isn't it more like slightly altering LT_LIBRARY_PATH in an application?
<SamB> er.
<SamB> LD_
<SamB> okay, so next time I get wierd errors when trying to branch a new plugin into my plugin directory, I guess I should try doing something in another directory ?
<lifeless> yah. also take . out of your path :)
<lifeless> its a security problem
<lifeless> for vim and other programs too
<SamB> *I* don't have it in my PYTHONPATH
<SamB> % echo $PYTHONPATH
<SamB> /home/naesten/hacking/Twisted:/home/naesten/hacking/Nevow:/home/naesten/lib/python:
<lifeless> it is
<lifeless> '' == .
<SamB> lifeless: eh?
<lifeless> its the last element in your path
<SamB> yeah, I could have sworn python(1) said something different though
<lifeless> >>> "/home/naesten/hacking/Twisted:/home/naesten/hacking/Nevow:/home/naesten/lib/python:".split(':')
<lifeless> ['/home/naesten/hacking/Twisted', '/home/naesten/hacking/Nevow', '/home/naesten/lib/python', '']
<mwhudson> oh heh
<SamB> lifeless: where is it documented that an empty element does that?
<lifeless> I doubt that it is
<lifeless> in the context of PYTHONPATH
<lifeless> however, listdir and other os functions treat anything not starting with '/' as a relative path
<lifeless> and listdir('') == listdir('.')
<SamB> crazy shit
<SamB> maybe bzr should at least warn if you run it like that -- or at least warn about it when it does crash?
<SamB> oh
<SamB> I wrote "PYTHONPATH=~/hacking/Twisted:~/hacking/Nevow:~/lib/python:$PYTHONPATH" in my ~/.zprofile
<SamB> what do I really want ...
<lifeless> if [ -z "$PYTHONPATH" ]; ...
<lifeless> ok, time for iter_changes loving
<SamB> lifeless: thanks for the help even if it was mostly me being stupid ;-)
 * SamB supposes this is why they added something for explicitly relative/absolute imports?
<lifeless> part of it
<lifeless> a bigger reason is that namespacing is horribly broken if you can't say 'start at the root'
<SamB> well, yeah
<spiv> poolie: hey
<spiv> poolie: it's going pretty well, I'm just putting together the network bits.
<poolie> oh ok, great
<SamB> so ... I guess you won't be needing this -vv output?
<poolie> is there already a bug for socket.error giving a traceback?
<lifeless> nope, no need
<mwhudson> SamB: yeah
<poolie> i thought there would be a heavily-duped one but i can't find it
<mwhudson> as in "you're right, no need"
<spiv> poolie: in what context?  I don't know of any outstanding bugs with socket.error tracebacks (although I can believe they exist)
<poolie> like bug 326485
<ubottu> Launchpad bug 326485 in bzr "bzr checkout bzr: ERROR: socket.error: (104, 'Connection reset by peer') " [Undecided,New] https://launchpad.net/bugs/326485
<spiv> I fixed one at UDS.
<poolie> launchpad can't search for "socket.error" which sucks a bit
<poolie> i don't think we treat it as an environment error but we probably should
<SamB> poolie: and google didn't index it yet?
<lifeless> poolie: socket error (just skip the dot)
<spiv> Hmm, that particular example is arguably a bug in our ftp.py
<poolie> lifeless: it gives me bugs containing {socket || error} which is a lot of them
<SamB> spiv: a bug report can show the presence of more than one bug simultaneously, yes ;-)
<spiv> I'd be a bit wary of a catch-all for treating socket.error as normal and not a bug.
<SamB> https://launchpad.net/+search?field.text="socket+error"
<lifeless> poolie: oh uhm.
<SamB> poolie: try that ?
 * SamB almost sent "trie that" ;-)
<SamB> incidentally, the title for that URL is really awful
<SamB> Pages matching ""socket error"" in Launchpad
<spiv> SamB: that's why they're called double quotes!
<SamB> spiv: ... noo, it isn't!
<poolie> SamB: gives an error
<SamB> there ought to be a "bzr sucks" command, which would just raise some sort of error
<SamB> poolie: what the?
<SamB> poolie: are you using edge or something, maybe?
<spiv> SamB: "bzr alias sucks=rocks"
<poolie> spiv, can you think of a good counterexample?
<poolie> case 393713 btw
<SamB> spiv: but bzr rocks doesn't raise an error
<spiv> SamB: true.  You could always alias it to something buggy I guess.
<SamB> spiv: I was thinking it should be there for testing the bug-report thingy
<spiv> poolie: if a socket.error ever escapes the HPSS client code that would be a bug, although not necessarily a serious one.
<spiv> poolie: Also potentially many different internal operations might use sockets, e.g. if you make a commit via bzr:// (or to a lp: URL, which is resolved via XML-RPC), and you also have bzr-email make an SMTP on commit and another plugin that uses TCP somehow to kick off a buildbot, or a plugin to tell LP to update its mirror.
<poolie> spiv, i guess you could say that each transport or other network-using code should catch it
<poolie> and translate it
<poolie> spiv, yeah, i know
<spiv> poolie: so the question is how to report those different situations to the user
<poolie> well
<poolie> i would agree you don't just want a mysterious "connection refused" with nothing more
<spiv> A general "bzr: socket error: connection reset by peer" isn't going to help the user a whole lot.
<poolie> hopefully you can at least say what host it was
<spiv> Right.
<poolie> right
<poolie> otoh a traceback's not much better
<spiv> Agreed.
<spiv> The main issue is to give a good error.  I'm not sure that socket.error can give you enough details to report a host name or the particular operation that failed.
<poolie> i think in general that's going to rely on transport-level or similar code decorating it
<poolie> if it comes from eg a write() call, python's probably not smart enough to remember the host name
<poolie> associated with that fd
<spiv> So I think we need to be catching it at the point it happens and turning it into something more useful for the user, e.g. "FTP connection closed during PASV".
 * mwhudson just merged pyflakes trunk into lp:~mwhudson/pyflakes/support-lazy-imports, if anyone is interested
<spiv> Yeah, I think for socket-using transports the transport code needs to decorate it.  Similarly for plugins etc that use SMTP or XML-RPC.
<spiv> mwhudson: ooh, ta
<mwhudson> (actual conflicts this time!)
<spiv> It's a bit hard to know exactly which information is most relevant to tell the user when an error happens.
<spiv> But the type of socket error (connection reset or whatever), hostname/port, and some sort of high-level description of what bzr was attempting to do (e.g. "retrieve file from $URL") is probably achievable and good enough.
<spiv> poolie: I can add this opinion to #393713 if you like
<poolie> yeah
<poolie> just paste the irc log
<spiv> Ok.
<fullermd> So, am I just special, or is the wiki really broken for everyone else since the openid change?
<bialix> wfm
<fullermd> Well, it's nice to be special I guess...
<GungaJin> I just merged from trunk to a branch.. and I need to rebase to a previous revision of trunk in the branch.. how can I do this?
<spiv> GungaJin: there's a bzr-rebase plugin, but why do you "need to rebase"?  Rebasing is generally a means to an end, not an end in itself.
<GungaJin> because I merge from trunk a revision that doesn't compile... so I need to reverse that or to rebase.
<poolie> fullermd: wfm too, can you be more specific?
<thumper> uncommit?
<GungaJin> but I committed already.
<dash> GungaJin: that's what 'bzr uncommit' is for.
<poolie> spiv, do you want a catchup call?
<poolie> well, i do anyhow :)
<fullermd> poolie: Well, I can't set anything in my UserPreferences, since it just keeps repeating "This email already belongs to somebody else."
<fullermd> The time zone is wrong too, but it's grayed out so I can't even attempt changing it anyway.
<lifeless> fullermd: please open a question at https://launchpad.net/launchpad
<lifeless> fullermd: that will get sysadmin attention
<lifeless> fullermd: an/or try removing your moin cookie and logging in fresh
<poolie> fullermd: your tz is supposed to come in openid from launchpad
<fullermd> Yes, but it comes in as -0600.  That's wrong; I'm on DST so it's -0500 now.
<fullermd> lifeless: Does it really have anything to do with LP?  I thought LP just provided the initial auth; all the Prefs in the wiki should just be moin-internal, no?
<lifeless> fullermd: 'that will get sysadmin attention'
<lifeless> fullermd: but try the cookie thing first
<fullermd> Already did, no change.
<GungaJin> what a mess...
<lifeless> then its possibly/presumably a side effect of the moin openid plugin
<lifeless> GungaJin: what do you mean?
<GungaJin> I mean something is messed up in my project..
<poolie> fullermd: it's using a moin plugin to take at least some settings, including tz, from the openid thingum
<fullermd> So saving prefs actually works for everyone else?  :(
<lifeless> haven't tried
<spiv> poolie: sure, call me in 5?
<vila> hi all
<vila> fullermd: Didn't your mother tell you about going to bed early ? Now you find even wikis can't understand your tz ? And you wonder ?
<spm> hey vila
<vila> hi spm !
<spm> vila: I must say it's good to be back in a ... more reasonable TZ ;-)
<vila> :-D
<fullermd> vila: She might've, I dunno.  I was sleeping late that day   :p
<spiv> poolie: was that you calling?  All I got was a bit of crackling then silence.
<vila> spiv: ghosts do that these days, but poolie...
<thekorn> hi, I accidentially removed a file at revno 10, I'm now at revno 20, how can I get this removed file back
<thekorn> with all its history
<spiv> thekorn: "bzr revert -r9 path/of/file"
<thekorn> spiv: ah, ok, thanks, and than bzr commit path/to/file and revert the other changes?
<thekorn> that's easy
<thekorn> oh, nevermind
<thekorn> ignore my last lines
<thekorn> thanks again
<spiv> thekorn: you're welcome :)
<lifeless> thekorn: yes, you do need to commit the revert
<thekorn> lifeless: right, that's what I did, I was a bit confused because I did not know it is possible to revert only a certain file
 * igc dinner
<jml> bzr alias upll="pull"
<Peng_> More important is aliasing zbr to bzr. :D
<Peng_> And /em to /me...
<poolie> hello vila, Peng
<Peng_> Good morning. :)
<vila> hi poolie
<vila> poolie: we both fixed the yY/nN FIXME in get_boolean but I wonder if mine isn't too broad...
<vila> I added the ability to use y/n Yes/No On/Off 1/0 for booleans in config files, but allowing the latter for get_boolean (which add y/n to the prompt) may not be such a good idea in retrospect... thoughts ?
<poolie> vila, both fixed in the sense of both merged or just both had patches?
<poolie> i just wanted to merge the patch attached to that bug
<vila> poolie: you merged, I didn't submit my patch yet
<Peng_> Is it just me, or did a blog post called "Scalability benchmarking: packs vs 2a on OpenOffice.org" semi-appear on the planet?
<poolie> Peng_: why 'semi'
<poolie> vila, good stuff on the strict push etc
<vila> poolie: I need to talk with jam about his concern, I don't quite understand :-/
<vila> poolie: there is another patch waiting for a review about send --strict :-}
<vila> I'm waiting for both of them to land before submitting the boolean stuff and the tree.has_changes() asked during review of the first attempt to fix push --strict
<vila> poolie: by the way, I've switched to using mixins in the tests, you were right, that's clearer :-)
<Peng_> poolie: It appeared in the feed, but without an URL. It's not displayed on the website.
<Peng_> poolie: Never mind, now it's there.
<Peng_> Still doesn't have an URL, though.
<Peng_> igc: ping
<visik7> a developer A has a local branch
<visik7> how can I get it ?
 * vila lunch
<igc> hi Peng_
<Peng_> igc: http://planet.bazaar-vcs.org/ lists a blog post by you, "Scalability benchmarking: packs vs 2a on OpenOffice.org", but there's no link to the rest of the post.
<Peng_> Oh, I just found a link to igc's blog post on the mailing list. I had checked that blog once, but only before the post appeared.
<lifeless> \o/ http://bazaar.launchpad.net/~domas-mituzas/%2Bjunk/uncache/annotate/head%3A/uncache.c for testing cold cache
<jam> lifeless: so that lets you test cold cache without destroying everything?
<jam> nice
<jam> though figuring out what exactly needs to be uncached is probably a little tricky
<Peng_> uncache looks slightly scary.
<bialix> jam: good day
<bialix> jam: I have question about TBZR version you're using to bundle into installer
<bialix> jam: are you using tbzr trunk?
<jam> bialix: since AFAIK tbzr has never had a release, yes
<jam> though I think I need to manually update it
<jam> bialix: I was just sending a response to your bug comment
<bialix> I've read your build_release.py script
<jam> and building a 1.16.1-2 release
<jam> with the latest python pyqt and tbzr
<jam> I'm copying it now
<bialix> ok, thanks
<garyvdm> Hi bialix
<bialix> Hi Gary!
<vila> hi Gar, hi Alexander :-D
<garyvdm> I'm busy updating the qbzr version in karmic :-)
<bialix> Bonjour!
<vila> hi Gary, hi Alexander  (where did that y get lost ???)
<garyvdm> hi Vincent
<bialix> garyvdm: about your logslot branch: what I should to look there?
<garyvdm> I think just give it a test - Make sure there are no regressions that I have missed
<bialix> ok, will do in next few days.
<bialix> there is too hot these days, my brains are melting.
<garyvdm> bialix: I'm asking for reviews just to try avoid regressions. - Maybe what I should do with large changes like this is push it to launchpad, run it locally. and give it a week before I merge it, so that I put it through it paces before I submit it on you guys.
<garyvdm> push it to a branch on launch pad...
<vila> garyvdm: the silver bullet against regressions is.... :-D
<garyvdm> tests
<garyvdm> :-)
<LarstiQ> jml: /win 22
<LarstiQ> jml: woops, sorry :)
<bialix> vila: heh, it's not silver :-P
<vila> bialix: why ? (May be I miss a joke there...)
<bialix> when someone run tests on one platform then other platfrom can regressed, you know
<bialix> it's not joke, it's a sad
<vila> ha ! That's because we don't do *engouh* tests !
<vila> bialix: I'm setting up a build farm as a background task, windows will find its way, one day, I promise
<fullermd> Well, there ARE only so many bits out there, so the domain IS finite.  So it's theoretically possible to do exhaustive testing...
<fullermd> It would take a rather long time, though.
<vila> bialix: and fullermd just voluntereed for a *BSD slave :)
 * fullermd emancipates all his machines.
<vila> fullermd: joke aside, I also want to add a BSD slave and I never installed one, so your advice will be appreciated
<awilkins_> fullermd: I don't hink it's possible - because to do exhaustive testing you need more state than the astate you are testing. But then you need more state than that to test the testing. So exhaustive testing is infinite.
<vila> awilkins_: pfff, only for small values of infinites, we're talking about TRUE infinite here
 * fullermd . o O ( `bzr selftest --aleph-one` )
 * vila . o O (`bzr selftest --parallel=morris-worm`)
<jelmer> vila: :-))
<jelmer> vila: botnets are the new cloud
<jml> LarstiQ, np
<vila> jelmer: hehe, botnets *are* the true power of the net, it always scares me to compare the raw power of the internet periphery and the raw power of the internet backbone...
<vila> ...especially when the power of the former are used to attack the later.
<Pilky> hey all, I'm currently looking into building an Obj-C API for bzr. Am I right in thinking that bzrlib.builtins is the best place to look at how bzrlib is used from the command line UI?
<Pilky> basically I'm wanting to look at it from the view of "I can do bzr add from the command line, what does bzr call in bzrlib to do that" so I can use that for the basis of the Obj-C API
<jelmer> Pilky, yeah, bzrlib.builtins seems like the best place for that
<Pilky> cool, thanks
<beuno> jelmer, hi
<beuno> I'm trying to release loggerhead again
<jelmer> beuno, Hey
<beuno> and one of the blockers is daemonizing serve-branches
<beuno> jelmer, could you point to your preferred implementation in bug 393619?
<ubottu> Launchpad bug 393619 in loggerhead "serve-branches should be daemonizable and replace start-loggerhead in setup" [Medium,Triaged] https://launchpad.net/bugs/393619
<jam> abentley: I think bundlebuggy is down again
<abentley> jam: restarted
<jam> thanks
<vila> jelmer: bzr-gtk users are dying for a new release ! :)
<jelmer> vila, yeah, I know :-/ I'll see if I can do another release at some point.
<jelmer> vila, It should really only matter for people who use the tarball though, and they can also use the bzr branch
<vila> jelmer: that would be very appreciated
<vila> jelmer: well, I'm pretty sure some distros will use only released versions...
<Junqiang> hi all
<Junqiang> anyone knows how to use new eol filter feature in bzr? I have serious trouble with it.
<kfogel> what command what I run to find out if a file is under version control, in a bzr working tree?
<kfogel> 'bzr status -v FILE' ?
<kfogel> I guess so: silence means it's versioned, "unknown:" means it's not.
<visik7> I have 2 branch of the same code
<visik7> one at revision 1
<visik7> the other at rev 2
<LarstiQ> kfogel: I'd go with `bzr ls -V` I think
<visik7> from rev 2 I run bzr send
<LarstiQ> kfogel: but status would be my other approach
<visik7> and from rev 1 I run bzr merge file.patch
<visik7> but I got this error:
<visik7> NoSuchRevision: KnitPackRepository('file:///Users/visi/Documents/Flex%20Builder%203/fotografie/.bzr/repository/') has no revision ('biagio@mattonella-20090630164723-2uiorutm7tj3srtq',)
<kfogel> LarstiQ: thanks
<Junqiang> Who have ever used the EOL filter feature?
<LarstiQ> visik7: is the rev1 the submit branch for the rev2 one, and how did you run bzr send?
<jelmer> Junqiang, igc developed it, but he's in .au so probably asleep atm.
<LarstiQ> Junqiang: I haven't, but what are you having problems with?
<visik7> the first question : I dunno, the second question: in which sense  how I run it?
 * SamB wonders *why* git doesn't list directories in the index
<kfogel> SamB: does git really version directories?
<jelmer> kfogel: it only supports "implicit" directories, much like CVS I think
<SamB> kfogel: it could, if it did
<LarstiQ> Junqiang: don't message people in private unasked, it is rude and will not get you help from other people
 * LarstiQ personally is at europython and a talk just started
<mneptok> isn't "Europython" a porn film?
 * mneptok shrugs
<spetrunia> Hi! Anybody could help with this problem: my bazaar doesn't send commit notification emails. "bzr gcommit" says nothing but returns non-zero status
<spetrunia> the commit iself is made, can see it in bzr log
<SamB> jelmer: you have a really wierd way of numbering bzr-svn versions, you know that?
<jelmer> SamB, what's strange about it?
<SamB> well, I see 0.6 above 2.0 on this tree view ...
<spetrunia> Here are .bzr.log and config: http://pastie.org/529613 ... overall the system is a very regular ubuntu 9.4
<jelmer> SamB: That's a Launchpad bug
<SamB> jelmer: oh ;-)
<Tak> yay fetch-ghosts!
<LarstiQ> hmm, Junqiang left. I messed that one up.
<LarstiQ> mneptok: isn't everything?
 * LarstiQ moves to the CouchDB talk
<kfogel> spetrunia: I'm no expert, but I'll take a look
<kfogel> spetrunia: :-(  I lack the knowledge to help.  Sorry!
<spetrunia> kfogel: thanks for the attempt anyway :-)
<kfogel> spetrunia: it was pretty futile -- I realized looking at your setup that you probably are more bzr expert than I am :-).
<jelmer> spetrunia, does "bzr commit" work ok?
<spetrunia> let me try...
<spetrunia> jelmer: It has returned zero status, but still haven't tried to send the message... here's .bzr.log: http://pastie.org/529669
<spetrunia> I wonder which part of bazaar sends emails? Is it its integral part or a plugin (property of your install), or a script (property of the branch), or both, or?
<jelmer> spetrunia, do you have post_commit_to set? do you have bzr-email installed?
 * spetrunia looking
<spetrunia> jelmer: the tree has .bzr-mysql/ directory (next to .bzr) which has default.conf  which sets post_commit_to = maria-developers@lists.launchpad.net
<spetrunia> bzr-email... not sure.. "bzr plugins" shows bzrtools 1.13 , dbus , gtk, launchpad, netrc_credential_store
 * spetrunia tries to figure out if 'bzr commit' will even read .bzr-mysql/default.conf
<spetrunia> hmm it does but it's not clear whether that is a read of config file or part of commit action...
 * spetrunia googles for bzr-email
<spetrunia> Hooray! after installing  bzr-email plugin, and seeing post_commit_to globally, it worked
<spetrunia> jelmer: thanks!
<jrwren> is there any smart server via fcgi info newer than http://doc.bazaar-vcs.org/bzr-0.15/http_smart_server.htm ?
<jrwren> what purpose does the pipe server in the regex?   RewriteRule ^(.*/|)\.bzr/smart$ /srv/example.com/scripts/bzr-smart.fcgi
<jrwren> isn't that equivalent to .*/? ?
<luks> .*/? would mean "something and optionaly /"
<luks> I guess you could rewrite (.*/|) as (.*/)?
<jrwren> .* isn't something though, it oculd be empty, so aren't they call equiv?
<luks> it could also not be empty
<luks> you don't want to accept "foo" as an input
<luks> only "foo/" or "/"
<luks> sorry
<luks> only "foo/" or ""
<jrwren> ah, ok.
<jrwren> thank you.
<Haris1> Hi, I need to do some web dev work and have been given access to a bzr installation. Being new to bzr I'm not sure whether I need to bzr checkout or bzr branch?
<Haris1> I want to work on a local xampp installation and then when done developing upload back to the love server (original bzr installation)
<LarstiQ> Haris1: either will work
<LarstiQ> Haris1: ah, for that branch is better
<LarstiQ> Haris1: since with a checkout every commit will go directly to the place you checked out from
<Haris1> Hi LarstiQ, ok thanks, i was concerned that when i did a bzr commit it would send things back to the main server against my will
<Haris1> aha that makes sense
<LarstiQ> Haris1: `bzr branch` will get you a fully decentralized standalone branch to work with
<Haris1> When I'm done developing locally, is it possible to send the local commit history and commit messages back to the main working folder (live server)?
<LarstiQ> Haris1: commit is just local, push/send  get it upstream
<LarstiQ> Haris1: yes
<Haris1> Great! is push and send the same command?
<jrwren> i'm having a bit of trouble with a wsgi smart server.   bzr ls bzr+https://myserver/rootofbzr works, but drilling down into a dir like https://myserver/rootofbzr/dir does not.
<jrwren> it says bzr: ERROR: Server sent an unexpected error: ('error', "An attempt to access a url outside the server jail was made: 'chroot-62309520:///'.")
<LarstiQ> Haris1: no, two different ones, you probably want push (send is for when you don't have write access/want to mail the history/review etc)
<LarstiQ> jrwren: that sounds like it doesn't like access above 'rootofbzr'?
<Haris1> That's great it all makes sense now, thanks again LarstiQ, I'm off to put it into practice! :)
<LarstiQ> Haris1: ok :)
<jrwren> it should, but there is no "above" in the repo of rootofbzr, and in the apache config, the "above" is just the exposed bzr files.  I don't need a local checkout do i? because this is a repo with no trees.
<LarstiQ> Haris1: the user guide should also help answer some of these questions
<LarstiQ> jrwren: no, just the .bzr control dir
<Haris1> I have been looking at it but I got a bit lost in the detail, will give it another look now that you've given mecontext
<jrwren> if I have two .bzr dirs, that means 2 different branches or repos, right?
 * LarstiQ nods at Haris1 
<LarstiQ> jrwren: .bzr/ can contain any of /repository/, /branch/ or /checkout/
<jrwren> I always found this particular repo rather strange.  I have c:/repo/.bzr and c:/repo/effectivelytrunk/.bzr and I thought I had all one repo, but now I'm thinking I actually have 2 repos
<LarstiQ> jrwren: if you have a shared repository, you will have one for the repository and one for each branch
<jrwren> ah, so that is what I have, a shared repo and each branch.
<LarstiQ> jrwren: what does `bzr info` think of them?
<LarstiQ> jrwren: sounds likely
<jrwren> I was hoping to expose the whole repo, and all branches via bzr-smart.wsgi - but maybe I can only smart share a branch?
<LarstiQ> jrwren: I haven't heard of bzr-smart.wsgi before, but I'd expect you to be able to expose the whole repo
<jrwren> LarstiQ: indeed, my effectivelytrunk says it is a repository branch: effectivelytrunk
<LarstiQ> jrwren: in particular, the branch control dirs don't contain the revision data, so if you don't expose the repository .bzr there is no way anyone can use the branches
<jrwren> but it says Location: shared repository: .
<jrwren> the repo is actually at .. relative to effectivelytrunk
<LarstiQ> jrwren: if you run it from ..?
<jrwren> yes
<LarstiQ> jrwren: right, that makes
<LarstiQ> sense
<LarstiQ> jrwren: try to cd to effectiveltrunk and run `bzr info .`
<jrwren> ok, so that was relative to my curdir, not relative to the subdir.
 * LarstiQ nods
<jrwren> LarstiQ: yup, just did that, and it makes sense.
<LarstiQ> jrwren: so, when you access a branch, it walks up the directory structure to find it's repository
<jrwren> ok, so this repo looks good.  Now I just need to figure out how to use bzr-smart.cgi (the wsgi is just a port of the cgi) with a repo
<lifeless> moin
<lifeless> jam: yes
<lifeless> jam: cd repo; uncache; test
<jam> morning lifeless
<lifeless> I haven't tested it yet; but its from a drizzly/mysqly person so I imagine they have used it on Ubuntu :)
<lifeless> hi jam
<jam> lifeless: well, I suppose it depends if you want to flush the source files
<lifeless> hmm, I wonder if it actually drops dentries as well or only content
<jam> if you are just testing repo perf, then that looks quite good
<lifeless> if (node->fts_info != FTS_F) continue;
<lifeless> skips dirs I think
<lifeless> but its probably tunable
<lifeless> would need to use a stack
<lennymaiorani> hello all. I have just upgraded to bzr 1.16.1 and I am seeing unusually high CPU load. Is this a known issue? Is there some way I can fix this?
<mwhudson> lennymaiorani: on the server or the client side?
<mwhudson> and doing what sort of operation?
<mwhudson> (basically, i haven't heard of anything like this)
<lennymaiorani> mwhudson: I have only looked at the client. I can take a peek at the server as well. I am doing a checkout, but also noticed it doing commits.
<mwhudson> hmm
<mwhudson> lennymaiorani: what did you upgrade to 1.16.1 from?
<lennymaiorani> mwhudson: 1.15+x. I am not sure exactly which 1.15 I was on. It was something from the devel PPA
<mwhudson> ok
<mwhudson> that's pretty strange
<mwhudson> commit was supposed to be faster in this release :)
<mwhudson> i think
<mwhudson> lennymaiorani: what format are you committing to?
<lennymaiorani> mwhudson: server looks normal. very low load while i am doing a checkout
<lennymaiorani> mwhudson: the server has a rich-root-pack repo
<mwhudson> strange
<lifeless> what bzr version is the server?
<lennymaiorani> 1.17dev
<lennymaiorani> oops. i thought it was 1.16.1
<lennymaiorani> actually, my client is also. maybe i should go back to 1.16.1. my fault.
<lennymaiorani> looks like i am on the nightly PPA. i meant to be on the beta PPA.
<mwhudson> well if 1.17dev is acting up and 1.16.1 is not, that's interesting :)
<lennymaiorani> mwhudson: I am downgrading to bzr 1.16.1 right now
<lennymaiorani> mwhudson: I am seeing the same behavior from 1.16.1
<mwhudson> lennymaiorani: so the problem is committing to a rich-root-pack ... lightweight checkout?
<lennymaiorani> mwhudson: it is a rich-root-pack repo and a shared rich-root-pack repo full checkout
<mwhudson> m
<mwhudson> hm
<mwhudson> i have one of them too
<mwhudson> and it seems ok
<mwhudson> (well it's 1.9-rich-root, but that shouldn't really matter)
<mwhudson> lennymaiorani: how big is the branch?
<lennymaiorani> mwhudson: 107 MB
<mwhudson> mm
<mwhudson> all i can suggest is collecting as much data as you can (like, how much slower is it that it was) and filing a bug
<lennymaiorani> mwhudson: gotta run. i will try to get that done tomorrow. thanks for the input.
<mwhudson> no worries
#bzr 2009-07-01
<poolie> hello all
<poolie> lifeless: hi, i was thinking about having a stab at either bug 385826 or bug 393677 today...
<ubottu> Launchpad bug 385826 in bzr "push and pull with different formats extremely slow on network" [Critical,Triaged] https://launchpad.net/bugs/385826
<ubottu> Launchpad bug 393677 in bzr "pushing a 1.9 branch stacked on a 2a branch causes problems" [High,Confirmed] https://launchpad.net/bugs/393677
<lifeless> 38826 is what spiv is working on
<lifeless> 393677 doesn't conflict with anyone
<lifeless> so I'd suggest 393677
<poolie> hm i meant the one with InterDifferingSerializer
<poolie> but at any rate it's related to what he's doing
<poolie> i was hoping it would be complementary
<poolie> i wonder if he sent his patch...
<lifeless> poolie: so there are three things that need to lang all roughly at the same time
<lifeless> 1) streaming inv deltas
<lifeless> 2) fixup the streaming rich root conversion
<lifeless> 3) disable IDS for non-local operations
<lifeless> my hunch is that its better to have one person do all three, as I expect test interactions
<spiv> poolie: still working on that patch... currently fixing differences in behaviour between the streaming path and InterDifferingSerializer that the tests found.
<lifeless> spiv: the rich root conversion path?
<spiv> lifeless: right
<lifeless> great
<spiv> Which I guess is your 2) from above.
<lifeless> yes
<lifeless> there are three separate bugs for 1,2 and 3
<spiv> I'm basically taking the logic from IDS and transplanting it.
<lifeless> you'll probably want to close them all  :)
<spiv> Sure, the more bugs closed the merrier :)
<spiv> FWIW, I have the bulk of 1) done, although I haven't finished exhaustively testing or polishing because of 2).
<lifeless> the reason for 2 is that without 3, which needed 1, I'd have had to write awkward tests for 2 rather than the simpler generic tests
<lifeless> and as it wasn't being used that seemed counterproductive
<GungaJin> hHi
<GungaJin> I upgraded to 1.16 on Windows and I keep getting now "bzr: ERROR: Unable to look up default port for ssh".
<GungaJin> Any ideas why?
<spiv> GungaJin: Someone else had that error the other day, but I don't recall the cause :/
<spiv> Which version did you upgrade from?
<GungaJin> 1.14
<spiv> Hmm, I wouldn't expect there to be any changes since 1.14 that would cause that.
<GungaJin> But that's what I'm getting on Windows
<spiv> I wonder if something odd changed in the build process for the Windows installer since 1.14?
<spiv> It sounds like a system misconfiguration issue, but I don't know why 1.16 would expose it if 1.14 didn't.
<spiv> GungaJin: can you run the command with -Derror added to the commandline, and pastebin the traceback?
<GungaJin> sure
<spiv> Hmm.  That error string isn't part of bzrlib, so maybe it's one of the bundled plugins that's causing it...
<GungaJin> http://pastebin.com/m6d892fee
<spiv> Ah-hah, and I was right.
<spiv> It seems to be due to the bzr-svn plugin.
<lifeless> please file a bug on bzr-svn
<spiv> Probably you can work around it by using --no-plugins or explicitly giving the port number in your URLs (i.e. bzr+ssh://hostname:22/...)
<spiv> But please do file a bug.
<GungaJin> How can you tell it's in bzr-svn?
<spiv> I *think* this bug is already fixed in bzr-svn trunk, looking at the code.
<GungaJin> I think so too.. I just found a similar post in launchpad.
<spiv> (it now mutters that message to the log and returns cleanly, rather than raising an error)
<GungaJin> https://answers.launchpad.net/bzr/+question/73528
<spiv> GungaJin: I can tell because the last part of the traceback is in plugins\svn\auth.py
<GungaJin> i c
<GungaJin> (sorry.. I don't really know python..)
<spiv> Sure, that's ok.
<spiv> That's what we're here for :)
<poolie> igc, you should blog about the bzr-explorer release with pretty pictures
<igc> poolie: shall do
<zsquareplusc> is there a recommended way to convert from svn to bzr?  i used just "branch" (with bzr-svn installed) and it seems to do the expected (creating a native bzr branch)
<SamB> jelmer: with what should I replace "svnversion" in a Makefile in order to get something sensible from a bzr-svn working copy?
<RAOF> zsquareplusc: Yeah, that's about it.
<RAOF> SamB: GNOME Do uses 'bzr version-info --custom --template="bzr {branch_nick} r{revno}"'
<zsquareplusc> fine
<zsquareplusc> and is there a history editing tool. i.e i have an private branch that i'd like to clean up before publishing
<dash> zsquareplusc: 'uncommit' is about all there is
<RAOF> zsquareplusc: Not really.  You _can_ effectivly re-structure history by judicious merging, though.
<SamB> RAOF: I meant, a way to extract just the nearest ancestral SVN revision number
<SamB> with maybe some indication of how far away it was
<dash> zsquareplusc: in general, there's not much reason to clean up history in a branch
<poolie> igc, it does look like links to the group blog posts are broken on planet bazaar
<dash> since it doesn't show up in the normal log of mainline
<poolie> the feed looks ok to me so i'll file an rt I guess
<SamB> poolie: but clicking on things from the feed, does that work?
<poolie> yep
<RAOF> zsquareplusc: If you've got a branch with lots of experimental commits, and you'd like to tie them into feature-commits, you can bzr merge -rA..B ../experimental branch, possibly fix stuff, then commit.  Follow with bzr merge -rB..C ../experimental, rince and repeat.
<poolie> how about for you? http://bazaarvcs.wordpress.com/feed/
<GungaJin> How do I uninstall the svn plugin?
<zsquareplusc> dash: because i ran that project privately it may contain comments not intended for others eyes. or think of passwords in old changsets
<zsquareplusc> RAOF: ah ok. so i could create a new history with a few important points relatively easy.
<RAOF> zsquareplusc: I don't _think_ there's much support for that yet, although it's an acknowledged need.  Someone more knowledgable might have a better idea.  IIRC I've seen lifeless talk about this before?
<dash> zsquareplusc: what RAOF described doesn't erase history
<zsquareplusc> the alternative is i just import the head w/o any history. but that is kind of sad for all the time i took to write the commit comments :-)
<RAOF> Yeah.  What I sugested merely clusters history into potentialy more useful groups.
<lifeless> GungaJin: if you've used the executable installer you can't
<lifeless> GungaJin: because its bundled in the same exe
<poolie> filing an rt for the feed links...
<lifeless> GungaJin: I think we'll need to fix the 1.16.1 installer with a new bzr-svn
<zsquareplusc> i could start with an empty branch and go through the revisions of the original, copying the files to my branch for each step. would some work. :/
<dash> zsquareplusc: _do_ you have passwords in your revision history?
<GungaJin> lifeless - probably, but I don't feel like writing --no-plugins all the time... and I don't use this plugin anyway.
<dash> there is a plugin named 'bzr-rebase', it might be of help
<zsquareplusc> dash: probably not :-)  but it is a history over a few years, who knows what i did back then ;-)
<zsquareplusc> an other issue i have is with bzr-gtk. everytime i start one of its commands like bzr vis i get a traceback (DBusException) on the 1st run. the 2nd time it is working.
<zsquareplusc> mm. with 1.13.1 (jaunty)
<spiv> GungaJin: I think there may be another way around it
<GungaJin> I'll be glad to hear it.
<spiv> GungaJin: you might be able to avoid that error by adding an entry for ssh to your windows\system32\drivers\etc\services directory
<spiv> s/directory/file//
<GungaJin> ?
<spiv> GungaJin: I haven't used Windows in a pretty long time, so I might be wrong, but I think that file is used to lookup port numbers when a program calls the getservbyname winsock function.
<spiv> GungaJin: you can probably just add a line like "ssh 22/tcp" to that file to avoid that bzr-svn bug
<GungaJin> hmmmm... could be.
<GungaJin> but I'm just using the default port...
<SamB> spiv: why does guessing that have anything to do with using windows?
<spiv> (that bzr-svn bug is triggered when getservbyname fails to look up a port for a scheme like 'ssh')
<SamB> oh, because you can't remember if there is a file like that?
<spiv> SamB: I'm pretty sure there used to be a file like that in roughly that location in older versions of Windows.
<spiv> SamB: I could be wrong about the details, current Windows might do something completely different, etc :)
<SamB> well, if there is already a file there, you can be pretty sure that it's for that
<spiv> I think I'm mostly right, or wouldn't be wasting GungaJin's time, but I figure I should be clear when I'm not totally sure about my advice :)
<SamB> a quick google indicates that they're apparantly still there in vista
<kingos> lifeless: sorry to bug you, but any plans of what to do about my bzr check failing bug?
<kingos> lifeless: I have a lot of users that would like some faster performance, and we can't upgrade because check fails
<kingos> maybe there is someone else who could help?
<poolie> kingos: what's the bug number?
<kingos> bug 356028
<ubottu> Launchpad bug 356028 in bzr "bzr check fails with KeyError" [Undecided,New] https://launchpad.net/bugs/356028
<lifeless> kingos: hi. I'll look into it this afternoon.
<kingos> lifeless: thanks
<emet> jhello
<emet> 2 collaborators, no server
<emet> how do I set up something like this
<zsquareplusc> no server at all, or could you run a ssh/sftp server?
<poolie> emet, if you have email you can just use bzr send
<poolie> then merge or pulll from the bundles
<davidstrauss> zsquareplusc: please explain your question a little more
<zsquareplusc> davidstrauss: that was directed to emet.  i like that you can push and pull a bzr branch to a server with just an ssh account there. so no special SW on server
<emet> okay bzr send might be a solution, SSH seems like a more secure solution
<SamB> emet: bzr send is plenty secure if you review the diffs
<poolie> well, send is as secure as your email setup
<poolie> send with gpg and smtp tls and it's about as secure as ssh imo
<spiv> Grr, pycurl test hangs are annoying.  At least you can strace to find out the fd it is polling then use gdb to close the fd to unhang it (and fail the test).
<lifeless> popping out for a walk; going to think about how best to fit in the iterchanges changes for dirstate
<spiv> Still, everything other test is passing, so that's good.
<spiv> Now to fix the duplicated code...
 * igc lunch
<poolie> spiv, can you push it before you go out?
<lifeless> I wish pyrex could be run straight from python
<lifeless> it would be awesome
<Peng_> Like what, import a .pyx and it would be automagically sorted out?
<Peng_> Doesn't Cython have a feature like that?
<Peng_> lifeless: http://docs.cython.org/docs/tutorial.html#pyximport-cython-compilation-the-easy-way
<lifeless> Peng_: no, I mean run in emulation
<lifeless> Peng_: to allow debugging with pdb etc while fixing shit
<lifeless> then set it free with C after that
<Peng_> Oooooh.
<lifeless> Peng_: do you do stuff with GnomeDo?
<Peng_> lifeless: Never heard of it.
<lifeless> I saw a reference to Peng in the release blog post for it yesterday
<lifeless> was wonding if Peng == Peng_
<Peng_> I really should've gone with a more unique handle...
<lifeless> Peng__?
<Peng_> lifeless: Too many other people use Peng.
<lifeless> Uin?
<Peng_> Yeah. :\
<lifeless> (pronounced 'win')
 * Peng_ is terrible at coming up with names.
<lifeless> I'm suggesting it for a name for you
<Peng_> God forbid I ever have children... :D
<Peng_> Oh.
<Peng_> Not taken. Does Freenode allow 3-lettern icks?
<Peng_> err, s/n / n/
<poolie> try it... :)
<lifeless> I suggested Peng__ too, but you seemed to miss the joke :)
<Peng_> lifeless: Oh. Yes, I did.
<Peng_> Someone on one network is annoyed by the single _. Two would probably kill him. :D
<poolie> "joke" :)
<lifeless> \o/ dirstate pyx passing the first test
<lifeless> its polish from here on it
<lifeless> *in*
<poolie> that's good
<lifeless> still got some careful thinking to do
<poolie> but also surprising to me
<lifeless> about ways we could still generate bad inv deltas
<lifeless> poolie: whats surprising?
<lifeless> python passes; CHKInv next
<vila> hi all
<poolie> hello vila!
<poolie> vila, lifeless, any thoughts on my recent comments at the bottom of bug 340347?
<ubottu> Launchpad bug 340347 in bzr "log+ transport apparently breaks readv iterator" [High,In progress] https://launchpad.net/bugs/340347
<lifeless> poolie: listifying is permitted by the contract
<lifeless> poolie: in particular, the http transports all buffer a full copy AIUI (because of the underlying behaviour)
<poolie> hm
<poolie> i doubt access to packs over http would work in that case
<poolie> and it does seem to
<vila> lifeless: meeep, only pycurl does that
<poolie> if it doesn't turn them back into a generator it will probably give a similar failure
<poolie> it might...
 * vila checking
<lifeless> poolie: so what failure do you get? MemoryError?
<poolie> lifeless: http does buffer a lot of stuff potentially but does eventually yield it out of readv, as a generator
<poolie> bzr: ERROR: exceptions.AttributeError: 'list' object has no attribute 'next'
<lifeless> oh
<poolie> typical failure for something that wanted a generator and got a list of course
<lifeless> the iterator probably wants to return iter() of what its returning at the moment
<lifeless> s/iterator/generator/
<vila> poolie, lifeless : confirmed, pycurl buffers as much as 4M, while urllib-based goes to great lengths to *not* buffer at all
<lifeless> -or- the calling code should iter() what it gets
<lifeless> vila: hyopthetical
<vila> lifeless: ??
<poolie> lifeless: itym s/iterator/decorator/?
<lifeless> vila: what happens if you ask for 10000000-10000999, 15-20, and the server gives a 200
<poolie> as i say, i'm actually wondering if we should do both of those
<lifeless> poolie: yes, yes, I do
<lifeless> poolie: and I think both would be sensible
<vila> lifeless: as in 'squid is involved' ? :-P Seriously, pycurl will certainly raise MemoryError, urllib should just seek() the unwanted bits (I don remember exactly if we allow unsorted ranges)
<lifeless> vila: any server is allowed to do this
<vila> lifeless: I know, but some proxies abuse it (still joking ;-)
<lifeless> vila: squid doesn't do this in fact; it generates ranges from its local cache
<lifeless> vila: if we _permitted_ it to cache it would do better
<vila> lifeless: hmm, I didn't thought about that... From https://bugs.edge.launchpad.net/bzr/+bug/120697/comments/7 , my conclusions at that point was that we don't want squid to download a whole xxGB pack files for answering requests that will at most represent yyyMB, am I wrong ?
<ubottu> Ubuntu bug 120697 in bzr "bzr shouldn't bypass http caches" [Unknown,Fix released]
<davidstrauss> Is it time to talk about Squid in this channel, too? :-)
<lifeless> vila: we don't, but on the other hand if we're going to read all the pack file eventually anyway, cache hits would be good
<vila> lifeless: ok
<vila> poolie: I implemented readv as http://paste.ubuntu.com/207353/ in my transportstats plugin, AFAIK the tests are still passing
<vila> poolie: i.e. just do for item in whatever-the-decorated-returns: yield item
<poolie> yeah
<poolie> log+ folds the whole thing into a list
<poolie> this may be inferior
<poolie> in several ways, but it does mean we can print the whole size
<vila> yup, that's a problem transportstats has to address at a different level (and theres is still that big FIXME)
<poolie> let's merge it sometime...
<poolie> at least the feature if not the code
<poolie> getting a total count at the end of -Dhpss is good...
<vila> yeah, there is a huge TODO in that plugin :-/
<lifeless> ciao
<vila> lifeless: g'night
<poolie> cheerio
<poolie> lifeless, how about moving ReadVFile from pack.py into transport?
<poolie> it seems totally generic
<poolie> i guess it can wait though.
<nono0> is there a bzr service like bitbucket
<lifeless> launchpad.net
 * igc1 dinner
<victory747> Hi, I have a problem with bzr-svn - I branched a repo and then branched from that for my working copy.  Later, I had to bzr svn-upgrade the svn repo due to the format changing in bzr-svn.  Now I can't merge my working copy back into the svn one since the ids are different, nor can I bzr svn-upgrade the working copy since the parent is not a foreign repository.
<awilkins> Should 2a always be smaller than the equivalent 1.14-rich-root repository?
<LarstiQ> awilkins: http://bazaarvcs.wordpress.com/2009/06/30/scability-benchmarking/
<awilkins> I'm just repacking it
<awilkins> It was 711M to start with now it's 904
<Peng_> Don't forget obsolete_packs.
<awilkins> Deleted those
<awilkins> And I'm only sizing "/packs"
<asabil> hi all
<asabil> a small stupid question, how can I cherry pick the last 3 commits from a release branch into trunk ?
<asabil> bzr merge -r -3.. ../series/0.2  doesn't produce the expected result for me
<jelmer> asabil, what's unexpected exactly?
<asabil> I would like it to apply the 3 last commits as patches into the current working tree
<asabil> at least that what I would expect since bzr doesn't track cherry picks
<jelmer> asabil, but what does bzr merge -r3... do that you don't expect?
<asabil> it just applies the last commit as a patch
<jelmer> asabil, ah, sorry
<jelmer> asabil, if you mean the *last* three patches, try -r-3
<asabil> -r-3 will only apply the 3rd to the last patch according to the bzr user guide
<awilkins> LarstiQ: After a repack it's now 651MB so a little smaller :)
<LarstiQ> awilkins: ok
<Peng_> bzr.dev r4494 ("(Jelmer) Pass create_prefix paremeter to BzrDir.push_branch.") doesn't actually introduce any changes...
<jelmer> asabil, I mean -r-3..
<asabil> jelmer: doesn't work, it tries to delete all the files
<LeoNerd> Having 'bzr shelve'd some changes, can I show the stored diff somehow; like bzr shelf1 show ?
 * asabil thinks that bzr needs something like bitbucket or github
<gmb> Hi.
<gmb> I'm receiving the following error when trying to `bzr branch`: http://pastebin.ubuntu.com/207499/ Is there anything I can do to resolve it?
<LarstiQ> gmb: there are bugs filed that look like that. Offhand you could try reconcile
<gmb> LarstiQ: Okay, I'll give that a shot and do some digging. Thanks.
<vila> Goood morning jam !
<jam> morning vila
<Tak> meh - is there a way to resolve "AssertionError: Tried registering <blah> as parent while None already was parent" on a bzr-svn pull?
<jelmer> Tak, what version of bzr-svn?
<Tak> whatever comes with the bzr1.16 winstaller
<jelmer> Tak, you may be able to fix it by removing the cache directory and letting it regenerate that
<Tak> where is the cache directory?
<jelmer> somewhere under the directory with local settings for your user account
<awilkins> %appdata%\bazaar\2.0\svn-cache
<awilkins> Yegods, our network is reaching new lows today
<Tak> success!
<bialix> hello bzr!
<bialix> jam, vila: I have fix for bug 307554
<ubottu> Launchpad bug 307554 in qbzr "`bzr branch URL .` refuses to create new branch in empty directory" [Medium,In progress] https://launchpad.net/bugs/307554
<bialix> can somebody review it? please
<bialix> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch21ldm%248pt%241%40ger.gmane.org%3E
<vila> wow, I was convinced you managed to addresed the problem in qbzr only and din't need a fix bzr 8-/ I realized you updated the bug on lp correctly but I misread things between the greyed 'undecided' and the double affectation bzr/qbzr :-/
<bialix> vila: no, the fix for bzr core is still required
<vila> bialix: I see that
<bialix> ok
<bialix> I've followed lifeless suggestions
<vila> bialix: sounds correct at first read, I'll install it and review
<bialix> I know, I've missed NEWS entry
<vila> bialix: an Ukrainian and French to write NEWS entry in English :-) Help !
<LarstiQ> can I help? ;)
<vila> Dutch to rescue ! Hurrah !
<bialix> it was joke, I knew
<bialix> :-)
<vila> bialix, LarstiQ : Joke aside if alex can pastebin a proposed NEWS entry and wouter can review it, I'll submit the result :)
<bialix> ouch!
<vila> branch now accepts a --use-existing-dir parameter (Alexander Alexander Belchenko, #307554)
<vila> Is that correct and complete enough ?
<bialix> no, you wrote my name twice
<vila> bialix: :)
<bialix> one sec
<vila> bialix: your got the code from cmd_checkout ?
<bialix> cmd_push
<bialix> vila, larstiq: http://pastebin.com/m160586c6
<bialix> LarstiQ: ^
<bialix> ok?
<vila> god for me
<vila> good for me
<bialix> LarstiQ: you have to approve it
<bialix> pleeeease!
<bialix> heh
<bialix> he's ran away?
<bialix> vila: it seems so
<bialix> vila: what is your verdict?
<vila> approve, I'm fixing a few typos and I'll submit
<bialix> ok, many thanks
<Tak> jelmer: should I file a bug about that? I'm not sure how to reproduce...
<Tak> (bzr-svn issue from hours ago...)
<jelmer> Tak, It works now?
<jelmer> Tak, I'm suspecting it's a bug in bzr-svn that was fixed earlier but caused issues in the cache
<Tak> ok
<Tak> yeah, it seems to be working
<SamB> jelmer: what was it that needed to happen before bzr-svn supports ignoring files based on that SVN property?
<SamB> jelmer: and more immediately useful, do you know of any tools to convert that property into the form used in .bzrignore files?
<jelmer> SamB: bzr needs to support a generic API for handling ignores rather than relying on the fact that a versioned file named ".bzrignore" exists
<SamB> jelmer: oh, that has to be versioned?
<jelmer> SamB, there's some functions in bzr-svn for handling svn:ignore data, which is used for svn:ignore in working copies
<SamB> that sounds kind of sick
<jelmer> SamB, .bzrignore doesn't have to be versioned atm
<SamB> ah good
<SamB> that's as it should be, I think
<SamB> ... how else is a soul supposed to test changes?
<SamB> so ... can bzr-svn access the svn revprops when in a bzr-format working copy for a bzr-format branch?
<jelmer> SamB, only svn:author, svn:log and svn:date (which are mapped to their bzr equivalents)
<jelmer> SamB, if you think there's a reason to support others, please file a bug :-)
<SamB> I was just hoping to add a command to to generate ignore rules in the form required by ".bzrignore"
<SamB> so it would have to get the property from somewhere ...
<jelmer> SamB, svn:ignore is not a revision property but a file property
<SamB> oh, file property
<SamB> right
<jelmer> file properties aren't stored anywhere either (bzr doesn't have "free-form" file properties, only specific ones)
 * SamB doesn't know why he said revprop above
<SamB> well, would it be reasonable to write a command that takes an SVN url (perhaps defaulting to bound or parent URL?) and perhaps SVN revision number and outputs .bzrignore rules ?
 * SamB wonders where svn:ignore is documented ... tries googling
<jelmer> SamB, yeah, that'd be reasonable
<SamB> is there a URL for the latest released svnbook ...?
<SamB> jelmer: so where is this code dealing with svn:ignore?
<jelmer> SamB, workingtree.py
<SamB> and would I be able to use this even if I don't have an SVN working tree?
<SamB> hmm, the main bit seems to be a method on SvnWorkingTree, so I'm thinking "not without refactoring"
<SamB> jelmer: how do you test bzr-svn?
<SamB> I mean, I don't really want to run all of the bzr self tests for bzr+all-installed-plugins
<backz> hi, how to get a list of changed files since X rev?
<beuno> backz, bzr log -v -r X
<backz> beuno: ok, but I need only list of files
<backz> I'm creating a rsync.txt
<beuno> backz, not sure if there's a command that will give you that exact output
<backz> ok, no prob, I'll parse log -v output in vim
<backz> thanks!
<Tak> ffs, how do you show the branch uri(s) in git?
<garyvdm> Wrong channel?
<Tak> it's relevant, because I'm trying to refind the uri for an existing git branch so I can rebranch it with bzr-git :-P
<Tak> then the voices will stop shouting
<phinze> just had a cool idea; wondering if there already exists a plugin that does this
<phinze> would be nice if i could put in a comment some keyword that would block a checkin with that file
<phinze> wouldn't be hard to have a plugin that checked incoming checkin for that keyword and bailed if it was found
<phinze> something like # DONT-CHECK-ME-IN \n print($SECRET_VALUE)
<ddaa> phinze: first note that you have to store secret values in the source tree of your deployment, you need a better configuration system.
<ddaa> phinze: then, the common way to deal with this use case is with "bzr ignore"
<ddaa> since involuntary commit is usually a consequence of runnig "bzr add" and not checking the result.
<phinze> ddaa: right, i was just using a simple example
<phinze> i'm just picturing a sanity-check that allows a dev to, for example, insert debugging code and make sure she doesn't forget about it before commit
<phinze> whereas bzr ignore is file-wise
<ddaa> oh, that's a much better use case :)
<phinze> i looked at a few other pre-commit plugins; and it should be pretty simple to whip up.  i'll post to the room if/when i do that
<ddaa> I sometimes put "NOCOMMIT" comments in my code. But what I usually mean is "do not merge that into trunk", not "do not commit that in my development brancH"
<ddaa> so, I guess it would be useful to have an option that says in essence "bzr commit --with-the-nocommit-crap-too"
<ddaa> <rant>You know, bzr developers have this strange habits of doing multiple commits on development branches before merging on mainline, while other dvcs have crappy log commands that cause this behaviour to be regarded as "commit log pollution"</rant>
<ddaa> <rant>So they write strange tools to avoid doing commits, such as hg queues, and they claim they are really cool, while they are half-assed solutions to the wrong problem.</rant>
<ddaa> Oops, sorry, I ranted on hg queues again.
<fullermd> ddaa: You should try hg queues; they totally solve that problem.  They're really cool.
 * ddaa hits fullermd with a large nail-studded stick
<mneptok> fullermd: don;t take offense. that's ddaa's customary mating ritual.
<ddaa> mneptok: I do not remember hitting any female with a nail-studded stick at our former common employer's meetings.
<ddaa> I guess it was against company etiquette, unlike, say, filling a female's belly button with sugar.
<fullermd> Are you mad?  Think of the calories!
<moldy> hi
<moldy> does bzr have an equivalent to svn export?
<Tak> export?
<moldy> Tak: i just realized that. the syntax was a little weird to me :)
<ddaa> moldy: what about 'bzr export'?
<moldy> ddaa: yep, thank you
<moldy> i got irritated by the fact that it takes the destination as first and the source as second argument
<ddaa> the common use case is to run this command from within the source
<moldy> yep, i happen to have another use case :)
<mwhudson> jelmer: hello
<jelmer> mwhudson, hey
<mwhudson> jelmer: thinking about using bzr-svn for launchpad again
<dash> horray
<jelmer> mwhudson, \o/
<mwhudson> jelmer: have you made any releases subvertpy of bzr-svn since the last time i talked to you about this?
<mwhudson> jelmer: does bzr-svn have anything like the git.db file?
<jelmer> mwhudson, that depends on what the last time was that we talked about this :-)
<mwhudson> jelmer: it has something in ~/.bazaar/svn-cache, right? not in the repo
<jelmer> mwhudson, bzr-svn basically has a companion release for every bzr major release
<mwhudson> jelmer: :)
<jelmer> mwhudson, yeah, it's separate from the repo indeed
<mwhudson> jelmer: so i guess if i did nothing each slave would end up building the cache separately
<mwhudson> jelmer: do you think it's worth trying to preserve it somehow?
<jelmer> mwhudson, if you have patience it's not really a problem to recreate it each time
<mwhudson> sounds easiest :)
<jelmer> preserving it would mainly save some CPU cycles on Launchpad's side
<jelmer> and if people start roundtripping revisions from bzr into svn heavily you might face some other performance problems
<jelmer> mwhudson: It would be nice to be able to import all of the branches from a foreign repository at once, that should in the general case be only slightly more expensive than fetching trunk
<jelmer> mwhudson: There are separate commands for this, but no infrastructure afaik
<mwhudson> jelmer: i think i'm going to mumble something about colocated branches here
<jelmer> mwhudson: :-)
<mwhudson> jelmer: i guess we could do something where we update all branches that we're doing from a particular repository at once
<mwhudson> jelmer: but that sounds a bit complicated
<jelmer> mwhudson, Well, the functionality for that is mostly already there but spread across multiple commands
<jelmer> this is what "bzr svn-import" / "bzr git-import" do, and we'll probably end up with a "bzr hg-import", too
<mwhudson> jelmer: complicated on my side, i meat
<mwhudson> *meant
 * mwhudson needs coffee
<jelmer> mwhudson, ah
<jelmer> yeah, it would I guess
<mwhudson> i'm not really worried about wasting launchpad cpu cycles
<mwhudson> (we can just buy more machines :)
<mwhudson> load on the remote server is more of a concern
<mwhudson> but heck
<mwhudson> cscvs is about as bad as it can possibly be for this...
<jelmer> well, there wouldn't be much overhead on the remote server with this
<jelmer> because we can update all branches at once
<jelmer> importing all branches at once would be a lot easier on the remote server than importing two individual branches separately
<mtaylor> lifeless: awake yet?
<mwhudson> jelmer: what about servers like svn.apache.org or svn.kde.org?
<mwhudson> that contain squillions of projects
<jelmer> mwhudson, that's trickier, though svn-import can import parts of the repository already
<mwhudson> which, obscurely, reminds me to go check on a svnsync i've had running for days
<lifeless> mtaylor: yes
<lifeless> mwhudson: multipull
<mtaylor> lifeless: yay!
<mtaylor> lifeless: so - since you know everything... you wouldn't happen to know what the gcc option is that causes pointer values to be set to certain values indicating uninitialized and freed, would you?
<mtaylor> lifeless: sometihng like ABBACDDC and BADDAFFA or something like that
<lifeless> in forte?
<mtaylor> is it in forte? I thought it was a gcc opt
<mtaylor> that might explain why I haven't been able to find it in the gcc manual
<lifeless> I'm fairly sure gcc doesn't, but othere compilers do (and I don't know which ones do)
<lifeless> it came up in the past in standards-wrangling discussions
<mtaylor> k. thanks.
<lifeless> 'is NULL == 0L'
<lifeless> and so on
<mtaylor> yes. lovely conversations those must bre
<LarstiQ> vila: hmm, no bialix. Sorry about earlier, but the conference wifi is pretty spotty at times
<lifeless> oh yes
<lifeless> mtaylor: if gcc has it it would be a -f option
<lifeless> mtaylor: and you'd need to compile the closure of libraries
<lifeless> [potentially]
<lifeless> -fdelete-null-pointer-checks - nice
<mtaylor> that's pretty
<mneptok> oh no! The Other Monty has infected #bzr!
<mneptok> *muah*
<lifeless> mtaylor: a quick google.. http://www.google.com/url?sa=t&source=web&ct=res&cd=11&url=http%3A%2F%2Fwww.parasoft-embedded.com%2Fproducts%2Finsure.jsp&ei=m-NLSs79N5Pq6gOPyMDFBQ&usg=AFQjCNH33zIQ-AZmFK1aptLpTwE9x-6ZPg
 * mtaylor is EVERYWHERE
<fullermd> Really?  Cool, I was needing somebody already in my attic to run some coax...
<mtaylor> fullermd: I'm not only there, the coax is already run !
<mtaylor> fullermd: now you just have to pay me the yearly licensing fee for use of the coax...
<poolie> hello all
<igc1> hi poolie
#bzr 2009-07-02
<mwhudson> jelmer: still here?
<jelmer> mwhudson, somewhat
<mwhudson> jelmer: python2.4, bzr 1.16.1 (1.17dev soon maybe), bzr-svn 0.6.3, subvertpy 0.6.8
<mwhudson> jelmer: all should work together ok?
<jelmer> mwhudson, yes
<mwhudson> jelmer: subvertpy.tests.test_properties.TestProperties.test_time_from_cstring fails, should i worry?
<jelmer> not really, I think that's still the same test
<mwhudson> ok
<jfroy> jelmer: new bug, never seen this before: https://bugs.launchpad.net/bzr-svn/+bug/394527
<ubottu> Ubuntu bug 394527 in bzr-svn "SubversionException - "At least one property change failed"" [Undecided,New]
<poolie> hello garyvdm
<garyvdm> Hi poolie
<lifeless> poolie: I'm off for a bit as discussed
<jfroy> jelmer: I'm not sure I understand your comment on the bug.
<jfroy> But does it basically mean I should make a smaller commit (a batch of commits)?
<mrooney> hey bzr friends, it looks like the Limitations section of http://bazaar-vcs.org/BzrForeignBranches/Subversion is out of date (some of the limitations are addressed which is great!)
<mrooney> jelmer: specifically I noticed the first and last subversion file properties, this is your domain, correct?
<mwhudson> the bzr-svn tests still segfault :(
 * igc back
<garyvdm> igc: I've just landed my tree widget into lp:qbzr
<igc> garyvdm: excellent! I'll take a look tonight
<garyvdm> and I'm busy changing qcommit, qadd, and qrevert to use it.
<igc> garyvdm: cool. So that means I can add files in a directory yet to be added when that's done?
<garyvdm> igc: Yes - I've got it showing the contents of a unversioned dir.
<igc> garyvdm: hooray!
<garyvdm> But getting it to decide how to pass the parameters to the subprocess is a bit of a challenge
<garyvdm> If you change the selection in a subdir, it needs to pass the subitems and say --no-recurse. And if you don't change any thing, it must not pass the sub items, and not pass --no-recurse.
<garyvdm> And if you have mix????
<garyvdm> igc ^^^
<igc> garyvdm: why is no-recurse needed when a subitem is selected? If that itself was a subdir, I'd expect it to recurse from there?
<garyvdm> If you have 1 sub items that is deselected, you need to pass no-recures, and pass all the other items that remained selected.
<garyvdm> igc ^^^
<igc> garyvdm: ok, I'll give it a go tonight. Thanks for getting this going
<RenatoSilva> https://bugs.eclipse.org/282226
<bob2> is there a bzr.dev-as-2a branch somewhere?
<spiv> bob2: Probably only as throw-aways on a couple of devs laptops.
<spiv> I don't think we want to start inviting people to make rich-root revisions that they might submit back to us until bzr.dev itself is in a rich-root format.
<bob2> ah, fair enough
<poolie> jelmer: are you still here?
 * igc lunch
<poolie> spiv, hello! how's it going?
<spiv> poolie: good, I have InterDifferingSerializer and streaming fetch sharing the same code for generating new roots.
<spiv> I got a bit alarmed at https://bugs.edge.launchpad.net/bzr/+bug/196080/comments/1 this morning
<ubottu> Ubuntu bug 196080 in bzr "`bzr info -v bzr://host/branch` hides actual branch/repo format" [Medium,Confirmed]
<poolie> yeah, i saw your reply
<lifeless> it would be nice if fixed bugs could not be touched except by team members
<poolie> not reopened?
<lifeless> not touched, even comments on fixed tasks are noise - I'd much rather the user get directed to open a new bug
<poolie> cos i just reopened a fixed bug in launchpad to point out it's actually not fixed
<spiv> Well, perhaps after say 3 months?
<lifeless> spiv: something.
<poolie> arguably i should have opened a new one but that's kind of noise too
<poolie> some kind of warning would be good
<lifeless> poolie: true, OTOH the lp dev could: dup it, reopen the original.
<spiv> Certainly I wouldn't immediately assume it's wrong for a user to reopen a bug within a week, but for sufficiently old bugs it's almost certainly better to open a new bug.
<lifeless> I have a strong bias to 'always open new bugs'
<lifeless> because dupping is easy
<spiv> Yeah, I flied a bug about this today.  I think there should be a way to take a comment and automatically turn it into a new bug (and remove/hide the original comment).
<spiv> So that splitting becomes easier, although still not as easy as marking a dupe.
<spiv> Oh, interesting, read_inventory_from_string doesn't work with CHKSerializers.
<spiv> Or perhaps I'm feeding the wrong thing to it.
<spiv> No, I don't think I am...
<lifeless> spiv: it can't
<lifeless> spiv: or rather, its used in places that want to do one IO to get an inventory and so we chose to make it error, IIRC.
<spiv> Hmm, well, the code we had is feeding the wrong thing, rather than my code per se ;)
<stefanlsd> garyvdm: congrats on getting qbzr 0.11 into karmic :)
<garyvdm> stefanlsd: Thanks for all the help.
<garyvdm> stefanlsd: I guess I got to find some other packaging to do :-)
<stefanlsd> garyvdm: np! yeah!  lots of stuff to do!   :)
<lifeless> poolie: http://paste.ubuntu.com/207940/
<spiv> Ah, I see, get_stream_for_missing_keys is producing fulltext inventories...
<poolie> typo introducead
<vila> hi all, I'll be barfu (back after reboot for update :)
<lifeless> gnight
<johnskulski> I have shelved some changes. then i made a change and committed. now when i try to unshelve I get an error about it not merging cleanly. How can I go forward?
<lifeless> unshelve --force ?
<lifeless> poolie: you might enjoy  http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html
<vila> poolie: regarding bug #261770, it seems that both users really wanted 'bzr revert -rxxx' even if they tried 'bzr uncommit -r xxx' they both wanted to follow that by 'bzr revert'
<ubottu> Launchpad bug 261770 in bzr "cannot uncommit to a non-mainline revision" [Medium,Confirmed] https://launchpad.net/bugs/261770
<vila> poolie: so what fix do you think about here ? Giving a proper error message pointing to bzr revert ?
<vila> poolie: making uncommit -r accept non left-hand revisions seems wrong to me
<lifeless> vila: why ?
<vila> if it's not in my left-hand ancestry I didn't commit it, how come I can uncommit it ?
<lifeless> someone pushed to it pivoting your history
<lifeless> so you may well have committed it
<lifeless> also, I don't see why not being the committer should have anything with the ability to uncommit
<vila> because, to me, uncommit means: "Oh wait, that (these) commits were wrong, put me in a state where I can commit again (i.e. don't change a single bit in working tree, the state is fine, but put me in the ancestry graph at *that* point)
<lifeless> sure
<lifeless> I don't see why we should cripple its ability
<vila> what the reporters want (in *both* cases) is: give me the working tree at that revision
 * igc dinner
<lifeless> vila: well, I'd investigate why they thought uncommit would change the wt
<lifeless> vila: but that seems orthogonal to me
<vila> lifeless: full agreement, hence my question
<lifeless> vila: let me put this another way
<lifeless> vila: given that uncommit == 'bzr pull . -r <arg> --overwrite' minus the tree changes
<lifeless> vila: why put additional constraints on it
<lifeless> well, its really EOD for me now.
 * lifeless puts the laptop away
 * vila tries the desktop
<vila> lifeless: I see, have a good eveniing
<poolie> hi vila
<vila> hey poolie !
<vila> jam: too early, go back to sleep !
<jam> vila: definitely too early, just my machine losing and then gaining network access :)
<vila> jam: :-D
<vila> good morning jam (should be better now :-)
<vila> jam: It could have been your son waking you up and you not finding your sleep anymore :-)
<jam> yeah
<jam> that certainly happens sometime
<jam> but I usually don't have trouble finding my sleep
<jam> my wife does, though
<mozmck_work> is it possible/recommended to have multiple unrelated projects in one repository?
<ddaa> it is possible
<mozmck_work> I have numbers of personal projects I am working on, and my thought is that it would be nice to have my whole projects directory in one repository so I can do a single commit or update to save work on them all at once.
<ddaa> that's something different than putting different projects in one repository
<mozmck_work> ok, what would be the best way to do that?
<ddaa> the short answer is: you can't
<ddaa> the slightly longer is: you could look at the scmproj plugin which might do something close to what you want
<ddaa> the longer is: "I'm not sure you are clear on what you want to do. Why do you want to do commits in unrelated projects at once?"
<ddaa> What we call that in bzr land is "nested trees". And they are not supported yet, with no defined timeline.
<ddaa> The main use case for nested trees tracking is recording which revisions of multiple interdependent projects go toghether.
<ddaa> Unless you have a specific need for something like that, I would just write myself some shell scripts.
<mozmck_work> ok, I have a projects directory with 10 or 20 different projects. PIC micro firmware, computer software etc.
<mozmck_work> sometimes I may work on 3 or 4 or more of these in a day
<mozmck_work> they are currently not in version control at all, but I want to put them there for revision history, and because I work on them on 3 or so different computers from several locations.
<mozmck_work> my thought was if I could just put the whole projects directory as a repository I could commit everything under it at once.
<dash> mozmck_work: are you changing everything at once? would they all hav ethe same commit message? :)
<mozmck_work> hmmm, the commit message would be a problem I guess.
<dash> i guess i'm not understanding why you'd want to commit to separate projects simultaneously
<mozmck_work> I should probably just commit each one when I get done with it.
<dash> probably :)
<mozmck_work> well, to save time and having to remember which ones I even worked on!
<ddaa> The recommended style in bzr is actually: commit whenever you have a "good" state, or a state you want to share.
<dash> mozmck_work: that sounds weird :)
<dash> why wouldn't you commit after running your tests?
<mozmck_work> yeah, but I'm working alone.
<ddaa> It's recommended to do multiple commits on a branch within a single session, as dash said, after runnig the tests.
<mozmck_work> well, some of these are for work, and I work on them at work and at home.
<dash> ok?
<mozmck_work> so I use a thumb drive right now to bring stuff back and forth.
<dash> sure
<mozmck_work> and I forget at times which computer has the newest version of which program.
<mzz> bzr can certainly be useful for that kind of sharing, but the recommended way to use it is to commit considerably more frequently than once a day when you're moving between systems
<mozmck_work> that's what I'll need to do.
<dash> mozmck_work: why are you waiting so long to commit?
<mzz> (I do use bzr to prevent getting confused and having multiple diverging versions of the code spread across systems)
<ddaa> mozmck_work: note, you will not NEED to commit more often. We say it's good practice, and doing so gives you the full benefit of the tool.
<mozmck_work> I'm not yet because I don't use VCS.
<mozmck_work> I need to or my code will be at work when I want it at home :)
<mzz> you most definitely *can* stick multiple projects into the same branch, which would let you commit all of them. But if you do that it's relatively hard to get a single project back out.
<mzz> bzr isn't like svn in that
<mozmck_work> mzz: that makes sense.
<mozmck_work> it was kind of a wild idea I guess :)
<mzz> assuming both systems are networked I'd use one bound branch per project and a shared repository somewhere reachable from both
<mzz> that just leaves figuring out how to deal with changes that aren't quite ready for a commit before you move between systems
<mozmck_work> I can set up a server to network them.
<mozmck_work> what is a bound branch?
<mzz> if they're not networked you can put that shared repo on a thumb drive
<mzz> I'm hoping bound branches are explained in the documentation, sec...
<mzz> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-checkouts but that's not ideal. Can someone give me a better doc link?
<mzz> or give mozmck_work a better doc link, really
<mozmck_work> ok, I can find it.  but only one shared repository per project right?
<mzz> well, depends
<mzz> afaict you won't need more than one for what you're doing
<mzz> <-- not a bzr expert though
<mozmck_work> me neither (obviously!)
<mozmck_work> I'll keep reading.  there's too many options...
<igc> night all
<awilkins> Wowzer, sourceforge.net got all purrrty
<Xavura> impossible!
<Xavura> oh wow
<ddaa> why do sf.net look like twitter all of a sudden?
 * awilkins registers sourcetwit.net
<Xavura> they're kinda late to hop onto the web 2.0 bandwagon but err
<ddaa> Apparently, their web20 script monkeys STILL have not heard of this innovation: margins
<Xavura> rofl
<kfogel> bzr pack
<kfogel> bzr: ERROR: Pack '39d0c482e6e64ea0f509082e76b76e37' already exists in <bzrlib.repofmt.groupcompress_repo.GCRepositoryPackCollection object at 0x8ba604c>
<kfogel> anyone know what that's about? ^^
<Xavura> does look a bit croweded
<ddaa> that's a bug in bzr-hg, bzr-git whatever your are trying to use.
<kfogel> That was from the final command in 'bzr reconcile && bzr upgrade --2a && bzr pack' with very latest bzr bleeding-edge.
<kfogel> ddaa: (were you responding to me?)
<dash> also they bought Ohloh
<ddaa> kfogel: yup, I guessed (apparently wrong) what you were trying to do.
<kfogel> ddaa: yeah, this was just a straight upgrade to the brisbane-core format
<mzz> well, http://sourceforge.net/ is currently giving me a *very* pretty 500 page
<mzz> I'm not sure that's what you folks meant though
<ddaa> mzz: well, no. But I guess you can still see the improvement from where you stand :)
<jelmer> kfogel, Afaik that happens if you try to pack while there is nothing to pack, and you end up generating a new pack file with the same contents (and hash)
<Peng_> jelmer is correct. There could always be some other cause, of course, but it's probably that. Bug #382463.
<ubottu> Launchpad bug 382463 in bzr "'bzr pack' of an already packed dev6 or 2a repo fails with Pack exists" [Medium,Triaged] https://launchpad.net/bugs/382463
<kfogel> Peng_: dang it.  I just was over in the bug tracker finding that bug.  I should have waited for you to say it!
<Peng_> "bzr pack" on older formats just reorganizes data, so they short-circuit when there's only 1 pack file, but BBC recompresses too, so packing when there's only one pack may still lead to a different file.
<Peng_> So it's a bit harder to decide what to do to fix it.
<kfogel> Peng_: well, it could attempt to recompress and then if there's no advantage, just remove the attempt and say nothing.  (Or, if it wanted to be really fancy, it could store a flag the first time saying it has been compressed, and with what algorithm/compression-level, so it would know not to bother trying to do better unless there's been an upgrade).
<Peng_> kfogel: Yeah, but then all of that CPU would have been wasted for nothing.
<kfogel> Peng_: Not in the latter case.  But wasting CPU is better than an error message for a non-error in any case!
<kfogel> :-)
<gioele> hello
<Peng_> kfogel: You could propose the flag thing in the bug. ;-D
<mozmck_work> in .bzrignore, can I use dir/*.* to ignore everything in certain directories?
<gioele> I'm experimenting with bzr-svn. Is there a way to make sure that it does not commit anything to the remote svn repository?
<gioele> mozmck_work: yes
<Peng_> gioele: You could not run "commit".
<Peng_> mozmck_work: What if the filenames don't have "." in them?
<jelmer> gioele, don't use the "checkout" or "push" commands
<Peng_> mozmck_work: Just ignore dir/ or, if you want to version the directory for some reason, dir/*
<gioele> jelmer: what about commits?
<jelmer> gioele, if you commit in a checkout, it'll be committed to the master branch as well
<jelmer> gioele, if you commit in a standalone branch that was created from a svn branch, it won't affect the branch it was cloned from
<gioele> jelmer: perfect
<jelmer> gioele, if the svn repository has a read-only URL you could use that
<mozmck_work> I tried dir/*.* and then ran "bzr ignored" and it didn't list any files from that dir as being ignored
<jelmer> that way you're always sure you won't do any writes
<gioele> jelmer: sadly it has not it.
<Peng_> mozmck_work: You do know that ignore rules do not apply to already-versioned files, right?
<mozmck_work> yes, I'm setting up .bzrignore before I add any files
<mozmck_work> dir/* didn't work, but dir/ did
<kfogel> Peng_: it's too obvious; anyone looking seriously at this bug will see all the options.  I think the bottleneck is dev attention, not solutions.
<jelmer> we have a lot of these bugs related to simple unpolished bits of bzr
<Peng_> kfogel: Well, I don't think anybody else proposed it.
<gioele> OK, next topic: how important is it to have svn 1.5 instead of svn 1.4 with regard to bzr-svn? Are there thinks that I can't do when only svn 1.4 is available on the remote repo?
<dash> svn 1.5 supports revision properties
<dash> which bzr-svn will used to store metadata
<dash> on 1.4 and earlier ti uses file properties, which are a little more intrusive
<awilkins> 1.4 svn repositories support revision properties, but you need to use bzr-svn against the 1.5 API to use them
<awilkins> gioele: So as long as your CLIENT uses 1.5 or above, you will gain the benefit
<dash> oh!
<dash> news to me
<awilkins> SVN has supported revision properties for as long as I can remember, back to about v 0.39
<ddaa> awilkins: I think the news is something like "unprivileged users can now set them at commit time"
<gioele> awilkins, dash: thank you
<gioele> wow: subvertpy does not provide very useful exceptions: "bzr: ERROR: subvertpy.SubversionException: ("In directory 'svn/branches/src/...'", 155009)"
<Peng_> ERR_WC_BAD_ADM_LOG, apparently.
<SamB> gioele: what, you want it should convert the svn error number into human-readable form?
<jskulski> hey all, I shelved some changes, and made some changes to my tree (moved functions to a new file) and now bzr unshelve says that it won't be clean. Is there a way I can point it at the new file or get a patch I can apply and delete it from the shelf?
<verterok> beuno_: ping
<beuno_> verterok, hey
<verterok> beuno_: do you have a minute to chekc verterok.com.ar?
<beuno_> verterok, sure
<verterok> beuno_: it's returning 404's :/
<beuno> argh
<beuno> I must of screwed up migrating
<beuno> oh
<beuno> *I* didn't
<beuno> someone else did
<verterok> beuno: oh, nice! it's always good to don't be the one who broked it ;)
<beuno> verterok, DNS FAIL
<beuno> sorry  :(
<beuno> fixing it now
<beuno> but it will take an hour or two to propagate
<verterok> beuno: ok, thanks!
<verterok> beuno: I noticed because of Bug #394847
<ubottu> Launchpad bug 394847 in bzr-eclipse "Update site 404s" [Undecided,New] https://launchpad.net/bugs/394847
<beuno> verterok, I can mirror the account on a different server in the mean time if it's critical
<verterok> beuno: not critical, thanks!
<Pilky> anyone with any experience with GPL licensing technicalities? I want to know if I write an Obj-C API to hook into bzr, whether I can licence it as LGPL?
<fullermd> By the standard interpretation, no.
<Pilky> :/
 * Pilky stabs GPL
<fullermd> Now, theoretically Canonical owns all the copyrights, so you could potentitally negotiate other terms with them.
<Pilky> well the only reason is I want to use the API to write a GUI for bzr on OS X
<Pilky> but I want as much of the code as possible to be licensed as MIT
<dash> do like bzr-eclipse does and use bzr-xmloutput
<Pilky> I considered that before but it seems a bit hackish
<Pilky> using bzrlib I can take python objects and convert them to Obj-C quite easily
<Peng_> You can negotiate other terms with Canonical. Well, the website says so; I dunno if anyone ever has.
<Pilky> yeah I'll probably look into that
<Pilky> if they allowed my API to be licensed LGPL or even MIT it could help provide a boost for bzr on OS X as a means of talking to other tools
<Peng_> Since Canonical owns everything, relicensing would be pretty easy, if they decided to.
<Pilky> yeah, I mean I'm not looking into relicensing bzr itself
<beuno> well, it's unlikely that Canonical will relicence bzr to MIT for distribution
<Pilky> just whether I can create code that talks to bzr lib that doesn't have to be condemned to GPL status
<dash> more's the pity
<Peng_> LGPL is possible... Mercurial is firmly non-LGPL, though, so Bazaar might make the same decision.
<LarstiQ> Obj-C?
<LarstiQ> Pilky: you're not at EuroPython by any chance?
<Pilky> nope
<LarstiQ> ah ok, pure coincidence then
<Pilky> how so?
<LarstiQ> Pilky: there has been at least one talk about python and objc and some interest on the mailing list
<Pilky> ah cool
<LarstiQ> and then at least one bof iirc
<Pilky> well I'm going to be looking into PyObjC for building this bzr API
<LarstiQ> whereas before that, I hadn't really seen much activity on it
 * LarstiQ nods at Pilky 
<Pilky> yeah, a lot of people see Obj-C as some scary weird language, when they get introduced to it and can see that you can talk to cocoa with Python and Ruby as well then they get more interested ;)
<monteldeonte> Can someone help me with bzr?
<LarstiQ> Pilky: I feel old now :)
<dash> monteldeonte: no, you're doomed
<LarstiQ> monteldeonte: sure, what can we help you with?
<LarstiQ> dash: oi :P
<Pilky> heh
<dash> monteldeonte: (what is your problem? :)
<monteldeonte> lol
<monteldeonte> Is there a way that i can sync a bzr branch with svn?
<Pilky> so yeah, who would be the best person at canonical to get in touch with about my licensing problem?
<dash> monteldeonte: probably. what's your situation?
<LarstiQ> monteldeonte: in general, yes, with bzr-svn. There are some corner cases, so as dash said, could you elaborate on your situation?
<LarstiQ> Pilky: Martin Pool
<Pilky> ok cool, thanks!
<monteldeonte> I need to import the SVN from a project, and upload it to a branch
<monteldeonte> I also need to be able to sync it with the branch
<monteldeonte> i mean'
<SamB> Pilky: you can write code and license it under more liberal terms, but if you link it with canonical's code you'd need to provide the source anyway, as per the GPL...
<monteldeonte> sync the SVN every now and then
<dash> monteldeonte: sure. install bzr-svn and you can treat svn branches like bzr ones, mostly
<monteldeonte> dash: I know, i have. I just dont know how to use it
<Pilky> SamB: well it will remain open source, but I don't want to licence it as GPL as that will limit uptake IMO
<dash> monteldeonte: 'bzr branch svn://yoursvnurl/.../'
<LarstiQ> monteldeonte: `bzr branch http://host/svn/repo/path/in/repo/to/branch`
<SamB> and if this is all Python code we're talking about I frankly don't think it makes a difference
<monteldeonte> LarstiQ: then how to i update the SVN?
<dash> monteldeonte: 'bzr push <svn url>'
<LarstiQ> monteldeonte: if you have commits in your bzr branch you want to get into svn, what dash said
<LarstiQ> monteldeonte: basically, you can treat svn branches as any other bzr branch
<SamB> monteldeonte: you just run "bzr pull" in your local copy of the SVN branch
<fullermd> Y'know, I was just thinking, it's been so boring here lately, let's have a license discussion   :p
<monteldeonte> I mean, when there is a new revision on the SVN, how do i sync it with the branch?
<SamB> monteldeonte: (it's a good idea to keep a pristine copy of the SVN branch, since SVN makes such a terribly slow DVCS)
<dash> monteldeonte: 'bzr merge'
<SamB> then you run "bzr merge ../code-from-svn"
<SamB> where ../code-from-svn is the pristine bzr copy of the branch SVN branch that you just pulled into
<monteldeonte> I am sorry,
<monteldeonte> I dont get it
<monteldeonte> LarstiQ: Ok, what is the first thing i do
<LarstiQ> monteldeonte: first, branch from svn.
<monteldeonte> k, h.o
<SamB> monteldeonte: basically, bzr-svn just allows Bzr to treat SVN branches as Bzr branches
<SamB> really, really *slow* Bzr branches
<LarstiQ> monteldeonte: (you mgith be more comfortable with a checkout style, but we'll come to that later)
<SamB> and you really don't want to do a bzr checkout directly from SVN
<SamB> well, maybe a heavyweight one ...
<LarstiQ> SamB: that, and if you're sitting next to the server...
<SamB> ... but I've had those fail in mostly-incomprehensible ways
<SamB> LarstiQ: does that actually help much?
<SamB> I suppose if it has a 10th or less the round-trip-time as usual ...
<LarstiQ> SamB: very small latency, lots of bandwidth
<SamB> LarstiQ: the bandwidth doesn't seem to be much of an issue usually
<LarstiQ> SamB: talking a gigabit office connection
<LarstiQ> SamB: are you using tdb or sqlite?
<SamB> what? I don't actually run any of the SVN repositories I pull from ... or are you talking about bzr-svn's cache?
<monteldeonte> LarstiQ: OK, now what
<monteldeonte> Say there is a change in the SVN, how do i get it?
<SamB> LarstiQ: using tdb or sqlite *where*?
<monteldeonte> Do i have to do that over again?
<SamB> monteldeonte: I would suggest keeping that directory just for the stuff from SVN
<SamB> and use a different one to hold your local branch
<SamB> which you would create by "bzr branch copy-of-svn my-branch"
<SamB> monteldeonte: then, when you want to update from svn, you can just go in the one you branched from SVN and run "bzr pull"
<LarstiQ> SamB: bzr-svn's cache
<SamB> and you go back to yours and run "bzr merge"
<monteldeonte> hah! you guys rock!
<LarstiQ> monteldeonte: SamB's advice is sensible.
<monteldeonte> I think i got it good now.
<monteldeonte> LarstiQ: OK, i already have a bzr branch, the one i was updating manually. How do i remove the stuff from that, and put this one into there?
<monteldeonte> should i just remove it and make a new one?
<monteldeonte> SamB: ?
<LarstiQ> monteldeonte: if you intend to use it to interact with svn but didn't produce it with bzr-svn, I'd ditch it if you can
<monteldeonte> k kool
<monteldeonte> LarstiQ: the old address for the branch was lp:noxbot now it is lp:~m.deonte/noxbot/main, how do i get that back?
<LarstiQ> monteldeonte: lp:noxbot is a shorthand, lp:~m.deonte/noxbot/main looks like the expansion for that
<LarstiQ> monteldeonte: if they no longer match, you can do `bzr pull --remember lp:noxbot`
<monteldeonte> woo hoo!
<monteldeonte> LarstiQ: So, when there is a change in the SVN, all i do is bzr pull and then bzr push?
<LarstiQ> monteldeonte: as long as svn and local don't diverge, yes
<LarstiQ> monteldeonte: if they do, you need `bzr merge`
<monteldeonte> LarstiQ: Diverge?
<LarstiQ> monteldeonte: SamB outlined a workflow for that
<LarstiQ> monteldeonte: say if you commit something locally, and someone commits something in svn
<LarstiQ> monteldeonte: neither is then anymore a strict superset/subset of the other
<monteldeonte> Wait, so if this guy commits on SVN,
<monteldeonte> What do i do?
<LarstiQ> monteldeonte: first, `bzr pull`
<monteldeonte> then
<LarstiQ> monteldeonte: then, if it says you need to use `bzr merge`, that
<monteldeonte> Oh, it will tell me?
<LarstiQ> monteldeonte: as SamB said, I'd advise to keep one local mirror you only pull into, and only commit just before you synchronise with svn
<LarstiQ> monteldeonte: yes
<LarstiQ> monteldeonte: and use a local branch of that mirror to do actual work
<monteldeonte> LarstiQ: OK, so when someone gets this branch, how do they update it?
<LarstiQ> monteldeonte: just the usual pull/merge. Other than svn, are you familiar of how bzr works?
<LarstiQ> s/of/with/
<monteldeonte> not really.
<LarstiQ> ok
<monteldeonte> LarstiQ: Wait, so will that other person have to have brz-svn installed?
<LarstiQ> monteldeonte: if they interact only with your bzr branch? No.
<SamB> monteldeonte: only if they also want to pull from SVN
<SamB> well, merge is more like it
<LarstiQ> monteldeonte: if they want to communicate directly with svn, then yes
<monteldeonte> OK, so say someone downloads my branch. When i push to bzr, what do they do to get it?
<LarstiQ> monteldeonte: bzr pull
<monteldeonte> Will that pull from the SVN?
<LarstiQ> monteldeonte: no, from the same location they got your branch
<monteldeonte> shweet
<LarstiQ> monteldeonte: In case you hadn't seen it yet, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
<LarstiQ> monteldeonte: I have to go now unfortunately (well, drinking beer)
<LarstiQ> monteldeonte: so good luck and I'll check in when I get back
<monteldeonte> Ok, thank you for your help
<monteldeonte> I think i get it now
<monteldeonte> Ok, thansk
<LarstiQ> good
<gioele> I cannot understand the wording of section 8.2.3: it first gives an example using 'svn-import', then says 'Here's the recipe from above updated to use a central Bazaar mirror:' adn then gives and example where svn-import is not mentioned
<gioele> section 8.2.3 == http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#bzr-svn
<Peng_> gioele: Well, use "bzr svn-import" to import all the branches from a repo. Use "bzr branch" for one branch.
<Peng_> gioele: The end result is equivalent; svn-import just makes it easier to import multiple branches at once.
<gioele> Peng_: from what I see the leading text should say "In addition to svn-import, also XXX can be used to create a central Bazaar mirror. Here is the recipe from above updated to use method XXX"
<Peng_> Ehh. I don't have documentation paged into my brain.
<gioele> Peng_: well, as I wrote, my comment was about the "wording" of that section
<Peng_> I such at English.
<fbond> Hi.  I was just thinking -- there's been some talk of support for history editing on the ML.  Would it make sense at all to build this around shelve, instead of following the rebase model?
<fbond> Some automation on top of shelve would get me just about everything I would want...
<mozmck_work> I've used git just a little.  It looks like a git branch is about equivalent to a bzr tag - right?
<gioele> in bzr help svn-layout there is an example of a custom repository layout. It uses a new section inside ~/.bazaar/subversion.conf. The example use "[203ae883-c723-44c9-aabd-cb56e4f81c9a]". How do I know which number should I put there for my repository?
<garyvdm> mozmck_work: No - because a tag does not move forward when you commit.
<mozmck_work> hmmm, what does that mean?
<dash> a bzr tag is just a name for a revision
<mozmck_work> I see.
<mozmck_work> in git you can have say a release branch and the main dev branch "master"
<jocr> !help
<ubottu> Hi! I'm #bzr's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots
<mozmck_work> and change between them in the same working directory with a simple command
<dash> mozmck_work: right. the normal bzr workflow is two separate dirs
<dash> but you can use 'bzr switch' if you really want to use the same working copy.
<mozmck_work> that was my next question!
<mozmck_work> I don't know yet which I would prefer.
<mozmck_work> if you have 2 branches I guess they can go in the same repository.
<dash> that's what repos are for
<mozmck_work> thanks.  I'm slowly figuring it out - I think...
<jocr> where can I find information about how bzr deals with merge conflicts. I haven't been able to find the right documentation yet.
<garyvdm> jocr: what do you want to know?
<a_c_m> anyone know of any php libs or apps that can browse a bzr repro ?
<jocr> I see a bunch of suffixes on files that had conflicts and I just wanted to know which file was what
<jocr> suffixes are like BASE or BASE.moved or OTHER
<Peng_> a_c_m: This was discussed a bit on the mailing list recently.
<a_c_m> Peng_: ahh cool any good conclusions, or is there somewhere online the mailing list is stored?
<Peng_> a_c_m: The answer was "no", and yes, but I don't have a link handy. :P
 * Peng_ goes to eat.
<Peng_> Sorry!
<a_c_m> Peng_: shame :(
<fbond> window goto (st
<fbond> Whoops.
<jocr> !BASE
<ubottu> Sorry, I don't know anything about BASE
<jocr> !.BASE
<garyvdm> jocr: sorry - I can find any docs - allthough I'm sure that there are.
<jocr> that's o.k. I'll keep looking
<garyvdm> .THIS is the file from the branch that you merged into
<garyvdm> .OTHER is the file from the branch that you merged from
<gioele> jocr: bzr help conflicts
<gioele> (in general bzr help topics is quite helpful)
<garyvdm> .BASE is the version of the file that both branches have is common.
<jocr> I see, I was starting to deduce all this but thanks for the help.
<jocr> Another question is if I get a version of the file that I want to keep, say the .BASE version do I delete the others and to bzr resolve to fix the conflict?
<garyvdm> rm foo
<garyvdm> mv foo.BASE foo
<garyvdm> bzr resolve foo
<jocr> I see thanks again. and thanks gioele, I'll read the help file here
<garyvdm> All though it's very unlikely that you want to keep the BASE
<garyvdm> If it's a binary file, you generally keep the THIS or the OTHER
<jocr> no it's a source file with some different fixes in both versions
<jocr> that is the THIS and OTHER versions
<lifeless> moin
<RenatoSilva> where can I see the source of builtins.tree_files(file_list)
<bob2> bzrlib/builtins.py
<garyvdm> bzrlib/builtins.py line 71?
<RenatoSilva> bzrlib is at?
<garyvdm> root of bzr.dev
<RenatoSilva> I can't find it in bzr home
<RenatoSilva> what is bzr.dev
<garyvdm> Trunk of bzr
<garyvdm> http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/head%3A/bzrlib/builtins.py#L70
<RenatoSilva> what are the .pyd files?
<RenatoSilva> garyvdm: thanks
<RenatoSilva> I need to browse over the code
<RenatoSilva> it's just bzr branch lp:bazaar/trunk, right?
<garyvdm>  bzr branch lp:bzr
<RenatoSilva> ok
<RenatoSilva> Does anyone suspect how can ProgramaÃ§Ã£o become into Programaâ¡Ão?
<garyvdm> The text is bing decode in the wrong charset
<garyvdm> *being
<RenatoSilva> It's what comes from WorkingTree.id2abspath
<RenatoSilva> I'm trying stuff like  print u'ProgramaÃ§Ã£o'.encode('latin-1').decode('cp850')
<RenatoSilva> Without sucess, none of them lead to the above string
<dash> try removing the decode?
<dash> it's probably just latin-1
<lifeless> RenatoSilva: python -c 'import bzrlib; print bzrlib.__path__' will tel you where bzrlib is being loaded from
<RenatoSilva> dash: tried
<RenatoSilva> dash: how can ProgramaÃ§Ã£o become into Programaâ¡Ão?
<RenatoSilva> dash: that's what I mean
<Peng_> Is it a bad idea for multiple, completely unrelated projects to use the same file IDs?
<lifeless> Peng_: it would be odd
<lifeless> Peng_: not necessarily bad; why?
<RenatoSilva> hum, what is this: http://bazaar.launchpad.net/%7Ebzr/bzr/trunk/annotate/head%3A/bzrlib/osutils.py#L1127
<Peng_> lifeless: bzr-git does it. I was just curious.
<RenatoSilva> How can Bzr guess that the string is either unicode or utf-8 encoded?
<lifeless> Peng_: it does?
<lifeless> Peng_: what algorithm?
<RenatoSilva> when it is str, it is not necessarily utf-8 encoded right?
<Peng_> lifeless: It just uses the file's relative path.
<lifeless> RenatoSilva: that function isn't guessing
<jelmer> Peng_: Well, with some escaping
<Peng_> jelmer: Oh.
<Peng_> Hi jelmer. :D
<Peng_> I guess you have to do that because Git doesn't have convenient repository UUIDs like svn?
<RenatoSilva> lifeless: because the user should call it only for such cases?
<jelmer> Peng_, right
<lifeless> RenatoSilva: first it checks if it *is* unicode, and if its not unicode it expects to be given a utf8 str
<jelmer> Peng_: And I could use the sha of the path or something like that
<lifeless> RenatoSilva: yes, we use utf8 for our disk data structures
<jelmer> Peng_, But that would just cause indirection because there wouldn't be a way to go from file id to path cheaply
<lifeless> RenatoSilva: and we use that function when handling deserialisation from them
<RenatoSilva> lifeless: so it *expects*, it should not be called for non-utf-8
<lifeless> RenatoSilva: thats right
<Peng_> jelmer: Would it be possible to include the revision ID that introduced the file?
<Peng_> bzr-svn does that, IIRC?
<jelmer> Peng_: That would be possible, but expensive, and there's no point
<lifeless> jelmer: does it prefix it with git: or something?
<lifeless> jelmer: there is a point
<RenatoSilva> lifeless: it seems the problem is in WorkingTree then
<Peng_> lifeless: No prefix.
<lifeless> jelmer: consider a repo with any projects; the per-file graph is often loaded in bulk by bzr (e.g. for annotate)
<RenatoSilva> lifeless: http://bazaar.launchpad.net/%7Ebzr/bzr/trunk/annotate/head%3A/bzrlib/workingtree.py#L204
<lifeless> jelmer: having the same fileid in many projects with do very odd things to the per-file graph size and index shape
<lifeless> s/with/will/
<Peng_> lifeless: Will it actually cause problems, though?
<Peng_> lifeless: I mean, errors?
<RenatoSilva> lifeless: it also expects utf-8 or unicode
<lifeless> Peng_: it will cause slowness
<jelmer> lifeless: if we have to include the revision sha in which a file was introduced it means different slowness
<jelmer> lifeless, because we can't just fetch an arbitrary tree and know the file ids in it, we have to search history
<Peng_> How does bzr-svn do it?
<jelmer> Peng_: It searches history, and caches heavily
<Peng_> jelmer: Why have bzr-svn and bzr-git do it differently?
<lifeless> jelmer: tree-1 in the target will know, and it should be cheap to access
<lifeless> jelmer: also, do you do rename heuristics at import?
<jelmer> lifeless, we don't necessarily have tree-1
<jelmer> lifeless, we don't do rename heuristics yet
<jelmer> lifeless, when we do, I agree it would make sense to start looking at this
<lifeless> I suspect your file id allocation will mean you cannot do file rename heuristics :>
<jelmer> lifeless, That's not a problem
<jelmer> lifeless, We can't introduce rename heuristics without changing the mapping anyway
<jelmer> lifeless: so if we have to change the mapping anyway, we might as well change the file id allocation
<lifeless> ok, good
<jelmer> and introduce all of the infrastructure to deal with more complex file ids
<lifeless> because, at the moment, bzr-git repos of all of ubuntu will behave terribly.
<jelmer> Peng_: bzr-svn does roundtripping, bzr-git does not
<jelmer> lifeless: right
<lifeless> RenatoSilva: is WorkingTree.open() being called with a str, rather than a unicode ?
<lifeless> bbs
<Peng_> jelmer: Why doesn't bzr-git do roundtripping?
<jelmer> Peng_: The effort hasn't been put in and there's no really good place to put the bzr metadata
<RenatoSilva> lifeless: I'm trying to look at the right file, brb
<jelmer> Peng_, The only real place is the git commit message, and that's a bit intrusive
<RenatoSilva> lifeless: tree = WorkingTree.open_containing(default_branch)[0]
<lifeless> default_branch should have been decoded by the command argument parser from your console encoding
<RenatoSilva> lifeless: def tree_files(file_list, default_branch=u'.', canonicalize=True,
<RenatoSilva> lifeless: tree, file_list = builtins.tree_files(file_list)
<Peng_> jelmer: ok :)
<RenatoSilva> lifeless: i.e. default_branch is '.' however the complete path is returned in output
<lifeless> RenatoSilva: yes, that shuold all be fine; u'.' when passed to the file system means we get a filesystem encoding decoded cwd
<mathrick> who could give me some help with implementing rebase --interactive support?
<mathrick> ie. retroactive history shaping
<dash> mathrick: evil
<mathrick> dash: how else am I supposed to submit clean patches to projects?
<RenatoSilva> lifeless: I think that the path comes from tree = WorkingTree.open_containing(osutils.realpath(file_list[0]))[0]
<dash> mathrick: what's wrong with diff
<dash> mathrick: i assume you mean non-bzr projects?
<mathrick> dash: I mean bzr projects
<lifeless> RenatoSilva: it could as well, yes.
<mathrick> non-bzr ones of course get plain diffs
<dash> mathrick: then why would it matter?
<dash> mathrick: send a bundle
<lifeless> RenatoSilva: are you on windows?
<mathrick> dash: then I can't split them into featuresets and comment each one in a separate mail
<mathrick> which is the preferred form for very many projects
<mathrick> including, I believe, bzr :)
<dash> mathrick: why'd you do multiple features in a single branch? :)
<lifeless> mathrick: its nice to get clean featuresets; its more important to get patches though :)
<mathrick> dash: no, it's for bigger patches implementing a single feature / set of related features
<dash> I just finished breaking up a gigantic change into about 5 separate feature sets
<dash> but i used loom and it's for syncing one SVN repo to another
<RenatoSilva> lifeless: yes
<RAOF> You could do that with bzr merge cherrypicking, assuming each commit contains a single feature.
<lifeless> RenatoSilva: what bzr version do you have?
<poolie> hello all
<dash> mathrick: right, that sounds like a mistake to me
<mathrick> dash: howso?
<RenatoSilva> lifeless: I think that there may be a problem in http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/head%3A/bzrlib/osutils.py#L1127
<lifeless> hi poolie
<lifeless> RenatoSilva: what bzr version are you using?
<dash> mathrick: I don't see the problem with one branch and one merge per feature
<RenatoSilva> lifeless: ignore the line please, I mean realpath method
<mathrick> dash: the point is that a single feature should be multiple patches when it's big enough
<dash> mathrick: yeah, i don't really believe that
<mathrick> but it happens
<mathrick> case in point, wine's DIB engine
<dash> heh
<mathrick> they have specifically rejected patches which did that as a single "all-in-one" dump before
<RenatoSilva> lifeless: 1.15
<lifeless> mathrick: what dash is saying is that you should do each component in a separate branch
<RenatoSilva> lifeless: in tree = WorkingTree.open_containing(osutils.realpath(file_list[0]))[0]
<lifeless> RenatoSilva: please try bzr 1.16
<RenatoSilva> lifeless: something is going wrong...
<lifeless> bialix recently changed the command interpreter to decode all arguments to unicode
<lifeless> for problems like that
<mathrick> lifeless: but that's not how it happens. That's precisely the point, I can't know what I will end up implementing before I start
<RenatoSilva> lifeless: is there a windows installer for 1.16?
<dash> mathrick: waiting until all your changes are done seems like a poor time to break stuff up
<lifeless> RenatoSilva: I don't know, have a look :)
<lifeless> mathrick: I know, and I agree.
<dash> mathrick: i'm not saying you have to know before you start
<lifeless> mathrick: we want tools to do this; that doesn't actually imply rebase though it can be used if you haven't published your code.
<mathrick> lifeless: I only used the shorthand because that's where it is in git, which is well-known
<dash> just that once you know, put your unrelated changes into a different branch :)
<lifeless> I wrote a manifesto about this a few weeks back
<mathrick> I don't want to imply it should be inside bzr rebase
<mathrick> lifeless: link?
<mathrick> and that's exactly what I want, to give tools
<RenatoSilva> lifeless: downloading...
<lifeless> mathrick: https://lists.ubuntu.com/archives/bazaar/2009q2/059263.html
<lifeless> breakfasting
<mathrick> dash: the historical patch order is never the same as logical. Forgotten files and stupid typos happen. I want tools to be able to reshape that easily, instead of devolving to a bunch of dirs with branches and fighting with diff
<mathrick> lifeless: oh good, that seems interesting. I was actually wondering myself about being able to edit it without losing the actual patches as they happened
<dash> mathrick: and my point is that the historical patch order is also important, and some people are altogether too eager to destroy that. :)
<mathrick> dash: that's another problem that needs solving, not denying the problem #1 doesn't exist
<mathrick> s/doesn't//
<mathrick> also, it should help / interplay with how I wanted loom to work (as opposed to how it actually works today(
<dash> mathrick: I just think the prevalence of that particular problem is overstated
<RenatoSilva> installed but the same error: bzr xmlstatus > file is returning <?xml version="1.0" encoding="UTF-8"?><status workingtree_root="C:/Programaâ¡Ão/"></status>
<mathrick> dash: I don't think so. If I want to present patches in a logical order, my VCS gives me absolutely no tools above diff. That's not the brave new world we were supposed to have with DVCS
<dash> who says? :)
<mathrick> it's silly that it's distributed and facilitates the exchange easily except for when you want to send patches by email and discuss them
<mathrick> dash: says what?
<dash> mathrick: what we were supposed to have
<mathrick> dunno. I see a problem the tool fails to solve
<RenatoSilva> lifeless: maybe C:/Programaâ¡Ão comes from encoding as cp1252 when it's expected cp850
<mathrick> can we retroactively send brimstone upon the inventors of codepages?
<RenatoSilva> lifeless: something in the chain guess that it should be cp1252, but it should not according to chcp command. If I run chcp 1252 before it, then the file chars are ok
<dash> mathrick: if we could, it would have already happened
<mathrick> dang
<RenatoSilva> * is guessing
<RenatoSilva> maybe the problem is here http://bazaar.launchpad.net/%7Ebzr/bzr/trunk/annotate/head%3A/bzrlib/osutils.py#L1058
<mathrick> lifeless: I don't understand the "Integration" section
<lifeless> is the file on disk encoded in cp1252/
<lifeless> ?
<lifeless> RenatoSilva: ^
<lifeless> RenatoSilva: please file a bug about this; it could be a bug in bzr-eclipse, xmloutput or bzr, or even just a wrongly encoded filename on disk
<RenatoSilva> lifeless: yeah, it could be a bug in many places hehe
<RenatoSilva> lifeless: the file is created by > as latin-1, which is covered by cp1252 afaik
<RenatoSilva> lifeless: there no workaround to do, unless there is a way to make an _actual_ encoding conversion
<RenatoSilva> * there is
<RenatoSilva> WorkingTree.id2abspath is returning an unicode string from a non-utf-8 encoding
<RenatoSilva> the terminal expects to receive a cp850 output, and treats it as that, then put that in file
<RenatoSilva> well, actually it is cp850
#bzr 2009-07-03
 * RenatoSilva is very confused
<lifeless> the terminal should encode the unicode string to your code page
<thumper> Yay pipelines (bzr-pipeline) they rock!
 * LarstiQ wonders what they are
<lifeless> poolie: call?
<lifeless> LarstiQ: topgit for bzr; no versioning of the structure, its wysiwyg, and uses regular branch objects
<thumper> LarstiQ: I'll be blogging about them soon
<poolie> um
<LarstiQ> lifeless: stgit:topgit :: looms:pipelines?
<LarstiQ> thumper: cool
<lifeless> LarstiQ: I haven't reviewed how they would work for e.g. ubuntu packages, but certainly should be nice and easier for local patch creation
<thumper> LarstiQ: so look out in planet bzr :)
<lifeless> LarstiQ: yes
<thumper> LarstiQ: hopefully today, but if not, the weekend
 * LarstiQ might have a look at them, now that the regular conference part of EuroPython is done
<LarstiQ> (tomorrow/weekend)
<poolie> lifeless: sure, give me a call
<RenatoSilva> bug 394943
<ubottu> Launchpad bug 394943 in bzr "Wrong chars in bzr xmloutput > file" [Undecided,New] https://launchpad.net/bugs/394943
<igc> morning all
<LarstiQ> morning ian
<mthaddon> I just tried upgrading bzr to 1.16 per https://edge.launchpad.net/~bzr/+archive/ppa and now I get "bzr: ERROR: The API for "<module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'>" is not compatible with "(1, 13, 0)". It supports versions "(1, 15, 0)" to "(1, 16, 1)"." on a bzr branch operation
<mthaddon> anyone have any ideas?
<Peng_> mthaddon: Yes. Upgrade whichever plugin is whining about it.
<mthaddon> that's the only output - I don't know what plugin it's whining about
<Peng_> mthaddon: Yeah, I know. There *might* be a traceback in ~/.bzr.log
<a_c_m> can you change your parent branch -- switch doesnt seem to do it ?
<mthaddon> http://pastebin.ubuntu.com/208656/ is the traceback (I think)
<lifeless> mthaddon: bzr-gtk likely
<mthaddon> lifeless: I don't have that installed
<james_w> mthaddon: bzr-svn
<lifeless> oh, traceback - bzr-svn
<mthaddon> thx, that did it!
<lifeless> mathrick: re Integration - whats confusing?
<mathrick> lifeless: you present a bunch of different options, but you don't explain in which the integration happens. And then there's "For projects that do 'releases', the contents of a series could be much more mutable with no ill effects." which I completely fail to get
<poolie> lifeless: just to check i understood, did you say last night that spiv would necessarily need to fix bug 368921 as part of his current work?
<ubottu> Launchpad bug 368921 in bzr "rich root upgrade adds inconsistent parents/rich root parents are not evaluated correctly." [Critical,Triaged] https://launchpad.net/bugs/368921
<lifeless> yes, and he has already
<lifeless> its in his branch
<lifeless> mathrick: so the integration section is largely definitional
<lifeless> mathrick: projects that branch off for each release, like bzr does, can do history edits outside of releases without affecting the ability to do archaeology across releases
<mathrick> lifeless: humm, I'm afraid I still don't see what the integration is defined as. Is that the process of accumulating the code in branches? Or carving out a single 'release' out of them? (But then, why do you mention those that never do 'releases')
<lifeless> its the process of integrating code from developers
<lifeless> getting code from my branch to bzr.dev is integration
<mathrick> ah
<lifeless> if, for instance, we rebased integration it wouldn't affect bzr 1.16 at all
<lifeless> s/integration/bzr.dev
<mathrick> right
<mathrick> although it'd introduce certain confusion potentially
<lifeless> right
<lifeless> but we could do a history-preserving edit to cleanup something in bzr.dev much more safely than doing it to 1.16
<lifeless> because bzr.dev has no releases
<mathrick> lifeless: to be precise, history-preserving is defined as "trees will still merge properly afterwards"?
<lifeless> yes
<mathrick> and what kind of edits can you do where that holds?
<mathrick> I thought bzr only had the notion of complete states, so any change whatsoever morphs the state into something new and incompatible, no?
<lifeless> so a history preserving edit is broadly a new commit that refers to the old one in some way
<lifeless> e.g. as a parent
<lifeless> or perhaps we can add some other annotations
<mathrick> ah, this way
<mathrick> so you mean alter the presentation, but not the contents
<lifeless> yes
<lifeless> FSVO yes
<lifeless> the manifesto tried to capture goals and motivations, not implementations
<mathrick> sure, I'm just trying to see what you had and hadn't in mind
<lifeless> I wanted to try and get a cohesive view of /why/, so that when people talk about how, they don't need to debate merits of motivation
<lifeless> without a rationale that supports e.g. rebase, history discarding edits are very contentious
<lifeless> I didn't have particular implementations in mind
<mathrick> right
<RenatoSilva> join #python
<RenatoSilva> join #python
 * igc lunch
<amanica> how do I resubmit a merge-proposal of a branch on launchpad?
<amanica> (I commited more stuff as per review, but I don't know how to get the diff to update)
<Peng_> Euhhh. People do it all the time, but i have no clue how.
<amanica> https://code.edge.launchpad.net/~amanica/bzr/mv_after/+merge/6733
<Peng_> Maybe what you do is use https://code.edge.launchpad.net/~amanica/bzr/mv_after/+register-merge again.
<Peng_> I really don't know.
<Peng_> I've seen people do it, but I don't know how.
<amanica> I tried
<amanica> but it wont allow me
<amanica> it sais the branch already has a merge proposal
<amanica> thanks in any case
<Peng_> Can you change the status of the current proposal to superseded and then do it?
<Peng_> I'm really just guessin' here.
<amanica> I looksee
<amanica> I'll just add a comment for now, maybe one of the subscribers will be able to help me. thx again for trying.
<amanica> anyways, need to get an hour or two of sleep now before I have to go to work. goodnight/goodmorning.
 * spiv -> lunch
<sidnei> ooooh
<sidnei> vila, jam: ping?
<poolie> sidnei: hi
<poolie> sidnei: you know vila's been working on a buildbot too?
<sidnei> poolie: hey, i was heading to bed and heard a bit :)
<poolie> he should be here soon
<sidnei> beep even
<poolie> well
<poolie> by all means sleep
<sidnei> poolie: i saw a mention somewhere, but thought it was for something else
<poolie> is it 2am there?
<sidnei> poolie: yep
<sidnei> poolie: anyway, the client part is setup on kerguelen, we just need to find a proper master.
<sidnei> poolie: mine is running off a nokia n810 :)
<poolie> full points for style
<sidnei> hehe
<sidnei> alright, have a good erm... day :)
 * sidnei hits bed
<sidnei> poolie: maybe fwd my message to vila, and i will sync up with him
<poolie> night
<poolie> lifeless: just remembered, did you file an rt re tmpfs for pqm?
<lifeless> poolie: no, got sidelined, sorry. Doing now.
<poolie> np
<poolie> i just wanted the number
<poolie> it's not urgent
<lifeless> actually
<lifeless>  I can't
<lifeless> evolution crashes when I click to change the 'from' address for mail.
<poolie> :)
<lifeless> \o/ karmic
<lifeless> could you file it please?
<poolie> i don't believe in evolution :)
<poolie> sure
<lifeless> poolie: popping out quickly, need to catch the bank before they close
<poolie> np
<RAOF> lifeless: Yeah, that's everyone's favourite Karmic GTK bug, I believe.
<lifeless> RAOF: hmm, maybe I should take the time to fix it :P
<lifeless> RAOF: is there a smaller test case than evo?
<RAOF> lifeless: Pretty much every GTK app will do something like that _eventually_.  Evo seems to be the best at reproducing the particular phase of the moon required, though.
<lifeless> evo is fantastic at it
<lifeless> btw, turn up anytime
<RAOF> lifeless: Hm.  It seems my laptop wants me to go now :)
<RAOF> I was planning to get to the station at about 6ish; if I should be there earlier, I can do so.
<lifeless> I live close by
<lifeless> you can couch camp till its time to go
<RAOF> OK.  I'll check that my phone has absorbed sufficient electrons for the evening and depart.
<vila> hi all
<igc> hi vila
<vila> hi Ian
 * vila shudders... At least the sound is back in my VM !
<vila> Is there some reviewer around for https://code.launchpad.net/~vila/bzr/394190-osx-test-failures/+merge/8138 ?
<vila> Whoever you are, I'll be grateful :-)
 * igc heads off for a week of well deserved (in his opinion) vacation
<igc> see everyone in a week's time
<poolie> vila, i might do that
<vila> poolie: that will allow me to reach a significant milestone for by build farm: having all instances fully pass the whole test suite. From there we can decide about the next step.
<jml> who wants to review a small UI brancH?
<jml> https://code.edge.launchpad.net/~jml/bzr/verbose-lp-login-bug-217031/+merge/8172
<jml> bzr branch bzr://truth.local/bzr.dev
<vila> jml: reading it right now
<jml> vila, thanks.
<vila> jml: I don't think 'jml' is meta enough to be used in tests, other than that: approve :D
<jml> vila, thanks. will fix, add a NEWS entry & submit
<vila> jml: oops, it was a joke ! Feel free to use whatever you see fit, it's refreshing to work with jml instead foo, bar, joe@example.com
<jml> vila, hah. it's too late now :)
<vila> jml: on the other hand, since it's your real handle, that may be risky if some leak occurs for an obscure reason, but that's a bit paranoiac :)
<vila> jml: Now that I think about it, I should re-read these tests more carefully, maybe you're trying to take over every user that is running the test suite...
<jml> haha
<jml> next step: make bzr use launchpadlib
<Kinnison> Is launchpadlib packaged nicely?
<jml> Kinnison, I think it's in ubuntu & I think PyPI as well
<jml> so... I'm thinking that lp-login should do the launchpadlib oauth authentication
<bialix> perhaps I'
<bialix> perhaps I'm missing something: does merge requests in bzr ML still supported?
<bialix> or should I push my fix to LP as mandatory step?
<bialix> vila: hi?
<spiv> bialix: they're still supported AFAIK
<bialix> ok
<bialix> it's just BB is often down
<jml> semslie, bzr ls -VR --kind=file --null | xargs -0 grep -In %s
<jml> bialix, you can 'bzr send' to LP
<jml> bialix, it'll create the branch for you.
<bialix> jml: I can *send* to LP?
<bialix> how?
<jml> bialix, merge@code.launchpad.net
<jml> bialix, I think detailed instructions are on help.launchpad.net/Code
<bialix> there is nothing about sending
<amanica> Peng: I figured out how to resubmit in launchpad: just click on the merge proposal status and change it to resubmit
<bialix> amanica: hi, how are you?
<amanica> hi bialix, I'm great, and you?
<amanica> long time no see
<bialix> I'm fine, planning vacation
<amanica> ah, I'm still recovering from mine :)
<bialix> :-)
<amanica> where are you going?
<amanica> South Africa perhaps?
<bialix> IIUC there is winter, right?
<bialix> :-)
<amanica> yes, but it doesn't snow here
<amanica> not much anyways
<bialix> although here is too hot, but I'd like to go to the sea with family
<amanica> ah ok, enjoy
<bialix> :-)
<jml> bialix, https://help.launchpad.net/Code/Review
<bialix> did you saw new Bazaar Explorer?
<amanica> I still need to try it out - too many things on my todolist, but I'm very exited about BE
<bialix> jml: there is certainly some black magic under the hood, how I should specify project?
<amanica> I'ms tutorial with pictures looks very nice
<amanica> /I'ms/Ians/
<bialix> jml: I suspect it still require to have the branch on LP beforehand
<bialix> it's not problem per se though
<jml> bialix, well, the trunk branch needs to be on Launchpad
<bialix> amanica: and you can translate it to Afrikaans ;-)
<jml> bialix, if the public url of the submit branch is known to Launchpad, Launchpad will use the project of that branch
<jml> bialix, lots of awesome magic.
<bialix> jml: ok, will try
<amanica> bialix:  I thought about that, but then I think its not that important for Afrikaans-speaking people since our English is generally good
<bialix> I know, it was joke
<amanica> especially for programmers, since our work is mostly english
<bialix> ok ok
<bialix> :-)
<amanica> :-)
 * bialix bbl
<jml> poolie, you around?
<Peng_> amanica: Ah, thanks. :)
<amanica> Peng_: cool, I'm glad I found it
<vila> bialix: hi !
<bialix> vila: hi
<bialix> does jam will be here?
<vila> I second jml, it's not mandatory, but we now prefer merge proposals on LP
<vila> bialix: nope
<bialix> should I re-send my patch?
<bialix> can I persuade you to review patch for set_hidden_attr?
<vila> I will be better yes, can you add a  test ?
<bialix> test for what?
<vila> One that really handle a path *under* the directory, the one you have it handling the directory itself,
<vila> certainly fine, but no harm in adding one that is described in the comment :)
<bialix> ok
<vila> I will leave jam approve and land it though as I'm a bit hesitant to land a patch that I can't test myself (yes, yes, setting up a windows VM is still on the list :-/)
<bialix> oho! you really surprise me!
<vila> bialix: about what ? Nor approving or not having a windows dev VM set up ?
<bialix> about your intent to setup windows VM
 * bialix tries to send to LP
<vila> bialix: I had one in my previous life, but for perl-based dev, I never found the time since to set up one for python (but I briefly used bzr on windows at one point)
<vila> I feel a vergence in the force... is jelmer starting to work on releasing bzr-gtk ? :-)
<fullermd> No, that was just me...   I had beans for lunch.
 * bialix found bug in bzr send @ win32
<bialix> what is 'vergence'?
<jelmer> vila, :-)
<vila> jelmer: if not and I can help to, lpease ask
<jelmer> vila, first step is to clear up all bug reports, hopefully a release after that
<vila> bialix: no idea, I'm repeating what I heard in Star Wars ;-D
<vila> awesome
<fullermd> I don't think it's actually a word, at least in any sense like it was used there.
 * bialix never seen Star Wars in English
<vila> fullermd: your use or Obi-Wan use ?
<fullermd> I think it springs from the Star Wars Rule; if it {looks,sounds,tastes} cool, it doesn't matter if it's imaginary or impossible, it's in.
<bialix> vila: ha-ha, got it!
<bialix> "I feel vergence in the force"
<bialix> LOL
<bialix> after translating it to Russian I can see your joke
<bialix> :-D
<vila> bialix: the context in Star Wars was that something was happening, but nobody knows how it will turn out in the end
<vila> bialix: and of course paranormal powers are absolutely required for such predictions
<bialix> I've always thought they talked about Power or Force (see capitalization), but it seems it's just force :-(
<bialix> rats! bzr can't see my default e-mail client. something broken
<bialix> again
<bialix> ha ha
<bialix> I can't send merge request to LP
<bialix> it says: All emails to merge@code.launchpad.net must be signed with your OpenPGP key.
<bialix> very nice, I don't have one right now
<bialix> heh
<vila> rats :-/
<vila> bialix: you know that lp created stacked branches now though, did you try bzr push lp:~bialix/... recently ?
<bialix> old good push should help me
<bialix> I have good channel right now, so I'm pushing
<vila> ok
<bialix> but I'm just wanna see magic
 * bialix cries
 * fullermd pulls a rabbit out of vila.
<bialix> the branch pushed but not scanned yet
<fullermd> Voila!
<bialix> interesting, can I make merge request regardless?
<vila> bialix: it usually takes a few seconds, minutes at worst
<vila> bialix: by the way, the push was quick, you *do* have a good connection right now :0D
<bialix> I did it! https://code.launchpad.net/~bialix/bzr/hidden_attr_on_unicode/+merge/8181
<bialix> but send to ML was very nice thing
<vila> bialix: want a cute one, try: 'bzr push ; bzr lp-open' :-D
<vila> bialix: You can also request another review from jameinel from the URL above
<bialix> C:\work\Bazaar\bzr-repo\hidden_dot_bzr_unicode>bzr lp-open lp:~bialix/bzr/hidden_attr_on_unicode
<bialix> Opening https://code.edge.launchpad.net/~bialix/bzr/hidden_attr_on_unicode in web browser
<bialix> bzr: ERROR: No module named webbrowser
<bialix> You may need to install this Python library separately.
<bialix> :-P
<bialix> jml: why lp-open tries to open edge???
<bialix> it's not fair!
<vila> bialix: because, Yes You Can :)
<vila> I thought webbrowser was part of the standard python library, are you using bzr.exe ?
<bialix> what is Review type?
<bialix> of course I'm using bzr.exe
<bialix> vila: new test is OK for you?
<vila> bialix: then file a bug against bzr.exe for not including a standard package used by a standard plugin :-D
<bialix> it should be there, hmmm... another regression?
<vila> bialix: yup
<vila> bialix: it's imported lazily, could that explain it ?
<bialix> yes
<vila> hmm, tricky
<bialix> yes
<bialix> hm, does default e-mail client is editor?
<vila> jelmer: can you update me about https://bugs.edge.launchpad.net/bzr/+bug/107169 ? Is it fixed upstream ? How ? Will it find its way in jaunty (since I hit it once after every reboot) ? Didn't Silvester had a work-around (swallowing the exception ?) ? Etc ? :D
<ubottu> Ubuntu bug 107169 in bzr-gtk "Failed to execute dbus-launch to autolaunch D-Bus session" [Medium,Triaged]
<jml> bialix, because it uses the edge xmlrpc service, because xmlrpclib handles redirects badly
<bialix> I don't understand
<jml> bialix, it gets the url from launchpad
<jml> bialix, but it gets it from _edge_ launchpad
<jml> bialix, so it's an edge url
<bialix> non-edge lp can't do this?
<jml> bialix, it can, but it will try to redirect anyone in launchpad-beta-testers
<bialix> ok, it's too complex for me.
<vila> bialix: are you a launchpad-beta-testers member ?
<bialix> no
<vila> ha, it's a bug then :)
<bialix> in me?
<vila> bialix: that too :-)
<bialix> :-P
<vila> no in lp, if you're not part of l-b-t, you shouldn't be redirected to edge, jml ? Am I correct ?
<jml> vila, you're half right.
<jml> vila, if you are not l-b-t, you are not redirected to edge
<jml> but that's not what's happening here
<jml> the bzr plugin has made a conscious decision to use edge
<jml> because if we don't use edge, then people who are members of l-b-t get terrible errors
<jml> because _some_ Python standard libraries don't support redirects.
<jml> ZOMG it wasn't 200 it must be an error
<vila> jml: ZOMG :) This one can be read in french as is :-D
<jml> heh
<jml> does l'AcadÃ©mie FranÃ§aise know about that?
<vila> jml: pfff ;-P We have what we have and we do what we can with it :) whwwhawdwecwi sounds like mwhahahaha to me...
<vila> I always Quebecers were better are defending French, but I was recently told I was wrong...
<vila> I always thought Quebecers were better are defending French, but I was recently told I was wrong...
<vila> L'AcadÃ©mie FranÃ§aise is good about defending herself though
<jml> heh
<vila> It's not that I don't like French, I like it very much thank you, but some of translations of words that never existed even in english are just a bit too much for my taste. Some are very nice at capturing the true meaning of the new word, but they are the exceptions. Some are just stupid like mel for mail which is just English with a strange accent ;-)
<vila> dÃ©verminateur for debuger never made it for me, I was already a addicted bug hunter when they coined it though...
<jml> heh
<vila> For a good translation, I quite like ordinateur better than computer, but both are a bit out-dated now...
<bialix> vila: can you run `bzr selftest -s bt.test_win32utils` on Linux? with LANG=C? please? s'il vous plait?
<bialix> (for my patch)
<pilky> anyone know what time zone martin pool is in, just wondering when he'd be on IRC
<jml> pilky, Sydney.
<pilky> ok thanks
<vila> bialix: ha, *with* your patch ? WIthout it gives: http://paste.ubuntu.com/209036/
<vila> rats, storm here, need to close windows
<sidnei> hey vila!
<pilky> a rat storm?
<bialix> on Linux
<vila> bialix: oh come on :-) In my appartment :)
<vila> sidnei: Hey ! My word, what is your TZ ?
<sidnei> vila: GMT-3
<bialix> jam is right, but I think I need to check OS rather than Unicode
<pilky> sidnei: -3? Is that Iceland?
<vila> sidnei: oh, cool
<sidnei> brazil actually
<AfC1> lots of rat storms
<vila> hmm, I feel like missing a joke about rats and storms, can someone kindly explain ? :-}
<pilky> oh, I thought -3 was mid atlantic, ah well
<pilky> "vila: rats, storm here, need to close windows"
<AfC1> otherwise the rats will get in
<sidnei> vila: so what can you tell me about your effort with buildbot?
<vila> LOL, I thought 'rats' was kind of metasyntactic curse :)
<vila> sidnei: anything you want to know :-)
<bialix> vila: can I use TestSkipped or I should introduce OSWindowsFeature to skiup windows-specific tests?
<sidnei> vila: what's the plan, basically. i know nothing about it ;)
<vila> bialix: Using a feature is better so you get the number of tests skipped in the summary after a selftest run
<vila> sidnei: did you see my mail from a couple of hours ago ?
<bialix> vila: they'are already there: http://paste.ubuntu.com/209036/
<sidnei> vila: maybe not, checking again
<vila> bialix: then reuse it or define a new one
<vila> bialix: let me have a closer look
<bialix> vila: reuse TestSkipped?
<vila> bialix: no, the features, circa line 58 in test_win32utils.py
<bialix> there is no required module
<bialix> even if win32file is not available, the code still works
<vila> bialix: then look at bzrlib.test.Feature definition class and all classes that derive from it
<bialix> let's say another time: does OS Windows is feature?
<vila> bialix: if win32file is not available then I think jam remark is appropriate, use self.requireFeature(tests.UnicodexxxxFeature)
<bialix> I can't find one
<vila> I don't think OS windows is a feature (no pun intended :-D)
 * vila is such a liar
<vila> bialix: one sec
<vila> bialix: bah, you even have two ! UnicodeFilename and UnicodeFilenameFeature
<bialix> hm
<bialix> ok, from the name it seems I need the latter
<vila> right, UnicodeFilenameFeature is the one to be used, the former sounds like dirt to me
<bialix> ok, I've fixed this. pushed on LP. jam already approved.
<sidnei> vila: so you have a buildbot master setup yet?
<bialix> vila: do you have the power to merge it, oh great master?
<vila> sidnei: yes, on jaunty, with three slaves: jaunty, OSX tiger, OSX Leopard
<vila> bialix: since jam approved, yes, did you update your branch ?
<sidnei> vila: so can we point the buildbot client on kerguelen to it?
<bialix> revno.4509
<vila> sidnei: if you set up a slave to run the tests certainly
<bialix> vila: yes, LP already got it
<sidnei> vila: i've got it ready for building the installer, tests would be next step
<vila> sidnei: hmm, I'm not sure I understand the logic here, my master ask the slaves to run the tests, not to build an installer
<sidnei> vila: i guess you don't understand the master then :)
<bialix> sidnei: is that you made zc.build patch?
<sidnei> vila: you can configure the master to build many projects
<sidnei> bialix: yes
<vila> sidnei: ha, then I miss that part
<bialix> sidnei: what the goal?
<vila> sidnei: and associate only some slaves to some builders ?
<sidnei> vila: so, in buildbot terms, you can have many 'builders', those are the different projects. and each 'builder' can have many slaves
<sidnei> vila: exactly
<vila> oh great
<vila> so you mean I will be able to ask kerguelen whatever I want in addition to building the windows installers ?
<sidnei> vila: correct
<vila> woohoo
<sidnei> bialix: automate fetching the build dependencies for the installer.
<bialix> and?
<vila> bialix: automate running the test suite against bzr.dev once a day and collect the results
<vila> bialix: kerguelen is a windows machine in case you didn't notice
<bialix> vila: I know
<vila> bialix: do I surprise you again ? :-D
<bialix> I don't understand why for "automate fetching the build dependencies for the installer." is needed? It's not target per se but mean. Yes? What's the target?
<bialix> vila: no :-P
<bialix> I was aware about kerguelen
<bialix> this name is pun
<sidnei> bialix: and there's a ton of dependencies scattered all over the place. you could have a plain python script or even a .bat file to fetch the dependencies, but using zc.buildout there are existing dedicated recipes for doing things like 'download this zip file and unpack in directory X' and 'checkout branch Z from this url'
<vila> bialix: looking at your patch in context: self.requireFeature() perfect: http://paste.ubuntu.com/209051/
<bialix> vila: thanks
<vila> sidnei: do you know if the zope license is compatible with the GPL  ?
<bialix> sidnei: are you aware about Bug 388790
<ubottu> Launchpad bug 388790 in bzr "problems with bzr.exe vs Python-based installers" [Medium,Confirmed] https://launchpad.net/bugs/388790
<bialix> sidnei: if you can solve python-vased install with your zc.build patch this will be Great Target. No?
<vila> bialix: does your patch fixes #335362 or is it only a partial fix (i.e. should I --fixes lp:335362)
<sidnei> vila: im almost sure it is, but why the question? there's no ZPL code there
<vila> sidnei: I think the file you added is under zope license
<bialix> vila: not really
<sidnei> vila: ah, bootstrap.py might be
<vila> sidnei: yes maybe that one
<bialix> vila: it was discovered by Naoki while discussing that bug.
<vila> bialix: of so, no --fixes
<sidnei> vila: http://www.zope.org/Resources/ZPL
<bialix> I prefer no fixes
<sidnei> "This license has been certified as open source. It has also been designated as GPL compatible by the Free Software Foundation (FSF)."
<vila> sidnei: great
<sidnei> bialix: i wasn't aware of that bug. in fact, im not supposed to be working on the installers per se, only automating the build.
<bialix> automating for what or for who?
<vila> bialix: -m '(bialix) Setting hidden attribute on win32 should never fail (and OS locks must die, but I diverge).' ok ?
<bialix> perfect!!!
<bialix> :-D :-D :-D
<sidnei> bialix: having a buildbot that builds each installer every day, so that it requires no manual intervention other than telling buildbot when new versions are released.
<bialix> sidnei: so, it can/should be used instead of build_release.py?
<vila> bialix: naaaah, they will die, no need for that :)
<bialix> rats!
<vila> sidnei: so what needs to happen ? You send me your master.cfg file and I send you my build master host/port address ?
<vila> sidnei: and you nokia can take some rest ? :0D
<sidnei> bialix: supposedly yes. to make it clear, build_release.py expects you to manually get all the bits and pieces like the svn dev binaries and tortoiseoverlays. the new stuff fetches the svn dev binaries and tortoise overlays and all the different bzr branches of the plugins for you, then there's a 'build-installer.bat' that does just the core of what build_release.py does.
<sidnei> vila: correct, that's the plan.
<vila> sidnei: ok
<sidnei> vila: if you can put *your* master.cfg on a branch, and then i send you a merge proposal, that would be perfect actually
<sidnei> vila: i like that idea of keeping the passwords external to it though
<sidnei> vila: so we should do that
<vila> sidnei: ok, I let you know as soon as it is done
<bialix> sidnei: one suggestion then: can you start the process from root dir, will be nice as `make xxx` and put all installers there?
<sidnei> bialix: sounds good to me
<sidnei> bialix: i will do that
<jml> Python 2.6.2+ (release26-maint, Jun 19 2009, 15:16:33)
<jml> [GCC 4.4.0] on linux2
<jml> Type "help", "copyright", "credits" or "license" for more information.
<jml> >>> from bzrlib.transport import get_transport
<jml> >>> t = get_transport('bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk')
<jml> >>> t.base
<jml> 'bzr+ssh://bazaar.launchpad.net/%7Ebzr/bzr/trunk/'
<jml> >>>
<LarstiQ> right
<jml> what the hell is escaping the tilde
<vila> jml: damn ! It's not as if noone landed a patch to avoid precisely that ! :-)
<sidnei> bialix: so where the installers should be put? at the root dir?
<jml> vila, :)
<bialix> sidnei: it will be nice, though the last word should be from jam
<sidnei> bialix: ok, thanks!
<bialix> sidnei: from the rule: don't break what is working today
<sidnei> bialix: yeah, i tried to avoid that as much as possible, hopefully it will be fine.
 * mgedmin sighs
 * bialix sighs
<LarstiQ> mgedmin: can I help you?
 * mgedmin doesn't know
<mgedmin> do you know why in jaunty I cannot use bzr viz?
<mgedmin> I get an internal error
<mgedmin> I have no plugins in ~/.bazaar
<LarstiQ> bzr-gtk and bzr are both from jaunty?
<mgedmin> are there plugins in jaunty that are incompatible with bzr in jaunty?
<mgedmin> yes they are
<mgedmin> no PPAs
<LarstiQ> mgedmin: I would hope not
<mgedmin> bzr 1.13.1-1, bzr-gtk 0.95.0+bzr629-1ubuntu1
<mgedmin> the error is ... gone!
 * LarstiQ blinks
<mgedmin> it was DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 0
<mgedmin> I hadn't thought to simply re-run the command again
<LarstiQ> ah
<mgedmin> should I file a bug?
<LarstiQ> that sounds like a bzr-dbus thing
<LarstiQ> mgedmin: hmm, maybe check if there is already one
<jelmer> mgedmin, IIRC this was a seahorse bug
<jelmer> mgedmin, the first time seahorse is contacted over dbus it breaks and doesn't reply
<mgedmin> seahorse.py is in the traceback, yep
<mgedmin> I'm at a sprint and we'll be kicked away from here in 30 minutes, so I don't have time to search launchpad for bugs now
<mgedmin> but thanks for the explanation
<mgedmin> hey, actually my working dir is clean and I won't have time to start a new task
<mgedmin> oh no, I closed the terminal with the traceback
<vila> mgedmin: try again, for me that bug happens only once after each reboot
<mgedmin> I'm most definitely not going to reboot just to reproduce a bug, sorry
<mgedmin> reboots in ubuntu *suck*
<dash> huh. more than in something else?
<dash> oh he left
<dash> so i guess i can't tell him about http://www.ksplice.com/
<vila> dash: LOL
<vila> Well my point was to give him the work-around not asking to reproduce :)
<johnskulski> I am working with a svn repository that I bzr branched. So when I merge changes, commit and push all the commits come from me and not the people who actually committed. Is there a work flow around this?
<Peng_> lifeless: Ya know, lp:bzr-guess is branch 6, even though it uses a 2a repo. :D
 * SamB still doesn't understand what the --incremental option to svn-import does
<Peng_> SamB: If 'bzr svn-import' was 'bzr branch', 'bzr svn-import --incremental' would be its 'bzr pull'.
<SamB> hmm. so why doesn't the help for svn-import say anything to that effect?
<Peng_> SamB: I dunno. Maybe I'm wrong, eh? :D
<SamB> and why not make it the default?
<Peng_> SamB: I dunno. Ask jelmer.
<SamB> hmm, I'm pasting this IRC conversation into a bug, okay?
<Peng_> Okay.
<SamB> thanks ;-)
<Peng_> Seconds after I installed bzr-guess, I typed "bzr missung", and it worked. :)
<SamB> hmm, too bad that john dude left :-(
<SamB> Peng_: okay, it's bug 395266
<ubottu> Launchpad bug 395266 in bzr-svn "svn-import --incremental not clearly documented" [Undecided,New] https://launchpad.net/bugs/395266
<Peng_> SamB: Yeah, I just saw the bugmail. :D
<SamB> Peng: ah.
<SamB> didn't know who all was on the team or whatever
<SamB> hmm, should I have used your real name instead of your IRC nick?
<Peng_> SamB: I'm not, but I subscribe to a lot of bugmail.
<Peng_> SamB: Eh, doesn't matte.r
 * Peng_ gets killed by ghosts.
<Peng_> How do you find if a certain revision ID exists in a repo, without knowing the specific branch?
<SamB> oh, that reminds me
<SamB> I need to complain about bzr-gtk not supporting visualization of entire repositories, or at least of all branches that can be found within them
<Peng_> Oh, never mind, I had just messed something up.
<gioele> SamB: use "bzr explore" (from the Bazaar Explorer plugin)
<SamB> doesn't that need qbzr?
<gioele> SamB: yes it does
 * SamB checks if he has that, and if not why not
<gioele> SamB: there is a PPA for latest qbzr
<SamB> hmm, reason seems to be that it pulls in 65 megabytes of qt4-related dependencies
<SamB> stupid gigantic python-qt4 package :-(
<Peng_> See? 640k and the CLI should be enough for everyone. :D
<gioele> SamB: ask the python-qt4 packagers to split the package into qt4-like sub-modules
<SamB> you think they'd listen?
<SamB> the libc maintainer was really not keen on splitting the debug info into multiple packages -- not even a seperate one for x86_64 :-(
<gioele> SamB: well, libqt4 packages are split in Ubuntu
<SamB> libqt4 packages themselves are split here, too
<Peng_> What the... How can pulling a bunch of branches from one repo to another leave the new repo with more revisions than the old one? Especially when I left out one branch?
<Peng_> Oh, it's cuz I'm a moron and confused which repo was which. :D
<jh> hi, I have an outdated local repository with some uncommitted changes. now I want to pull a new copy from the global repository. but with "bzr pull --overwrite" I encounter several conflicts... how is that possible?
<Peng_> jh: I guess your uncommitted changes conflict with some upstream changes?
<jh> but I said --overwrite
<SamB> jh: that's not what overwrite does
<jh> what does overwrite?
<jh> and what does what I want? =)
<gioele> jh:  overwrite means "ignore that I have something to merge upstream"
<SamB> what --overwrite does is it disregards whether the revision your tree is currently based on is an ancestor of the one you would be pulling in
<SamB> normally, it refuses to pull when your revision isn't an ancestor of the one to be pulled in
<jh> hm, bzr pull --overwrite + bzr revert does what I want
<SamB> I don't think you should pass --overwrite
<SamB> it doesn't do what you want, and might do something you don't want
<jh> I just want the current revision from the global repo in my working copy
<jh> ignoring everything else
<jh> how should I do that?
<gioele> bzr update?
<gioele> oops, I meant, "make it bound thatn bzr update"?
<gioele> s/thatn/then/
<jh> "make it bound"?
<gioele> bzr reconfigure --bind-to
<jh> k, thx
<jh> will try that next time
<Peng_> Isn't there a bug about Bad Things happening to the dirstate when upgrading to rich roots?
<ndurner> Hi
<fta> james_w, i have a problem with bzr-builddeb in karmic: http://paste.ubuntu.com/209269/
<james_w> fta: ouch
<fta> james_w, i have that quite often, and the tarball is always fine. dpkg-buildpackage has no problem dealing with it directly.
<fta> started a few weeks ago
<james_w> gzip: stdout: Broken pipe
<james_w> so tar is dying?
<james_w> no, clearly not
<james_w> but gzip is failing to write to it
<Peng_> I just "bzr pack"ed a 2a repo down 9 KB. Awesome! :D
<fta> james_w, as i said, the tarball file is just fine, but bzr-builddeb can't use it, for some reason. looks like a short pipe to me, one end closing too early. as it's gzip complaining, it's either tar or python
<james_w> tar I think
<fta> but tar in cli has no problem
<james_w>                 ret = subprocess.call(['tar','-C',tempdir,'-xf',tarball])
<james_w> so I don't see what is different there
<james_w> can you reproduce with something like that in a python prompt
<james_w> does it happen every time?
<Peng_> But then repacking made something else 16 KB larger. So much for that.
<Peng_> Shouldn't "bzr pack" be deterministic?
<Peng_> Or, well, uh, not changing every time you run it?
<fta> james_w, http://paste.ubuntu.com/209289/
<Peng_> Err, bytes, not KB.
<james_w> fta: I've no idea really why that would be happening
<fta> james_w, http://paste.ubuntu.com/209301/
<fta> strange, every few days, it's a different tarball. asac is also experiencing that on his side
<james_w> how do you "fix" it?
<james_w> it happens every time for that tarball once it starts?
<james_w> could you add a "v" to the command to see if that gives any clues?
<fta> i straced it, it's trying to write on a closed fd
<james_w> fta: could you pastebin the strace please?
<fta> james_w, http://paste.ubuntu.com/209340/
<james_w> so it seems to finish, and then keep trying to write more data
<james_w> it is odd
<james_w> I wonder if it could be http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009/07/02#2009-07-02-python-sigpipe
<fta> james_w, sorry, i know a lot of languages but close to nothing in python.. http://paste.ubuntu.com/209345/
<fta> i can give you the tarball if you like, it's 100% reproducible here
<james_w> you can just add preexec_fn=subprocess_setup to the original call by my reading
<james_w> otherwise that works for me
<fta> http://www.sofaraway.org/ubuntu/tmp/songbird_1.3.0~a~svn20090703r14148.orig.tar.gz
<james_w> thanks
#bzr 2009-07-04
<pltonik> hello. i was wondering if it is possible to do 'daggy fixes' using bzr?
<Pilky> poolie: you around?
<jskulski> hey all
<jskulski> i am wroking with a SVN repository that I branched with bzr-svn. I have been working succesfully, but when I bzr merge, commit, push it seems to overwrite any log of the real commit (everyone else is using svn as per normal)
<jelmer> jskulski, see the bzr-svn FAQ
<jskulski> jelmer:: thanks
<mzz> is there some way to share *uncommitted* changes with someone that's better than "bzr diff" and doesn't involve me committing them? They're incomplete/broken, so I want to avoid committing.
<Peng_> mzz: "bzr merge --uncommitted" *might* work remotely.
<Peng_> mzz: You might also be able to rig something using shelves. E.g. "bzr shelve" the changes and then rsync/scp the files over. Or something.
<mzz> Peng_: mmm, but only if the branch I'm trying to merge from is accessible remotely by the other user, so that wouldn't really work here.
<Peng_> mzz: There are probably better ideas, but I don't know them. :D
<mzz> Peng_: (perhaps other people would just commit for this case)
<mzz> if this was my own code I'd just use commit and uncommit, because I'd be pretty sure the bogus revision wouldn't "escape" after I uncommit it.
<mzz> err, if both branches were on systems I control, I mean. Or something like that.
<mzz> the goal here was to share a very incomplete change with someone else, and they found a pastebinned diff a little hard to read and apply.
<mzz> he wanted me to push the change to launchpad, but pushing a known broken branch to launchpad seemed like a bad idea.
<Peng_> mzz: Personally, I'd commit it, with a message explaining that it's half-complete and currently broken.
<Peng_> mzz: Hmm, didn't think of Launchpad. I push things to my server and kind of mirror them on LP as an afterthought. Huh.
<Peng_> mzz: Still, you could push it up in a separate branch, maybe even in +junk, with a name and/or description that explains it.
<mzz> Peng_: I actually have my own http server to push to too, just trying to work like I don't, since it may become a less convenient option in the future.
<Peng_> I hope it doesn't become less convenient. :D
<mzz> yeah, I guess a +junk branch is just the best option available and I should be less anal about only pushing commits I think work (it's actually not like I never commit broken code, I just try not to do it *intentionally* :)
<Peng_> Heh
<Peng_> Pretend you didn't notice? :D
<Peng_> (that it doesn't work)
<sohail> OK PEOPLE EMERGENCY
<sohail> just kidding
<sohail> I'm going to be away from coding headquarters and would like to code, however I need to be able to work on multiple branches
<sohail> I can clone the master branch, but then do I have to clone all the branches manually?
<sohail> I did bzr clone bzr+ssh://.../path/to/master master
<Peng_> sohail: What do you mean? You want to get copies of a bunch of branches at once, without having to run "bzr branch" 17 times?
<sohail> Peng_, I don't even know what I should be doing, branching or cloning
<sohail> and yes, I'd like to basically have exactly the same setup as I have on my desktop
<sohail> (all the branches)
<Peng_> sohail: Welll...I'd probably just use rsync.
<Peng_> sohail: There are plugins that help with this, but I can't remember their names. multi-pull is one.
<sohail> Peng_, then how would I push back, just rsync back?
<sohail> is that safe?
<Peng_> sohail: At that point, I'd use bzr pull.
<Peng_> sohail: Err, push.
<sohail> Peng_, how does it know where to push back?
<sohail> oh I'd tell it
<sohail> man this is confusing..
<Peng_> sohail: ...Didn't think of that. Yeah, you'd have to set up locations.conf or pass the location to push.
<sohail> I think my brain is not advanced enough for bzr
<sohail> oh Peng_ one more thing, I recall I was told NEVER to do bzr push on the branches because bad things happen
<sohail> so I guess I can't bzr push can I?
<Peng_> sohail: What what? when does bzr push do Bad Things?
<RenatoSilva> where can I find the source code for bzr start-xmlrpc?
<RenatoSilva> and for rpc processings in general
<RenatoSilva> one is returning <class 'xml.parsers.expat.ExpatError'>:not well-formed (invalid token): line 1, column 255
<domas> hi! Is there a way to get $Id:$ kind of things inside bzr files, apart from using 'bzr version-info' ?
<Peng_> domas: I'm not sure if it's fully supported yet, but that's one of the purposes of the content filtering stuff added starting in version 1.14.
 * domas eyes http://bazaar-vcs.org/KeywordExpansion
<domas> right
<jml> wuuu hooo
* jml changed the topic of #bzr to: Bazaar version control system | 1.16.1 released 26th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Birmingham sprint is *on*
<Peng_> I don't think I can sprint all the way to Birmingham. Even if I was in good shape, there's the ocean...
<Peng_> Sorry, bad joke.
<Peng_> Carry on.
<jml> :)
<jml> gnublade, http://pqm.bazaar-vcs.org/
<jml> 'mutter' is for general debug log, right?
<ferrouswheel> Just recently upgraded to latest bzr - now my lp repository gives "bzr: ERROR: short readline in the readvfile hunk." if I try to create a local branch - people with 1.13 (in jaunty) don't seem to be having any issues.
<ferrouswheel> Does anybody have any clue about what I should try next? Existing local repositories do the same thing, so I though a fresh branch might fix it, but doesn't seem to help :(
<jml> ferrouswheel, I'm going to search launchpad for that error message
<Peng_> I think that's been fixed now.
<Peng_> It's definitely in progress, at the very least.
<jml> https://bugs.edge.launchpad.net/bzr/+bug/360476
<ubottu> Ubuntu bug 360476 in bzr "short readline in the readvfile hunk on smb mount" [Medium,Confirmed]
<ferrouswheel> Yeah, unfortunately it's not on a smb mount... although I guess it could be a broader bug that's been named wrong.
<ferrouswheel> (unless LP use it... which I guess would be highly doubtful!)
<ferrouswheel> what's weird is that "bzr pull" works on the local repo, but "bzr update" gives the same error as branch.
<ferrouswheel> FYI, the problem I was having was due to a corruption from a not cleanly unmounted drive. :(
<Peng_> Eh. I guess I'm glad there wasn't a bug in bzr, but I hope ferrouswheel was able to recover his/her/its data.
<LarstiQ> gnublade1: bug  249919
<ubottu> Launchpad bug 249919 in bzr "should have an example of -c usage on diff" [Wishlist,Confirmed] https://launchpad.net/bugs/249919
<mgedmin> bzr-svn incompatible with google code?
<mgedmin> bzr: ERROR: subvertpy.SubversionException: ("REPORT of '/svn/!svn/bc/272': 200 OK (http://jrfonseca.googlecode.com)", 175002)
<LarstiQ> mgedmin: sometimes. google code is a funny svn server implementation
<Peng_> That's a new one for me, though.
<Peng_> 175002 is the ever helpful ERR_RA_DAV_REQUEST_FAILED.
<Peng_> fwiw
<gnublade1> LarstiQ: bug 213185
<ubottu> Launchpad bug 213185 in bzr "tag conflicts do not change exit code" [Medium,Confirmed] https://launchpad.net/bugs/213185
<mgedmin> git-svn accepts that repository, but then kills me with merge conflicts when trying to rebase later
<jelmer> mgedmin, Not sure about that one
<jelmer> mgedmin, 157002 is a generic "Request failed" return code in Subversion
<mgedmin> you can try yourself with bzr branch http://jrfonseca.googlecode.com/svn/trunk/xdot xdot-bzr
<mgedmin> or I could go to launchpad and look for bug reports...
<mgedmin> full traceback: https://bugs.launchpad.net/bzr-svn/+bug/395482
<ubottu> Ubuntu bug 395482 in bzr-svn "can't bzr branch from google code" [Undecided,New]
<jelmer> mgedmin, this looks like a problem in the google svn server
<jelmer> mgedmin, try running "svn log -r272:1 -v http://jrfonseca.googlecode.com/svn"
<jelmer> you'll see the same error
<mgedmin> fun
<mgedmin> svn log -r2 -v http://jrfonseca.googlecode.com/svn fails
<mgedmin> all other revs appear to be normal
<jelmer> the web view gives a 404 for that revision: http://code.google.com/p/jrfonseca/source/detail?r=2
 * mgedmin looks for a way to report bugs in googlecode.com, in vain
<jelmer> mgedmin, Actually, it might be a bug in the way a particular reply is handled in libsvn
<jelmer> mgedmin, so it might be worth reporting and attaching a packet trace
<jelmer> moin
<jml> jelmer, hello :)
<jelmer> jml, Hey
<jelmer> jml, How's the sprint going?
<jml> jelmer, pretty good.
<jml> jelmer, at least I'm getting stuff done that I've wanted to do for ages :)
<jml> jelmer, wish you could have made it.
<jelmer> jml: Cool, what are you working on?
<jml> jelmer, using launchpadlib in the launchpad plugin
<jelmer> jml: ah, neat
<jml> jelmer, first command implement: bzr lp-mirror
<jml> implemented, rather
<jml> now I want to do interactive commit
<jml> of course, I'm going to fix launchpad first :(
<Peng_> jml: You know there's a bzr-interactive plugin?
<jml> Peng_, yes.
<Peng_> OK :)
<LarstiQ> Peng_: it seems to consist of shelf1 files copied from bzrtools
<LarstiQ> Peng_: with a couple of bugs filed against it that would be solved if it was shelve2 based
<Peng_> I used to use hg's interactive commit plugin, as a substitute for shelves, but I've never actually done it in bzr. :D
<Peng_> Well, maybe once, but not recently.
<mgedmin> bzr push --remember refuses to change the push branch
<mgedmin> it says Value "bzr+ssh://bazaar.launchpad.net/%7Emgedmin/gtkeggdeps/trunk/" is masked by "bzr+ssh://fridge/home/mg/www/gtkeggdeps/bzr/" from locations.conf
<mgedmin> what on Earth does that mean?
<mgedmin> hm, I have a ~/.bazaar/locations.conf with interesting contents
<mgedmin> it says ##push_location:policy = norecurse
<mgedmin> without the ##, I mean
<jml> I haven't seen that one before
<mgedmin> I assume I had an unfortunate interaction with bzr-svn (since the parent dir of my bzr branch is in svn), and probably applied some workaround to make it work a long time ago
<mgedmin> and now the long-forgotten workaround is biting me
<mgedmin> is there a way to ask bzr to try to opportunistically push my changes to the parent branch after every commit?
<mgedmin> bzr bind kinda does that, but it insists too strongly
<mgedmin> I don't want the commit to fail if I'm offline
<mgedmin> and I'd like to be able to ^C if the push is too slow
<mgedmin> but have the commit committed locally without any further interaction
<LarstiQ> iirc amanica wrote something for that
<LarstiQ> can't find it right now
<jml> mgedmin, 'bzr ci && bzr push' would one way to do that.
<jml> mgedmin, but I don't think bzr has something built in.
<jelmer> jml: What does lp-mirror do?
<jml> jelmer, requests that launchpad mirror the branch now
<jelmer> ooh
<jml> jelmer, Launchpad needs a new method on its API for it to be fully useful though
<jml> jelmer, I'm writing that new method right now :) bug 395076
<ubottu> Launchpad bug 395076 in launchpad-code "API for getting a branch by URL" [High,Triaged] https://launchpad.net/bugs/395076
<jml> kfogel, hello
<kfogel> jml: hey!
<Peng_> ...I totally didn't know there was a "bzr mkdir" command.
<spiv> Peng_: me either!
<mgedmin> ouch
<mgedmin> why do you hate me so, bzr!
<mgedmin> I do bzr push lp:myproject; I do bzr bind; I edit some files; I try to commit, it tells me of a divergence and tells me to bzr up; I run bzr up and I get a conflict of some kind
<mgedmin> now I've no clue what's happening in my working dir or what to do
<mgedmin> ah, what I did was bad: bzr push remote; bzr add newfile; bzr commit; bzr bind remote; edit file; bzr commit -> divergence detected!
<mgedmin> shouldn't that bzr bind have pushed my local changes to remote?
<mgedmin> if that's a bug, I've got a typescript file demoing my problem
<LarstiQ> afaik, it shouldn't
<mgedmin> jml: do you remember what my $PWD was when you walked over to me?
<mgedmin> nm
<mgedmin> https://bugs.launchpad.net/bzr/+bug/395514 has the exact sequence of commands
<ubottu> Ubuntu bug 395514 in bzr "bzr push; bzr add; bzr ci; bzr bind; bzr ci -> weird conflict of a branch with itself" [Undecided,New]
<mgedmin> aaargh data loss
<jml> :(
<mgedmin> bzr revert --forget-merges or something else I did trying to untangle the mess resulted in that file disappearing
<mgedmin> ah, bzr revert file3.txt
<mgedmin> deleted it
<mgedmin> wtf
<mgedmin> revert means "give me what was there before"
<mgedmin> it was there before
<mgedmin> it was committed, ffs
<LarstiQ> mgedmin: you're bound now, right?
<LarstiQ> mgedmin: the revision is still in your repository
<mgedmin> at least I have the full contents (both versions) in the terminal scrollback
<mgedmin> I unbound as soon as it bit me
<LarstiQ> mgedmin: try `bzr heads --dead-only`
 * jml wonders why bzr hates mgedmin so much
<LarstiQ> then you can pull -r revid:relevantrevid
<mgedmin> because I'm impatient and don't read docs
<mgedmin> it's supposed to be intuitive and easy to use and forgiving, right? right?
<jml> mgedmin, it is.
<jml> mgedmin, ... supposed to be.
<mgedmin> and if I believed that, you'd sell me a bridge, right?
<mgedmin> nah, bazaar is fine, it just needs a few more years to mature
<mgedmin> to make a fool-proof system you need years of stress-testing by fools like yours truly
<jml> mgedmin, I think that bound branches in particular need to have more love
 * mzz is confused about what happened there
<mgedmin> mzz:  https://bugs.launchpad.net/bzr/+bug/395514 has the exact sequence of commands
<ubottu> Ubuntu bug 395514 in bzr "bzr push; bzr add; bzr ci; bzr bind; bzr ci -> weird conflict of a branch with itself" [Undecided,New]
<mzz> yeah, I was just reading that
<mzz> I would've expected it to complain when you ran that bind
<mgedmin> so would I
<mgedmin> either push or tell me that the branches aren't identical
<mgedmin> I expected it to push
<jml> mgedmin, well, I can reproduce that error locally
<mgedmin> there was https://bugs.launchpad.net/bzr/+bug/43744
<ubottu> Ubuntu bug 43744 in bzr "bzr bind should just bind, not push" [Medium,Fix released]
<mgedmin> which says that bzr bind no longer pushes, but it also talks about warning the user, which never happened
<jml> so bind should warn
<jml> and that conflict error should be a *lot* more helpful
<jml> since following the instructions can lead to data loss.
<mzz> so afaict its suggestion to run "update" is backwards
<mgedmin> I should mention that
<mzz> afaict running "bzr push ../bazaar-hates-me-again" after the "bind" makes it work
<mzz> running "bzr up" at that point is confusing at best, and "bzr push" complains about no push location being set
<mgedmin> bzr heads: unknown command "heads"
<jml> mgedmin, you need bzrtools for that
<mzz> in fact running "bzr push ../bazaar-hates-me-again" after "commit" fails (and tells you to run "update") works
<mzz> I expected doing the (failing) commit with --local and then running "bzr up" to work too, but that also gives a weird conflict.
<LarstiQ> gnublade1: https://lists.ubuntu.com/archives/bazaar/2009q3/060216.html
<Glenjamin> hi guys, i'm trying to build the latest bzr on windows - it was working before but now i'm getting errors about missing zdll
<Glenjamin> presumably there's some new dependancy i'm missing?
<Glenjamin> oh wait, i can just use the binary dist can't I >.<
<LarstiQ> Glenjamin: libz has recently become a dependancy. But yes, you can use the binary installer :)
<woeye> real men build their own binary ;)
<Glenjamin> heh, i tried!
<woeye> :D
<Glenjamin> also, what is the recommended method for installing on OS X?
<woeye> i'd go with the binary
<Glenjamin> i was hoping to play with bzr-svn and qbzr on my work computer
<woeye> Szilveszter announced some minutes ago that he released a binary for leopard
<woeye> https://launchpad.net/bzr/1.16/1.16.1
<Glenjamin> excellent
<Glenjamin> also, is there any way to get the windows installer to make a bzr.py file in the Scripts dir?
<woeye> I am currently installing bzr by using MacPorts which his horribly outdated - so I had to patch the portfiles manually
<Glenjamin> it only makes bzr and bzr.bat - but i have .py on my pathext
<Glenjamin> i tried installing bzrtools using ports, it managed to install graphviz from source including all dependencies
<woeye> yeah, but bzrtools ist out-of-date as well (1.13)
<woeye> If only those MacPort maintainers would apply my patches o.O
<Glenjamin> yeah, so after it downloaded compiled and staged about 15 dependencies, it didnt run >.<
<Glenjamin> easy_install wasnt having any of it either
<woeye> hehehe :)
<Glenjamin> also on linux i've found easy_install installs bzr and bzrtools as separate eggs, so the plugin doesnt get placed inside bzr
<LarstiQ> yes
 * LarstiQ stabs easy_install in the face
<Glenjamin> amusingly the windows install is the least painless
<Glenjamin> except on ubuntu with root i suppose
<mzz> hrm?
<mzz> setup.py build_ext -fi doesn't suffice on linux?
<Peng_> "make" is shorter. :D
<mzz> oh, sure
<Glenjamin> "setup.py install" is fine
<Glenjamin> but you have to download and unpack
<mzz> or that
<Glenjamin> because easy_install fails
<mzz> and on windows I have to download and click through the installer
<mzz> I fail to see the problem
<mzz> also, on linux you should have it packaged for $yourfavoritedistro
<Glenjamin> assuming i have root, yeah
<mzz> ah, there's that.
<Glenjamin> it'd be much easier if you didnt keep updating so often :p
<LarstiQ> Glenjamin: not that you need to install bzr to use it
<Glenjamin> time to have another go on the mac
<mzz> it runs quite acceptably as pure python straight from the tarball, just a bit slower with the extensions not built
<Peng_> 2a repos will also use more disk space without the C extensions.
<mzz> and it runs with no dependencies other than a recentish python if you don't need sftp
<mzz> ah, I didn't know about that one
<Peng_> Probably not much or anything, but some.
<Peng_> The Python version of groupcompress is limited to line-based deltas, while the C version is not.
<mzz> I hope the recent glitches with the release tarballs missing c files have been worked out then
<Glenjamin> has much work been done with the smart server since 1.10?
<Peng_> mzz: Heh.
<Peng_> Glenjamin: ...Yes.
<Peng_> Glenjamin: Define "much".
<mzz> Glenjamin: skim the release notes
<Glenjamin> will do
<Peng_> Glenjamin: ISTM a lot of the hpss changes have to do with stacking and the 2a disk format. If you're not using those, the changes are less relevant.
<Glenjamin> i had a bit of a go at getting a web interface + authentication + smart server going a while back
<Glenjamin> didnt really get anywhere
 * mzz is tempted to go with "meh, just use launchpad" for that one
 * Peng_ is happy with Loggerhead + bzr+ssh + bzr+http.
<LarstiQ> Peng_: streaming push though
<mzz> I occasionally use bzr+ssh, haven't bothered with bzr+http
<mzz> bzr+ssh is pretty neat in that it even works pretty well on windows using plink + pageant last time I tried
<Peng_> LarstiQ: Ah, good point. There are some nice new features, huh? :)
<Peng_> mzz: For a client, bzr+http needs nothing.
<mzz> yep
<Peng_> I run it on my server for fun. Mostly dogfooding, I guess.
<mzz> Peng_: I'm usually not a client, and for small branches plain http suffices
<Peng_> mzz: Especially since I use plain CGI, so the startup time diminishes the efficiency benefits.
<Peng_> Someday somebody's going to do something weird and a bzr-smart process will take out my poor little VPS. :D
<Glenjamin> gah
<Glenjamin> the whitespace decoding bug in bzrtools still hasnt been fixed :(
<Peng_> Whitespace decoding bug?
<Glenjamin> on vista the tab completion throws a unicode decode exception because string.whitespace contains a non ascii character
<Peng_> Ah, fun.
<Glenjamin> i reported it months ago, its been repreoduced by multiple people, and has a fix
<Glenjamin> oh wow, the mac installer worked perfectly
<LoRe> why is bzr transfering so much data? i've just done a pull, 4 MB were transfered, but only 3 files were updated.
<LarstiQ> LoRe: one answer could be (depending on the transport and the format), is that it needs to first read the indices to find out what to get
<LoRe> LarstiQ: ic, thanks
<LarstiQ> LoRe: you can try -Dtransport and -Dhpss for some more detail
<Glenjamin> anyone know which version of the svn development libraries i need for subvertpy? (for bzr-svn)
<jml> LarstiQ, https://bugs.edge.launchpad.net/bzr/+bug/238776
<ubottu> Ubuntu bug 238776 in bzr "Confusing error message if ssh login fails while using lp url" [High,Confirmed]
<LarstiQ> Glenjamin: the ones matching your subversion library.
<LarstiQ> Glenjamin: ideally 1.6, but 1.5 should work too
<Glenjamin> ty
<Peng_> Hell, 1.4 works...
<LarstiQ> Peng_: it does, but it is rather suboptimal
<Glenjamin> as i'm doing this
<Glenjamin> i'm stuggling to remember why i didnt just use the windows installer for the whole lot
<Peng_> LarstiQ: Well yeah.
<Glenjamin> has anyone had problems opening a transport that uses http basic auth?
<LarstiQ> Glenjamin: nafaik, can you be more specific?
<Glenjamin> auth['user'] is None gives a key error on line 1921 in the http transport lib
<Glenjamin> 1291 even
<Glenjamin> i've only reproduced it with svn so far, on mac and windows
<Glenjamin> i dont know of a bzr branch behind http auth
<LarstiQ> Glenjamin: is that a svn url I can try against?
<gnublade> jml: when you're done, got a change that could possibly benefit with a test, or should I just bang it into another email?
<Glenjamin> this particular one is VPNed i'm afaid
<jml> gnublade, another email, I think...
* jml changed the topic of #bzr to: Bazaar version control system | 1.16.1 released 26th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Birmingham sprint is gone for a real ale or two
<LarstiQ> hmmm
<LarstiQ> sorry for (temporarily) removing subvertpy from the bzr ppa
<james_w> anyone know what's going on in http://launchpadlibrarian.net/28691173/buildlog_ubuntu-karmic-i386.subvertpy_0.6.7-1~ppa1~karmic1_FAILEDTOBUILD.txt.gz ?
<LarstiQ> james_w: looking at it now
<LarstiQ> james_w: http://groups.google.com/group/nose-users/browse_thread/thread/ab603fb160cc2d9c seems relevant ("ython-nose is fully broken in ubuntu karmic alpha 2 and I'm not able
<LarstiQ> to understand why. "
<LarstiQ> james_w: or more specifically, https://bugs.edge.launchpad.net/ubuntu/+source/nose/+bug/389942
<ubottu> Ubuntu bug 389942 in nose "python-nose is broken with python 2.6.3-dev" [Undecided,New]
<LarstiQ> sigh, reporting as I go
<LarstiQ> james_w: upstream nose bug: http://code.google.com/p/python-nose/issues/detail?id=276
<LarstiQ> james_w: I'm willing to live with subvertpy not working on karmic till someone fixes nose or python itself
#bzr 2009-07-05
<RenatoSilva> where should I look for 1.16.1 source? here in https://code.launchpad.net/~bzr/bzr/1.16, or in trunk?
<LarstiQ> RenatoSilva: I'd download the 1.16.1 tarball?
<LarstiQ> maybe I don't get what you're after
<mzz> there's a "download" button on bazaar-vcs.org, the source tarball is not far from there
<RenatoSilva> LarstiQ: 1.16.1 in in 1.16 or trunk?
<RenatoSilva> mzz: oh you're here too
<mzz> or do you mean you want a bzr branch?
<RenatoSilva> mzz: I want to browse with loggerhead
 * LarstiQ blinks
<LarstiQ> okay
<RenatoSilva> someoneme must know which next version is in trunk
<LarstiQ> RenatoSilva: then the url you pasted sounds like the choice, bzr.dev/trunk has moved quite a bit since 1.16
<RenatoSilva> if 1.17 or 1.16.2
<LarstiQ> RenatoSilva: never 1.16.2
<mzz> this'd be easier if launchpad loaded
<LarstiQ> RenatoSilva: 1.16.2 will be made from the 1.16 branch, not the development focus
 * LarstiQ still doesn't get what the goal is
<RenatoSilva> LarstiQ: so anything under 1.16 will be in the 1.16 branch right?
<mzz> RenatoSilva: yes, that's what the 1.16 branch is for
<RenatoSilva> LarstiQ: the goal is browsing 1.1.6.1 source code in launchpad, that simple
<RenatoSilva> ok thanks
 * mzz wonders if loggerhead does tags
<LarstiQ> RenatoSilva: well, the 1.16 branch might have moved a little from 1.16.1, but it's the closest
<mzz> most recent commit there is "Tweak NEWS file for 1.16.1 release."
<mzz> so probably not
<RenatoSilva> LarstiQ: humm, so there's not a "static" branch for 1.16.1...
<mzz> RenatoSilva: there should be a tag, but I don't see any tags in loggerhead
<RenatoSilva> mzz: when loggerhead implement tags we'll be able to do it
<mzz> RenatoSilva: anyway, the head of the 1.16 branch should be it. Trying to confirm but it'll take a bit.
<LarstiQ> RenatoSilva: I don't think it's really useful, but I'll look around to see if there is
<RenatoSilva> LarstiQ: tags? there's not
<LarstiQ> no, a 'static' 1.16.1
<RenatoSilva> ah ok
<RenatoSilva> mzz: bug 246739
<ubottu> Launchpad bug 246739 in loggerhead "tags are not available" [Wishlist,Fix committed] https://launchpad.net/bugs/246739
<mzz> and "bzr tags -d lp:bzr/1.16" isn't working very well either
<LarstiQ> mzz: what goes wrong with that?
<mzz> LarstiQ: it takes forever
<mzz> LarstiQ: well, it grabbed a few MiB worth of data if I can trust the progress indicator, then I aborted it
<mzz> I'm just pulling the branch, but it'll take a while because of the slowness of the network partition I'm pulling it into
<LarstiQ> RenatoSilva: https://edge.launchpad.net/bzr/1.16/1.16.1 just has the release files
 * LarstiQ checks branches
<LarstiQ> but I'm pretty sure we don't do branches for point releases
<RenatoSilva> LarstiQ: where did you find this link, it's not listed in 1.16 series
<RenatoSilva> LarstiQ: ok got it, sorry
<LarstiQ> RenatoSilva: launchpad.net/bzr, click on the 1.16.1 link in the series canvas thingy
 * RenatoSilva is trying bzr tags -d lp:bzr/1.16, slow too
<RenatoSilva> is it downloading the branch or only the .bzr?
<RenatoSilva> to where?
 * mzz frowns
<LarstiQ> the branch is a subset of .bzr
<mzz> either this repo is a lot further behind than I realised or I'm doing something stupid with repository type mismatches.
 * LarstiQ looks at what cmd_tags does
<LarstiQ> a cursory glance looks like it really shouldn't be slow to get the tags
<RenatoSilva> it is in 3082KB, no progress in bar
<RenatoSilva> seems to be downloading a big stuff
<mzz> my "bzr branch" is now at revision 800/6292, and looks like it'll take a while still.
 * LarstiQ tacks on a -Dtransport
<mzz> I don't know how much of that is the bzr+ssh I'm downloading through and how much is the sshfs I'm downloading onto, but the latter is probably significant.
<mzz> I really should switch that to something faster one of these days.
<LarstiQ> mzz: why do you have things set up like this?
<LarstiQ> oh boy
<mzz> LarstiQ: I have my repositories sitting on a server on my lan. I should upgrade that to nfs instead of an sshfs though.
<mzz> (they're treeless repositories, with lightweight checkouts sitting on my local drive)
 * RenatoSilva just download the source, and found C code o.O
<LarstiQ> RenatoSilva: there are python fallbacks, so you can run in pure python
<LarstiQ> RenatoSilva: but the C (generated from pyrex) is faster for a couple of bits
<mzz> it runs well enough as pure python that it took people a bit of time before they realised the release tarballs were missing the c files (twice, iirc) :)
<RenatoSilva> LarstiQ: pyrex? you mean all the C code is entirely generated from python code??
<LarstiQ> RenatoSilva: pyrex code is not exactly pure python code. But yeah, mostly.
<LarstiQ> there used to be some pure C too though, not sure if we still have that
<RenatoSilva> ok
<LarstiQ> for the patience diff algorithm I think
<LarstiQ> RenatoSilva: see the *.pyx files
<mzz> mmm, so if I have a lightweight checkout and the thing it is bound to moves around, how do I re-bind it to the new location?
<dash> bzr bind or bzr switch
<mzz> "bzr bind newlocation" is giving me "bzr: ERROR: Not a branch: oldlocation/.bzr/branch"
<mzz> as is "bzr switch"
<dash> oh, lightweight. i'd be switch
<dash> it'd
<mzz> as is "bzr switch --force", and bind doesn't have a --force
<RenatoSilva> LarstiQ: I see.. the generated C code is crazy
<mzz> I can just edit .bzr/branch/location, but that's lame.
<james_w> LarstiQ: thanks
<RenatoSilva> mzz: I'm reading commands.py...it seems that the only encoding_type value supposed to cause an error is 'strict', but the xmloutput has no command set as 'strict'
<mzz> RenatoSilva: iirc that's what my patch changed
<LarstiQ> RenatoSilva, mzz: try tags with --show-ids
<RenatoSilva> most of them are 'replace', which is supposed to replace with '?' the problematic chars, instead it was raising an error
 * RenatoSilva just noticed the tags command finished
<LarstiQ> the slow part is the revno lookup
<mzz> LarstiQ: duh
<RenatoSilva> where does it put the downloaded files?
<LarstiQ> RenatoSilva: where does what?
<mzz> RenatoSilva: it *was* replacing them with ? when you were feeding it unicode (which was written in the wrong encoding)
 * LarstiQ is falling asleep
<mzz> RenatoSilva: it only started erroring once you started explicitly feeding it utf-8 encoded bytes
<LarstiQ> could one of you file a bug on tags doing that lookup stupidly, and assign it to me?
<RenatoSilva> LarstiQ: it seems to download a lot of files
<LarstiQ> RenatoSilva: yes but what
<LarstiQ> RenatoSilva: `bzr tags` will not put anything anywhere
<mzz> LarstiQ: later, I'm also kinda sleepy
<RenatoSilva> mzz: yes, and 'replace' should try to decode from utf-8 and encode as cp850, and when it fails it should get the problematic chars and replace them with '?', not raise the error to the user, right?
<RenatoSilva> LarstiQ: so what are those KB growing up
<LarstiQ> RenatoSilva: as I said, naive revid â revno lookup
<mzz> RenatoSilva: no. With "replace" it expects you to feed it unicode, which it'll encode as cp850. Feeding it utf-8 is unsupported and will blow up as soon as it's non-ascii.
<mzz> which it did.
<LarstiQ> RenatoSilva: try --show-ids to see the difference
 * mzz is fairly certain he understands what the commands api wants you to do here now.
<mzz> well, mostly
<RenatoSilva> LarstiQ: ok, but it seems files being downloaded, the message could be fetching revisions instead
<mzz> RenatoSilva: exactly, which is what he wants a bug filed on
<LarstiQ> RenatoSilva: fsvo files, nothing that would be in your working dir
<RenatoSilva> mzz: "replace - put in a bogus character (typically '?')"
<mzz> RenatoSilva: yep, *if* you're feeding it unicode. Once you start feeding it bytes it's free to blow up, that's not the intended use.
<LarstiQ> not bogus, and always '?', on purpose
<RenatoSilva> LarstiQ: fsvo?
<LarstiQ> RenatoSilva: for some value of
 * LarstiQ sleep now
<RenatoSilva> mzz: humm
<mzz> RenatoSilva: up until you mentioned "bzr" yesterday I was assuming your "stdout" was sys.stdout. What a non-'strict'-mode bzr command gets isn't sys.stdout.
<RenatoSilva> mzz: ?
<RenatoSilva> mzz: when I don't use > file, isn't it using sys.tdout?
<RenatoSilva> mzz: it's a file with encoding == cp850, which makes me think it's the terminal
<mzz> RenatoSilva: it's using sys.stdout wrapped in an object from the codecs module that encodes unicode before handing it to the actual sys.stdout
<RenatoSilva> mzz: it encodes to the encoding set in outf right?
<RenatoSilva> mzz: in sys.stdout I mean
<mzz> RenatoSilva: http://docs.python.org/dev/library/codecs.html#streamwriter-objects that is
<mzz> RenatoSilva: logic for finding the encoding is in bzrlib.osutils.get_terminal_encoding, which does indeed look at sys.stdout.encoding
<RenatoSilva> why do you say 'replace' expects to receive unicode objects? how can it know that certain unicode char is not supported by the target encoding? does it really know? does it really analyze each char and check against the target encoding? when I was not sending utf-8, sometimes it was sent raw cp850 to encode as cp850, and sometimes it was sending unicode (the dir path). In this last case, you mean â¡Ã was a replacement caused by by encoding_type = 'repla
<RenatoSilva> sorry for the typos
<RenatoSilva> http://pastie.org/534468 --> this description is a bit confising
<RenatoSilva> strict - abort if we cannot decode -- decode an unicode obj???
<RenatoSilva>  exact - do not encode sys.stdout -- so who will encode? because unicode chars are not actual bytes
<mzz> you weren't sending raw cp850, it would've failed the same way it did when you sent raw utf-8
<RenatoSilva> ok, always unicode
<mzz> and I was confused, my patch used 'exact', right?
<RenatoSilva> yes
<mzz> patch used exact, so it got the actual unwrapped stdout, which it then wraps using codecs.getwriter (just like bzr would do for us) *but* using utf-8 as the encoding instead of using the terminal encoding.
<RenatoSilva> I mean 'replace' should replace Ã§Ã£ with ?? not â¡Ã
<mzz> the problem was that the characters you were asking it to write *were* available in the terminal encoding (iirc cp850) but the bytes they were mapped to meant something else in whatever encoding whatever you used to view the result used.
<RenatoSilva> hummm, because N++ does not supoport cp850
<RenatoSilva> and no editor I've ever seen ...
<mzz> I don't know if it doesn't support it, but it wasn't using it when reading the file.
<mzz> and even if it did the file would be lying: the contents of the file would mention the utf-8 encoding, which it isn't actually encoded in.
<RenatoSilva> and when I send str objects when using 'replace' it will try to decode and encode again?
<RenatoSilva> decode from get_encoding?
<mzz> you read that "what every programmer must..." page you were linked to, right?
<RenatoSilva> it seems that I didn't
<mzz> that page wasn't python-specific, but it's a bit hard for me to explain this if you haven't at least skimmed that article, or are already familiar with what's described in it.
<RenatoSilva> I was linked to?
<mzz> I think you were, sec
<mzz> http://www.joelonsoftware.com/articles/Unicode.html is the one I meant
<RenatoSilva> oh I read this in the past
<RenatoSilva> Joel is boring
<RenatoSilva> but I want to read it again
<mzz> basically what's passed around inside bzr is usually python unicode objects, which are sequences of unicode codepoints
<RenatoSilva> I think my problem here is just to understand how encoding_type, unicode/str and write work together
<RenatoSilva> mzz: I think I 've got what are u''s and ''s
<RenatoSilva> mzz: and encode and decode
<RenatoSilva> mzz: I just don't get how u''/'' and encoding_type and write work together
<mzz> that article explains what code points are to some extent. Anyway, like most good bzr commands this one is passing around unicode objects, and they're *correct* (which I checked by having you print the repr of one)
<RenatoSilva> I mean, for each encoding
<RenatoSilva> sorry
<RenatoSilva> for each encoding_type x for each in (unicode, str), what is the behavior of write?
<mzz> the command layer then assumes that you're usually running commands interactively, and that most commands deal in unicode, not bytes (aka str) objects
<mzz> so unless you use a nonstandard mode the "output" you get from the commands layer wants *unicode* objects which it *encodes* to bytes using the terminal encoding (which it gets off sys.stdout.encoding or some other place)
<mzz> normally this works pretty well
<mzz> this was all bzrlib stuff. There's also a general python rule to be aware of: if you pass something a str where a unicode is needed or vice versa python implicitly converts using the ascii encoding, which means it'll blow up unless there aren't any accented or other weird characters in there.
<RenatoSilva> mzz: I think if I read the right code I will be anwered
<mzz> so if you're using this mode of the command layer you *cannot* write in a different encoding: you can convert to bytes, but then python will go and decode those back to unicode when bzr tries to helpfully encode using the terminal encoding, which you don't even want!
<RenatoSilva> if you pass something a str where a unicode is needed or vice versa python implicitly converts using the ascii encoding, which means it'll blow up unless there aren't any accented or other weird characters in there. ---> oh I didn't know that, I thought it was a bzrlib stuff!!!
<mzz> no, that's a python thing
<RenatoSilva> big news to me
<mzz> what's happening is basically '\xc3\x88'.encode('cp850') (try that one in an interactive python prompt)
<mzz> I forgot what character you were using, but let's assume it's u'\xc8' (which is an E with a ` on it). If you .encode('utf-8') that you get '\xc3\x88'. Your stdout then tried to .encode('cp850') that.
<RenatoSilva> mzz: so when I was sending cp850 bytes, python was decoding from preferred encoding (cp850), and then bzrlib was encoding again as preferred encoding (cp850)? :D
<mzz> but you can't encode '\xc3\x88': it's already a str. So python tries to convert it back to unicode using the ascii encoding.
<mzz> that's what happened when you stuck that explicit .encode('utf-8') in there, and you started getting UnicodeDecodeErrors
<mzz> what happened when you did get output, it just didn't look right in n++, was that n++ was guessing the encoding wrong
<mzz> guessing encodings is very hard (except for a few of them)
<mzz> and yes, bzr was decoding and encoding using the preferred *terminal* encoding (cp850) but you weren't actually looking at the file on the terminal.
<mzz> it *should* have shown up correctly with the output to the terminal, not a file.
<mzz> If that *also* failed python was getting the terminal encoding (sys.stdout.encoding) wrong.
<RenatoSilva> "So python tries to convert it back to unicode using the ascii encoding." ---> Hummm!!!!!!!
<mzz> all this works much better in python 3, where that implicit conversion was removed
 * mzz wantssssss it
<RenatoSilva> mzz: n++ has ANSI, UCS and UTF8, there's no cp850, and notepad.exe does not have this either
<RenatoSilva> mzz: I've heard all strings are unicode in py3k
<mzz> unsurprisingly there's still a "bytes" type (similar to the py2 "str" type), and what's called the "str" type in py 3 is similar to the "unicode" type in py 2. There's no type called "unicode" in py 3.
<mzz> more important than the name change is that those implicit conversions went away. The implicit conversions are annoying that you don't realise they're happening as long as your input is ascii (unaccented chars), and that's pretty common when you're coding in english.
<RenatoSilva> mzz: If that *also* failed python was getting the terminal encoding (sys.stdout.encoding) wrong. --> by falied you mean wrong chars in _terminal_?
<Pegasus_RPG> hello. How can I search a repo for the latest revision of a now-deleted file?
<mzz> Pegasus_RPG: there's a "heads" command in bzrtools that may be of use
<mzz> Pegasus_RPG: err, wait, I misread that
<mzz> Pegasus_RPG: the file's gone but you just need to go backwards in history to get it back, right?
<Pegasus_RPG> correct, I still want everything else to be current
<mzz> RenatoSilva: yep
<RenatoSilva> mzz:  unsurprisingly there's still a "bytes" type (similar to the py2 "str" type), and what's called the "str" type in py 3 is similar to the "unicode" type in py 2. There's no type called "unicode" in py 3.  ----> looks nice, someone cleaned the bedroom
<mzz> RenatoSilva: note that (assuming an ntfs filesystem) the filenames on disk aren't actually cp850 :)
<RenatoSilva> mzz: they're cp1252
<mzz> RenatoSilva: yep, that's what py3 is all about. py2 can't fix things like this because it tries to be backwards compatible.
<RenatoSilva> I guess
<mzz> RenatoSilva: they shouldn't be.
 * mzz looks up the on-disk encoding name
<RenatoSilva> should be what?
<Pegasus_RPG> mzz: correct, I still want everything else to be current
<RenatoSilva> mzz: a python function returns cm** or so... but I thought it just meant cp1252
<mzz> RenatoSilva: hopefully utf-16 on disk, but you shouldn't have to care about that. Try sys.getfilesystemencoding()
<mzz> Pegasus_RPG: mmm, I don't quite remember how to do that. Sec.
<RenatoSilva> mzz: sys.getfilesystemencoding() == 'mbcs'
<Pegasus_RPG> mzz: to add another wrinkle, I'm working on a branch. the file was deleted back in trunk awhile ago
<RenatoSilva> mzz: should be some MS UCS
<Pegasus_RPG> (When trunk was in svn. :) )
<mzz> Pegasus_RPG: shouldn't really matter, I think, assuming this is a bzrsvnified branch
<Pegasus_RPG> it is
<mzz> bleh, is launchpad really slow or does it just not like me?
<mzz> ah, I have an idea
<mzz> or rather the help does
<RenatoSilva> mzz: lp has been slow to me too these days
<mzz> Pegasus_RPG: can you find a revision that file existed at?
<Pegasus_RPG> I was hoping bzr could tell me :)
<mzz> Pegasus_RPG: if you do you should be able to "bzr log -rthatrevision.. -p thefile.txt"
<mzz> Pegasus_RPG: from "bzr help log": "To log a deleted file, specify a revision range so that the file existed at the end or start of the range."
<Pegasus_RPG> ok
<Pegasus_RPG> I could just give it an insane range
<mzz> yeah, exactly
<Pegasus_RPG> ok thanks
<mzz> if you give an open-ended range with one end at a spot where it exists I'd expect it to pick it up
<RenatoSilva> mzz: thank you for helping
<mzz> Pegasus_RPG: there's also a bzr-undelete thing, but launchpad won't divulge further information to me
<Pegasus_RPG> RenatoSilva: sorry for interrupting
<mzz> Pegasus_RPG: lp:bzr-undelete, not sure if it's useful or works.
<Pegasus_RPG> ok bzr log found it thanks!
<Pegasus_RPG> oop, now I need to get that file without messing up my existing checkout
<Pegasus_RPG> do I just bzr cat it to a new file?
<Pegasus_RPG> or can I preserve the history some other way?
<mzz> I don't remember if "bzr revert -rblah old/rev/filename" works, but I'd expect it to.
<mzz> "bzr help revert" says it should work.
<Pegasus_RPG> sweet it did. thanks!
<RenatoSilva> Pegasus_RPG: you did not
<RenatoSilva> Pegasus_RPG: interrupt
 * RenatoSilva 'll brb
<RenatoSilva> how to apply a single patch? it's being rejected...
 * RenatoSilva used raw patch tool
<RenatoSilva> Created new stacked branch referring to /~verterok/bzr-xmloutput/trunk.
<RenatoSilva> what's this?
<AfC> Wow. bzr 1.16 feels a lot ... slower. So I tried Robert's strace trick, and saw Bazaar spending ~0.3s trying to unlink .pyc files.
<AfC> Yeah. time bzr-1.15.1 status = 0.19s. time bzr-1.16.1 status = 0.89s. Bloody hell.
<spiv> D'oh, missed AfC.  That's almost certainly an issue with stale .pyc files, which would be a packaging/installer bug.
<Glenjamin> is there a seprate channel for bzr-svn issues?
<Glenjamin> aha
<Glenjamin> nailed the bug:
<Glenjamin> request.auth is an empty dict if a URL redirects
<Glenjamin> ok, reproducible as well
<Glenjamin> bzr info http://glenjamin.co.uk/other/bzr/menudjen/
<Glenjamin> this redirects to a page which is protected by http auth, which then throws a keyerror
<Youssef> Hi GUYS!!!!
<Youssef> i come to report a bug!
<Peng_> ......
<gioele> suppose I change a single byte in a text file with very long lines (100k bytes per line). Will bzr save a one-byte difference or will it save the whole line?
<Peng_> gioele: Unless you're using the development6-rich-root or 2a disk formats, with C extensions compiled, deltas will be line-based.
<SamB> Peng: ... why doesn't the Python implementation do line-based deltas?
<SamB> er. I mean, why does it?
<Peng_> SamB: Simplicity, I imagine, and maybe performance.
<Peng_> I'm pretty sure I'm right, but I'd kinda like to verify it.
<SamB> I thought the Python code was supposed to always have the same results as the C code :-(
<Peng_> SamB: It is compatible, just not as small.
<SamB> that seems like it could be a serious issue :-(
<Peng_> SamB: In what way?
<RenatoSilva> bzrlib/transport/__init__.py lines 1535 - 1557
<RenatoSilva> could you help me to understand this code? I'm trying to fix a bug
<thumper> abentley: I don't suppose you are working on a take-changes for pipelines ATM are you?
<thumper> abentley: did you see my blog post about pipelines? wrote it last night
<RenatoSilva> Is any xmoutput folk here?
<LarstiQ> RenatoSilva: starting with the _urlRE regex?
<thumper> grr
<thumper> somehow bzr 1.16.1 package trumped the daily ppa build
<RenatoSilva> LarstiQ: line 1569: base = base.encode('ascii')
<thumper> now I have bzrtools requiring bzr 1.17 and an "old" bzr
<RenatoSilva> LarstiQ: isn't it dangerous?
<RenatoSilva> LarstiQ: that's the cause, when you use non-ascii paths thios code causes an error
<LarstiQ> thumper: hmm
<LarstiQ> thumper: can you list the version numbers involved?
<LarstiQ> RenatoSilva: no
<thumper> LarstiQ: for the currently installed bzr?
<thumper> Version: 1.16.1-1~bazaar1~jaunty1
<LarstiQ> RenatoSilva: the interface for get_transport is that you pass it an URL
<LarstiQ> RenatoSilva: URLs _must_ be in ascii. This is a check that no one is passing unicode when they shouldn't
<RenatoSilva> LarstiQ:  :param base: either a URL or a directory name.
<LarstiQ> thumper: and the daily package?
<RenatoSilva> LarstiQ: # Only local paths can be Unicode
<RenatoSilva> LarstiQ: and it is
<LarstiQ> RenatoSilva: right, then it tries convert_path_to_url
<RenatoSilva> LarstiQ: humm, it is passing a local Unicode URL...
<thumper> LarstiQ: 1.16+4508+117 I think
<LarstiQ> thumper: ok, so I think the version on that is bogus then
<thumper> james_w: you are the only one in the changelog
<RenatoSilva> LarstiQ: xmloutput is... how can I convert the non-ascii chars? it is already an URL, so will urlutils.local_path_to_url() work?
<thumper> james_w: is your script doing this?
<thumper> I know nothing about deb version numbers
<thumper> except for that they sometimes go screwy
 * thumper runs bzr from trunk until the package gets worked out
<eggy_> Hello, when I locally clone a bzr repository, it works, but when I do it over bzr+ssh I get 'bzr: ERROR: Not a branch: ...'
<RenatoSilva> eggy_: wrong address?
<eggy_> RenatoSilva: hmm, maybe. Doesn't it start at my home directory?
<RenatoSilva> eggy_: you're cloning from lp?
<eggy_> RenatoSilva: from lp? I dunno, I did 'bzr clone bzr+ssh://myhost/relative/path/from/home/directory/to/repo'
<eggy_> But I now see that if I prepend home/user it works
<LarstiQ> RenatoSilva: urls should not have unicode. See bzrlib.urlutils
<eggy_> To the relative path that is
<LarstiQ> thumper: I think it's johnf not james_w?
<LarstiQ> eggy_: it's an absolute path
<LarstiQ> eggy_: /~/ and you get relative to your home directory, however the sftp server interprets that
<eggy_> LarstiQ: ah, ok, thanks
<fullermd> Not on bzr+ssh it won't...
<RenatoSilva> LarstiQ: I't trying to use urllib.quote
<LarstiQ> fullermd: ah, didn't pay attention enough...
<RenatoSilva> LarstiQ: bzrlib.urlutils.escape?
<LarstiQ> RenatoSilva: bzrlib.urlutils.normalize_url might be more appropriate
<RenatoSilva> LarstiQ: ok
<mwhudson> jelmer: hi
<mwhudson> bzr merge $svn-branch -r revid:revid-not-in-branch stack traces
<mwhudson> jelmer: is this a known bug?
<jelmer> mwhudson: depends on the stack trace :-)
<mwhudson> jelmer: it's not very exciting, it shouldn't be an internal error i think
<mwhudson> http://pastebin.ubuntu.com/210699/
<mwhudson> jelmer: ^
<mwhudson> (maybe it's a bzr bug)
<mwhudson> jelmer: slightly clueless report of the same problem: https://bugs.edge.launchpad.net/bzr-svn/+bug/395906
<ubottu> Ubuntu bug 395906 in bzr-svn "bzr merge crashes on erroneous command line args: NoSuchRevision exception" [Undecided,New]
<mwhudson> :)
<jelmer> mwhudson: yeah, that's a bzr bug. it should be handling NoSuchRevision
<mwhudson> jelmer: ok
<lifeless> mmm
<lifeless> npt sure I agree
<lifeless> an error in fetch is fatal and bad
<jelmer> lifeless: wrt the bug I mentioned?
<jelmer> lifeless: "bzr merge -rrevid:foo" blows up in the same way
<jelmer> lifeless: without bzr-svn involved anywhere
<lifeless> yeah
<lifeless> perhaps the revid: revspec should do validatio
<lifeless> n
<jelmer> yeah, that'd make sense. it would mean we didn't have to handle NoSuchRevision in various cmd_* classes in bzrlib.builtins
#bzr 2010-07-05
<lifeless> mtaylor: btw
<lifeless> mtaylor: please tell me if my fix works for you in builddeb
<mtaylor> lifeless: I will check it
<lifeless> mgz: yes, interbranch multimethod was extracted from previously plan branch methods
<lifeless> mgz: most of the tests are just copies of the old branch ones
<mgz> thanks.
<mgz> lp:launchpad still hasn't finished branching...
<lifeless> harh
<lifeless> its a tad big
<mgz> ha! ran out of disk space
<lifeless> ><
<lifeless> are you hoping to patch launchpad ?
<lifeless> mgz: ^
<mgz> I thought I'd see if the problem with group membership being seen as more important than direct subscription was something as simple as a badly-ordered if chain
<lifeless> ah cool
<lifeless> you'll want about 1.5GB
<mgz> I think I'll check via the web interface before finding a big enough drive :)
<lifeless> + a bit of slack
<lifeless> I have a 4G VM
<lifeless> with 550M free in it, to do LP development
<lifeless> I documented that on the dev.launchpad.net wiki under running/vm, or something like htat
<lifeless> I'm off to do various things; shall be back online periodically.
<exarkun> I'm having difficulties merging some changes from one branch into another.
<exarkun> http://pastebin.com/PQ2hFcCd
<exarkun> Is something wrong with that?
<mgz> branching rev 0 isn't something I've every tried personally.
<spiv> Good morning.
<spiv> exarkun: there's a bug about that
<spiv> exarkun: are you aware that branching rev 0 is essentially the same as doing "bzr init"?
<spiv> exarkun: IIRC there's a bug that rev 1 cannot be a merge commit.
<spiv> exarkun: See https://bugs.edge.launchpad.net/bzr/+bug/242175, and the bug it links to (and the bugs linked to from its comments...)
<ubot5> Launchpad bug 242175 in Bazaar "Better error message when merging into empty branch (affected: 1, heat: 0)" [Wishlist,Confirmed]
<exarkun> How about this one, http://pastebin.com/h1Z2U7Qk
<exarkun> It seems odd to get conflicts when merging like that.
<spiv> exarkun: that seems odd to me too
<spiv> exarkun: file a bug :/
<exarkun> will do
<exarkun> I don't know if I'll file all the bugs I ran into tonight :/
<exarkun> it's five so far, that seems excessive
<exarkun> I can't seem to bring myself to try isolating the most recent
<spiv> Oh, hmm.
<spiv> exarkun: oh!
<spiv> exarkun: I'm silly; it would be because "bzr merge -r 2..16" doesn't include the changes from 1->2.
<exarkun> :(
<exarkun> That explains some issues, I guess
<spiv> exarkun: Usually the way you'd express "merge up to point X" is by simply "bzr merge -r X"
<spiv> I think we could give better feedback in this case, perhaps.
<exarkun> This whole thing I'm doing has problems.  But on the other hand, I'm done now, so I hopefully I don't have to care.
<spiv> Like explicitly announcing if the merge is a cherrypick.
<lifeless> mmm sadness
<lifeless> bzr-builddeb has no direct merge-upstream tests
<spiv> Hmm, I think I may have stumbled upon a reason why 'get_stream_for_missing_keys' is needed even for initial fetches which.
<spiv> ...which should be able to easily enough send a complete stream.
<lifeless> ghosts?
<spiv> lifeless: overly aggressive calculation of "uninteresting" chk root nodes.  The logic doesn't seem to allow for the possibility that two different inventories might refer to the same chk_maps.
<spiv> Still digging into the details.
<vila> hi all
<aidalgol> I'm using the development version of a project that uses Bazaar.  Instead of pulling updates from the repository on the Internet onto both my laptop and desktop, I want to pull them from the Internet to only my dekstop and then push them to my laptop.  How do I do this?
<aidalgol> (Without using shared directories.)
<lifeless> on your desktop run bzr pull
<aidalgol> Right, figured that much out. :)
<lifeless> then bzr push bzr+ssh://laptop/path/to/branch
<aidalgol> Is there a way to not use SSH?
<lifeless> finally on the laptop run 'bzr update' if there is a tree where the branch is (if there is the push will alert you to that fact)
<lifeless> btw, shared repositories are totaly unrelated to your request; can I ask why you said you didn't want to use them?
<aidalgol> Shared?
<aidalgol> I haven't heard of that.
<lifeless> ah sorry
<lifeless> I misread, you said 'shared directories'. My bad - ignore my question.
<lifeless> uhm yes, you can use any protocol bzr supports.
<aidalgol> lol OK :)
<lifeless> But ssh is best. Is it a problem for you?
<aidalgol> I don't want to set up ssh on my system.
<aidalgol> I only do this kind of thing at home on a fairly secure LAN.
<aidalgol> So, for syncing my files, I've been using Unison's unsecure protocol.
<aidalgol> Because I have good physical security.
<lifeless> its not about security
<lifeless> ssh runs the bzr server at the far end so its very very effiicent
<aidalgol> I'll take a look at the list of protocols bzr supports.
<maxb> In this case, the recommendation to use ssh is not about security, but because it's an excellent way of making two machines talk to each other
<maxb> Unless you're stuck running Windows?
<aidalgol> Convenience is more important than efficiency for me.
<aidalgol> maxb: No, thank heavens.
<maxb> Setting up ssh on Linux *is* convenient
<maxb> Because every distro provides it packaged
<aidalgol> bzr serve looks like a good option.
<aidalgol> I agree it's convenient, but I'd rather not run a system daemon if I don't have to.
<aidalgol> What's the LOCATION syntax?
<aidalgol> I ran bzr serve --port=X on my desktop.
<aidalgol> Not I need to run bzr pull [something] on my laptop, right?
<mwhudson> hmm
<mwhudson> i seem to be getting bzr bugmail now
<lifeless> \o/ ?
<mwhudson> You received this bug notification because you are a member of bzr-qa, which is subscribed to Bazaar.
<lifeless> oh right
<lifeless> thats unexpected ;)
<lifeless> it might be because you're in bazaar-canonical.
<lifeless> I think the group layout isn't quite right.
<mwhudson> err
<lifeless> are you in bazaar-canonical ?
<mwhudson> i'm in ~bzr, indirectly, which owns ~bzr-qa, but i'm not _in_ ~bzr-qa
<lifeless> oh
<mwhudson> lifeless: yeah
<mwhudson> so i don't know why i'm getting these emails
<lifeless> right, so poolie rearranged things this morning
 * mwhudson looks at some headers
<lifeless> ~bzr is meant to give you that bugmail anyway
<mwhudson> i guess i'll see how much mail this results in before complaining further :)
<lifeless> I'll try to look tomorrow
<lifeless> feel free to drop me a mail your midday if its driving you batty ;)
 * lifeless changes a few things, just because
<hayalci> Hi, I can't use recorded passwords with bzr-svn
<hayalci> I tried authentication.conf
<hayalci> and tried some settings, but bzr either asks for password, or gives the error message :
<vila> hayalci: svn handles its own cache which bzr-svn is able to use
<hayalci> bzr: ERROR: Permission denied: ".": OPTIONS of 'http://...." : authorization failed: Could not authenticate to server: rejected Basic challenge
<vila> hayalci: do one successful auth with svn and things should be fine
<hayalci> vila: thanks for the info
<hayalci> that worked with a tweak. I am using KDE, and kwallet for password storage. While svn can store and access passwords in kwallet, bzr-svn couldn't
<hayalci> after forcing svn to not use kwallet, and storing password in a file, bzr-svn could access the svn repo
<hayalci> Actually, that's ok with me. That password is not important.
<vila> hayalci: may be worth filing a wishlist bug against bzr-svn for the record
<poolie_> spiv, hi?
<poolie_> does https://bugs.edge.launchpad.net/bzr/+bug/601798 ring any bells for you?
<ubot5> Launchpad bug 601798 in Bazaar "'NoneType' object has no attribute 'get_config' in filename_matches_config executing bzr switch (dup-of: 559436)" [Undecided,New]
<ubot5> Launchpad bug 559436 in Bazaar 2.1 "AttributeError: 'NoneType' object has no attribute 'get_config' (affected: 7, heat: 31)" [High,Fix released]
 * spiv looks
<spiv> poolie_: that's weird, it looks like 559436, but that was fixed in exactly 2.1.1, which is what they are running
<spiv> Or at least, that's when NEWS claims it was fixed...
<spiv> The NEWS file in -rtag:bzr-2.1.1 agrees, though.
<poolie_> sorry i was offline, more maverick/hardware problems :-(
<lifeless> poolie_: what did they say ?
<spiv> poolie_: ouch :(
<spiv> poolie_: I left a comment on the bug with my thoughts
<poolie_> thanks
<poolie_> lifeless, it's working now
<lifeless> poolie_: \o/
<poolie_> burned a cd at low speed, booted from that, reset bios back to ahci
<poolie_> despite appearances it can boot from cds in ahci mode, they just appear as a different device
<lifeless> glub
<lifeless> ah
<lifeless> vila: tell me about this config lock patch
<lifeless> vila: where do you think its up to, is it ready, are you happy with it?
<vila> lifeless: given the discussions I'm more inclined to wait for the sprint to discuss it, there so many things to do with configs that I didn't even mention in the patch that I think we need to talk about
<vila> lifeless: the patch itself...
<vila> well, it needs at least to be split (once or several times) to make my intents and constraints clearer
<vila> using a transport for example was required to use lockdir but also a good thing in itself if we want all IOs to go thru a transport object
<vila> _get_parser() is currently abused by tests as a way to create a config file and we need something better
<lifeless> whats wrong with that ?
<lifeless> by which I mean
<lifeless> what problems does that cause
<vila> overall, far too many things stuffed in this patch were not related to the bugfix itself
<vila> _get_parser() ? Well, in some cases if the config is not empty, supposing that it came from a file make things simpler
<vila> I don't remember the exact context/failing test, but at one point it was obvious/knee-jerk that this wasn't worth maintaining (I tried to nevertheless)
<vila> I think it was related to the ability to use _parser.reload() which itself requires a file name rather than rebuilding a configobj object
<vila> rebuilding the configobj object helped with failures with the intrumented one (hence the addition of reload() there)
<vila> and this last addition was a bit silly since its implementation is a no-op
<vila> kind of: ok this bug fix is simple: oh wait, I need a small refactoring here, oh wait, unrelated tests are failing, one more bit of refactoring, oh wait, etc
<poolie_> hi there vila
<poolie_> and good night
<poolie_> vila, would it make any sense to send an rfc email about config locking just to summarize the progress at a higher level than an mp?
<vila> poolie_: it would, I have a list of other points I haven't mentioned so far regarding config
<lifeless> the python-ideas thread on their use of hg makes me sad
<lifeless> consensus emerging seems to be to not accept branches from non-committers.
<lifeless> !
<poolie_> really
<lifeless> really
<lifeless> bai
<mwhudson> lifeless: !
<lifeless> yeah
<mwhudson> doesn't that almost completely miss the point?
<lifeless> 'pulling all the patches generates too much noise people won't review, so people should make a single patch and put that in the bug tracker'.
<lifeless> mwhudson: you'd think so.
<mwhudson> err
<mwhudson> does hg not have merge --preview?
<mwhudson> or some moral equivalent
<jamesh> I think there are lots of people who still want linear histories
<jamesh> even though they're using DVCS
<jamesh> they consider the extra non-linear history to be noise rather than valuable information
<lifeless> yes
<lifeless> add to that
<lifeless> hg doesn't do nonlinear history - it logs all left-aligned, all patches show.
<jamesh> they should fix that
<lifeless> gnight
<knielsen> Hi, I'm looking for docs on bzr formats (bzr 2.1.1), `bzr info` says format: rich-root-pack and `bzr checkout` says "on-the-fly conversion from RepositoryFormat2a() to RepositoryFormatKnitPack4()". But I didn't find info about those formats in docs (http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/formats-help.html)
<knielsen> anywhere I can find info on that/those formats?
<spiv> knielsen: 'RepositoryFormat2a()' is the internal name for the '2a' format
<spiv> knielsen: and 'RepositoryFormat2a()' is the internal name for the 'rich-root-pack' format
<knielsen> spiv: right, so RepositoryFormatKnitPack4 and rich-root-pack are two different names for the same format?
<spiv> Oops, copy-and-paste screwup
<spiv> Right, 'RepositoryFormatKnitPack4' is the same format as 'rich-root-pack'
<spiv> 'rich-root-pack' is quite old, it dates back to bzr 1.0
<knielsen> spiv: right, so the question is, where can I read about that rick-root-pack format?
<knielsen> ok, yes I suspected that it was old, that's the main info I need, thanks
<spiv> Basically you should be using '2a' for everything.
<spiv> Please file a bug about the documentation being a bit lacking there.
<knielsen> ok, will do
<spiv> Thanks!
 * spiv goes to bed
<parthm> knielsen: there is bug #567064 about improving the message.
<ubot5> Launchpad bug 567064 in Bazaar "message about on-the-fly conversion is unclear (affected: 2, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/567064
<spiv> parthm: that's a related but different bug, I think
<parthm> spiv: yes. i suppose it could avoid using internal names + give a suggestion of upgrading to 2a.
<GaryvdM> Hi mgz
<knielsen> filed as https://bugs.launchpad.net/bzr/+bug/601912
<ubot5> Launchpad bug 601912 in Bazaar "Missing documentation about repo format rich-root-pack (internal nameRepositoryFormatKnitPack4) (affected: 1, heat: 6)" [Undecided,New]
<rioch> I've written an app which I now want to use bazaar to do version control. If I do bzr init <project> will it pick up everything that is already there, or should I create it blank and then add the files and commit them?
<GaryvdM> rioch: You can do bzr init in you existing dir. You will then need to do bzr add and bzr commit.
<rioch> GaryvdM: thanks :)
<rioch> I created a branch with bzr init, then decided to start again and deleted the project, copied the files across from a backup, and now when I do bzr init I get this error: bzr: ERROR: Already a branch: ".".
<maxb> Sounds like you deleted all the visible contents of a directory, but kept the .bzr subdir
<rioch> maxb: I thought that too, but that's gone as well.
<maxb> That error message is a clear indication there is a .bzr in the location you are trying to init
<rioch> maxb: well, I emptied my trash and now it works, so maybe it was aware I deleted it?
<lifeless> morning
<GaryvdM> Hi lifeless
<mgz> hey all.
<GaryvdM> Hi mgz
<GaryvdM> mgz: re py2exe extraction - It work for just bzr, but not with plugins. I've not debug much...
<mgz> you also have a slight problem with both me and you changing the bzr setup.py and those new bits not being copied across yet
<mgz> easy to fix though.
<GaryvdM> I'm working on been able to specify revision specs.
<lifeless> \o/
<GaryvdM> mgz: Yes - I'll fix that when I get it to work. :-)
<mgz> I've just been tracking down the double-auth thing from the other day, it's a mess of abstractions.
<mgz> basic issue is the http connection creation is deeper than the try-smart-protocol-then-dumb, so if the first bit fails it throws away everything it has set up so far including the auth information
<mgz> also it doesn't store the credentials unless it actually gets a 200, so 401-404 will raise without recording that it actually got past the auth correctly.
<lifeless> \o/
<mgz> so, it's what I expected, which I might be able to fix, plus a bigger issue in bzrdir that I have no idea for.
<lifeless> whats the bigger issue?
<mgz> well, when it's probing for formats, it has no concept of an http connection
<lifeless> yes
<mgz> so I don't see any clear way of preserving the auth credentials, that are stored on the connection, across two seperate probes
<mgz> except some global store, which is sort of what the text file on disk is.
<lifeless> the probes don't make a new transport object
<iocor> how do I find out what changed between bzr version 1.18.1 and 2.1.1
<mgz> but the auth stuff is on the request, not the transport
<lifeless> iocor: read the NEWS file for 2.1.1
<iocor> lifeless: is that online anywhere?
<GaryvdM> iocor: http://doc.bazaar.canonical.com/latest/en/release-notes/index.html
<lifeless> sure
<mgz> ah, or is it...
<lifeless> or http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/head:/annotate/NEWS
<lifeless> I think thats the url anyway, :)
<GaryvdM> http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/annotate/head:/NEWS
<GaryvdM> But it breaks because annotate takes to long.
<mgz> 's on ConnectedTransport._shared_connection which I guess I'll poke and see if it survives
<mgz> ...does seem to have the same id
<lifeless> mgz: thats a feature
<lifeless> tcp is slow.
<lifeless> reuse is good.
<mgz> goodie, so, it's cleverer than I feared
<lifeless> I like to think of it as simpler.
<lifeless> :P
<mgz> if it was simple, wouldn't have taken this long to find out ;)
<mgz> ...now I have to look into writing http tests that don't leak horribly
<lifeless> \o/
<mgz> semi-related, if you get the username or password wrong is it expected to get:
<mgz> bzr: ERROR: Invalid http response for http://float.endofinternet.org/bazaar/testauth/.bzr/branch-format: Unable to handle http code 401: Authorization Required
<mgz> it seems... unhelpful.
<lifeless> mmm, I wouldn't say expected.
<lifeless> if its a single line then its just the regular exception-printout
<iocor> i've got some pythoncode that uses bzrlib, and we're attempting to make commits, and for some reason we're unable to make updates to files
<iocor> anyone got any ideas why?
<lifeless> paste the code
<lifeless> I have a few minutes, I'll have a peek for you
<iocor> thanks man
<iocor> http://dpaste.com/214900/
<iocor> this is the commit function
<iocor> http://dpaste.com/214902/ class initialiser
<iocor> http://dpaste.com/214903/
<iocor> function to update files
<lifeless> ok, so you don't have a tree on disk ?
<iocor> calling commit is meant to write the tree out to disk
<lifeless> uhm
<lifeless> some terms
<GaryvdM> iocor: small nit pick: line 16 of http://dpaste.com/214900/ should not be necessary.
<GaryvdM> "self.b = bzrlib.branch.Branch.open(self.b.base)"
<lifeless> iocor: a branch is a line of development
<lifeless> iocor: a Tree is a single collection of the users files, either editable (a WorkingTree) or immutable (a RevisionTree)
<lifeless> iocor: a 'commit' takes a Tree and puts it into the branch's Repository, and updates the branch last_revision.
<lifeless> iocor: so if you have a WorkingTree, to commit you just do 'tree.commit()'
<iocor> lifeless: ok, so I'm looking to take in some changes, apply them to the current branch to get a new branch
<iocor> or
<iocor> an update to the branch
<iocor> it's very simple linear style committing
<lifeless> iocor: your code won't work properly prior to 1.18 anyway, I would just not support it.
<iocor> also, I'm using bzr 2.1.1 but the branch isn't getting updated
<lifeless> not your fault, just bzrlib internals.
<lifeless> what is in _update_tree ?
<iocor> and the #as of 1.18 thing isn't executed
<iocor>         self.PrevTree = self.TransPrev.get_preview_tree()
<iocor> one line
<iocor> also, I inherited this system and it isn't particularly well documented or functional on anything other than bzr 1.18.1
<iocor> at all
<lifeless> uhm
<lifeless> so that one line
<lifeless> is discarding all the data you've got
<lifeless> to work with PreviewTree there is a strict sequence you have to follow
<lifeless> 1) make a Transformpreview
<iocor> (happens at class init)
<lifeless> 2) call methods on it to create/move/delete files
<iocor> lifeless: I note that creating files and deleting files works just fine
<lifeless> 3) call get_preview_tree()
<iocor> modifying their contents doesn't
<iocor> ohic
<lifeless> 4) call that-tree.commit()
<iocor> so in fact, this is pretty broken?
<iocor> aaaaaaaaaaaaaaaaaaaaah
<lifeless> I may be wrong
<lifeless> but looking at _PreviewTree.__init__
<iocor> lifeless: is this going to be massively painful to fix?
<lifeless> I don't see why
<lifeless> just don't call _update_tree where you are
<iocor> ok
<lifeless> and don't call self.PrevTree = self.TransPrev.get_preview_tree() in init
<lifeless> instead, do that line in your commit
<iocor> I have a merge function also
<iocor> should I call it there?
<lifeless> actually
<lifeless> I may be wrong about risk of making new trees
<lifeless> jus tshove a self.PrevTree = self.TransPrev.get_preview_tree() call into your commit function
<iocor> and don't remove the updatetree calls elsewhere?
<lifeless> yeah
<lifeless> see how that works
<lifeless> can I ask, what this is for?
<iocor> to cut a long story short, an online ide for python that controls robots and has to be deployed in an environment where we can't install software, so it's web-based
 * lifeless whistles
<lifeless> thats pretty cool
<iocor> :D
<iocor> lifeless: http://studentrobotics.org
<iocor> :O
<iocor> :OI
<iocor> :O
<iocor> I think
<iocor> you just fixed it
 * iocor waits for the tests to finish
<iocor> oh my god
<iocor> lifeless: I owe you all my internets for a wek
<lifeless> glad I could help
<iocor> :D:D:D:D
<GaryvdM> Bla - just realised, the feature I've been planing for the last hour, was already implement by Ian, just not in use :
<GaryvdM> :-)
<lifeless> :P
<fullermd> Superrelativistic implementation FTW.
<lifeless> nah
<lifeless> guido's time machine
<lifeless> dude just can't seem to keep it locked up
<fullermd> Well, it's a time machine.  If you forget to lock it up ONCE, it's the same as never locking it up.
<GaryvdM> Bla - SEACOM down for 6-8 days: http://www.seacom.mu/news/news_details.asp?iID=143
<GaryvdM> I nice reminder of how slow SAT3 is.
<GaryvdM> For Ian's new window installer build script, he added the ability to define more than one series.
<GaryvdM> See http://bazaar.launchpad.net/~bzr/bzr-windows-installers/trunk/annotate/head:/bazaar_releases.py
<GaryvdM> For 2.2 I need to specify defined revisions.
<GaryvdM> But for .dev, I want it to use the latest version for each plugin.
<GaryvdM> You can specify a revision spec per Project/Plugin object.
<GaryvdM> But the way that is currently defined, you can only define the 2 series to have the same plugin versions, as they are shared.
<GaryvdM> I'm not sure how to change this so that I can have different plugin versions, but not have to repeat plugin details, and be syntactical clean.
<GaryvdM> Maybe add a copy_write method, define the plugins globally, and copy_write with the specific revision for the series.
<GaryvdM> Any better ideas?
<poolie> hi GaryvdM
<poolie> hi jam
<GaryvdM> Hi poolie
<mgz> hm, got another mail with team membership overriding direct subscription for X-Launchpad-Message-Rationale and bottom note
<lifeless> heh
<lifeless> hi poolie
<mgz> as I completely failed to branch launchpad, guess I better just file a bug
<lifeless> poolie: I was out by 2 hours on my thing this morning :O
<poolie> in which direction
<lifeless> just finished
#bzr 2010-07-06
<spiv> Good morning.
<poolie> hi there spiv
<poolie> mkanat, hi?
<mkanat> Hey poolie!
<lifeless> moin
<poolie> spiv, where is the 'tc qdisc' thing documented?
<poolie> i can't find it in the doc directory
<spiv> Hmm
<spiv> I guess it's just documented on the wiki, not in the doc directory.
<spiv> i.e. http://wiki.bazaar.canonical.com/SmartPushAnalysis1.4
<swathanthran> i did one commit over the trunk, now i see the changes from upstream needs to be merged, now i prefer to "move" my commit to another branch and keep the trunk clean. what should i do?
<spiv> swathanthran: how about "bzr branch -r -2 . ../clean-trunk"?
<spiv> Or alternatively "bzr branch . ../new-branch && bzr pull --overwrite upstream-url"
<swathanthran> ok, my free net time is over now, so will those methods lose the downloaded-but-not-merged changes? (All i did was a commit over the trunk and "bzr pull" ended saying "these branches have diverged.. use merge to reconsile them"..
<spiv> No, they won't lose any data.
<swathanthran> thats great:) thanks..
<swathanthran> so now, i should do bzr merge on clean-trunk?
<swathanthran> i did bzr branch -r -2 . ../clean-trunk
<spiv> clean-trunk will have all but the last commit from your original branch
<spiv> If you want to keep it as a mirror of the upstream trunk then pull rather than merge.
<spiv> (Also, you probably want to use a shared repository for these branches to save space and time)
<lifeless> spiv: ping; hey :- are you in the middle of a patch at the moment ?
<spm> bzr workflow question. have pristine branch of trunk; bzr merge <proposed> ; a bug is found, updates pushed to same place merge from place as new revno. Do I bzr revert and re-merge; or simply bzr merge again and bzr will DTRT?
<lifeless> revert and remerge
<spm> cool; that's what I've been doing, but did wonder. ta
<lifeless> be nice if running merge again Just Worked but I'm pretty sure it will currently Just Hit You Hard
<spm> heh
<spiv> lifeless: was in the middle of lunch, actually :P
<lifeless> spiv: :) I meant a slightly larger scope than that :>
<spiv> I am fairly deep in 522637 atm :)
<lifeless> bug 522637
<ubot5> Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 11, heat: 58)" [High,In progress] https://launchpad.net/bugs/522637
<lifeless> awesome
<lifeless> james_w: so, I don't have dh_make installed
<lifeless> nevermind
<lifeless> PEBCAK
<vila> hi all
<fullermd> Well, there goes the neighborhood...
<vila> fullermd: hey ! long time no see :)
<fullermd> I've been hiding out.  Safer that way.
<poolie> hi there vila
<vila> hey poolie
<vila> poolie: I just sent the rfc/summary about config locks
<poolie> hey, thanks
<poolie> that's pretty good
<poolie> i think even a little more overview could be good, next time
<vila> ok
<vila> poolie: hmm, just reading your doc-testing mp, I think the dependency for --parallel=fork is testtools, not subunit
<poolie> isn't testtools always required?
<poolie> to run selfttest
<vila> it is
<poolie> in other words i think you need testtools to run selftest at all
<poolie> but if you want to run --parallel then you will also need subunit
<vila> yes you need testtools anyway, I can't remember if subunit is a soft dependency or not
<vila> poolie: why ?
<lifeless> hai
<poolie> because we use subunit streams between the subprocesses and the master
<vila> oh yes, sorry, I didn't check for_for_tests, nevermind
<vila> fork_for_tests
<poolie> hi vila
<lifeless> http://whatthecommit.com/
<fullermd> So, we need a plugin...?   :p
<lifeless> yes
<lifeless> yes we do
<fullermd> The sobering (or drunkening, really) part is that doing that would probably improve the quality of commit messages in a non-trivial percentage of cases...
<lifeless> bah
<GaryvdM> It's not often that you see 2 identical mp
<GaryvdM> https://code.edge.launchpad.net/~jelmer/bzr-pipeline/missing-lplib/+merge/25843
<GaryvdM> https://code.edge.launchpad.net/~gz/bzr-pipeline/no_launchpadlib_needed_601466/+merge/29156
<lifeless> james_w: hai
<Automaattimarsu> anyone here familiar with checking newest revision from bzr branch with hudson when trying to do continous integration?
<GaryvdM> Automaattimarsu: Maybe vila may be able to help you.
<GaryvdM> Automaattimarsu: What's wrong?
<Automaattimarsu> GaryvdM: its just the lack of instructions pretty much everywhere connected to hudson and its plugins. No apis anywhere or anything
<Automaattimarsu> or atleast I cant find any
<Automaattimarsu> I'm trying to get it so, that hudson would check the bzr revision from my trunk and if there are any changes, it would run a new build and restart the server o.0
<maxb> Automaattimarsu: I don't know much about Hudson. Perhaps you could execute `bzr revno` ?
<maxb> Or perhaps `bzr revision-info` to detect a change even if it is a push --overwrite which doesn't change the revno
<vila> Automaattimarsu: most of it is automatic, what is your specific need ?
<vila> Automaattimarsu: ha, yes, running on new commits only right ? Hmm, I haven't dig that so far (I'm happy with 'Poll SCM' with '@daily' for schedule) but it should be a hudson thing not specifically a bzr one
<vila> Automaattimarsu: the help there mentions a "push" trigger and a link https://hudson.dev.java.net/build.html
<vila> GaryvdM: hi :)
<GaryvdM> Hi vila
<Automaattimarsu> vila: hudson doesnt have bzr scm by default does it?
<Automaattimarsu> if it does, whats its syntax
<Automaattimarsu> i havent been able to find that anywhere D:
<vila> Automaattimarsu: haaaa, you need to install the plugin first
<Automaattimarsu> is it the one from launchpad?
<vila> not at all, the hudson one, search in manage husdon/plugins
<Automaattimarsu> i do have hudon plugin for bazaar
<vila> ha, ok
<Automaattimarsu> hudson*
<Automaattimarsu> but I couldnt find any documentation on how the Poll SCM works
<vila> then in your job description you should have a Source Code Management section
<Automaattimarsu> since the default one only handles CVS
<vila> and there there should be a Bazaar choice available
<Automaattimarsu> yeah i have bazaar there o_o
<vila> Automaattimarsu: easy to miss if you looked there *before* installing the plugin ;)
<Automaattimarsu> true
<Automaattimarsu> i read somewhere that the default (hudson) plugin always returns false on revision change checks o.o
<vila> Automaattimarsu: how it's implemented is a bit unclear to me, but I suspect they use a generic solution that requires keeping the source tree on the master
<vila> generic here means working for any SCM
<Automaattimarsu> hmm
<Automaattimarsu> Guess I'd need to check it after some changes are made
<vila> Automaattimarsu: But how do check what the plugin is returning ? It looks quite opaque to me...
<vila> s/how do/how do you/
<Automaattimarsu> vila: i just checked some of the issues on the plugin page
<vila> ha
<Automaattimarsu> :D i'll leave how they managed to get that information to the ones that are smarter than me
<vila> Automaattimarsu: hehe, I hoped you were smarter than me then ;)
<Automaattimarsu> if i was, i'd recon i would not be here asking questions lol
<vila> being smart doesn't imply knowing everything, asking questions *is* smart :)
<Automaattimarsu> guess so :P
<Automaattimarsu> im a bit new to this bzr thing to begin with, let alone hudson
<Automaattimarsu> silly technologies
<vila> fir silly values including smart ? =)
<vila> s/fir/for/ typo-in-joke rule striking
<GaryvdM> vila: do you not use the bzr plugin for babune?
<vila> GaryvdM: I do use it of course :)
<vila> GaryvdM: but it's a hudson plugin not a bzr plugin, or did I misunderstood your misunderstanding ? :-P
<GaryvdM> No - thats what I meant.
<GaryvdM> vila: Something you said made me think so.
<GaryvdM> Hi jam
<GaryvdM> I have a windows installer which I think is a release candidate.
<GaryvdM> Going to test it, and then upload to lp.
<GaryvdM> :-)
<GaryvdM> http://dl.dropbox.com/u/4494367/bzr-2.2b3-2-setup.exe
<GaryvdM> jam: This is how I specified the release tags: http://bazaar.launchpad.net/~garyvdm/bzr-windows-installers/maybe/revision/126
<GaryvdM> jam: Ian did most of it, just had to do the last little bit.
<jam> GaryvdM: you should be using Ubuntu-one for your hosting :)
<jam> anyway, glad it is working.
<jam> I'm not super happy with the syntax, but it is reasonable
<GaryvdM> jam: I'm not happy with the syntax either, any suggestions?
<jam> well, #1 is you should be using "revision='tag:foo'" rather than "revision = 'tag:foo'" :)
<GaryvdM> Ok
<jam> I wonder if for our purposes using a property sort of thing for:
<jam> bzrtools.copy_write(tag='release-2.2.0') and fastimport.copy_write(revno=275)
<jam> (or revno='275')
<jam> the idea is that 'tag' and 'revno' could directly translate themselves into "tag:XXX"
<jam> rather than saying: revision="tag:release-2.2.0"
<GaryvdM> Ok
<jam> I would probably rename "revision" to "revision_spec" or "revspec"
<jam> since it isn't a revision-id, etc
<GaryvdM> Are you ok with me putting out a build with some dev plugins?
<GaryvdM> svn etc...
<jam> GaryvdM: well, I don't really like doing it, but if jelmer doesn't make a release of bzr-svn which is compatible with bzr2.2 we don't have much of a choice
<jam> hey jelmer, you've had 4 months, what's up with that? :)
<GaryvdM> I'm getting this error: http://pastebin.org/384461 with my 2.2b3 build, but not the bzr.dev build.
<jam> mgz: ^^
<jam> GaryvdM: the specific error was turned into a warning, or maybe even into just a test-suite failure
<jam> however, I think it really does indicate that the doc strings are getting stripped
<jam> and we need to watch out for that
<jam> as we don't want to ship bzr and have "bzr help explorer" fail
<GaryvdM> jam: But qlog does have help, so I think it is to do with -OO
<jam> It is sort of a shame we can't keep the error to help us
<jam> GaryvdM: that's my point and why I mentioned mgz :)
<GaryvdM> jam: I saw some code that turned on -OO for bzr, but off for plugins.
<GaryvdM> Trying to locate it...
<jam> GaryvdM: https://code.launchpad.net/~gz/bzr/installer_plugin_script_timestamp_rounding/+merge/29157 is part of the issue
<jam> GaryvdM: its in setup.py
<jam> the issue is that if you get the timestamps wrong
<jam> at install time
<jam> then at run-time the .pyo gets rebuilt on-the-fly
<jam> and since bzr.exe is running as -OO everything gets stripped
<jam> also note that manually installed plugins (stuff in BZR_PLUGIN_PATH) will also end up stripped always
<jam> which we don't really want
<jam> though we can configure plugins to use the new '__doc__ == """' syntax
<jam> sorry
<jam> __doc__ = """
<jam> syntax
<GaryvdM> jam: configure, or change the code?
<jam> vila: ping about https://code.launchpad.net/~vila/bzr/cleanup-docs/+merge/29211
<jam> GaryvdM: you have to change the plugin
<jam> so instead of
<jam> class cmd_foo(...):
<jam>   """My docstring
<jam> they do
<jam> class cmd_foo(...0:
<GaryvdM> ok - got you...
<jam>   __doc__ = """My docstring
<jam> look at bzrlib/builtins.py for the example
<jam> I'm not 100% sure what the answer is for the 2.2 release
<jam> we may just back out the change
<jam> we may go around and push changes to all plugins we can find
<GaryvdM> back out -OO?
<jam> right
<GaryvdM> mgz: Do you have metrics on how much -OO improves the cold start?
<vila> jam: ping
<vila> jam: pOng
<jam> vila: the '|--|' thing seems to be pretty pervasive in our codebase, I'm not sure how you say "I couldn't find where it is used"
<jam> (Perhaps not in index.txt itself, but in lots of other files)
<vila> jam: I suspect I searched the _build hierarchy which may not copy doc/developers
<vila> jam: or I search doc/en instead of doc/
<jam> vila: I don't really know the answer. I also don't know why '--' is important, though perhaps it was an editing artifact
<jam> somebody edited the docs and it inserted the --
<jam> and then somebody cleaned it up to rest so that it kept the unicode char
<jam> http://en.wikipedia.org/wiki/Dash
<vila> yeah, that's my point, if it makes html prettier, makes it html specific
<vila> now that I know where to look I can try to find an alternative
<vila> jam: yeah, looks like doc/developers is not taken into account in the shinx build
<jam> vila: "en dash is used to compare things, em dash is used to demarcate a parenthetical thought"
<jam> so it isn't just about html prettiness
<jam> though I don't know if non typographical humans know the difference
<vila> jam: then the rest spirit would be to detect it, not require an artifact
<vila> especially a unicode one :)
<vila> jam: and I think all readers won't mind reading -- instead of an em dash
<vila> jam: but more to the point: it's a blocker so the easiest thing was to get rid of it
<vila> jam: argh, rest recognizes unicode : http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html (search for em dash) but doesn't seem to provide an alternative
<jam> vila: so you can put a literal em dash in your text (after setting the text encoding properly), but you can't supply an ascii variant?
<jam> though I'll mentioned
<jam> we did it just fine by pulling it out to an insert glyph-here command
<jam> and I don't know why texinfo is being unhappy
<jam> it doesn't support non-ascii?
<vila> jam: I need to check again but from memory, yes, unicode was causing problems
<jam> vila: sounds like a texinfo bug
<jam> given that it is an international project, not supporting i18n for your preferred documentation seems limiting
<jam> vila: anyway, -- is fine with me, though why not just do '-' is beyond my understanding
<vila> kind of out of scope here :)
<jam> vila: perhaps, but we can treat it as a bug on their end
<vila> sure, once I get a working texinfo writer I'll be more demanding
<vila> But I need to reconsider anyway since there *are* uses
<vila> I should at least look at them
<GaryvdM> Night all - Bed early tonight
<janisozaur> in svn I can "svn log -r BASE:HEAD", it shows the commit logs between what I have locally and what server has. how can I achieve the same in bzr?
<mgz> missed garyvdm... will respond anyway so he can read the log
<mgz> <GaryvdM> It's not often that you see 2 identical mp <- oh man, I checked for bugs before doing that, but didn't think to look for unmerged proposals
<mgz> <GaryvdM> I'm getting this error: http://pastebin.org/384461 with my 2.2b3 build, but not the bzr.dev build. <- this is showing you've not got the complete fix for bug 600803 in yet, there's your qbzr file is getting recompiled
<ubot5> Launchpad bug 600803 in Bazaar Windows Installers "Plugin pyo files may be ignored and recreated from source (affected: 3, heat: 14)" [Undecided,New] https://launchpad.net/bugs/600803
<mgz> the docstring problem and hard error is actually quite useful here to find that
<mgz> but as jam says, it might be best to back the -OO thing out for this release still, as there are still going to be a few cases where plugins will lose their help
<jam> mgz: well, we could ensure that all plugins being bundled into 2.2 will have the docstrings fixed
<jam> not as easy as just rolling back your change, but better *progress* :)
<mgz> well, that's not the problem once the installer bug is fixed
<lifeless> mornink
<mgz> they'll be compiled with optimize=1 and no longer recompiled at runtime
<jam> mgz: except for the stuff people start manually installing, which may be new versions of the bundled plugins
<jam> which would fail again
<jam> hi lifeless
<mgz> the only issue is BZR_PLUGINS with source, rather than installed, plugins
<mgz> right.
<mgz> can someone kick aaron to merge jelmer's bzr-pipeline proposal and reject mine?
<jam> abentley: kick ^^
<mgz> just so it doesn't get written for a third time ;)
<abentley> jam: ow
<jam> abentley: soft pat and cookies
<mgz> hm, trying to assign the bug to jelmer gives me a funky pink "Constraint not satisfied" error
<lifeless> wow
<lifeless> screenshot + bug file please!
<mgz> http://float.endofinternet.org/temp/launchpad_constraint_not_satisfied.png
<lifeless> yeah
<lifeless> thats not meant to happen. Bug filing time! bugs.launchpad.net/malone
<mwhudson> that's like the worst error message ever
<lifeless> it will help to know if you're on edge or production, too.
<mwhudson> and launchpad is all too happy to give it out :(
<lifeless> mwhudson: stop being so positive.
<mgz> that was edge, just tried production and it worked.
<lifeless> right - please file :)
<mgz> <lifeless> right - please file :) <- Timeout error ... (Error ID: OOPS-1648C1494)
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1648C1494
<mgz> I'll get that bug filed in the end.
<lifeless> argh
<xnox> when i do $ bzr merge -r 8..9 ../trunk/ to backport a fix, how can I make bzr reuse commit message?
<mgz> That's a cherrypick, not the same revision, so you probably don't want to reuse the exact message but instead say "Cherrypick fix for..."
<xnox> mgz, true except that the log message are long and descrptive (../trunk/ is svn with very large commits)
<xnox> I've ended up copy pasting the output from $ bzr log =)
<mgz> lifeless: who was it you said was interested in launchpad bug mail issues?
<mgz> I found bug 474615 which is basically my gmail filtering problem.
<ubot5> Launchpad bug 474615 in Launchpad Bugs "lp email 'rationale' header should use most specific criterion, or add header for direct subscription (affected: 2, heat: 8)" [Low,Triaged] https://launchpad.net/bugs/474615
* Chex changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it | Launchpad down/read-only from 23:00 - 00:30 UTC for a code update
#bzr 2010-07-07
<gregcoit> hi.  how do I undo a "bzr rm"?  no other commands have been run since then (like "bzr ci").
<maxb> bzr revert pathname should do it
<gregcoit> maxb: ty - that worked!
<lifeless> mgz: deryck
<poolie> good morning
<poolie> hi lifeless
<lifeless> hi poo
<lifeless> hi poolie
<poolie> snort
<mgz> you really want those last three letters
<mgz> lifeless: should I bug him on irc or subscribe him to the bug or what?
<lifeless> mgz: overloaded word that
<lifeless> I'd discuss with him
<lifeless> and see if he wants a unique bug or what have you
<mgz> thanks.
* jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it | Launchpad down/read-only from 23:00 - 00:30 UTC for a code update
<spiv> Good morning.
<lifeless> hola
* Chex changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it
<poolie> hi there spiv
<thumper> in the bzrlib source
<thumper> is there a method to do interdiffs?
<poolie> thumper: i don't think so-
<lifeless> mmm
<lifeless> depends on what you mean
<thumper> I'd really like to not to have to shell out to interdiff binary
<lifeless> ok, that, no - we haven't done that yet.
<thumper> I have an old review diff, and a new review diff generated from newer commits
<thumper> I want to see the difference between them
<thumper> (and email it out)
<lifeless> right, lp mp incremental changes ?
<thumper> yep
<lifeless> if I can suggest a different way
<lifeless> you have the old tip O and the new tip N
<lifeless> do a preview-merge with O and get a tree - not a diff
<lifeless> do a preview-merge with N and get the tree.
<lifeless> then do diff between the two preview trees
<lifeless> I'd expect that to be more useful, and its not going to be an interdiff, so its easier to read.
<thumper> are preview trees up to that yet
<thumper> ?
<lifeless> If they aren't it will be straight forward to fix I suspect
<lifeless> if they aren't I'd really like to know anyhow :)
<poolie> lifeless: re ease of reading, the output of interdiff is not a diff of diffs
<poolie> iirc
<poolie> it's just a diff
<lifeless> ah yes
<lifeless> I'm thinking debdiff
<lifeless> which is interdiff
<lifeless> of patches
<lifeless> and known to blow up spectacularly with some packages
<poolie> jam (if any), lifeless, we need a way to get debug info for out of memory errors
<lifeless> poolie: nevertheless the failure modes in two previews seem better to me, IMBW.
<lifeless> poolie: yes, agreed.
<lifeless> hmm, -Derror should give us something
<poolie> can anyone confidently answer about bzr-svn in https://answers.edge.launchpad.net/bzr/+question/116868
<poolie> there is a bug for this
<poolie> may need jam jam
<lifeless> jam jam ?
<jam> lifeless, poolie: you rang?
<lifeless> I didn't; poolie may have
<jam> poolie: what sort of mem info do you want?
<lifeless> jam: there is an OOM error occuring on a 30MB file according to some guy in some bug report.
<poolie> jam, when bzr crashes with MemoryError i'd like us to get some useful debugging info back from the user
<lifeless> be nice to be able to see whats really oging on.
<poolie> there's a bug asking for this
<jam> poolie: I remember chatting with you about this a bit. One of the problems is that stuff like 'str' objects aren't in the gc list
<jam> strs and ints/floats/etc being the most obvious not present
<jam> and now StaticTuple :)
<poolie> so i guess the question is:
<poolie> if there is any data we could easily report we should do it
<poolie> even if it's not 100% complete or if it's useful in only a subset of cases
<jam> poolie: well, you can certainlly call trace.debug_memory()
<jam> which would at least tell you vmpeak and vmsize, etc
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.2 is out
<poolie> mm, we should put that into the apport file ,if we don't already
<poolie> i don't know if that will tell us _why_ we ran out though
<poolie> perhaps the traceback may give some clue
<poolie> can we take the question that you'd ask the user experiencing an oom problem
<poolie> and automatically answer it when they first hit the bug?
<jam> poolie: I'd have to think about what the first questions would be. Things I would usually ask are stuff like "what action were you taking" which should already be in the log file
<jam> what the size of files are you working with
<jam> I think that would be a bit hard to automatically answer
<jam> knowing the sizes of objects in the frames on the stack could be useful
<poolie> jam i guess we could walk up the stack and print either the actual contents of the locals, or some data about them
<poolie> such as their estimated size
<jam> poolie: I think contents is risky, but size could be reasonable
<poolie> some risk of leaking private data there
<jam> well, I'm thinking more about 100MB files
<poolie> that too
<poolie> there is a cgitb module that does some of this
<poolie> including trimming large values
<poolie> so there's a function (in meliae?) that estimates the size of an object?
<jam> poolie: in python 2.6 you can use sys.getsizeof()
<jam> meliae also exposes something like this
<poolie> ok
<poolie> so this won't tell us if we're using lots of memory in a global not referenced by the stack
<poolie> and it would probably be too noisy to print all the globals
<poolie> but that may be an unusual condition
<poolie> i guess we could print globals using a lot of memory
<jam> we could walk gc.get_referents() at a cost of 1 pointer per object
<poolie> cost in terms of needing to allocate more memory to do that?
<jam> yeah
<jam> for the list that holds it
<jam> it could be a problem if we are already oom
<lifeless> jam: for when you awake.
<lifeless> https://bugs.edge.launchpad.net/bzr-builddeb/+bug/552950
<ubot5> Launchpad bug 552950 in bzr-builddeb "Additional changelog entries are modified when merging another branch (affected: 1, heat: 10)" [Medium,Triaged]
<lifeless> please comment
<yao> if I commit 10 times, from rev 1 to rev 10, in my local branch, and didn't push them to remote branch yet,
<yao> I want to uncommit commit #5, what should I do?
<yao> 'bzr uncommit' doesn't help,
<poolie> yao: it depends on exactly what you want
<poolie> do you want to pretend #5 never happened, or do you want to just reverse it's effect?
<yao> poolie: former, I think,
 * yao is wondering whether it is possible to pretend #5 never happened
<aidalgol> Google is turning up nothing on this: is it safe to edit .bzrignore?
<spiv> Yep.
<aidalgol> OK, good.
<aidalgol> Why might this line (in a .bzrignore) have *two* stars?
<aidalgol> lisp/**/loaddefs.el
<spiv> aidalgol: see 'bzr help ignore', it explains the patterns
<spiv> (Also, 'bzr help patterns')
<spiv> To answer your specific query: "/**/ - Matches 0 or more directories in a path"
<poolie> hi there spiv, vila
<vila> hey poolie
<poolie> sorry yao i missed you there
<poolie> are you still here?
<poolie> have a look at the bzr-
<poolie> have a look at the bzr-rewrite plugin
<yao> poolie: I am here...
<poolie> do you want to keep the later commits as distinct commits?
<poolie> or are you happy to fold them into just one?
<yao> poolie: I want to keep later commits as distinct ones...
 * yao is looking at https://launchpad.net/bzr-rewrite
<poolie> try bzr help rebase
<poolie> we should document that specific case
<yoroy> How do I find where bzr is intalled on OS X? Trying to get the Eclipse plugin working.
<C-Keen> yoroy: which bzr will tell you on a Terminal
<yoroy> C-Keen: forgot to mention I don't want to use a Terminal
<yoroy> :)
<yoroy> but I could handle it if I knew the command
<C-Keen> I don't understand
<GaryvdM> mgz: Ping
<yoroy> C-Keen: the eclips plugin asks me for the path to the bzr executable. I don't know how to find that path
<C-Keen> yoroy: well type 'which bzr' on a Terminal and you know
<yoroy> C-Keen: thank you
<mgz> pong garyvdm, but I'm leaving in five minutes, hopefully be around a bit later though
<GaryvdM> Hi mgz
<GaryvdM> The .pyo in the installer were fine
<GaryvdM> for plugins
<GaryvdM> but the .pyo that were created for plugins that I had in BZR_PLUGIN_PATH got doc strings removed
<mgz> did you see the log?
<GaryvdM> So if we could get the files in library.zip to be -OO
<mgz> you've not got the final part of my don't-recompile-plugin-pyo-files fix
<GaryvdM> but leave the exe as -O
<GaryvdM> Oh - were is that?
<mgz> you need the recent change to bzr setup.py and/or the third rev in the bzr-windows-installer merge proposal
<mgz> <GaryvdM> but leave the exe as -O <- if one of us can work out how to do this, it would also be good.
<GaryvdM> Ok - I find that an try a build...
<mgz> I saw the bug with recompilation and stopped investigating there, but getting the exe as -O would be good.
<GaryvdM> mgz: maybe build the library.zip ourselfs
<GaryvdM> Ok cool.
<mgz> there's probably a neater way, just didn't get as far as looking for it.
<GaryvdM> Thanks
<mgz> okay, leaving now.
<bobslee> hi, does bzr explorer install without a glitch on mac osx?
<GaryvdM> bobslee: The installer works well
<GaryvdM> bobslee: There are some polish issues on mac though - like the app name in the menu shows as "python".
<GaryvdM> bobslee: I'm also not sure if it installs a app icon, so either run "bzr explorer" from a terminal, or create a shortcut icon.
<bobslee> GaryvdM: ok thanx for info. But it requires a bunch of dependencies Qt, QBzr.. takes a while to install?
<GaryvdM> bobslee: Maybe you are reading a old info. The latest installers have every thing you need.
<GaryvdM> bobslee: http://wiki.bazaar.canonical.com/MacOSXBundle/SnowLeopard
<GaryvdM> bobslee: What version of Mac OS do you have
<bobslee> 10.5 (leopard)
<GaryvdM> bobslee: The 10.6 installer has everything, but for the 10.5 installer, you have to install Qt
<bobslee> GaryvdM: allrighty, thanx I'll give it a try
<GaryvdM> bobslee: http://wiki.bazaar.canonical.com/MacOSXBundle
<bobslee> GaryvdM: do you whether bzr supports reverse merging (like i.e. in svn: merge -r1000:993) ?
<GaryvdM> bobslee: yes
<bobslee> GaryvdM: I prefer to install bzr (explorer) via macports. Is that a good choice? - because I want to prevent dependency/upgrade nightmares..
<GaryvdM> bobslee: my experience no, but I don't use a mac much, so I would say investigate yourself.
<GaryvdM> bobslee: check if they have the latest versions...
<bobslee> GaryvdM: thanx again
<detritux> hi all. I've been trying to push my local modification to my launchpad project for a while but never succeeded: Transport operation not possible: readonly transport
<detritux> I added my ssh keys to launchpad and logged into launchpad from my bazaar explorer as described in one of the tuto
<detritux> any ideas?
<GaryvdM> detritux: Have you done 'bzr launchpad-login'?
<detritux> yes I did that in the bazaar explorer
<detritux> if I run it without any arguments it prints my login so I assume it worked
<GaryvdM> detritux: What is the url that you are pusing to.
<detritux> bzr+ssh://bazaar.launchpad.net/~ugocupcic/sr-ros-interface/trunk/
<GaryvdM> detritux: That's odd.
<detritux> :S yeah, I only found tutorials / forums and it seemed quite straightforward each time
<GaryvdM> detritux: could you please pastbin the relevant entry from ~/.bzr.log
<detritux> 0.173  bazaar version: 2.1.1
<detritux> 0.173  bzr arguments: [u'commit', u'-m', u'added dependency to robot_state_publisher for easier build.', u'shadow_robot/sr_hand/manifest.xml']
<detritux> 0.175  encoding stdout as osutils.get_user_encoding() 'UTF-8'
<detritux> 0.210  ssh implementation is OpenSSH
<detritux> 8.869  opening working tree '/home/genugo/Projects/st-ros-interface'
<detritux> 8.934  Traceback (most recent call last):
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 853, in exception_to_return_code
<detritux>     return the_callable(*args, **kwargs)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1055, in run_bzr
<detritux>     ret = run(*run_argv)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 661, in run_argv_aliases
<detritux>     return self.run_direct(**all_cmd_args)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 665, in run_direct
<detritux>     return self._operation.run_simple(*args, **kwargs)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 122, in run_simple
<detritux>     self.cleanups, self.func, *args, **kwargs)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 156, in _do_with_cleanups
<detritux>     result = func(*args, **kwargs)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/qbzr/lib/commands.py", line 788, in run
<detritux>     return run_subprocess_command(cmd, bencoded)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/qbzr/lib/subprocess.py", line 789, in run_subprocess_command
<detritux>     return commands.run_bzr(argv)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1055, in run_bzr
<detritux>     ret = run(*run_argv)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 661, in run_argv_aliases
<detritux>     return self.run_direct(**all_cmd_args)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 665, in run_direct
<detritux>     return self._operation.run_simple(*args, **kwargs)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 122, in run_simple
<detritux>     self.cleanups, self.func, *args, **kwargs)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 156, in _do_with_cleanups
<detritux>     result = func(*args, **kwargs)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 3138, in run
<detritux>     exclude=safe_relpath_files(tree, exclude))
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/decorators.py", line 192, in write_locked
<detritux>     self.lock_write()
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/workingtree_4.py", line 618, in lock_write
<detritux>     self.branch.lock_write()
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 2377, in lock_write
<detritux>     remote_tokens = self._remote_lock_write(token)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 2367, in _remote_lock_write
<detritux>     repo_token or '', **err_context)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 52, in _call
<detritux>     return self._client.call(method, *args)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/smart/client.py", line 132, in call
<detritux>     result, protocol = self.call_expecting_body(method, *args)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/smart/client.py", line 145, in call_expecting_body
<GaryvdM> detritux: Next time, please use something like http://pastebin.org/ when you paste :-)
<detritux>     method, args, expect_response_body=True)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/smart/client.py", line 81, in _call_and_read_response
<detritux>     expect_body=expect_response_body),
<mwhudson> detritux: paaaaaaaaaaaste bin
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/smart/message.py", line 306, in read_response_tuple
<detritux>     _translate_error(self.args)
<detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/smart/message.py", line 355, in _translate_error
<detritux>     raise errors.LockFailed(*error_args[:2])
<detritux> LockFailed: Cannot lock LockDir(lp-70455952:///~ugocupcic/sr-ros-interface/trunk/.bzr/branchlock): Transport operation not possible: readonly transport
<detritux> 8.934  Transferred: 1KiB (0.1K/s r:1K w:1K)
<detritux> 8.934  return code 3
<detritux> 411.969  Traceback (most recent call last):
<detritux>   File "_dirstate_helpers_pyx.pyx", line 1852, in bzrlib._dirstate_helpers_pyx._loop_one_block
<detritux> StopIteration
<iocor> oh my lord
<detritux> 417.318  return code 1
<detritux> a bit long, sorry :S
<detritux> sorry guys, I'll use pastebin next time
<mgz> is your launchpad username *not* ugocupcic?
<mgz> because you can't push to other people's branches.
<GaryvdM> mgz: /whois detritux = "Ugo Cupcic"
<GaryvdM> Seems like that is his user :-)
<detritux> yeah
<mgz> okay, that's me out. anyone else?
<GaryvdM> detritux: I just want to make sure about something. Please will you pastebin 'bzr info'.
<mgz> on his local branch rather than the lp one?
<GaryvdM> Yes
<GaryvdM> Ah - maybe bug 412657
<ubot5> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/412657)
<detritux> http://pastebin.org/385322
<GaryvdM> https://bugs.edge.launchpad.net/bzr/+bug/412657
<ubot5> Launchpad bug 412657 in Bazaar "update fails when trying to lock master branch (in a readonly checkout) (dup-of: 412223)" [Undecided,New]
<ubot5> Launchpad bug 412223 in Bazaar "bzr up locks master branch (affected: 2, heat: 4)" [High,Confirmed]
<mgz> that bug doesn't seem to have anything for cause or workaround...
<detritux> hm unbind / rebind I can try that
<mgz> oh, wait, bind/unbind/redo
<detritux> how do you unbind ?
<mgz> bzr unbind && bzr bind
<detritux> :D
<mgz> if that fixes it for you I'd wham an "affects me to" on that bug.
<GaryvdM> mgz: Can we chat re installer -OO?
<GaryvdM> time ok?
<mgz> yup, I'm back and lunched now
<GaryvdM> Cool - so I was building with all your patches
<mgz> ^or rather, affectsmetoo on the bug that one is duped against I guess
 * GaryvdM get branch urls to prove
<detritux> yeah I'll do that if it fixes it
<mgz> and... stuff still breaks?
<GaryvdM> Yes.
<mgz> meh, my timestamp checking lines are scrolled out of buffer
<mgz> I think I pasted them in here though...
<GaryvdM> mgz: The issues was that a plugin that was allready installed on disk from source in a manually set BZR_PLUGIN_PATH got compiled with -OO when bzr.exe ran.
<mgz> basically, need see if the mtime of the py file which complains is the same as the stamp in the packaged pyo file
<mgz> oh, that's possibly expected
<mgz> if it was never actually installed with optimize
<GaryvdM> mgz: when I did "set BZR_PLUGIN_PATH=" then it worked...
<mgz> one of the things I wanted to find out with that patch is if it's common to use from-source plugins with bundled installers
<mgz> which strikes me as dodgy compared to installing into the right plugin dir, but if non-devs actually do it...
<GaryvdM> mgz: So the only way that I see -OO viable is if we can get it so that library.zip is compiled as -OO but the .exe is not .
<mgz> if people actually do that, I agree (for the moment, a future way is just to mark up plugin cmd objects as well)
<GaryvdM> mgz: Your patches to prevent pyo recompile are still valuable though...
<mgz> I'll poke around in py2exe
<GaryvdM> mgz: How much difference does -OO make compared to -O?
<GaryvdM> mgz: I think it would be good to try measure.
<mgz> not much, a couple of megs to library.zip and a fractional cold startup improvement
<mgz> Alexander did a couple of tests at UDS for me when we were merging it
<mgz> https://code.launchpad.net/~gz/bzr/support_OO_flag_installer/+merge/24484
<GaryvdM> mgz: the branches that I built with: lp:~garyvdm/bzr-windows-installers/maybe and lp:~garyvdm/bzr/2.2b3+packing
<GaryvdM> The latter now has the org -OO patch reverted.
<mgz> dod you know if there'll be a 2.2b4 from the current trunk?
<GaryvdM> Bla - lp is sloooow at the moment.
<GaryvdM> mgz: according to https://edge.launchpad.net/bzr/2.2 - yes
<mgz> is that lp's fault or your undersea cable's?
<GaryvdM> Oh yeah - I forgot about that.
<mgz> okay, reading py2exe source, doesn't seem to be a configurable way of doing it, but could easily chop it in
<GaryvdM> mgz: 7.7% faster cold start - Ok - that makes it worth it ...
<GaryvdM> mgz: We could also maybe look at which plugins we can do a -OO on, and which not...
<mgz> well, it's not a big job to just fix them all
<mgz> but messing with py2exe looks amusing
<GaryvdM> mgz: Would it work  if we ran byte_compile(optimize=2) for everything going it to library.zip, and then did py2exe with optimize=1 .
<GaryvdM> mgz: or does it compile from scratch?
<mgz> nope.
<mgz> sec, I'll give you a diff to try
<mgz> http://paste.ubuntu.com/460272/ < how about that for a horrible hack
<GaryvdM> Not to bad.
<detritux> GaryvdM: ah I found my real problem in fact. You can't commit on a branch that's being pulled from a svn. That's logical... thanks for your help
<GaryvdM> mgz: Suggestion: In build_executable, remember what optimize was, and then restore it.
<mgz> I started writing that, then I looked at the diff context and decided it was silly
<mgz> really that's a sensible setting we want to keep, so would be best to get a proper version upstream
<GaryvdM> mgz: +1 for upstream.
<mgz> ...last release was 2008
<mgz> I've got theller to look at patches before though so can probably get it in svn at least
<GaryvdM> Very useful: http://pastebin.org/385361
<mgz> yeah, methods are bound late, get a different object back each time
 * GaryvdM goes to find food.
<lifeless> vila: hi
<lifeless> vila: Is it true, a fix for the locking thing is in 2.1 branch? if so, we should get it into the LP tree
<elmo> blah, what's the bzr push trick to push to where I just branched from?
<elmo> I thought it was bzr push --parent, but it's not that
<james_w> push :parent
<elmo> james_w: thanks
<lifeless> james_w: hi
<james_w> hi lifeless
<lifeless> I've pushed up a test
<lifeless> I'm going to try and get some more love in place today and tomorrow
<lifeless> I can has review? [or is it buried in my email overnight?)
<james_w> lifeless: I'm in the middle of looking at it
<james_w> it looks broadly fine
<lifeless> \o/
<lifeless> thanks
<lifeless> I realise the test style is a fresh one
<lifeless> its not quite -right- but its broadly where I want things to be
<lifeless> I think its fairly readable ?
<james_w> I don't think you need to use dh-make, but I can understand that working out the needed steps might be a bit much
<lifeless> james_w: if you want to give me a recipe to slot into that fixture, great.
<james_w> yeah, it's fairly readable
<lifeless> I was fighting a bit of an uphill battle at the time ;)
<james_w> it's not what I would expect fixtures to be used for really
<lifeless> thats interesting
<james_w> well, at least say the FileMovedReplacedUpstream part
<james_w> I would expect to have something like BranchBuilder, where you call methods, rather than compose fixtures
<james_w> I'm happy to see how this develops though
<lifeless> great
<lifeless> I'll use these as a basis for the next patch too then
<lifeless> its why I wanted to get this one seen to rapidly, to avoid a big pile of 'nooo' from you :)
<james_w> heh
<james_w> I just think that the method calls would make reading the intent of the test easier, but let's find out
<lifeless> it would be nice
<lifeless> (perhaps)
<lifeless> to do @with_fixture(fixture_description_here)
<lifeless> thats kindof the philosophic reason for making it all declarable rather than procedural
<lifeless> one of the .. reasons
<lifeless> another is to be able to switch out implementations very easily, a BranchBuilder is more monolithic, so you would switch out all at once rather than granularly.
<davidstrauss> How can I make Loggerhead only bind to localhost?
<davidstrauss> nvm
#bzr 2010-07-08
<poolie> hi jam, spiv, lifeless
<lifeless> hiya
<spiv> Morning.
<poolie> hi spiv
<poolie> spiv, i'm preparing my session for the epic
<poolie> what are you up to today
<spiv> poolie: working on bug 522637, there seems to be some disagreement between a repo and its fallback about the CHK roots for an inventory (and as a tangent having some ideas on a new hpss verb)
<ubot5> Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 11, heat: 58)" [High,In progress] https://launchpad.net/bugs/522637
<spiv> poolie: then thinking about the epic
<poolie> ah that sounds good :)
<poolie> i'm just about to propose we fork off 2.2 and do 2.2b4
<poolie> i want to make the branch allow at this point non-bugfix changes but no api breakage
<spiv> Or at least controlled API breakage :)
<poolie> i wonder if having it be different to released stable branches will cause confusion
<poolie> no intentional api breakage :)
<poolie> actually i think not even any deprecations
<poolie> but having an 'api freeze' phase is not unprecedented
<jbowtie> I just got approval from legal to release my Bazaar plugin.
<jbowtie> I'm planning on pushing it to Launchpad under GPLv2 or later; any best practices for publishing plugin projects?
<lifeless> generally they are found on LP in bzr-pluginname projects
<lifeless> often people put them in the 'bazaar' project group, which gives ~bzr (the broad set of developers of bzr and its plugins) access to do bug triage etc
<lifeless> and sometimes people make the trunk branch owned by ~bzr or a dedicated group which ~bzr is in, so that other folk can update the plugin when API changes break it.
<lifeless> these are all optional voluntary things of course
<jbowtie> lifeless: Thanks, the 'bazaar' project group stuff I didn't know.
<poolie> lifeless: i was just wondering why you declined bug 522637 for 2.0 and 2.1
<ubot5> Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 11, heat: 58)" [High,In progress] https://launchpad.net/bugs/522637
<poolie> is it infeasible to fix there?
<lifeless> checking
<lifeless> poolie: it was ages ago that I declined it
<lifeless> the UI kind of encourages 'propose for' on *problems* but perhaps its *solutions* that should be proposed.
<lifeless> its the conflation between bug exists and will-fix-in again.
<poolie> maybe so
<lifeless> ...anyhow... I suspect the fix will be non trivial
<poolie> well, i guess the merge can be proposed to either
<lifeless> but spiv is working on it I think ?
<poolie> but it may be nice to say "we want to try to fix it in 2.0."
<poolie> he is
<poolie> if he think it's easy to backport
<poolie> we can do that
<poolie> was just curious
<lifeless> I'd get the fix and then make an assessment of that.
<poolie> yep
<EdWyse_Home> Is there a way to convert a lightweight checkout to a heavyweight one? or do I just have to re-checkout the whole thing?
<lifeless> bzr reconfigure --checkout, I think.
<EdWyse_Home> Close enough... Thanks
<jbowtie> There we go... https://launchpad.net/bzr-tfs
<lifeless> \o/
<jbowtie> It's a pure python solution, too (relies on python-ntlm for authentication) - means it works nicely on Linux, not just on Windows.
<jbowtie> I suppose now I need to write some documentation, and tests, and so on...
<lifeless> thats really cool
<lifeless> poolie: brief call ?
<poolie> lifeless: hi, sure
<lifeless> could you ring my NZ house # ?
<thumper> how do I cherry pick a revision?
<lifeless> merge -c revno branch
<thumper> ta
<thumper> jbowtie: that's pretty cool
<thumper> jbowtie: I don't suppose you are looking at a visual studio plugin are you?
<jbowtie> thumper: Not for a while, too many other things on my plate.
<parthm> i am seeing some weird error on pqm for the bad-pattern patch. http://dpaste.com/215805/ .. the tests pass locally.
<parthm> any ideas?
<parthm> the pqm-stderr has this http://pastebin.com/Fn6zSE79
<spiv> parthm: those pastes don't give many clues :(
<parthm> spiv: i am downloading pqm-stdout to see if that has something.
<lifeless> look at the end of pqm-stdout generally
<parthm> is there a quick pattern i can search for? the summary shows 3 failures: http://pastebin.com/XL5NHXu7 ... its difficult to different expected tracebacks from actual failures.
<lifeless> have you got subunit installed ?
<parthm> lifeless: yes. '/usr/lib/python2.6/dist-packages/subunit/__init__.pyc'
<parthm> is DeprecationWarning considered an error? .. http://pastebin.com/V8kEyB1z
<lifeless> parthm: 'gunzip -c pqm-stdout.gz | subunit-filter --no-skip | subunit2pyunit'
<parthm> lifeless: i don't have subunit-filter and subunit2pyunit. where can I get that?
<lifeless> parthm: apt-get install subunit
<parthm> lifeless: thats pretty neat. http://pastebin.com/hJ98AauT
<parthm> bt.test_globbing and bt.test_osutils seem to work fine locally.
<parthm> for re_compile_checked the only difference is that its deprecated now. test results: http://pastebin.com/B5JaL8k9
<spiv> parthm: IllegalUseOfScopeReplacer means lazy_import is involved
<spiv> parthm: which suggests that it might be sensitive to the exact order imports happen :/
<spiv> (And so presence/absence of plugins could affect that)
<parthm> spiv: ah yes. i see the error now.
<parthm> spiv: there is a direct import (not lazy) "from bzrlib.trace import ( errors, ...)" ... note the trace.
<parthm> spiv: interestingly it passes locally. i don't know why.
<lifeless> plugins
<parthm> spiv, lifeless: the import errors is for globbing.py .. forgot to mention.
<parthm> i suspect that will fix the scope error. any idea on the re_compile_checked error?
<spiv> parthm: regardnig globbing.py, that is pretty weird that lazy_import is involved in the traceback when it's not used in that file.
<parthm> spiv: yes. its surprising. also, the tests passing (locally) with that is weird.
<spiv> parthm: regarding the deprecation, I think pqm runs python with -Wall, which means warnings are raised as errors, including deprecations
<spiv> The docs on writing tests should explain how to write tests for deprecated functions (i.e. how to expect a deprecation from a particular call)
 * parthm goes digging into testing docs for deprecation.
<spiv> (I mean "should" in the sense of "I do not know if they actually cover that, but if they don't then please file a bug and/or fix that" :)
<spiv> If they don't, you should be able to grep the test suite for how other tests do it.
<parthm> spiv: its not mentioned in the testing doc. but HACKING.txt mentions "TestCase.applyDeprecated" without much explanation. i will file a bug for updating the testing doc.
<spiv> parthm: thanks :)
<parthm> spiv, lifeless: thats for the help in locating the issues :) ... i will try to land this again once these are fixed.
<poolie> hi spiv, parthm
<parthm> poolie: hi
<vila> hi all
<lifeless> hiya
<parthm> looks like another error. http://pastebin.com/Z4qRJUGX ... looks like re.compile is calling python2.4 re.compile directly and not the lazy one. test passes locally (python2.6)
<parthm> lazy re_compile: http://bazaar.launchpad.net/~parthm/bzr/300062-bad-pattern-error-part-1/annotate/head:/bzrlib/lazy_regex.py#L61
<parthm> compile failure should be raising InvalidPattern and not re.error. any ideas?
<parthm> lifeless: just saw the mail on your move to launchpad. congratulations and thanks for all the reviews and piloting :) good luck.
<lifeless> thanks!
<parthm> hmm. i ran the test with python2.4 and didn't see any problem. so its not python related.
<lifeless> parthm: have you tried with --no-plugins ?
<parthm> lifeless: yes. i am running it with no-plugins. the tests pass locally with 2.4 and 2.6.
<parthm> looks like re is not being lazy on babune. the stack trace doesn't seem to be going through lazy regex http://pastebin.com/Z4qRJUGX
<lifeless> mmm
<lifeless> vila: ^ :)
<parthm> does the test generate a .bzr.log with exception details?
<parthm> vila: "python -Wall ./bzr --no-plugins selftest -v -s bt.test_osutils.TestReCompile" passes locally but fails on pqm.
<vila> parthm: what os are you using ?
<lifeless> parthm: oh
<lifeless> parthm: run other tests that use re perhaps ?
<lifeless> parthm: I suspect you're running into a test isolation issue of some sort.
<parthm> vila: ubuntu 9.10
<lifeless> possibilities: something puts the real re back; something triggers the regex you expect to be lazy before your test runs (solution, use your own private re), $something else.
<parthm> lifeless: thats the only test thats failing now (even on pqm). rest all pass.
<lifeless> parthm: great.
<lifeless> bbiab
<vila> parthm: babune is not supposed to change anything regarding loading python modules (the mere thought of it scares the hell out of me)
<parthm> vila: is pqm on babune or is it a different system. just curious.
<vila> parthm: nah, pqm is a totally different host/chroot/etc
<parthm> oh ok. then its what i am seeing on pqm. babune is fine :)
<vila> But is pqm still running 2.4 ?
<parthm> vila: yes. thats what the error shows http://pastebin.com/Z4qRJUGX
<parthm_> sorry. i dropped off.
<parthm_> this is the failing test case. http://bazaar.launchpad.net/~parthm/bzr/300062-bad-pattern-error-part-1/annotate/head:/bzrlib/tests/test_osutils.py#L1718
<parthm_> maybe its playing badly because i now have assertRaises + applyDeprecated together.
<parthm_> but interestingly it works ok locally.
<spiv> parthm_: have you tried 2.4 locally?
<parthm_> spiv: yes. it passes with 2.4 as well as 2.6.
<spiv> I doubt assertRaises or applyDeprecated would interact or otherwise be the cause.
<spiv> Perhaps the deprecation decorator itself is involved?
<spiv> Though that seems a bit unlikely too.
<vila> parthm: too many interacting stuff here to diagnose remotely without reproducing :-/
<parthm> vila: yes :( ... will see if i can try to reproduce it locally.
<vila> parthm: generally, a test subset pass but not the whole test suite, you need to first run the full suite locally to see if *that* reproduce it
<parthm> vila: makes sense. i will try to do that.
 * parthm fires the full test suite
<vila> lifeless: hmpf, best wishes for your new role but while this isn't fully unexpected it makes me sad :-(
<parthm> i am starting to get the "can't start new thread" errors. is there something i can do? i am already using --parallel=fork.
<vila> parthm: bump BZR_CONCCURENCY up
<vila> BZR_CONCURRENCY
<parthm> vila: what should i set it to? i have two cores.
<vila> the precise value is: it depends :->
<vila> I'd try with 4 then 6 or 8 depending on available resources
<vila> parthm: be ready to ^C it if it start swapping like hell
<parthm> vila: at the moment its not set. ok. i will try with 4. hopefully my 1gb ram won't be an issue. maybe its time for an upgrade :)
<vila> 1GB seems a bit short, all babune slaves have 2GB
<parthm> ok. everything seems ok till now ... 1500 tests. ... and its fast :)
<vila> parthm: hehe, it sure is :)
<lifeless> vila: THANKS
<lifeless> bah
<lifeless> thanks
<parthm> vila: yup. the error is reproducible half way through the full suite run. now i just need to figure out whats causing the laziness to go away.
<parthm> forcing lazyness seems to fix the problem http://pastebin.com/b5csDHQd .. while not the _right_ solution, i feel it should be ok as the api being tested is deprecated anyway and is not used.
<parthm> should i be filing a bug for test isolation?
<lifeless> night
<GaryvdM> Hi all - Why do I get this error: http://pastebin.org/386377
<GaryvdM> Which differs from the documentation: http://docs.python.org/release/2.6/library/threading.html#id1
<GaryvdM> Ah - nvm - must just do lock.acquire(False), not lock.acquire(blocking=False)
<mgz> hey Gary. where are you at with the installers? is 2.2b3 is a finished-ish state?
<GaryvdM> Hi mgz
<mgz> hey.
<mgz> I'm just writing up a message for the list, can you read it before I post to make sure it makes sense?
<GaryvdM> mgz: 2.2b3-2 does the -OO backed out...
<GaryvdM> let me try again..
<GaryvdM> mgz: 2.2b3-2 is built with your org  -OO patch backed out...
<mgz> need to leave in an hour, won't be around again till Tuesday, so make any final choices on that for me
<GaryvdM> mgz: I would like to try you py2exe hack
<GaryvdM> mgz: Ok - I'm only going to start trying to build 2.2b4 next week any way
<mgz> ah, cool.
<GaryvdM> So - yhea - 2.2b3 probably  won't get any more bulids....
<GaryvdM> (from me)
<GaryvdM> mgz: I was just about to go to ice hockey practice, so I will only be able to read your mail much later.
<mgz> ah, I'll just post it when I'm done then.
<GaryvdM> ok
<GaryvdM> mgz: What is it re?
<mgz> what plugin authors need to know about docstring stripping
<mgz> bascially summing up what's been said in the merge proposal and in here the last few days
<GaryvdM> Oh - ok.
<GaryvdM> mgz: I just want to make sure that we are on the same page with the -OO issue: We want to get it so that library.zip is -OO, but the exe's are -O.
<mgz> ideally, yup.
<GaryvdM> mgz: ok cool.
<GaryvdM> bye
<mgz> urk, running out of time
<mgz> okay, email sent, and I'm leaving
<mgz> as did it in a hurry, probably full of mistakes, feel free to correct me on things
<mgz> back Tuesday.
<LeoNerd> I don't suppose there's much by way of bzr/perforce integration, is there?
<rockstar> LeoNerd, I know some Nvidia folks that are doing it, but I don't think it's publicly available.
<LeoNerd> Right.. ahwell
<james_w> LeoNerd: there is https://code.launchpad.net/bzrp4
<james_w> no idea what state it is in
<idnar> what are branch nicknames for?
<chaosaddict> It seems like with a large repository (6000 commits, 40gb of files+history), routine commands take about an hr to return and use up all available memory. Does anyone know if this is a known issue and if it will be fixed in the future? I'm looking into migrating from Perforce to Bazaar for my company, but right now it looks like it would be much too costly.
<idnar> is there an easier way to do "bzr merge -r before:ancestor:trunk.. feature-branch"?
<mkanat> chaosaddict: I think one of the problems there is that most VCSes don't expect to be storing enormous binary blobs.
<mkanat> chaosaddict: It is a known issue, though, that bzr uses up a lot of memory when dealing with large files.
<mkanat> chaosaddict: I'll take a wild guess and say that this is a VCS for a game?
<mkanat> Those are the only people I know who store enormous binary blobs in the VCS, are game developers.
<mkanat> I understand why, it's just not something that most VCSes are geared toward.
<mkanat> idnar: They show up in the log history.
<mkanat> idnar: So you can tell what branch a commit was made on.
<idnar> okay
<chaosaddict> mkanat: It's not for a game. I think we just have a lot of files. It's been complicated by Perforce storing branches as copies of files, so we often have maybe 30 copies of the same file.
<mkanat> chaosaddict: All right. But a single checkout is 40GB?
<mkanat> chaosaddict: Or just the history is 40GB?
<chaosaddict> mkanat: I imported all the code for one product, which probably has multiple logical projects that would normally be tracked separately in bazaar. Additionally, there are maybe 20 branches, that have no concept of a main trunk, so all the files are duplicate each time. The fast-import dump file was 30gb, and the resulting bazaar repository after import is 40GB for all the files, with the history.
<mkanat> chaosaddict: Hmm. I wonder if you'd want to somehow hack up the importer to understand that some of those files have a common history.
<chaosaddict> I think it did a good job of replicating what was in Perforce. I'm not quite sure how I would fix it. Maybe split off each branch into its own bazaar repository and merge it back into a main branch to preserve the history.
<mkanat> chaosaddict: Well, if they have identical files, that won't work.
<mkanat> chaosaddict: Because bzr doesn't recognize files by name, but by an internal id.
<chaosaddict> mkanat: ah. So if the files don't have the same origin, as far as Bazaar knows, then they can't be merged with history preserved? We have fields in the files that Perforce updates with revision numbers and date submitted, etc, so the files won't even hash to the same value, even if they were the same as far as Perforce was concerned.
<mkanat> chaosaddict: Right.
<mkanat> chaosaddict: The importer has to understand from the start that those files have a common history.
<lifeless> morning
<chaosaddict> good morning
<detritux> hi
<hicham> bzr is acting weird when cloning a repo from lp
<hicham> i have 50 MB of history for a 15 revisions branch, and it not finished yet
<EdWyse_Office> Is there a way to fix an InconsistentDelta?
<EdWyse_Office> I can find a lot of things that tell how to get to that state, but nothing about how to repair from it.
#bzr 2010-07-09
<lifeless> EdWyse_Office: depends on where its happening
<lifeless> EdWyse_Office: where is it happening
<EdWyse_Office> on a commit
<lifeless> there are two likely possibilities
<spiv> Good morning.
<lifeless> a) your dirstate is already damaged, so we need to replace it.
<lifeless> b) you've found a new bug: congratulations.
<lifeless> EdWyse_Office: what bzr version do you have?
<EdWyse_Office> Not sure if that's entirely what you're asking for, but my user made a bunch of changes, and when she commits, there's a huge error message that's all about inconsitent delta.
<EdWyse_Office> hehe
<EdWyse_Office> thanks
<EdWyse_Office> 2.0.3
<lifeless> I *think* that has the various fixes in it. Did you start with that version, or has your user been using bzr for a bit ?
<EdWyse_Office> This user has been using this version since the start.
<lifeless> ok
<lifeless> uhm
<EdWyse_Office> I'm leaning toward bug now... I've committed directories one-at-a-time and am succeeding (so far).
<lifeless> if we can get a copy of the dirstate and the commit command that was failing, that would help use determine the bug
<EdWyse_Office> I hate windows. (ugh)
<lifeless> this would disclose file paths to the devs, but not file content.
<EdWyse_Office> There's nothing you couldn't see by visiting our web site anyway.. hehe.
<EdWyse_Office> well that's much better. I got it down to one file causing the problem.
<EdWyse_Office> So you're asking for .bzr/branch-lock/dirstate, correct?
<lifeless> .bzr/checkout/dirstate
<EdWyse_Office> oops, yeah, that's what I meant. :D
<EdWyse_Office> Ah, I see... so if the file in question isn't even in dirstate, that might be my problem.
<lifeless> well
<lifeless> you are getting an error that is opaque
<lifeless> so we should fix it
<lifeless> dirstate + the command that fails + a 'bzr st' -> enough data for an engineer to fix, I think.
<lifeless> hi spiv
<spiv> Hey lifeless.
<chadrik> hi all, i've got a couple of quick questions about bzr. anyone here want to field them?
<spm> chadrik: your best bet is to just ask them. if someone is willing and able to answer they will.
<chadrik> i need to version control some very large files. git's loose object store is very well suited to this purpose, but i would really prefer a user-friendly dcvs written in python
<mkanat> It's amazing how three people have come and asked that question today.
<chadrik> mercurial is just too slow and wasteful with large files: renames cause duplicate data (and time associated with this), and delta compression wastes time.
<chadrik> haha
<mkanat> chadrik: bzr is also currently rather wasteful, last time I checked.
<chadrik> so, i come to bzr with the hopes of finding a middle ground
<mkanat> chadrik: It's something that should hopefully be improved in the future.
<mkanat> chadrik: The problem that I know about right now is that bzr uses RAM in an amount somewhere between 3x and 6x the size of the largest file it deals with.
<chadrik> hg has similar problems.
<mkanat> I think lifeless or jam was talking about doing something about it. Or maybe it was somebody else; I forget.
<chadrik> in reading through the docs, it seems that bzr is designed in such a way that it is possible to add new storage formats
<chadrik> i imagine this is quite a bit of work
<spiv> It is.
<spiv> There's a bug about the excessive memory consumption when dealing with large files.
<chadrik> but it is designed to be able to use different models? is this correct?
<chadrik> so it would be feasible to implement a model designed specifically to handle large files?
<spiv> The short answer is we know how to fix it, but it's a fair bit of work and not a priority for Canonical staff at the moment (our priority is making bzr handle source code really really well).
<spiv> Definitely; see the bug for some discussion.
<chadrik> for me, the memory thing is only part of the problem.
<spiv> (I think it would be feasible to implement a format that copes well with large files with no significant penalty for smaller files)
<chadrik> 90% of what i need to version control are large binary files, many over 1GB
<chadrik> before i go further with this, let me ask a couple of basic questions
<chadrik> does bzr currently use deltas for large files?
<chadrik> spiv: where can i find the bug?
<chadrik> my hope is to create a storage format like git's loose object store, but where the file/blob data is left completely unchanged. blobs in the store will be read-only, such that they can safely be hard linked or symbolically linked into the working directory
<rubbs> chadrik: IIRC this is the bug you're looking for: https://bugs.launchpad.net/bzr/+bug/109114
<ubot5> Launchpad bug 109114 in Bazaar "[master] bzr holds whole files in memory; raises MemoryError on large files (affected: 21, heat: 188)" [Medium,Confirmed]
<chadrik> rubbs: thanks
<rubbs> np, it could be wrong, but I think that is the onw spiv was talking about
<chadrik> looking now. def looks like the one
<rubbs> It's been a while since I've been involved with bzr as a project. Work and other pressing projects have taken my time, so I'm more or less out of touch.
<rubbs> I lurk here so I don't get left too far behind ;)
<chadrik> i've come to realize that what i need is just too specific to expect to find it natively in a dcvs.
<chadrik> i guess i'll look into what is necessary to implement a new storage model
<rubbs> AFAIK it's pretty hard, but it might be worth trying. The devs here would help you out I think. It could be useful for other too.
<chadrik> have you heard of dulwich?  it's a pure-python implementation of the git object model
<chadrik> my goal would be to use it to drive the new storage model
<lifeless> git has the same problem chadrik
<lifeless> bzr's core is plenty sufficient to implement sharding of large files on
<chadrik> lifeless: do you mean the memory consumption?
<lifeless> yes
<chadrik> my use case is pretty specific since i will be working almost entirely with non-mergable binary files
<chadrik> effectively, i'll just be copying files into the store. i'll just need to read them in order to generate a hash
<chadrik> merging is simply a matter of choosing A or B
<chadrik> once the files are in the store they are made read-only.  then they can be symlinked or hard linked into the working copy
<chadrik> specifically, my use case is this: provide many users read-only access to large binary files on a local file system
<lifeless> poolie: ring whenever
<cpsmusic> Hi
<cpsmusic> I'm new to Bazaar
<cpsmusic> But I've worked with SVN
<cpsmusic> I have a question
<cpsmusic> I've setup up a branch of a project on Launchpad
<cpsmusic> But I can't figure out how to check it out
<cpsmusic> I keep getting an error msg saying
<cpsmusic> bzr: ERROR: Not a branch:
<parthm> cpsmusic: what is the command you are using?
<cpsmusic> the branch is at
<cpsmusic> lp:~cpsmusic/pencil/audio
<cpsmusic> I've tried
<cpsmusic> bzr branch lp:~cpsmusic/pencil/audio
<cpsmusic> also
<cpsmusic> bzr checkout lp:~cpsmusic/pencil/audio
<parthm> cpsmusic: the branch page ( https://code.launchpad.net/~cpsmusic/pencil/audio ) says "This branch has not been pushed to yet."
<cpsmusic> yep I saw that
<cpsmusic> what does it mean
<parthm> looks like you created the branch with the webui (?). you will need to push it up.
<cpsmusic> i thought pushing was like committing changes
<cpsmusic> ah
<parthm> if its new content, you should be able to bzr init; and bzr push lp:~cpsmusic/pencil/audio
<spiv> cpsmusic: how did you create the branch on Launchpad?  Typically if you are starting a project you just "bzr init" a directory locally, make and commit some changes, then you "bzr push" to publish that branch to somewhere like launchpad.
<cpsmusic> it's a branch of project that's already on Launchpad
<cpsmusic> I used the web pages
<spiv> Ok, if you want to make a branch of an existing project, it's just "bzr branch $existing_branch" to your local system, and when you have changes locally you want to publish, "bzr push" them somewehre
<cpsmusic> I used "Register a branch" on Pencil's Code page
<cpsmusic> Ah, I see
<cpsmusic> I thought that once I made the branch I'd have to checkout from it.
<spiv> The "Register a branch" link is an attractive nuisance for branches you are making yourself :(
<spiv> You don't need to register it in advance at all, you can just push to create the branch on Launchpad.
<maco> git user?
<spiv> SVN, apparently.
<spiv> Are you thinking it's confusing vs. how github operates?
<maco> well i remember keybuk getting all upset about how git's hard to use because you have to *do things* on the remote server before pushing, unlike bzr
<spiv> Ah right.
<cpsmusic> the thing I found confusing was that once "Registered a branch" I thought there would be a complete branch
<cpsmusic> It's actually just a placeholder until the first lot of code is pushed into it - is that right?
<lifeless> yes, don't use it in fact,.
<lifeless> its something we want to delete
<parthm> cpsmusic: i never use the "register a branch" feature. to branch from existing project, I tend to use 'bzr branch lp:proj && hack && bzr push lp:~username/proj/branch-name'
<cpsmusic> I'm new to Launchpad and Bazaar - it was the first thing I saw
<cpsmusic> and I was told to make a branch there by one of Pencil's devs
<lifeless> yeah
<lifeless> its confusing
<lifeless> thats why we want ot remove it ;)
<parthm> i was going through the large file mail on the mailing list and decided to do a 'bzr mv' experiment with a 100MB file. http://pastebin.com/G5vqByFM
<parthm> i was surprised to find that the mv increases the space used by the file size. is this expected? i was under the impression that files moved are meta data.
<parthm> ^ s/space used/size of .bzr/
<lifeless> parthm: ?
<parthm> lifeless: hi
<parthm> lifeless: i was just wondering why the space usage goes up. i know bzr as first-class support for files so i thought mv would probably be some meta-data update. is that not the case?
<lifeless> what do you mean by space usage goes up
<fullermd> Don't commits just always store fulltexts of every file touched?
<lifeless> fullermd: yes, because snapshot based.
<maco> should just store a diff
<spiv> lifeless: see his paste; 'du -hs .bzr' goes up
<lifeless> oh
<lifeless> parthm: do a bzr pack
<parthm> lifeless: for a 100mb file the mv makes .bzr go from 100mb to 200mb
<fullermd> Yes, but I mean physically storing fulltexts, not delta compressed 'till pack.
<lifeless> fullermd: yes, exactly.
<parthm> the file doesn't compress as its /dev/urandom data.
<lifeless> parthm: every time a file changes we store the file under (fileid, revisionid) in our tuple space.
 * parthm runs pack command.
<parthm> lifeless: i haven't changed the file. its just a mv. http://pastebin.com/G5vqByFM
<spiv> lifeless: where "changes" includes metadata changes, I presume?
<lifeless> yes
<lifeless> spiv: a refactoring I considered, but deferred in the 2a work was to separate 'inode data' and 'content data'
<parthm> lifeless: neat. pack brings the size down to 101MB again http://pastebin.com/2Gv4NFHh
<lifeless> spiv: which would have made a mv an inode-data only change, and not stored a text at all; the per file graph would be more capable there etc
<parthm> lifeless: thanks
<lifeless> hmm
<lifeless> spiv: do 'bzr help other-formats' for me
<lifeless> spiv: what do you see?
 * lifeless hates regressions
<spiv> lifeless: no formats
<spiv> Which does indeed sound like a regression.
<parthm> spiv, lifeless: so should the .bzr size not be going up in the first place?
<spiv> lifeless: separating out the inode data does sound attractive.  Why was that deferred, just lack of tuits?
<lifeless> spiv: yeah
<spiv> Yeah, I'm not surprised :)
<lifeless> spiv: which was accurately judged in hindsight.
<spiv> Agreed :)
<lifeless> parthm: it should because you changed the inventory entry for the file. And that means it stores a copy of the file.
<lifeless> parthm: then, when you pack they are identical and it just references a single compressed version
<parthm> lifeless: ok. that makes sense. i was wonder what regression you were referring to.
<lifeless> parthm: 'bzr help other-formats' should list rich-root-packs and other things like that
<parthm> lifeless: oh. ok.
<parthm> separate inode-data and content-data would have been really cool.
<vila> hi all
<vila> parthm: where are you  ?
<swathanthran> bzr documentation site is down?
<lifeless> shouldn't be
<swathanthran> oh ok, pdnsd was down here
<detritux> hi. I have a problem: I just pulled my branch from launchpad and all my files are not writable (even if I do a chmod +w on them)
<detritux> -rw-r--r--  1 ugo ugo 2426 2010-07-09 08:57 CMakeLists.txt
<detritux> chmod +w CMakeLists.txt
<detritux> -rw-r--r--  1 ugo ugo 2426 2010-07-09 08:57 CMakeLists.txt
<detritux> any idea?
<mwhudson> well, that's writeable by you now
<mwhudson> but not by people only in the 'ugo' group or random others
<mwhudson> this seems mostly sane...
<detritux> it's writeable by root only
<detritux> my bad... it's my emacs that's acting crazy: I have the correct permissions, but I can't edit it with emacs... have to look into that
<detritux> cheers
<vila> detritux: smells like a backup directory owned by root which forbids emacs to create backups, oh wait, you're not here aymore to read that :-/
<vila> I so love people asking questions in write-only mode :)
<mwhudson> yay
<Kennef> hi
<Kennef> I have a problem installing bzr, could someone help me ?
<Kennef> I install it correctly on my Ubuntu
<Kennef> and then when I launch it, it segfaults
<Kennef> I have absolutely no idea of what the problem could come from
<Kennef> nobody ?
<maxb> You have not given much information - people would need to know 1) exactly how you installed it, and 2) exactly how it's crashing, to have a reasonable chance of starting a diagnosis
<Kennef> ok sorry for that
<Kennef> I installed it by adding the ppa to my system (add-apt-repository ppa:bzr/ppa), and then sudo aptitude update and sudo aptitude install bzr-explorer
<maxb> The best way to attract help on IRC is to make it easy for people glancing at the channel to quickly decide whether helping you lies within their skill set :-)
<Kennef> and the crash has nothing special, I just "bzr-explorer" in my shell and it answers me "segmentation fault"
<Kennef> :/
<Kennef> (being right back, my boss pays me meal)
<maxb> I am unfamiliar with bzr-explorer, try checking whether plain bzr works
<spiv> Kennef: that's pretty strange, please file a bug with those details.  My best guess from the info so far is something mismatch with the python-qt bindings.
<Kennef> maxb: with my shell, bzr works perfectly, I can pull / push / branch without any problem. I will use that mean to work while I'm trying to find where the problem comes from
<Kennef> spiv: I will do that, thank you for the advice
<thrope> how do I get my working tree to be at an earlier revision?
<thrope> bzr checkout -r 423 gives an error file exists
<parthm> thrope: bzr update -r
<thrope> cool thanks
<parthm> jam: ping
<thrope> any loggerhead folks here? commit 424 breaks support for python2.4 (uses defaultdict)
<thrope> not sure if you're planning to support python2.4 but as its still default on centos (as far as I know) I'd vote to keep it
<parthm> thrope: bzr supports 2.4 so i would assume loggerhead would support it too.
<thrope> ill file a bug then
<jam> hey parthm
<parthm> jam: hi
<parthm> jam: i was able to reproduce bug #603461 ... its python2.5 specific. i will look into fixing it.
<ubot5> Launchpad bug 603461 in Bazaar "bzrlib.tests.blackbox.test_log.TestLogErrors.test_log_bad_message_re failing (affected: 1, heat: 6)" [High,In progress] https://launchpad.net/bugs/603461
<jam> parthm: thanks
<jam> also, we should watch out for the "unprintable" exception
<jam> We might want to use "assertNotContainsRe"
<jam> as we want to make sure the exception can be printed
<parthm> jam: ok.
<jam> parthm: are you working on that now?
<jam> I would like to get it into the 2.2b4 code if possible
<jam> which I want to release today
<parthm> jam: regarding bt.test_errors, is that only for format check? i am wondering if the test case should import re and check assertion or just raise InvalidPattern("message") and check formatting
<parthm> jam: yes. i can look into it now. i don't think it will be a big fix.
<jam> thrope: so there was a brief discussion about this, but we now also depend on sqlite directly, which is bundled with python2.5+
<jam> so if someone wants to put in the effort for 2.4 compat, we would probably take it
<jam> but it isn't a strict focus like it is for bzr
<jam> parthm: test_errors is generally just formatting tests
<jam> fairly low-level testing
<jam> it catches stuff like parameters that aren't passed correctly, etc
<parthm> jam: sounds fine. i will add that also.
<parthm> jam: ok.
<thrope> jam: fair enough - have to look at upgrading python then... th
<parthm> jam: hmm. is there something special about the name "message" for the argument? changing this to "msg" fixes it in 2.5. python exception handling is the same so that wasn't the issue.
<parthm> ah. well. there is a comment in errors.py "'msg' is used instead of 'message' because python evolved and, in 2.6, forbids the use of 'message'."
<bigjools> hi all - can you make bzr reveal the location of the uncommitted branch you've merged?
<jam> parthm: there is something special about message
<jam> but I see you found that ):
<jam> :)
<jam> bigjools: 'uncommitted branch you merged" ?
<jam> the location you just merged from?
<bigjools> jam: yes
<bigjools> so in a shared account, I can see where someone merged from if there's uncommitted changes
<jam> bigjools: generally not that I'm aware of
<jam> you can see the revs, but not the URL
<bigjools> ok - I'll file a bug, cheers
<parthm> jam: https://code.launchpad.net/~parthm/bzr/603461-invalidpattern-python25/+merge/29587 .. i have tested it with Python 2.5
<parthm> i am assuming 2.6.2 works but I don't have that installed to try it.
<parthm> looks like the mp is merged. its late here. got to go ... bye.
#bzr 2010-07-10
<Meths> Hi, if I use bzr revert in a tree to test a previous revision how do I undo that revert to carry on from the latest revision?
* jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.2b4 has gone gold, build those installers
<jam> Meths: 'bzr revert'
<jam> no args
<jam> or 'bzr revert -r -1'
<Meths> Ah, thanks.
<eydaimon> I merged from branch1, committed. Made some checkins. Reverted back to a prior checkin before the merge form branch1 (deploy failed and committed the revert. Made changes in branch1 to fix issues, and now I need to merge branch1 again. However, only one file is actually merging over vs the intial 20+ files. What's happening ?
<eydaimon> If it's clear what I want form that description (otherwise ask me to expand) how can I get it to do "what I want" ?
<fullermd> Revert doesn't undo the commit [merge].  So you only have one more change (that one file) to merge, so that's all merge does.
<eydaimon> so how can I do what I want?
<fullermd> Well, you have to manually redo all the changes.
<fullermd> FSVO 'manually', which includes automated manualiness like 'revert'.
<eydaimon> bzr uncommit perhaps
<eydaimon> ?
<eydaimon> I can do bzr uncommit on the main branch
<fullermd> Well, that would work too, backing up to before you did the revert, if you can throw away all those later revs.
<eydaimon> yeah, that's fine to do
<eydaimon> in this case
<eydaimon> but what if that wasn't the case. I'd have to do it all manually?
<fullermd> Depends on how much things have changed.  If not at all (in context), you could bzr diff | patch -R to undo the revert and restore all the changes.  You can use 'merge' against yourself to do the same sorta thing a bit smarter-like.
<eydaimon> ok, I'm on revno 1198. I wish to go back to 1193
<eydaimon> and then remerge with the branch
<fullermd> And throw away 1194..1198?
<eydaimon> 1194 was the merge with the branch
<fullermd> Probably simplest to just use pull; somethine like `bzr pull --overwrite -r1193 .`
<eydaimon> so I could go back there, check that in, and then merge the new changes to the branch
<eydaimon> that may actually be the best
<eydaimon> so if I issue the pull command, will I be able to remerge with the branch again?
<fullermd> Yeah, since at that point you'd never meged that branch.
<eydaimon> yeah, that worked well, thanks
<eydaimon> in this case it was ok to throw away the changes after, but what if it wasn't ok? What if I needed 1998 ?
<eydaimon> I appriciate your help btw :)
<fullermd> Fiddling with merge against yourself or diff | patch to redo the changes.
<eydaimon> so fairly painful, in other words
<fullermd> Depending on how things got arranged, there are other possibilities involving really disgusting merge tricks.
<eydaimon> i was hoping it would be fairly easy to roll back a change that failed badly in production
<fullermd> Well, yes, with uncommit or pull to pop stuff off the top.
<fullermd> But revert just makes WT changes, it doesn't "undo" anything.
<eydaimon> yeah
<eydaimon> so maybe I should uncommit even this time?
<eydaimon> what's the cleanest, since uncommit is available?
<fullermd> You did the same thing with pull.
<eydaimon> ok, so it accomplished exactly the same thing, except made several "uncommits" easier
<fullermd> The difference is in what happens with the WT.
<eydaimon> the WT?
<fullermd> With uncommit, the WT and state is left untouched.  So after you 'uncommit', you're exactly where you were before you ran 'commit'.  Pending file changes, add's, mv's, etc.
<fullermd> If you used pull instead to back up to that previous rev, you'd be at the "clean" state for that rev.
<fullermd> (well, not exactly, since pull would try and merge any uncommitted changes you had sitting around, but for simplicity...)
<EdWyse_Office> I'm guessing WT=working tree?
<fullermd> Da
<eydaimon> so if I had no pending commits, doing the pull and several uncommits would result in the same state?
<fullermd> A pull to the previous rev is roughly equivalent to "pull ; revert".
<eydaimon> What would you do in my place?
<eydaimon> bear in mind, there are several checkouts of trunk too
<fullermd> I'm always in favor of running naked, screaming, and covered in blood through the streets.  It's cathartic.
<eydaimon> not sure how I'm to deal with the checkouts yet
<eydaimon> lol
<eydaimon> i may try that before i'm through with this
<eydaimon> good excuse to get rid of the cat anyway
<fullermd> They'll probably require some work to back the checkouts up.
<EdWyse_Office> What about doing a diff of your changes against the starting revision, then patching those diffs against trunk?
<eydaimon> I'v ebeen screwing around with it
<eydaimon> and I think I've got a solution
<eydaimon> ok. yeah, looks good
<eydaimon> I just did
<eydaimon> bzr pull --overwrite -r 1193 .
<eydaimon> and in the checkouts: bzr up && bzr revert
<eydaimon> hm, maybe not so easy
<parthm> the NEWS on trunk doesn't seem to have a date for 2.2b4. also there is no tag for 2.2b4 on trunk. is it branched?
<parthm> oh. ok. my bad. 2.2 is in its own branch.
<brylie> I am getting an error when I try to push to Launchpad: different rich-root support
<brylie> I have searched for a solution to this problem and have tried 'bzr upgrade --rich-root-pack' to no avail.
<brylie> What can I do to make the two repositories compatible? Is there a method I can use to make all subsequent local bzr repositories compatible with Launchpad by default?
<jobu1342> http://webchat.freenode.net/
<mathrick> hi
<mathrick> is there a command to import all revs / heads from a shared repo?
<jobu1342> has anyone successfully installed bzr on a bluehost server?
<jobu1342> I'm interested in writing up an install guide, but I might need some help with the install
#bzr 2010-07-11
<jobu1342> has anyone come across "ImportError: No module named bzrlib"?
<jobu1342> I'm running bzr 2.1.2
<jobu1342> the location of the directory called "bzrlib" is in my python path.
<jobu1342> Actually, the only time I don't get the error is immediately after running "make" in the extracted tarball of bazaar 2.1.2
<jobu1342> installing bzr on a bluehost server: http://myappadventures.blogspot.com/2010/07/creating-bazaar-repository-on-bluehost.html
<lifeless> hello from praha
<humanfly> there's no damned lawsuit against canonical.  if it is -- its false.  i'm sorry for the language but i'm emotional now because i am a ubuntu supporter
#bzr 2011-07-04
 * KombuchaKip hates Git
<bignose> bzr-svn is breaking suddenly
<bignose> AFAIK the Subversion server hasn't changed
<bignose>   File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line 505, in _open_directory
<bignose>     base_file_id = self.editor._get_old_id(self.old_id, path)
<bignose>   File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line 805, in _get_old_id
<bignose>     return ret.next()[1]
<bignose> StopIteration
<bignose> is this a known problem with an easy fix (and can I have a pony)?
<lifeless> https://bugs.launchpad.net/bzr-svn/+bugs?field.searchtext=stopiteration
<lifeless> shows nothing
<lifeless> so I suspect not a known issue
<bignose> lifeless: thanks
<spiv> Morning folks.
<bignose> can I âbzr branchâ from a local filesystem Subversion checkout?
<spiv> I think that's meant to work.
<bignose> âbzr help urlspecâ only talks about the Subversion server
<bignose> and Bazaar doesn't recognise the Subversion checkout as a branch.
<bignose> so âbzr branch foo.svncheckout/ foo/â just gives âbzr: ERROR: Not a branch: â¦/foo.svncheckout/â.
<bignose> spiv: so how can I branch from a working Subversion checkout?
<bignose> (accessing the server causes Bazaar to crash.)
<spiv> bignose: the same way you just tried to :/
<spiv> bignose: I think you need to file a bug (or in your case, pseudo-file by mailing the list and/or jelmer)
<bignose> shall do, thanks.
<_mathrick> $ bzr unbind
<_mathrick> bzr: ERROR: Unable to connect to SSH host lynx.imada.sdu.dk; [Errno 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
<_mathrick> uhh?
<_mathrick> why does it want to connect to unbind?
<lifeless> hmm, not sure.
<_mathrick> lifeless: it's a colo-ified repo
<mathrick> and I'm having trouble trying to find out what is bound to what exactly, since bzr info accepts no --local
<mathrick> $ cat .bzr/branch/location
<mathrick> sftp://mathrick@lynx.imada.sdu.dk/home/mathrick/public_html/repo/.bzr/branches/lipid-calc/
<mathrick> oh, that'd explain
<lifeless> thats not bound
<lifeless> thats a lightweight checkout
<mathrick> lifeless: well, I thought it was a lightweight checkout of .bzr/branches/lipid-calc which was then bound to the above
<mathrick> which is why it was surprising to me that it'd want to connect to unbind
<mathrick> and it sure worked they I'd expect it to before (when the server was not down), ie. both the local colo workspace and the remote one were updated on any commit/other change
<mathrick> s/they/the way/
<bignose> okay, this is looking less like a âbzr-svnâ problem
<bignose> <URL:http://paste.pound-python.org/show/9000/>
<bignose> it seems the repository is being strange
<bignose> could that be because of earlier âbzr-svnâ problems?
<lifeless> I think thats unrelated, and fixed in trunk.
<lifeless>  / 2.4
<spiv> Actually, I think that is likely to be related to earlier bzr-svn problems.
<spiv> FSVO of "earlier" :)
 * spiv digs up the bug number
<spiv> https://bugs.launchpad.net/bzr-svn/+bug/485601 is the one I'm thinking of
<ubot5> Ubuntu bug 485601 in Bazaar Subversion Plugin "missing chk node(s) for id_to_entry maps" [Critical,In progress]
<spiv> IIRC jelmer has corrected the problem in bzr-svn trunk (and maybe the current release?) but there isn't yet an easy way to repair affected bzr repos.
<bignose> would those repository problems show up on âbzr checkâ?
<spiv> No, although if you made a fresh import (i.e. into a new bzr repo) then use 'bzr cross-check EXISTING_REPO FRESH_IMPORT' it would.  (requires ~spiv/bzr-crosscheck/experimental plugin, I should really make that be the trunk version and/or integrate it into bzr-repodebug)
<bignose> spiv: are either of those in Debian Wheezy?
<spiv> I don't know of anyone packaging those.
<bignose> hmm, the âbzr checkâ has failed on this repository.
<spiv> bzr-repodebug is relatively new (although its contents aren't)
<bignose> if I make a new repository and branch again from Subversion, would I be wasting my time?
<spiv> Probably not.  How did check fail though?
<bignose> NoSuchRevision: CHKInventoryRepository('file:///home/benf/projects/svn/.bzr/repository/') has no revision ('svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:3356',)
<spiv> (If it is fallout from a now-corrected bzr-svn bug then making a fresh import would be the easiest way to continue working I think.)
<spiv> Hmm, a bit odd.  Does the traceback give any hint as to whether it was looking for a revision or inventory when that happened?
<spiv> (Unfortunately that error without context can mean either)
<lifeless> there will be a backtrace in ~/.bzr.log
<bignose> how much do you want to see?
<bignose>   File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 2382, in get_inventory
<bignose>     return self.iter_inventories([revision_id]).next()
<bignose>   File "/usr/lib/python2.6/dist-packages/bzrlib/repofmt/groupcompress_repo.py", line 899, in _iter_inventories
<bignose>     raise errors.NoSuchRevision(self, record.key)
<bignose> NoSuchRevision: CHKInventoryRepository('file:///home/benf/projects/svn/.bzr/repository/') has no revision ('svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:3356',)
<spiv> Ok, so it does think an inventory record is missing.  Have you used stacked repositories at all?
<spiv> Anyway, I would certainly try a fresh import from SVN at this point
<bignose> <URL:http://paste.pound-python.org/show/9001/>
<bignose> that's the full traceback
<bignose> I will try a clean repository. but my goal is to merge some revisions from the existing repository :-(
<spiv> There's a reasonable chance that you'll be able to merge them into the new repository.
<spiv> I'm not sure how you'd have ended up with a revision record without a corresponding inventory record.  Perhaps just an old bug that's been fixed that I've long since forgotten about :)
<bignose> new fun: the bound branch from Subversion into a new repository works
<bignose> but branching from that give:
<bignose> $ bzr branch ../svn/empowered/
<bignose> inconsistent details in skipped record: StaticTuple('719@58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands%2Fsend_profile_reminders.py', 'ben@benfinney.id.au-20110701043735-hyhpvogab661xpcz') ('4655593 322707 1213090 1213211', ((('719@58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands%2Fsend_profile_reminders.py', 'ben@benfinney
<bignose> Branched 3363 revision(s).
<jam> morning all
<sagaci> hi, just doing my first branch of lp:ubuntu/gnome-user-guide, it's up to  42616kB    84kB/s | Fetching revisions:Inserting stream:Estimate 5520/5533, how big is the initial revision size, should I save it for a rainy day or can someone shed light to the estimated total size..?
<jam> sagaci: I'll check, just a sec
<sagaci> thanks
<jam> sagaci: are you sure that is spelled correctly: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/%2Bbranch/ubuntu/gnome-user-guide/"
<sagaci> jam, it just finished at around 90MiB
<sagaci> but thanks anyway
<sagaci> sorry, gnome-user-docs
<sagaci> *facepalm*
<jam> hmm... I see it for natty,  but "lp:ubuntu/gnome-user-guide" didn't seem to work
<jam> ah, thanks
<jam> well, I'm glad it worked for you
<sagaci> yeah, just didn't want it to be ~1GiB and 4 hours later
<jam> yeah
<deni> question
<deni> can i have a repo in say /home/user1/repo and create a symlink to it in folder /home/user2/repo2 and have user2 user repo2 ?
<deni> i know i know this is completely wrong....on so many levels
<deni> but i have a ssh jail on one user and i want him to be able to just user that one repo that is located outside of the jail folder
<bob2> symlinks don't let you escape chroots
<lifeless> your jail would prevent that working
<lifeless> nevermind what bzr might support :)
<lifeless> you could use a bind mount
<deni> hmmm
<deni> user2 is jailed in /home/user2
<deni> the link is located is that folder.....wouldn't it seem like he never left /home/user2
<lifeless> sadly no, thats not how symlinks work
<lifeless> they get dereferenced (followed) in userspace
<deni> why can i cd to repo2 and write to it then? :D
<lifeless> because your shell + libc are collaborating to confuse you
<deni> also pwd says /home/user2/repo2/ and not /home/user1/repo
<deni> be as it may....i can still write to that folder
<lifeless> while you are jailed ?
<deni> yes
<maxb> What kind of jail is this?
<maxb> Doesn't sound very secure :-)
<deni> aarrghh..nope..just me being stupid
<deni> wait a secx
<deni> *sec
<lifeless> python -c 'import os;os.symlink("/etc", "foo")'
<lifeless> if you run that, while jailed
<lifeless> and ls foo shows you your /etc
<lifeless> then your jail is, uhm, not working well :)
<deni> lifeless: the jail is working fine, like i said it was just me being stupid (i was not logged in as the jailed user :D)
<lifeless> there you go
<deni> well i can always branch the repo in the jail and then have user2 push to it and then just merge from time to time
<maxb> The important thing to understand about symlinks is that they are *just* a pathname stored on the disk, that's all - and all of the dereferencing happens at the priviledge level of the user accessing them
<deni> lifeless: maxb: tnx
<lifeless> deni: or use a bind mount
<lifeless> deni: which will do what you wanted
<Rakesh> hello friends
<Rakesh> please help me in configuring bzr in windows
<bialix> Rakesh: ask
<Rakesh> helloo
<Rakesh> i installed bzr on my machine
<Rakesh> and its configured with some RSA key pair
<bialix> its = what?
<Rakesh> bzr
<Rakesh> i mean we have RSA public key used in server
<bialix> I don't think bzr is configured with RSA, are you talking about your SSH client software?
<Rakesh> and i ned ma private key in ma system to get connected
<bialix> what is your SSH client software?
<Rakesh> hmm:(
<bialix> I'd recommend you to use pageant from PuTTY package to hold your private key
<Rakesh> actually i created it from my Ubuntu machine
<Rakesh> and configured my bzr client in there
<bialix> on bzr it won't work the same way as on Ubuntu
<bialix> maybe you want install Cygwin to have SSH client similar to Ubuntu
<bialix> or just use PuTTY
<bialix> you need 2 utilities: puttygen and pageant
<bialix> using puttygen you have to import your private key and then save it in putty format.
<bialix> use pageant as ssh-agent software, load your putty-private key there
<bialix> also it will be better to ensure you don't have ssh.exe or plink.exe in your path, otherwise you'd better set env variable BZR_SSH=paramiko
<bialix> Rakesh: does it make sense for you?
<Rakesh> sorry, i ment SSH key
<Rakesh> its not RSA key :(
<bialix> I know, I told you about SSH key
<Rakesh> yea , thanks
<Rakesh> ok  i have the kay pair and i configured bzr in Ubuntu
<Rakesh> and what i need is i want to configure it for my windows machne too
<Rakesh> and  whan i tried to configure it there it asks for my private key password
<Rakesh> and its not detecting the password
<bialix> Rakesh: re-read my advices starting from "or just use PuTTY" sentence
<bialix> are you using GUI tools or command-line?
<Rakesh> GUI
<bialix> that's could be a problem then
<Rakesh> :(
<bialix> it seems you have Cygwin's ssh and ssh-agent instaled in your system, right?
<Rakesh> not actually
<Rakesh> I have the key which is generated  from ubuntu
<Rakesh> ssh-keygen -t rsa -b 4096 -f ~/.ssh/rakesh
<Rakesh> this is the way i created there
<Rakesh> and i need to use he same key in windows
<Rakesh> since that public key is used to register my acount in remote server
<deni> lifeless: mount --bind works like a charm. tnx
<bialix> Rakesh: you wrote: "and whan i tried to configure it there it asks for my private key password"? so I assume you have ssh-agent software
<Rakesh> what this ssh-agent doing :)
<bialix> Rakesh: if this is not your computer, then maybe you need to ask your system administrator about installed software
<bialix> ssh-agent holds your private key so you don't have to type the password every time
<lifeless> deni: cool
<Rakesh> bialix: okey , i will try once more and if angin the problem persist wil inform the admin
<Rakesh> bialix:  thanks for your supoprt
<Rakesh> :)
<Kamping_Kaiser> dont' remember if i asked this here - is ther a way to remotely rename branches?
<hellnest_> hello i've got this invalid http Missing the Content-Range header in a 206 range response
<hellnest_> i'm trying to clone a bzr repo
<ndurner> Hi
<ndurner> The patch https://code.launchpad.net/~ndurner/bzr/bzr-ftp checks for the return code 502, but now I have encountered a server that returns 452 (IIRC) at work
<ndurner> 452 is not compliant to RFC 452, which states "insuffient storage"
<ndurner> Now, what's the right thing to do here?
<ndurner> Interpret any 4xxx and 5xx return code as "server does not implement this"?
<ndurner> Or check for 502 and 452 explicitely?
<ndurner> * RFC 959
<ndurner> it's 451, not 452
<ndurner> "Append/Restart not permitted"
<jo-erlend> how big overhead does bzr introduce? I was considering placing my entire ~Â in revision control. But I have some folders that contain rather large sets of changing data, such as Videos where I download to, and VM_disks. I would like to know when those files have been added, changed and removed, but I would not want to compare their content. What do you think? Will this cause lots of overhead, or should it be doable?
<bob2> not doable
<bob2> there'sa  thing for git called git-annex, possibly someone has done something similar for bzr
<jo-erlend> bob2, why not?
<bob2> ?
<bob2> because multigigabyte files are expensive for bzr to deal with
<bob2> (or any other tool, too, hence git-annex et al)
<jo-erlend> ok. But I can exclude those directories?
<lifeless> jo-erlend: yes you can exclude them
<lifeless> jo-erlend: bzr will need enough memory to hold the entire directory listing in memory, + 2 times the size of your largest file that you choose to version control.
<jo-erlend> oh, ok! That makes sense and that makes it rather clear why I cannot put those directories in vcs :)
<lifeless> jo-erlend: entire ~ is probably fine; we've tested up to 1M files
<lifeless> jo-erlend: though it may get a bit slow :) - and any subdirs that are also bzr projects won't get versioned [because they are their own projects]
#bzr 2011-07-05
<bignose> nnnggg
<bignose> $ bzr update
<bignose> Tree is up to date at revision 3418 of branch svn+ssh://benf@subversion/home/svn/empowered/trunk
<bignose> $ bzr commit
<bignose> bzr: ERROR: Bound branch BzrBranch7(file:///home/benf/projects/svn/empowered/) is out of date with master branch SvnBranch('svn+ssh://benf@subversion/home/svn/empowered/trunk').
<bignose> To commit to master branch, run update and then commit.
<spiv> That's weird.  It sounds a bit familiar though, perhaps someone else will recognise the bug.
<vila> >-/ unbind/bind ?
<vila> makes no sense
<bignose> okay, it appears to be related to::
<bignose> $ bzr merge --revision 1823 ../../devel/empowered.rt12430.confirm-reminder-email/
<bignose> inconsistent details in skipped record: StaticTuple('719@58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands%2Fsend_profile_reminders.py', 'ben@benfinney.id.au-20110701043735-hyhpvogab661xpcz') ('4721568 342529 114092 114205', ((('719@58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands%2Fsend_profile_reminders.py', 'svn-v4:58802371
<bignose>  M  wdyt/source/wdyt/reminder/tests/test_reminder.py
<bignose> All changes applied successfully.
<vila> bignose: as in: you're out of trouble but this is worth filing a bug ?
<bignose> vila: as in, that's the consistent message that precedes the failure.
<bignose> I'm madly trying to merge these branches
<bignose> and it fails with that message
<vila> what fails ? 'All changes applied successfully' does not sound like a failure (which is confusing)
<bignose> or rather that message precedes the âERROR: Bound branch BzrBranch7(file:///home/benf/projects/svn/empowered/) is out of date with master branchâ message when I try to make a change
<bignose> the sequence is: merge, get that âinconsistent detailsâ message, then try to commit â ERROR
<vila> which versions of bzr / bzr-svn are you using ?
<bignose> $ bzr version
<bignose> Bazaar (bzr) 2.2.4
<vila> hmpf
<bignose> (from Ubuntu Maverick)
<bignose> bzr-svn 1.0.3-1
<vila> 2.3.3 / 1.0.4 are available from the stable ppa, that would be my first line of defense
<bignose> I'm not in a position to update this machine
<bignose> or install packages
<vila> I don't know the details but I know jelmer did a bunch of fixes (and he is out this week)
<vila> hmm
<vila> no other machine available to try ?
<bignose> what should I try, though?
<vila> same commands with upgraded bzr / bzr-svn
<bignose> you're aware that I've reported problems with bzr-svn this week, that others here have said are repository corruption?
<vila> if you can't upgrade it will be rather complicated to even get a fix (if it's not a known bug) :-/
<bignose> so I am trying to keep straight what's happened to each repository
<vila> hmm, no I wasn't :-(
<vila> irc is not a reliable medium when it comes to tracking bugs...
<bignose> no, I ended up reporting it to the mailing list
<vila> huh ? Did I miss that one ? ....
<vila> oh
<vila> Crash in âbzr-svnâ, but works with Subversion ?
<bignose> that's the one
<bignose> now I appear to be reaping the repository corruption, trying to merge my work from earlier this week
<vila> you mentioned bzr-2.2.1, you did upgrade since then ?
<bignose> how the heck can I get my work properly into the Subversion repository?
<vila> see above, jelmer being away this week, I'll try with recent versions first, I know there have been fixes related to statictuple stuff but nothing more detailed :-/
<bignose> vila: using bzr 2.3.1-1, bzr-svn 1.0.5dev
<bignose> I get a crash trying to merge
<bignose> File "/usr/lib/python2.6/dist-packages/bzrlib/repofmt/pack_repo.py", line 2171, in _commit_write_group "Cannot add revision(s) to repository: " + problems_summary)
<bignose> BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple(â¦
<vila> >-/
<vila> bignose: can you pastebin a bit more details so I can paste it to the bug report ?
<bialix> hi all
<bialix> jam: hi
<vila> bignose: missing chk root keys though... May be that can be worked around by pulling the right revisions in the right repo (if we can understand where they are missing that is...)
<bialix> bonjour vila
<vila> bialix: hi hi sir
<bialix> vila: after the latest team changes initiated by maxb I left ~bzr and moed to ~bzr-core. But I didn't realize that bzr-windows-installer project maintained by ~bzr.
<bignose> vila: <URL:http://paste.pound-python.org/show/9056/>
<jam> morning all
<bialix> so I can't land https://code.launchpad.net/~bialix/bzr-windows-installers/changelog_plugin/+merge/66760
<bialix> hi jam
<bignose> vila: thanks for the help so far
<maxb> huh. If anything my changes were to enable people to move from ~bzr-core to ~bzr
<bignose> I have to go now
<bialix> maxb: I don't blame you
<maxb> bialix: I'm just confused why you chose to do that move
<bialix> it was my mistake, I guess
<bialix> maxb: because of Olive
<bialix> anyway all Bazaar projects are too big for me
<bialix> bzr-core, qbzr, explorer and windows-installers -- those are areas of my expertise
<vila> bignose: bug updated
<bignose> vila: appreciated, thanks
<bialix> jam: may I ask you to look and merge before 2.4 final this patch, please: https://code.launchpad.net/~bialix/bzr-windows-installers/changelog_plugin/+merge/66760
<vila> jam: hello patch pilot ;-)
<bialix> vila: topic/
<maxb> bialix: ~bzr doesn't get any email about Olive
<bialix> maxb: it did some
<maxb> yeah, that was quicly reverted
<bialix> I was quicker
 * bialix is looking for jriddell
<maxb> I think it's time for me to shout a bit more about my refactoring bugmail thread
<maxb> The only tricky thing is that to get ~bzr down to receiving no more bugmail than ~bzr-core, we also need to remove structural subscriptions from:
<maxb> ~bzr-gtk ~bzr-hg ~bzr-upload-devs ~qbzr-bugs
<maxb> hmm, perhaps I should wait for a time when jelmer isn't away to propose this
<vila> YES ! Today is a good day :-D
<vila> 1) My daughter got her baccalaureat
<vila> 2) bug #805809 is almost dead
<ubot5> Launchpad bug 805809 in Bazaar "merge fails with NoFinalPath" [High,In progress] https://launchpad.net/bugs/805809
<jam> vila: btw, we decided that the stand-up tomorrow would be at 9am local time, right? Not 8am?
<vila> jam: yup, poolie send an invitation update
<vila> sent
<maxb> oooh
<vila> maxb: recognize the 31 failures ?
<maxb> 805809 might make you a hero of udd
<vila> maxb: just so you know (and because I didn't explain all the gory details in the bug nor the mp): this is partly due to debian and ubuntu branches having different root-ids
<maxb> urgh
<vila> this is quite messy as lenny branches tend to have the same root-ids as the ubuntu branches but not always
<vila> probably lots of of merge -r0..nnn involved
<vila> i.e. despite having different root-ids, a lot of file-ids are still common and even revids...
<maxb> we may want to throw away and reimport some
<vila> maxb: I thought a bit about that but that doesn't seem required (at least it's *not* required with this fix)
<vila> having different root-ids for upstream, debian, ubuntu branches is a use case we want to support
<vila> hacing different root-ids among debian branches (or ubuntu branches) is a bit more weird but still conceivable
<vila> maxb: note that *this* bug is occurring when generating the ubuntu merges which we don't use (yet) so a related fix for udd *may* be to ~ignore them
<vila> at least, this shouldn't block pushing to the lp packaging branches (and may be it doesn't already)
<vila> ghaa, retry:
<vila> maxb: I think the importer is pushing to lp and *then* failing to generate the ubuntu merges so these 31 failures are not blocking
<vila> maxb: does that sound right ?
<maxb> They are blocking
<vila> rats
<maxb> They were not blocking the first time it failed, but for every subsequent upload, the importer tries to finish off the push/merge stuff before importing anything new
<vila> ratsss
<vila> hmm
<maxb> We may need to destroy and reimport these ubuntu branches anyway
<maxb> We have several bugs filed by people who are finding out the hard way that bzr's merge behaviour is unhelpful when parallel imports happen
<vila> maxb: my next target is to address parallel import in a very restricted way but still valid for udd (i.e. we damn well know the paths are the same even when the file-ids differ)
<vila> maxb: I'm unclear about how the branches are created anyway and how we can ensure all packaging branches use the same root-id and even if we achieve that we may still encounter issues if upstream use yet another one (which is a valid use case)
<vila> maxb: but I won't object about reimporting the branches if it helps (I'm not sure all cases will be addressed with that though)
<maxb> Yes, I definitely agree that reimports will never solve the larger issue.
<maxb> There may be places where they are an expedient solution though
 * vila nods vigorously
<vila> why is 2.3.3 still in natty-proposed ?
<maxb> No one has verified any of the bugs, apparently
<maxb> http://people.canonical.com/~ubuntu-archive/pending-sru.html
<maxb> Also, wasn't there discussion of a potential regression?
<vila> do we need that even with MRE ?
<vila> oh, which one ?
<vila> 2.3.4 is planned for 13 July...
<maxb> bug 798688
<ubot5> Launchpad bug 798688 in bzr (Ubuntu) "possible regression in natty-proposed" [Undecided,Incomplete] https://launchpad.net/bugs/798688
<vila> <shudder> final slashes and ~/%7E ... madness
 * vila off for lunch
<ScottK> I have a directory in a bzr branch that I want to move to a different project (no common history).  How do I do that without losing the history for the files I'm moving?
<LarstiQ> ScottK: this may not be the recommended way, but you could split and join. Drawback is that you carry all of the other history along.
<ScottK> This is a tiny piece of the overall project it's leaving, so that would be a bit daunting.
<ScottK> Thanks.
<LarstiQ> ScottK: perhaps with fastexport and filtering inbetween?
<ScottK> Perhaps.  I'll look into it.
<lvh> Hi. Is there an easy way to find the point where the current branch branched off from its parent branch?
<maxb> lvh: It's not quite what you asked for, but there is "bzr find-merge-base BRANCH OTHERBRANCH"
<ChrisCauser> Hello #bzr
<ChrisCauser> Is there anyone out there who can help me with a spot of trouble I'm having with bzr 2.4?
#bzr 2011-07-06
<cinerama> poolie says he'
<cinerama> whoops, poolie says he'll be back in a little while -- just out running some errands
<sagaci> hi, trying to push a branch to lp, getting the error "bzr: ERROR: Connection error: while sending POST /bazaar/: [Errno 8] _ssl.c:499: EOF occurred in violation of protocol"... I'll admit that I'm on a kinda dodgy 3G connection but it was fine this morning, any ideas or just try to push it via a wired connection?
<lifeless> looks like an ssl problem
<lifeless> e.g. yes your 3g connection ;)
<sagaci> righteo then
<spiv> sagaci: the bzr 2.4 betas will avoid that problem (they don't use the XML-RPC interface to resolve lp: URLs)
<benonsoftware> Question: What does UDD mean?
<bob2> ubuntu distributed development
<benonsoftware> But what about UDD failures?
<bob2> bzr import failures I assume
<benonsoftware> Thanks
<benonsoftware> Is loggerhead a plugin?
<poolie> benonsoftware, hello, are you having trouble with udd packaging branches or something?
<poolie> or just curious about the titles?
<poolie> s//topic
<benonsoftware> Just wondering :)
<poolie> package-import.ubuntu.com
<benonsoftware> Do you know if loggerhead is a plugin poolie ?
<poolie> it is
<benonsoftware> So do I need to extract it and just place it in the plugins folder?
<benonsoftware> Do I need a web server for it poolie ?
<poolie> you can either run it stand alone or inside apache
<poolie> there are some docs in readme
<poolie> (or any other wsgi web server)
<poolie> biba
<benonsoftware> poolie: Can I just run it without any other software for it?
<spiv> benonsoftware: it has a few dependencies apart from bzrlib:
<spiv> benonsoftware: https://bazaar.launchpad.net/+branch/loggerhead/view/head:/docs/index.rst
<benonsoftware> Thanks. Does bzrlib come with bzr windows?
<spiv> It does, but I'm not sure if the windows installer provides it in a way that makes it readily accessible as a library for other projects.
<spiv> IIRC there's probably .zip file installed by the windows installer you can add to your PYTHONPATH that would make it available.
<vila> hi all !
<poolie> hi vila, jelmer, jam,
<vila> jelmer is in vacations AIUI
<poolie> oh he is too
<fullermd> Vacation?  How do I get me one of those?
* 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 | UDD failures: 400
<vila> fullermd: *you* can't :-p
<jam> morning all
<jam> fullermd: I believe the line is "no rest for the wicked"
<jam> hi poolie, You scheduled the meeting for 6UTC, but I think we actually agreed on 7UTC
<poolie> hi jam, want to join us?
<poolie> mm when i scheduled it it wasn't super clear which time it was actually going to be
<jam> sure. just 6UTC is before I take my son to school
<jam> I thought we wanted to move it by 1hr, not 2
<poolie> i'm not sure if the calendar captured my intention
<fullermd> Wicked?  Me?  Why, I never...
<AfC> james_w: are you still interested in / working on bzr builddeb?
<AfC> [or is someone else looking after it now?]
<spiv> Quite a few folks are poking at it regularly I think.
<spiv> I made a branch for it just yesterday :)
<AfC> spiv: Ok, I'll ask generally, then :)
<AfC> Query 1: the docs for bzr import-upstream make it seem less suited that merge-upstream for starting a new package. Am I right about that?
<AfC> Query 2: the docs for bzr-builddeb's "normal mode" #creating a new package recommends using merge-upstream, which then talks about being able to import farious .tar formats, "or a directory". Should that work [when starting from scratch?]
<AfC> (it doesn't)
<AfC> Query 3: would you have expected that
<AfC> $ bzr merge-upstream ~/path/to/file.zip --version 1.0 --distribution debian --package name
<AfC> (or ~path/to/unpacked/)
<AfC> would fail, whereas
<AfC> $ bzr dh-make --bzr-only name 1.0 ~/path/to/file.zip
<AfC> appears to work just fine? (creating a commit tagged 'upstream-1.0')
<AfC> Hm. That's just about a bug report, once someone tells me which the bug is.
<AfC> s/fail/apparently do nothing including not committing anything/
<AfC> [around here fail means stack trace]
<poolie> hi afc
 * AfC advances his regards poolie's way
<poolie> what's the context where you're running merge-upstream?
<poolie> an empty branch?
<poolie> that seems like it should be reported as a bug anyhow
<poolie> afc, to start a new package i would think you'd do import-upstream and then commit on top of that
<poolie> i wonder if it's sufficiently documented
 * maxb lols at pkg-bazaar-maint receiving spam selling pipes and looms :-)
<poolie> i get a lot of spam about pools and spas
<fullermd> I don't get any spam about bleaching clothes   :(
<mrevell> ing
<AfC> poolie: yes, an empty branch
 * AfC tries again
<AfC> ah. Well at least part of the problem is that `bzr dh_make --bzr-onle` groks a .zip upstream, whereas `bzr import-upstream does not.
<AfC> So I should report this, obviously. Any preference for a bug title?
<vila> AfC: No preference. Generally if/when I think the title is misleading, I just fix it once I get a better understanding of the bug. I don't necessarily have this understanding when I file one...
<sagaci> hi, i'm wanting to branch ubuntu-docs, being bzr branch lp:ubuntu-docs... is there an argument to check how big the download will be without actually downloading the branch
<vila> sagaci: no *precise* way (as in number of bytes), but 'bzr info -v lp:ubuntu-docs' should give you some hint
<sagaci> thanks vila
<vila> sagaci: just did 'bzr branch lp:ubuntu-docs' and it's ~8M on disk so it should be roughly the same download size
<vila> err, scratch that, actually it downloaded ~2M, the 8M includes the working tree
<AuroraBorealis> bazaar explorer says "unable to obtain lock file: c:\users\<username>\AppData\Roaming\bazaar\2.0\lock
<AuroraBorealis> ive deleted that file but it still keeps coming back and freezing the program
<spiv> Gar, the branch for bug 248418 has caused bug 806425.
<ubot5> Launchpad bug 248418 in Ubuntu Distributed Development "Should set append_revisions_only on branches it creates." [High,Fix released] https://launchpad.net/bugs/248418
<ubot5> Launchpad bug 806425 in Ubuntu Distributed Development "AppendRevisionsOnlyViolation in import_package" [Critical,Confirmed] https://launchpad.net/bugs/806425
<spiv> It's well past EOD for me, but if someone's interested it might be good to look into it and possibly revert the offending change.
<fullermd> Rrr.  The error on pull'ing from a non-branch-root is annoying.  Have I moaned about that before?
<Lo-lan-do> Hi all
<AuroraBorealis> can anyone please help me with this annoying bzr explorer bug =(
<AuroraBorealis> i dont know what its doing with this lock file
<JamesTait> Hello people.
<JamesTait> Can anyone suggest how I might recover from "bzr: ERROR: The dirstate file (DirState(u'/home/jtait/[snipped]/.bzr/checkout/dirstate')) appears to be corrupt: Bad parse, we expected to end on \n, not: 1" ?
<poolie> hi all
<poolie> hi abentley
<abentley> poolie: hi.
<poolie> is your mp essentially saying "no, there are no reasons to want to take the other root?"
<abentley> poolie: no, I'm just accepting that it's a less-disruptive change and doesn't expose several of our UI issues.
<abentley> poolie: It's restoring the status quo.
<poolie> right
<poolie> i guess i just wonder if we should try again at making that switch, perhaps by a different course
<abentley> poolie: If a user really wants it, they can just merge in the opposite direction, so the priority is pretty low, and several changes would need to be made.
<poolie> ok
#bzr 2011-07-07
<poolie> hi spiv
<poolie> i'm going out for a bit at 11
<bignose> I'm getting very confused over this âbzr-svnâ behaviour
<bignose> Subversion repositories that worked fine last weekmonth, with the exact same versions of all packages, are breaking now
<bignose> even after I delete the local repository of the bound branch, and re-create
<bignose> is there some other cache of Subversion data that I need to delete in order to clear out âinconsistent details in skipped record: â¦â errors?
<AuroraBorealis> can anyone help me with bzr explorer keeps freezing cause of a lock issue or something?
<AuroraBorealis> but no one is ever here :<
<poolie> AuroraBorealis, hi, what's up
<AuroraBorealis> bzr keeps locking up and keeps saying it can't acquire lock: "unable to obtain lock file: c:\users\<username>\AppData\Roaming\bazaar\2.0\lock
<AuroraBorealis> i keep deleting that folder but it keeps freezing bazaar and saying it :<
<poolie> maybe you have two processes trying to change the configuration at once?
<poolie> is there a traceback in .bzr.log?
<AuroraBorealis> where would that log be
<poolie> 'bzr version' will tell you
<poolie> bignose, https://bugs.launchpad.net/bzr/+bug/418257
<ubot5> Ubuntu bug 418257 in Bazaar "inconsistent details in skipped record" [Medium,Confirmed]
<poolie> according to that bug it's just a spurious warning
<poolie> is the command actually aborting?
<bignose> the command doesn't fail
<AuroraBorealis> http://pastebin.com/TdHRE2Lt
<bignose> but its appearance is simultaneous with the merge failures I've been getting
<bignose> s/merge failures/failures to commit merges/
<lifeless> poolie: AuroraBorealis's path looks like a lock on the config directory
<AuroraBorealis> yeah, but it keeps coming back even if i delete the lock/ folder
<AuroraBorealis> and it isn't a branch so bzr break-lock doesn't work there either
<lifeless> AuroraBorealis: this is -totally- a guess, but I suspect something (perhaps bzr-explorer) is trying to update your config too often, and deadlocking itself / your deletion
<lifeless> gettting a backtrace like poolie suggests will help
<AuroraBorealis> annnnd how do i fix this? its not doing this on any other computer
<AuroraBorealis> how do i get a back trace?
<lifeless> it will be in the log file
<lifeless> bzr --version
<lifeless> will show you the path of your log file
<AuroraBorealis> that pastebin is from the log file, i dont see any stack traces
<AuroraBorealis> http://pastebin.com/m05hWcdT that is all i get once i open bzr explorer from scratch and make it freeze again
<poolie> bignose, well what is that failure?
<lifeless> AuroraBorealis: ok; uhm I have to go for a bit; opefully someone here can help you further. It looks to me like a bzr bug; not sure why the lock is being lost, but I suspect its being taken out too often
<AuroraBorealis> i'll keep an eye on it
<AuroraBorealis> and keep deleting it for now :>
<spiv> Hi poolie
<mgz> OOPS-2014K7
<mgz> second try loaded mp fine...
<spiv> bignose: there's ~/.bazaar/svn-cache too
<spiv> bignose: and of course the SVN repo itself is presumably changing, it's possible that it's something about the state of it now vs. 1 month ago that is triggering the problem
<poolie> AuroraBorealis, it would be useful to find out if the process mentioned (like 6820 in this case) is still alive and if so what it's doing
<AuroraBorealis> there is no process 6820 atm
<AuroraBorealis> but i'll check it once it does it again
<bignose> poolie: <URL:https://bugs.launchpad.net/bzr-svn/+bug/805343>
<ubot5> Ubuntu bug 805343 in Bazaar Subversion Plugin "Crash w/ StopIteration" [Undecided,New]
<bignose> spiv: I have no â~/.bazaar/svn-cache/â directory
<bignose> poolie: the sequence now is: create new Bazaar repo; âbzr branch --bind svn+ssh//benf@foo/bar/trunk/ trunk/â â (several) âinconsistent details in skipped record: â¦â;
<bignose> poolie: then merge also complains about inconsistencies; then attempting to commit in the Subversion bound branch complains it's not up-to-date.
<bignose> even though âbzr updateâ reports it *is* up-to-date.
<bignose> since all of this came together (the âinconsistent detailsâ message along with the subsequent failure to commit a merge) it seems likely they're related.
<bignose> also with âKeyError: 'ben@benfinney.id.au-20110701055442-gb327dd7rxdgl61l'â trying to track differences in files
<bignose> it's all difficult for me to untangle what problems
<bignose> everyone says âno that's a separate problemâ for each thing I report :-/
<bignose> yet they all occur at once
<spiv> mgz: apparently that OOPS was LP getting a 503 from the Librarian service (where the diffs are stored).  I guess it's a transient problem.
<mgz> thanks spiv, I only got the one oops indeed.
<thumper> is bzr-search documented anywhere nicely?
<lifeless> I think there is a bit in one of the guides
<thumper> ta
<lifeless> or bzr help plugins/search
<bignose> okay, Bazaar refuses to commit even locally-made changes in this Subversion bound branch.
<bignose> so nothing to do with merge.
<bignose> details in an email message to the list.
<poolie> thumper, it has help
<poolie> oh, this is the "i won't file a bug" bug
<bradm> hi, I'm having a weird error message from bzr
<bradm> bzr: ERROR: Received bad protocol version marker: 'HTTP Error 404: NOT FOUND\n'
<bradm> but I only get that from a dual stack ipv6 host, on ipv4 only host it's fine
<spiv> Huh.
<spiv> That's a funny string.
<bradm> oddly I still get that if I do a ip addr flush on ipv6 addresses
<spiv> I'd suspect there's something weird happening on the host, but I cannot guess what
<spiv> That's not a valid HTTP response, and there's not really any reason why HTTP should be involved, so it's pretty mysterious
<bradm> let me try on my desktop instead of laptop and see
<bradm> my laptop's a pretty up to date natty install
<spiv> Which protocol are you trying?  bzr:// ?
<bradm> bzr branch lp:~harvest-dev/harvest/production
<spiv> Oh, hmm, if you're trying http://foo/bar, then it's probably a that the remote httpd isn't giving proper 404 responses to bzr's attempt to POST to /bar/.bzr/smart
<bradm> woah, desktop's response is even weird
<bradm> er
<bradm> bzr: ERROR: http://bazaar.launchpad.net/%2Bbranch-id/77880/.bzr/repository/indices/87baa8aa154c5e4a84187e7161d073f0.six is redirected to https://launchpad.net
<spiv> What does 'bzr lp-login --no-check' report?
<bradm> that works, gives my lp username
<spiv> Ok, that latter response is probably unrelated, it's a transient issue so probably retrying will work ok
<spiv> Huh, so you're logged into lp it'll be using bzr+ssh.  Then that response is even weirder!
<spiv> What happens if you try "bzr+ssh://bazaar.launchpad.net/+branch/" instead of "lp:" ?
<bradm> same thing
<spiv> Hmm
<spiv> So bazaar.launchpad.net doesn't have an ipv6 address
<bradm> but oddly my desktop (which isn't logged into LP) is pulling down data ok it seems
<bradm> no, we haven't done ipv6 anywhere yet
<spiv> Ok, ipv6 is probably a red herring
<spiv> More likely to be a screwy SOCKS proxy or something
<spiv> Or something weird in your ~/.ssh/config?
<spiv> (assuming you are using OpenSSH as your SSH client)
<bradm> oh here we go
<bradm> I might have to blame Ng for this
<spiv> What happens if you try 'ssh -l YOUR_LAUNCHPAD_USERNAME bazaar.launchpad.net' ?
<bradm> that connects fine, says no shells on this server
<bradm> might have something here in my ssh config
<bradm> yup, that fixed it, we were testing some stuff with LocalCommands to pull some data about hosts
<bradm> and funnily enough, that string is what the local command returned when the host wasn't in the db
<spiv> Hah.
<bradm> thanks for the help in finding that
<bradm> I should have thought what else had changed in the past day or so
<poolie> bradm i saw a redirect error like that before
<poolie> i wonder if it's weird handling of pack files not found
<bradm> poolie: maybe - retrying it worked fine on my desktop now
<bradm> and fixing the LocalCommand to redirect stderr to /dev/null fixes my laptop too
<poolie> istr someone filed a bug about it recently
<spiv> poolie: oh right, it might be that.  I was assuming it was a transient outage in the external-to-internal URL mapper
<poolie> i can't find the bug i was thinking of
<poolie> but it was also a pack file redirecting to some unlilkely location
<Riddell> good morning
<vila> Riddell: morning
<alf_> Hi! Is there a way to tell bzr which gpg identity to use for signing commits?
<Riddell> alf_: bzr sign-my-commits . "Amy Pond <amy@example.com>"
<Riddell> although it seems not for the create_signatures config option or the re-sign command for individual commits
<Riddell> that should be fixed, please file bugs :)
<alf_> Riddell: Sorry, I wasn't exact enough... In my case I have two gpg identities/users "alf1@foo.bar" and "alf2@foo.bar". My commits are made using alf2@foo.bar email but when trying to sign, I am prompted for the password of alf1.
<quotemstr> Can I cherry-pick hunks from a single file?
<alf_> quotemstr: cherry-pick and apply them to another branch?
<Riddell> alf_: that's not currently possible, if you file a bug then I'll implement it
<alf_> Riddell: so, bzr always signs using the default/first GPG identity?
<Riddell> alf_: yes
<alf_> Riddell: I will file a bug, thanks!
<alf_> Riddell: There seems to be an existing bug about this: lp #68501
<ubot5> Launchpad bug 68501 in Bazaar "bzr should have an option for defining which gpg key to use for signing" [Wishlist,Confirmed] https://launchpad.net/bugs/68501
<alf_> Riddell: I will add a comment there
<bialix> Riddell: hello
<Riddell> hi bialix
<bialix> can we talk about https://bugs.launchpad.net/bzr-explorer/+bug/805813 ?
<ubot5> Ubuntu bug 805813 in Bazaar Explorer "explorer 1.2 (trunk) does not work with bzr 2.3.3" [Critical,Confirmed]
<bialix> Riddell: ^
<Riddell> hmm, breakage from qverify-signatures?
<Riddell> no, that's qbzr
<bialix> no, explorer: 516: Jonathan Riddell 2011-06-16 [merge] refresh automatically branch views on changes
<bialix> I have no idea why it failed with 2.3, but if we can fix it to work with 2.3, it will be great
<bialix> otherwise we have to force bzr version check in explorer
<bialix> and update docs
<Riddell> hmm, I can't recreate the problem using 2.3.1
<bialix> it failed for me everytime with 2.3.3 on Windows
<bialix> that's could be PyQt-specific
<bialix> hmm, I have PyQt 4.5.2, Qt 4.5.2 packaged into windows installer
<Riddell> ok I'll reboot into windows and try
<bialix> jam1: HI
<jam1> hi
<bialix> jam1: do you by any chance know is there any plans to update PyQt libraries on windows installer build machine?
<bialix> I'm not sure but I thought at some point there was discussion about upgrading it. Currently installer has Qt 4.5.2
<bialix> Riddelll: I suspect it's related to PyQt version
<vila> jam1: hey !
<bialix> hello vila
<vila> bialix: _o/
<jam> I don't have any plans, but if we need to we can
<bialix> Riddelll: ping
<bialix> Riddelll: we either should fix this bug or beg jam to update PyQt on build machine. Fixing a bug is better, although updating PyQt is also good.
<bialix> jam: I think it will be nice to update PyQt for next 2.4 beta
<bialix> I think Gary has used more fresher PyQt version on his build machine. I'm not sure though
<Riddelll> bialix: how do I do the equivalent of export BZR_PLUGINS_AT= on windows?
<bialix> set BZR_PLUGINS_AT=xxx from command line, or use system properties
<bialix> set works for current shell
<Riddelll> bialix: how do I find out what version of pyqt I have installed?
<bialix> start explorer -> help -> about
<Riddelll> bialix: PyQt 4.8.2 from standalone bzr windows installer, I can't recreate the problem
<Riddelll> what PyQt do you have?
<bialix> I see 4.5.2... wait
<bialix> problem with paths?
<Riddelll> bialix: what do you mean with paths?
<bialix> I have PyQt for Python in my PATH
<bialix> wait a sec, I will edit my PATH
<bialix> hmm, still 4.5.2
<Riddelll> bialix: did you install pyqt yourself or from the bzr standalone installer?
<bialix> standalone installer
<bialix> I don't have 4.5.2 installed on my computer
<bialix> so that should be from installer
<bialix> how can we have different pyqt versions from the same installer?
<Riddelll> spooky
<bialix> Riddelll: can you check your PATH?
<Riddelll> bialix: how?
<Riddelll> (I'm afraid I know very little about Windows)
<bialix> type "path" in command prompt
<Riddelll> http://paste.kde.org/92659/
<bialix> ok
<Riddelll> this is the PyQt files I think it's using http://paste.kde.org/92671/
<bialix> Riddelll: I still can't find where my system can load 4.5.2
<bialix> I'm trying on another machine now
<bialix> Riddelll: what's your bzr version on windows?
<Riddelll> 2.3.1
<bialix> I have 2.3.1 installed on another machine, it has PyQt 4.8 as your
<bialix> I suspect that was build by garyvdm
<bialix> 2.3.3 and 2.4 was build on different machine, that can explain why they have another pyqt
<bialix> Riddelll: could you install latest 2.4b4, please?
<Riddelll> ok
<Riddelll> bialix: that gives me PyQt 4.5.2
<Riddelll> but I still can't recreate the problem when using bzr explorer from trunk
<sagaci> hi, just wondering if there's a similar option to wget -c when branching
<bialix> Riddelll: have you tried to open some branch?
<Riddelll> bialix: boom
<bialix> Riddelll: the problem occurs only on opening the actual branch, Welcome screen has no problem
<Riddelll> "TypeError: WorkingTreeView cannot be converted to PyQt4.QtCore.QObject in this context"
<bialix> yep
<Riddelll> very strange, WorkingTreeView should be a widget which should be QObject happy
<Riddelll> bialix: what's a decent editor to use on windows?
<bialix> well.... notepad++?
<bialix> I'm using FAR + FTE, but this is kinda vintage
<bialix> Riddelll: something Qt-based, maube, like Qt Creator?
<Riddelll> actually I remember I have KDE installed here so I can use Kate
<Riddelll> but I think I would need to work out how to do windows development first, there's no source files with this standalone install
<bialix> bzr branch lp:bzr-explorer explorer?
<jam> bialix: I have 4.5.2 from the bzr installer
<jam> That said, we had problems the last time we upgraded PyQT. I think that was the 4.7 series.
<jam> If you're happy with the 4.8 stuff, I'm happy to upgrade.
<Riddelll> jam: the current version on the installer on bazaar.canonical,.com is 4.8 so going back to an older PyQt for newer bzr versions seems strange and error prone
<bialix> Riddelll: I think bazaar.canonical.com wasn't updated, it's a wiki
<Riddelll> right enough, but if bzr 2.3.1 ships with pyqt 4.8 then shipping bzr 2.3.3 with pyqt 4.5 is strange
<bialix> jam: Riddelll that's because 2 different build machines are involved here
<Riddelll> right
<bialix> jam: I think upgrading to 4.8 on ec2(?) will be good
<bialix> I think Riddelll is agree
<bialix> wiki page is out of date :-/
 * bialix edits it now
<Riddelll> I see my problem, I did a Qt signal connect() into WorkingTreeView which is an "object" not a "QObject" and that's not allowed in older PyQts
<bialix> oh
<Riddelll> bialix: this will fix it http://paste.kde.org/92719/
<bialix> yes, please land the fix
<Riddelll> groovy, I'll switch back to a real operating system to do that :)
<bialix> :-)
<CaMason> can I somehow search the log for when a particular line of code was introduced?
<deni> hi guys
<sagaci> hi
<deni> can anyone tell how to checkout a repo from the server but only the repo...not the working tree
<deni> so that i can then make a branch out of that local repo and work in that
<vila> jam: thanks for the heads-up for the news entry, two wrongs can sometime makes a right ;)
<james_w> deni, bzr init-repo --no-trees foo; cd foo; bzr branch <wherever> target; cd ..; bzr branch foo/target target
<james_w> that will give a copy of only the branch in foo, and a branch and working tree in "target"
<james_w> CaMason, bzr annotate is a good starting point. If you have bzr-gtk then gannotate has a back button that is very useful. There's also "bzr log -p" that can help
<vila> CaMason: annotate will give a more precise answer (most of the time)
<CaMason> thanks I'll give that a go
<vila> CaMason: qannotate from the qbzr plugin is an alternative too
<CaMason> aha, ideal
<CaMason> if only it had a search function Â¬_Â¬
<vila> qannotate *has* a search function
<CaMason> where?
<vila> gannotate used to have one too but I didn't use it for a long time
<vila> ctrl-F
<CaMason> oh qannotate
<vila> unless you use an old version
<CaMason> yeah trying ctrl+f, no dice
<vila> where ?
<CaMason> in qannotate.. click on code area, ctrl+f - nada
<vila> ha, old version then
<CaMason> :)
<vila> but gblame has ! :D
<CaMason> its ok, I grepped with normal annotate and found the issue - thanks
<deni> james_w: tnx....i knew it had something to do with no-trees but i just didn't user it right obviously
<sagaci> just did a bzr branch lp:ubuntu/oneiric/ubuntu-docs, it's up to 220MiB, any idea how big this thing will be?
<vila> sagaci: hmm, wasn't lp:ubuntu-docs 2M only ?
<sagaci> vila, but this is bzr branch lp:ubuntu/oneiric/ubuntu-docs
<vila> yup, I noticed, I'm wondering why there is such a huge difference though
<sagaci> yeah, up to 280MiB now :S
<vila> hmm, you've got a fat pipe :)
<sagaci> any reasoning?
<vila> without seeing the content of the branch, no idea (could be some binaries wrongly committed in the history or something)
<sagaci> :/
<jam> vila, sagaci: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/ubuntu-docs/oneiric/.bzr/repository/packs/
<jam> Has a 320MB pack file in there
<vila> including tarballs or pictures or whatever
<jam> I don't know *why*, everything else is a lot smaller.
<jam> But that one is from Aug-4-2009
<jam> so it isn't particularly new.
<sagaci> oh, so nearly finished
<sagaci> so when I push a small change, do I have to push the whole 320 or just the small diff?
<vila> sagaci: finished here at 512.572  Transferred: 423293kB (826.0kB/s r:423286kB w:7kB)
<sagaci> sorry, wouldn't have a clue how bzr works
<vila> vila:~/src/ubuntu-docs :) $ du -sk .
<vila> 176984	.
<vila> vila:~/src/ubuntu-docs :) $ du -sk .bzr
<vila> 135056	.bzr
<vila> vila:~/src/ubuntu-docs :) $
<sagaci> yep
<vila> sagaci: may be worth filing a bug (but I'm pretty sure there is some related existing one), adding your case as a comment will help
<vila> bah, bad parentheses: sagaci: make sure your case is documented in a related bug or a new one
<jam> sagaci: we repack during fetch, I'm not sure why the LP version is so bloated.
<jam> are you using http vs bzr+ssh?
<jam> (The files on disk on Launchpad are about 400MB, so that is very comparable to what it transferred to you.)
<jam> if you have access, you could "bzr pack lp:..." though that will be slow and download another 400MB and upload 200MB :)
<vila> AAARGH, I'm cursed :(
<sagaci> :s
<vila> no matter how many times I run the tests locally it appears that I always have some pqm failures when freezing a release :(
<SafPlusPlus> Hi guy, do you mind a noob question?
<SafPlusPlus> I want to pull the changes from a remote repository, but not apply them yet, but I can't figure out if that's possible. Any insights?
<vila> SafPlusPlus: pull them in a different branch
<SafPlusPlus> vila: That sounds like an interesting aproach, I'll tinker with that, thanks!
<vila> puzzling, blackbox.test_branch.TestBranch.test_branch_broken_pack can (and did) fail ramdonly with even a  failed to open trace file: [Errno 13] Permission denied: '/you-should-use-TestCaseInTempDir-if-you-need-a-log-file' ....
<RainCT> Hi
<RainCT> Quick question, how can I delete a tag that's already been pushed to the server? (When using "bzr tag --delete foo; bzr push;" after the next "bzr pull" it's there again)
<vila> bzr tad --delete server:foo
<vila> gha
<vila> bzr tag --delete server:foo
<vila> that is: delete the tag on the server, tag deletions don't propagate, known bug
<vila> bug #138802, you can subscribe to it and mention that you're affected
<ubot5> Launchpad bug 138802 in Bazaar "tag deletion does not propagate" [Medium,Confirmed] https://launchpad.net/bugs/138802
<vila> RainCT: ^
<RainCT> vila: Thanks. "bzr tag --delete server:foo" doesn't work though ("No such tag: foo").
<vila> well, by server:foo I meant whatever url you want to push too
<vila> bzr config (or bzr info for older versions) will tell you which url it is
<maxb> Shouldn't it be 'bzr tag --delete -d :parent tagname' ?
<vila> RainCT: but be aware that other users or the server branch will also have to delete this tag
<vila> ha right, maxb is probably right RainCT ^
<RainCT> Yup, with -d it worked. Thanks
<vila> jam: ping
<vila> I need a teddy bear about creating a 2.4 pqm branch and when we want to do that (to avoid blocking trunk from landing API changes)
<vila> ha, past EOD for jam I suspect, will mail the list
<Riddell> alf_: how's this? https://code.launchpad.net/~jr/bzr/68501-gpg-signing-key/+merge/67210
<alf_> Riddell: Looks great, thanks! Another thing that coulb be useful perhaps, is also considering the id passed to bzr sign-my-commits for the key to use. eg bzr sign-my-commits . bla@bla.org, should try to use a bla@bla.org key.
<alf_> Riddell: but in any case with your changes there is a way to handle this (changing signing_key temporarily), so thanks! :)
<Riddell> I did consider adding a command line option to sign-my-commits and re-sign but I'm not sure how often you want to change your signing key, normally I expect people will only ever use one, or occationally use a different one for a different branch which can be set in config
<alf_> Riddell: yes, that makes sense
<alf_> Riddell: can signing_key be set in locations.conf?
<Riddell> alf_: yes
<alf_> Riddell: great :)
<vila> Riddell: no time for a real review but:
<vila> 1) use get_user_option so you don't have to define special methods ( we are getting away from them)
<vila> 2) use gpg.signing_key instead of just signing_key
<vila> 3) at some point we'll gain a command-line switch to override config options, don't bother for now
<tsdh> Hi
<tsdh> How can I bring back a file I've accidentally deleted?
<lifeless> was it previously committed?
<tsdh> Yes.
<lifeless> bzr revert filename
<tsdh> Thanks.
<jimis> is bzr-2.4.0 already broken on python2.4?
<jimis> or it's the plan to break compatibility?
<jimis> Because I need to install it on RHEL5
<mgz> it's already broken.
<jimis> I just found out :-o
<jimis> I wish they broke it after 2.4, RHEL5 is just way too common
<jimis> anyway I'll try 2.3, but I remember seeing some fixes lowering CPU/network usage that I needed them, hopefully they are on 2.3
<mgz> a subset of them got backported.
<jimis> ok, thanks mgz
<jimis> hopefully it will be good enough for huge packages, I'll try branching lp:gcc :-)
<poolie> hi mgz, all
<mgz> hey poolie!
<jimis> how can I list all branches of lp:project from the command line?
<maxb> You'd need a small launchpadlib script, or screenscraping
<jimis> hmm didn't think it was that hard, I was just curious how to get the same info I get from the website
<maxb> for b in lp.projects['bzr'].getBranches(status=("Development", "Experimental", "Mature", "Merged", "Abandoned")): print b.unique_name
<maxb> Hmm, there are a lot of those, perhaps I should have picked a smaller project :-)
<jimis> thanks :-)
<jimis> maybe it should be a command
<jimis> for example "bzr info lp:bzr"
<jimis> or list
<jimis> or anything :-p
<jimis> 1025MB VSZ, 850MB RES and counting... :-)
<jimis> when branching over http, is it expected to download a lot times more data than lp:project?
<dOxxx> it's possible that it's having to repack revision data, which over HTTP is a very expensive operation.
<dOxxx> using lp: the server is able to do the repacking
<lifeless> dOxxx: I think you are thinking of push :)
<lifeless> jimis: yes, its expected
<lifeless> jimis: over http it has to read the raw files and discard unneeded data, over lp: it streams just the needed data.
<jimis> but behind firewall I guess it's the only choice
<jimis> anyway I hope it reads all data only once :-)
<spiv> Usually yes, although sometimes we've had bugs (I think 'bzr branch --stacked' may currently have a bug along those lines)
<jimis> nice, it seems it entered the "Done" phase :-)
<jimis> spiv: I was aware of the bugs, that's why I needed 2.4. But they seem fixed on 2.3.3 as well
<jimis> otherwise it would fetch GBs of data
#bzr 2011-07-08
<dOxxx> lifeless: ah, my bad
<poolie> hi dOxxx
<dOxxx> hey poolie
<dOxxx> I'm kinda stoked the merge tool gui stuff is finally getting into a release :)
<poolie> great
<poolie> i have to confess i hadn't seen that
<poolie> do you mean the upcoming bzr 2.4?
<dOxxx> yeah, the corresponding gui changes in qbzr were merged in recently
<dOxxx> so they should be in this next beta
<dOxxx> if you're packaging trunk of qbzr, that is
<dOxxx> ~seen vila
<dOxxx> poo, no chanbot
<poolie> probably just a bit late for him
<poolie> well, 2:30am in france, so pretty late
<dOxxx> yeah, I sent him an email
<chrisvj> I have a checkout of my code on launchpad. When I try to commit to it, I get http://pastebin.com/mNfaDG5X  can someone help me?
<spiv> chrisvj: possibly https://bugs.launchpad.net/bzr/+bug/571064 ?
<ubot5> Ubuntu bug 571064 in Bazaar "TooManyConcurrentRequests when trying to commit to a network repo with no network connection" [High,Confirmed]
<chrisvj> spiv, im running windows, not ubuntu
<chrisvj> afk
<spiv> Sure, I don't think that rules out it having essentially the same cause.
<spiv> That said, I'm far from sure it's the same bug (but not because of Ubuntu vs. Windows).
<spiv> What does 'bzr info' say?  IIRC this might also be due URL aliasing or something like that.
<chrisvj> back
<spiv> Ugh, still jet lagged a bit.
 * spiv makes a coffee
<chrisvj> http://pastebin.com/TZzf0Pug
<jimis> I work on a lightweight checkout of a branch, and I have some uncommitted change that I want to find next time I work on this. How can I *switch* to another branch, and switch back later to continue my uncommitted changes?
<chrisvj> spiv, any breakthroughs?
<dmuir> I know this isn't really the place to ask, but I tried over in the mercurial channel, and nobody's responding... anyway, the question is, does hg have a direct equivalent of bzr merge?
<spiv> jimis: to switch, just use 'bzr switch'
<spiv> jimis: you may want to 'bzr shelve' your uncommitted changes first
<spiv> dmuir: I'm hardly an hg expert, but I would've guessed "hg merge".
<dmuir> spiv: that's what I would have thought too, but it only works if a pull results in two heads. The problem I have is that pull is doing a fast-forward, so there's only one head.
<spiv> dmuir: huh.  I wouldn't have expected that based on my quick reading of the man page.  Unfortunately I have no other guesses for you!
<spiv> dmuir: I suppose you could try installing bzr-hg and using 'bzr merge' ;)
<dmuir> spiv: haha, yeah, was thinking of doing that too
<jimis> spiv: thanks, shelve worked fine
<jimis> damn, bzr 2.4 is *many times* faster than 2.3.3 on some operations
<jimis> I just built a custom python in my homedir to be able to use it, because 2.3.3 took almost 9min for a "bzr switch"
<jimis> and 2.4 is indeed much faster
<spiv> jimis: :)
<vila> jimis: dropping compatibility with python-2.4/2.5 was a conscious decision based on the assumption that, for RH, getting a python2.5/2.6 was easy enough to not be a blocker
<jimis> vila: easy enough only if you have admin :-)
<vila> jimis: so the overall plan is to keep 2.3 compatible with 2.4/2.5 but any info about making it easy (or easier) to get python2.6/2.7 (or even .rpm packages) will be very welcome
<jimis> vila: if you don't have admin privs you have to build python from source
<jimis> vila: tedious, especially since that is the case you will be missing some -dev packages...
<jimis> for example, in my case bzip2-dev was missing and I just noticed that python was built without it, so bzr is misbehaving :-)
<vila> jimis: that's a trade-off, we have limited resources too.
<vila> jimis: file a bug !
<jimis> vila: for what? bz2 is necessary isn't it? So it's my fault if I built python without it?
<vila> jimis: we're generally pretty good at tracking hard and soft dependencies so that such issues are noticed and fixed
<vila> jimis: it could be a soft dependency and gives a nice error message telling you what is missing
<jimis> I see. So it's probably a bug since it setup.py didn't warn me that python didn't support bz2
<vila> jimis: could be there, could be in bzr itself, but definitely a bug, yes: http://pad.lv/fb/bzr ftw :)
<vila> jimis: err, wait a sec, you used setup.py ?
<jimis> yeap
<jimis> python2.7 setup.py --prefix=$HOME/dist install
<vila> jimis: ... as opposed to a bzr .rpm (I know almost nothing about how rpm works, so speak slowly ;)
<vila> huh ? You have a python-2.7 ??
<jimis> vila: rpms are only for administrators
<vila> jimis: you can run from source
<jimis> vila: I have compiled python2.7 in my home dir, that's why I explicitly use it with setup.py
<vila> great ! So you can use 2.4 on RH !
<jimis> I'm having problems, that's what I'm saying :-p
<jimis> bz2 module for example
<vila> jimis: ... there should a place on the wiki to capture your experiments and bugs...
<jimis> :-)
<vila> http://wiki.bazaar.canonical.com/DistroDownloads#CentOS/RHEL
<vila> jimis: you should be able to edit this page, ask for help here if you can't
<jimis> vila: later maybe, I'll try to get it working first :-)
<vila> jimis: if I read that right, it indeed requires admin privileges so describing what a *regular* user can do will be useful
<vila> jimis: sure, thanks for that !
<jimis> but it's getting way too complex
<jimis> I should compile custom bzip2 in $HOME, recompile python using that one, and *then* install bzr2.4 using that python
<vila> Is there any rpm packager around that could help ?
<spiv> vila: it's not an rpm packaging issue
<spiv> vila: jimis doesn't have the permissions to install rpms on that system
<vila> spiv: I get that. But building packages and being able to use them as a regular user is probably better understood by packagers nevertheless
<spiv> jimis: note that as vila says you don't need to install bzr, you can just do 'make build' and run it straight from its source dir just fine
<vila> jimis: how is bzr failing with regard to bzip2 ?
<vila> jimis: for a specific operation requiring bzip2 or for an unrelated operation ?
<spiv> Well, there is 'rpm install --prefix=/home/â¦' I suppose.  I imagine it's a bit fragile though
<jimis> vila: for a "switch -b newbranch"
<vila> jimis: right, so this shouldn't require bzip2, definitely a bzr bug
<vila> jimis: did you get a traceback or something ?
<vila> jimis: we just froze 2.4b5, but there is still  time to fix such issues before 2.4.0
<jimis> bzr switch -b df2-vecs
<jimis> bzr: ERROR: No module named bz2
<jimis> You may need to install this Python library separately.
<jimis> vila: In how many points is bzr2.4 incompatible with python2.4? Will you accept patches that fix that?
<jimis> If they are a few maybe it's the easiest path :-p
<vila> jimis: using 'with' to start with plans to use b'' and things like that
<vila> jimis: I don't know if we have an official policy about such patches, but the tendency is to lower the burden of maintaining this compatibility with py2.4 :-}
<vila> jimis: so making it easier to use py2.6/2.7 would be preferred ;)
<jimis> ah I see now
<spiv> There was an extended discussion on the mailing list before we dropped 2.4 support
<jimis> I thought it just happened and compatibility was lost :-)
<jimis> ok, I'll check it
<spiv> It's unlikely we'd revert that; bzr 2.3 is still there for folks that are stuck with Python 2.4
<vila> jimis: but file a bug about bzip2 so we support it as a soft depedency
<jimis> anyway, I agree that python2.4 misses lots of niceties
<jimis> vila: ok
<spiv> Yes, it's a bit surprising that bz2 is needed by 'bzr switch', I think we only use it for bundles, export to .tar.bz2, and in the smart server protocol.
<spiv> We could probably usefully add an import tariff test about that...
 * vila nods @ spiv
<vila> hmm, no poolie around ? EODed ?
<vila> spiv: ? ^
<spiv> He was around this morning, but I wouldn't rule out a surprise jetlag-induced nap.
<vila> fair enough, let him nap in peace :D
<spiv> Or he might just be away from IRC and thus actually getting some work done ;)
<vila> tada !
<fullermd> Phew!  Now we don't have to worry about work getting done   :p
<dmuir> spiv: hg merge was the right command, but it only works when you're using named branches
<mgz> <jimis> vila: In how many points is bzr2.4 incompatible with python2.4? Will you accept patches that fix that? <- I'd have kept it compatible had that been an option
<mgz> there wasn't really time in 2.4 to do anything but break things without using new features so I didn't really see the point, but most people on this list wanted to drop compat
<mgz> and semi-related, I wish bzr would deprecate bz2 usage, only the smart server wants it and it's not a great cpu/bandwidth tradeoff in my opinion, just staying with zlib would be better
<poolie> hi mgz
<mgz> morning poolie!
<poolie> it is pretty expensive of cpu for what it gains
<lifeless> hi poolie
<lifeless> happy friday
<poolie> hi there
<poolie> mgz, well, we have used some new features
<poolie> the big payoff will be if we can get to 3.0 support
<mgz> but that's not happening for 2.4
<poolie> it would probably be feasible to re-add python 2.4 support now that it's branched off
<poolie> that's ture
<poolie> *true
<mgz> and the cool 2.4 features would be cool regardless of python version
<mgz> on the other hand, there aren't many jimises compared to people on the list who didn't want to have to think about backwards compatibility any more.
<vila> mgz: yup, that was the trade-off, dropping py2.4 support is a significant step towards 3.0
<mgz> I have big doubts about that vila.
<mgz> and trying to support py3k will make us all beg for the days of just having to support 2.4 to 2.7
<spiv> Ok, one mp submitted, and mysterious test failures irrelevant to the stacking fetch bug I'm working on diagnosed and worked-around.  A good time to EOD and EOW I think.
<vila> mgz: well, there have been feedback that maintaining a single code for 2.4 to 3.0 was... ouch, hairy
<vila> mgz: but I don't have first hand experience with that
<mgz> as far as I can see, the hairy stays even with 2.4 and 2.5 dropped
<mgz> most of the hard problems I've run into have been abstractions and interfaces shifting, not spelling changes
<vila> mgz: but some hairy can't go without dropping (that's my understanding and belief)
<vila> mgz: overall, I expect *more* progress by dropping than by keeping (imbw)
<mgz> that's what I have doubts over.
<mgz> eg.
<mgz> python 3 doesn't support u"" literals
<mgz> so, the fact python 2.6 adds b"" literals helps not at all, as you still need to run a source-level rewrite to support both versions
<mgz> python 2.6 doesn't solve any of the actual problems with string types you'll run into trying to support python 3, even in the standard library let alone your own code
<poolie> Riddell, hi?
<Riddell> good morning poolie
<poolie> yeah, the py3 stuff may be just too hard
<poolie> hi there, how are you?
<Riddell> I'm all good thanks
<poolie> cool
<poolie> i was thinking this morning it would be good to have you do some more stuff that specifically connects bzr to ubuntu
<poolie> and vice versa
<poolie> one idea i had towards this could be if you were to review the new packaging guide that barry and co are working on
<Riddell> sure, I can do that
<poolie> that would be cool
<poolie> we could get either some improvements to the docs
<poolie> or, perhaps identify some things that are clunky to describe and could be reasonably easily technically improved
<poolie> jam, hi?
<jam> hi poolie
<poolie> hey there
<jam> just away for a bit, had a "dutch integration interview"
<poolie> !
<poolie> aka "Let's go Dutch"
<jam> Apparently if you live here longer than 3 years you are required to learn Dutch, etc.
<poolie> good luck
<poolie> could you see if you could help doko with a workaround ofr  https://launchpad.net/bugs/797915
<ubot5> Ubuntu bug 797915 in Launchpad itself "large bzr-svn imports failing" [Critical,In progress]
<jam> sure, looking at it now
<poolie> thanks very much
<poolie> doko's in #launchpad
<poolie> good night all
<AuroraBorealis> hello, i'm still having problems with bzr explorer getting hung up on 'could not acquire lock"
<vila> jam: ping
<lparry> Hi guys, I'm looking into a  method of versioning CAD files as part of a collaborative engineering project. Would Bazaar be able to cope?
#bzr 2011-07-09
<mgz> hey poolie.
<poolie> hi mgz
<mgz> lp:~mbp/bzr/fdatasync brings back happy mozilla memories
<poolie> oh of it losing its bookmarks, or something like that?
<poolie> i was happy to get that done
<mgz> and the epic bug report that lead to some major ext3/ext4 arguments
<mgz> the number of reports we've had that look like they finger ext4 means we probably do need the change though.
<mgz> os.fdatasync is posix only, looks like you need a platform check?
#bzr 2011-07-10
<AuroraBorealis> so, should i report a bug for bazaar explorer locking up repeatedly on the stupid 'can't acquire lock' error?
<fax8> hi guys, is there a command to delete non revisioned files from a bzr repository tree?
<fax8> I mean stuff like filename~ filename.bak and stuff like that
<isxek> fax8: try "bzr clean-tree"
<fax8> isxek: thanks! exactly what I was looking for!
<dOxxx> grar.... setuptools for anything other than 'helloworld.py' is bloody complicated
<spiv> Good morning.
<poolie> hi spiv
<poolie> hi xaav, thanks for the export update
#bzr 2012-07-02
<nmb> Any devs awake who could take a look at bug 1019954 ?
<ubot5> Launchpad bug 1019954 in Bazaar "RemoteBzrDir can't access branches that local BzrDir can access" [Undecided,New] https://launchpad.net/bugs/1019954
<nmb> It seems like the PathFilteringTransport that is used in the server jail is not letting the RemoteBzrDir access the paths at .bzr/branches, but I can't quite track down why.
<mgz> morning!
<vila> jelmer: the fix for weave I mentioned last week is up for review: https://code.launchpad.net/~vila/bzr/1020007-branchformat4-lock/+merge/113014
<jelmer> vila: cool, I'll have a look
<jelmer> vila: r=me
<jelmer> now we just have to wait for python-launchpadlib to be uninstalled before it can land..
<vila> urgh, you filed an RT for that ?
<jelmer> vila: jam replied to the RT about installing it
<jelmer> vila: 54023
<vila> cool, thanks
<vila> oooh, the pkg_resources warning popping its ugly head, good, hopefully this will help address this mess ;)
<jelmer> vila: well, if we just uninstall python-launchpadlib that won't really address the issue
<vila> indeed, but someone may get more incentive to fix the root issue (which has always be a total mystery for me)
<jimis> hi, how can I checkout only specific files from my +junk repo into current dir?
<jimis> For now I'm using "bzr checkout lp:~user/+junk/dir ."
<jimis> but it brings all files so it's a bit of a mess
<mgz> go back a step, what are you actually trying to do?
<jimis> fetch a script of mine into a cgi-bin directory
<jimis> but I don't need all the rest
<jimis> hmmm I'll work around that by fetching elsewhere and hard-linking
<jimis> if you think of a way to checkout a file in bzr please let me know, I'll be back in a while
<mgz> that's a reasonable approach
<jelmer> jimis: bzr cat can do that for you
<jelmer> bzr cat -d lp:~user/+junk/dir name-of-file > name-of-file
<mgz> then chmod, then try and remember not to edit the file
<mgz> having an actual branch and a link is better
<mgz> partial checkouts into an existing dir would have a worse problem,
<jelmer> I guess views could in theory do this for you?
<mgz> you'd have files both in the repo and the current dir that the vcs has no idea how to sync
<mgz> views would work provided the local dir was kept clean
<mgz> I'm not sure if they actually do anything useful with the tree though
<mgz> right, they just affect what bzr sees, not what's on disk
<mgz> jelmer: bug 1001169 is a dupe of bug 413430
<ubot5> Error: Launchpad bug 1001169 could not be found
<ubot5> Launchpad bug 413430 in Bazaar "ShortReadvError on index file" [High,Confirmed] https://launchpad.net/bugs/413430
<jelmer> mgz: marked as such
<mgz> ta
<jimis> jelmer: with bzr cat I wouldn't be able to update
<jimis> mgz: local dir not clean, but thanks anyway
<jimis> I'll follow the link way :-)
<jelmer> jimis: you can just rerun the command to update
<jimis> jelmer: that wouldn't merge my local differences :-p
<jelmer> jimis: true
<jimis> (some values are set on top of the script)
<jelmer> vila: could I tempt you to do a review of https://code.launchpad.net/~jelmer/bzr/branchfmt/+merge/100220 ?
<vila> jelmer: hmm, yet another branch with bzrlib/tests/per_branch/test_bound_sftp.py.THIS where are you getting that from ?
<vila> jelmer: note the final '.THIS'
<vila> jelmer: and by 'another' I mean I already encounter that in one of those suspicious merges I mentioned last week
<jelmer> vila: hmm, I'm not sure... it must have been from a long time ago
<vila> the scary bit is that that kind of file comes from a conflict and resolving the conflict should delete it...
<jelmer> I guess I had a local change to it at some point..
<vila> introduced in lp:bzr at revno 6503 removed at 6519 (guess who committed them ;)
<vila> so, no harm done on trunk (also 2.6b1 apparently was released with it), but it would be nice if you could kill for good ;)
<vila> jelmer: reviewed as needs info, please enlighten me ;)
<jelmer> vila: commented
<vila> jelmer: So, this is about reducing branch.py size ? Will that really make a difference on startup ?
<jelmer> vila: a bit - it also makes it easier to move the rest of this stuff out into a oldfmt plugin or something like that
<jelmer> and it simplifies the overall amount of code in branch.py, which should make it easier to read
<vila> hmm, right, would be nice to put your explanations in branchfmt/__init__.py then or newcomers will have a hard time understanding the in-progress layout
<jelmer> vila: is that really necessary? We don't have something like that for repofmt either
<vila> jelmer: repository.py and repofmt are more cleanly separated, you're not there yet with branchfmt, so my review is: please add comments. It will take you less time than trying to convince me to not put them :)
 * vila off to dentist
<mgz> heh
<mgz> Jelme is so fast he lost his 'r'
<mgz> "it's part of bzrtools" is an increasingly bad answer
<jelmer> using the R hurts my throat too much :P
<mgz> it's been rolled too much.
 * mgz bounces bug 1019984 on again
<ubot5> Launchpad bug 1019984 in Dulwich "dpush to github from bzr copy of git repo fails on winxp" [Undecided,New] https://launchpad.net/bugs/1019984
<mgz> maybe looks like bzr-git should override the dulwich SSHVendor with that from bzrlib?
<jelmer> mgz: I guess that would be an option
<Noldorin> heh
<Noldorin> push issue again with bzr-git eh!
<Noldorin> jelmer: does that tempt you to fix the other dpush issue while you're at it? ;)
<jelmer> Noldorin: as berfore, patches welcome :)
<Noldorin> jelmer: still can't persuade you damnit
<Noldorin> lol
<Noldorin> i only mention this again because someone is using my git mirror now, :P
<Noldorin> and it's annoying
<Noldorin> you know that a) i don't understand the codebase very well, b) i'm shit at python, c) i don't have the time...
<Noldorin> jelmer: but you said you'd get on it if someone paid you ha
<Noldorin> maybe i should find out how much now lol
<jelmer> Noldorin: I don't really have the time either (or rather, I choose to spend my spare time on other things)
<Noldorin> yes i know
<Noldorin> you've said before...
<Noldorin> but a) and b) are true still ;)
<Noldorin> hence why i asked if someone paid you heh...
<jelmer> Noldorin: I'm not the one bringing it up again..
<jelmer> :)
<Noldorin> hmm i think you misunderstand
<Noldorin> i'm not criticising you here
<Noldorin> language barrier perhaps. never mind :)
<mgz> window not having an ssh binary and bzr push not updating working tree aren't really bzr-git related
<Noldorin> not what i'm talking about though
<mgz> the thing with pet bugs is only you can care for them properly.
<jelmer> mgz: bug 1019984 is definitely not a dulwich bug though
<ubot5> Launchpad bug 1019984 in Dulwich "dpush to github from bzr copy of git repo fails on winxp" [Undecided,New] https://launchpad.net/bugs/1019984
<jelmer> mgz: dulwich shouldn't know about bzr's SSHVendor
<jelmer> I'll reassign it to bzr-git
<mgz> well, arguably dulwich should have a less lame SSHVendor
<mgz> but I agree bzr-git is probably the easiest place to fix it
<mgz> if I ever get downstairs I'll give it a go.
<jelmer> mgz: I would argue that bzr's SSHVendor is the lamer one to be honest
<mgz> it works on windows though! mostly...
<jelmer> dulwich support for paramiko would be ace too
<jelmer> that's quite different from monkeypatching bzr's SSHVendor into Dulwich though
<mgz> right.
<mgz> the code in dulwich seems to encourage monkey patching
<mgz> I'm not sure if that was the intention.
<jelmer> sortof, it was meant to allow bzr to plug in its own ssh thingies
<jelmer> and mercurial
<Noldorin> hah
<Noldorin> oh well
<Noldorin> jelmer ignores me now
<Noldorin> can't even pay him ;)
<Noldorin> byew
<jelmer> Noldorin: ?
<jelmer> Noldorin: what did I ignore?
<wgz> jelmer: what else apart from dpush depends on that SSHVendor in dulwich?
<wgz> just doing info and branch seem to work here anyway
<jelmer> wgz: fetching over ssh depends on it as well
<jelmer> wgz: you probably have ssh.exe installed?
<wgz> my terminal claims not...
<wgz> and I use plink normally and have bzr configured to use that
<jelmer> bzr-git might already be inserting the ssh vendor
<jelmer> there is some code there
<wgz> is there a -D I can pass that will tell me what bzr-git is up to with transports?
<jelmer> wgz: it doesn't really use transports, except for a dummy GitTransport
<wgz> okay, I can repo with branch git+ssh
<Noldorin> jelmer: read above ;)
<Noldorin> jelmer: though i guess we can't even pay you these days hehe
#bzr 2012-07-03
<mgz> morning!
<jelmer> lo
<mgrandi> hello
<jam> jelmer: and behold
<jam> vila: have you woken up yet this morning?
<vila> hehe, yeah, at work for almost 2 hours even ;)
<idnar> argh
<idnar> I don't suppose anyone has implement zsh tab-completion for bzr switch colo:...
<mgrandi> this error is highly annoying >.> "Jul  3 01:34:54 Corvidae python2.6[2370] <Error>: void CGPathAddLineToPoint(CGPath*, const CGAffineTransform*, CGFloat, CGFloat): no current point"
<vila> mgrandi: what's the point ? (sorry couldn't resist)
<mgrandi> it clearly doesn't know =P
<mgrandi> cause it spams that 100+ times every time you move anything in qdiff
<vila> filed a bug against qbzr ?
 * mgrandi searches but gets frustrated at launchpad being buggy as well! >.> https://bugs.launchpad.net/bzr/null?
<mgrandi> i thought it was reported, but im not finding it. hmm
<mgz> that's bug...
<mgrandi> yeah. its been reported in launchpad, they still haven't fixed it though >.>
<mgz> bug 897277
<ubot5> Launchpad bug 897277 in Launchpad itself "Going to +bugs results in incorrect URL location" [Low,Triaged] https://launchpad.net/bugs/897277
<mgz> poke Deryck and see if it's actually filed upstream in YUI yet
<mgrandi> email him?
<mgz> stick a comment in the bug, email, ping him on irc, knock on his door
<mgz> whatever works :D
<mgrandi> heh
<mgrandi> someone commented semi recently about it, didn't see a response from him
<mgrandi> and i guess the no current point hasn't been filed, interesting
<mgz> the fix in YUI should actually be trivial, provided they know about it
<mgz> could always try upstreaming the bug to them yourself
<mgz> it might already be there and just needs linking
<mgrandi> let me look
<mgz> apparently there's also a #yui channel here
<mgrandi> dunno if anyone would be up at around 3 am xD
<mgrandi> i'll look in a bit, trying to finish something
<mgz> mgrandi: I can't find anything currently, so http://yuilibrary.com/projects/yui3/newticket and refer to that opera forum post?
<mgrandi> yeah i cant find anything either
<mgrandi> also, do you know if there is an existing bug for the line i posted earlier?
<mgrandi> i cant find it in qbzr
<mgrandi> but i could of sworn it was reported already
<mgz> mgrandi: I've never seen it before and wouldn't have guessed it was qbzr related
<mgrandi> well it happens when you scroll around in qdiff , i guess i'll report that too
<mgrandi> it might be qt4 related, since those are objective-c apis that its complaining about..
<jam> vila, jelmer: Can you try to land your bzr changes? it looks like we got stuff unblocked
<vila> argh, jelmer will beat me, I'm rebooting :)
<jam> or mgz, depending on who has something
<vila> jam: thanks for the heads up
<jam> I'd like to do it quickly, in case we need to try something else
<vila> I'll try asap
<jam> jelmer: I'm submitting your branch-format branch
<mgz> we just want to make sure it works again right?
<jam> yeah
<vila> jam: submitted
<jelmer> vila: you beat me :)
<vila> \o/
<vila> :-D
<vila> hmm, dead already
<vila> jam: that went far too fast
<jam> vila: testtools is no longer installed, it would appear
<vila> jam: eeerk, beware about which version is re-installed !
<vila> mgz: what's the related bug again ?
<jam> vila, jelmer: can you come to launchpad-ops and try to help sort things out?
<mgz> vila: bug 839461
<ubot5> Launchpad bug 839461 in Bazaar 2.2 "can't run selftest for 2.2 with recent subunit/testtools" [Medium,In progress] https://launchpad.net/bugs/839461
<mgz> ah, you found it
<vila> mgz: yeah 3 minutes earlier, I'm fast today.. thanks anyway, I knew you'll know ;)
<fullermd> Ah, but did he know you'd know he'd know?
<vila> fullermd: I think...
<fullermd> vila: donc tu es?
<vila> hehe
<fullermd> (yeah, those 3 years of French weren't _entirely_ wasted.  Just mostly...)
<vila> fullermd: almost perfect french, pedantically speaking, you need a space before '?' :)
<fullermd> Sadly, spaces are currently rationed.  Some political thing.
<vila> two spaces for double punctuation signs(?:;!), one space for single ones (.,)
<vila> pedantics don't care about politics ;)
<mgz> so, the good news is my email config changes worked, the bad news is bzr pqm borkÃ©dness is not fixes
<mgz> -s+d
#bzr 2012-07-04
<jono> hey
<jono> I am getting this error:
<jono> Using saved push location: http://bazaar.launchpad.net/~jonobacon/ubuntu-accomplishments-system/adminportal/
<jono> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~jonobacon/ubuntu-accomplishments-system/adminportal/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<jono> can anyone help me resolve it?
<bob2> pretty sure you want to push via ssh instead
<bob2> I think it'll be misconfigured due to you using an lp: url to clone without having use bzr launchpad-login (so lp: resolves to anonymouse http)
<bob2> from my vague distant memories :)
<jono> bob2, I just re-authed with launchpad-login and it doesnt seem to fix it
<jono> I think the issue is that another user checked this branch out
<jono> and I changed the owner/group on the code
<bob2> possibly logging in will fix it, possibly you'll need to replace the htpt url in .bzr/checkout (maybe) by hand, or use 'bzr push --update-defaults-or-whatyever ssh://'
<bob2> what does bzr info say the url is?
<jono> Using saved push location: http://bazaar.launchpad.net/~jonobacon/ubuntu-accomplishments-system/adminportal/
<bob2> yeah
<jono> so I need to set it to default to ssh?
<spiv> If you're doing bzr push, just use "bzr push --remember lp:~jonobacon/ubuntu-accomplishments-system/adminportal" this once to remember the right location
<jono> cd ..
<spiv> (now that you've done 'bzr lp-login, the lp: URL will resolve to the right location)
<jono> thanks spiv
<jono> that fixed it
<mgz> morning
<james_w> I'm stopping the importer for the rollout
<james_w> backed up databases
<james_w> cleaning some cruft from the dbs and vacuuming
<james_w> starting importer
<james_w> first successful import
<jml> what's the reason for the named NOT NULL constraints in the table definitions in udd?
<jml> e.g. signature TEXT CONSTRAINT nonull NOT NULL
<jml> Why not "signature TEXT NOT NULL"?
<james_w> don't know
<james_w> I'd say one of "sqlite refused the alternative" or "I didn't know any better"
<jml> ok, thanks.
<jml> hmm.
<james_w> importer seems to be running fine so far fwiw
<jml> james_w: yay
<jml> james_w: some of these tables seem pretty weird, especially when creation is expressed with terser syntax
<jml> e.g. CREATE TABLE packages_update (anupdate TIMESTAMP NOT NULL)
<james_w> hmm, yeah
<jml> e.g. CREATE TABLE commits (package TEXT PRIMARY KEY)
<mikhas> hi, I am trying to use bzr-git on a git branch with a non-linear history (read: it has some merge commits)
<mikhas> cloning the branch fails, and I get bzr: ERROR: Unknown extra fields in <Commit f45a66d9ea4e1a3043c66e4cb0ee21f56ff7dcfd>: ['mergetag', '', '', '', '', '', '', '', '', '', '', '', ''].
<mikhas> any ideas?
<vila> james_w: Count me in
<james_w> vila, sorry, for what?
<vila> james_w: watching the importer
<james_w> vila, oh, great, thanks
<vila> I see dead imports...
<vila> joke aside, how did you start it ?
<james_w> ./etc-init-mass-import start or whatever the script is called
<vila> 674 outstanding jobs seems... unexpected
<vila> and only 18 failures too
<vila> sounds like.. dunno, retry-all-failures of whatever option jml added is on
<vila> on the bright side, some imports have succeeded
 * jml doesn't remember adding options
<vila> oh, did you clear the failures table or something ?
<james_w> vila, not intentionally
<vila> jml: pi.retry_all_failed_jobs ?
<vila> james_w: ok, may not be a problem in the end, was just checking
<james_w> vila, it might be
<jml> vila: I might have written it, but I honestly can't remember :)
<vila> jml: :)
<james_w> there's still a lot of failures in the failures table
<james_w> so maybe a bug in the retry logic
<james_w> it's also failing quite a lot with "something changed" with its own revisions, which shouldn't happen
<james_w> but that seems to have been happening a fair bit recently, so I'm not sure it's related to storm
<vila> james_w: there were quite a lot of such failures
<vila> james_w: we have successful imports, that means, most of the db updates are exercised and branches pushed
<vila> even gtk+3.0 imported a release (I saw it succeed for several of them this morning so that's a *new* one)
<vila> james_w: the backup you did should allow further and finer diagnosis, keep them preciously ;)
<vila> james_w: egoboo killed ?
<vila> http://package-import.ubuntu.com/status/egoboo.html#2012-07-04%2010:30:26.488895 ?
<vila> oh, *before* you restarted ?
<james_w> vila, yeah, I got bored of waiting
<vila> but that one wasn't requeued ? weird
<james_w> sorry, should have requeued that already
<vila> james_w: not sure, wait
<james_w> yep
<james_w> not doing anything :-)
<vila> egoboo is the new nexuiz-data, it can't succeed IIUC
<vila> so better not requeue it
<vila> hmm, key AssertionError:<module>:main:_import_package:find_unimported_versions:check will be retried automatically ?
<vila> somthing is probably wrong here... as if some data was inverted about the failure
<vila> or the retry one
<vila> james_w: my guess would be that something is wrong with the retry table and the code can't find what it's searching for inverting the whole behaviour
<james_w> vila, when considering what to automatically retry?
<vila> at least
<vila> all the failures being retried is already unexpected, then all failures are seen as needing a retry too
<vila> james_w: (out of curiosity) what did you clean in the dbs ?
<james_w> vila, old rows in the jobs table
<james_w> and old rows in the import table
<vila> 'old' means ?
<james_w> vila, earlier than this month for import
<james_w> vila, earlier than this year and active=0 for jobs
<vila> hmm
<vila> I mostly understand the later (I thought all active=0 can be purged and the importer will catch up) but the former rings no bell
<vila> ha no, the lp lag window, so not all active=0
<vila> james_w: just got the emails about {categorise|graph}_failures
<james_w> vila, I fixed categorise_failures
<james_w> I haven't seen graph_failures yet
<vila> james_w: yup, I saw the fix before the email :)
<james_w> ah, ok :-)
<jml> is 'jobs.id' ever used as a foreign key?
<jml> I don't think so.
<james_w> not that I recall
<vila> james_w: looks like the same traceback
<james_w> these dbs haven't ever really heard of normal form
<vila> james_w: so most probably already fixed too
<james_w> ok
<vila> james_w: http://package-import.ubuntu.com/status/mlton.html#2012-07-04%2012:30:30.284526 is *definitely* something that shouldn't be retried
<vila> james_w: this means the next lp fdt will create a bunch of failures that won't be retried
<james_w> vila, why is that?
<vila> well, if the retry logic is inverted, true failures are retried and transient ones are not
<james_w> ah, I see
<james_w> and retrying that failure would have bad consequences? or it's just something that certainly won't be fixed by a retry?
<vila> dunno, that's the point, but I would refrain requeue anything until you understand what is going on as I don't know what kind of data will be inserted then
<vila> nexuiz-data should not be retried because it can't succeed (we don't know why yet), but it's running right now (it has a special-cased timeout of 24h),
<vila> the last time it failed (I don't remember exactly how) the associated failure was a non-transient one,
<vila> as such it was black-listed
<vila> now it's not
<vila> no big deal for this one, but as a whole, the importer has now lost its knowledge about what should be retried or not
<james_w> vila, it certainly looks like it is retrying everything
<james_w> except for that linux failure, which is odd
<james_w> I'll look in to that
<vila> james_w: hmm, now that you mention it... I wonder if the linux failure wasn't marked as a transient one *by mistake* !
<vila> james_w: and since you said the blob -> text stuff  shouldn't be an issue, I wonder if the root cause may be in how signatures are created from backtraces or something...
<james_w> yeah
<james_w> that's what I'm thinking
<james_w> if that changed (either type, or the content) then it could well cause this behaviour
<james_w> though I would expect it to stop auto-retrying, rather than to auto-retry everything
<vila> hehe, that's part of what make bugs interesting, surprise us :)
<vila> wow, wow,  Exception: sqlite3.OperationalError: database is locked
<vila> not yet on the web page
<vila> python-bsddb3 base-installer vdr-plugin-live nexuiz-data (!)
<vila> followed by two successful imports
<vila> web page updated
<mikhas> is there a workaround for git mergetags? https://bugs.launchpad.net/dulwich/+bug/963525
<ubot5> Ubuntu bug 963525 in Bazaar Git Plugin "mergetag support" [High,Triaged]
<mgz> not that I'm aware of.
<mikhas> so nothing I can do then? other than swearing at bzr, of course?
<vila> james_w: and mails from add_import_jobs and categorise_failures with the same traceback too
<james_w> vila, database locked ones?
<vila> yup :-/
<james_w> ok
<james_w> no need to panic yet
<james_w> it's not like they were completely absent with the old code
<vila> I don't :)
<vila> indeed
<mikhas> since the error message I get is "ERROR: Unknown extra fields in blah", I was wondering whether I could force bzr to simply ignore the extra fields?
<vila> I realized today we weren't talking about the same db locked errors, you were talking about the one in your first attempt while I was talking about the existing ones, I was still hoping your change could kill two birds though :-/
<mgz> mikhas: ask in the bug or on the list, jelmer would know best but is not around today
<mikhas> ok
<vila> james_w: still, the ones in the existing code fired like... 10 times in the last 2 weeks, we're at 7 in 3 hours. In some ways, it's a progress, the bug is revealing itself, ready to be fought ;)
<james_w> heh
<vila> I don't remember categorise-failures triggering it either but I may be wrong
<james_w> vila, it's run less frequently than add-import-jobs, so I'd expect to see it fail with that error roughly one fifth of the number of times
<vila> james_w: unless an fdt ruined the game, and given that some very old failures seem to succeed (given the number of releases imported for some packages), I think it's worth to let the importer run a bit longer
<vila> true
<james_w> vila, I don't think there's a distinction between the existing errors and the ones from the last attempt
<james_w> it was just a matter of frequency of them occuring
<james_w> I predict we will all but abolish them by moving to postgres
<vila> that's a risky bet ;)
<james_w> so unless there is a significant performance degradation with the importer on the current code we should just push ahead with that
<james_w> vila, I'll bet you a beer :-)
<vila> hehe
<vila> if you fix the retry stuff, the picture will be clearer,
<vila> if we don't get too much locked errors, we can mark them as transient errors and pursue the experiment
<james_w> yeah
<vila> add-import-jobs and categorise-failures won't retry unless you fix them too but again as long as they *can* run often enough, it's still worth continuing
<vila> james_w: you still have 645 outstanding jobs to find a fix ;)
<vila> james_w: just to confirm, in your udd use case, you don't run import-package right ? Nor needs bzr-builddeb nor pristine-tar still right ?
<james_w> vila, correct, we do not
<vila> good
<vila> hehe, oops is a package name, was wondering about its appearance in an error message ;)
<james_w> vila, ok, found it
<james_w> MP coming
<vila> james_w: hmm, looking at the crontab categorise-failures and add-import-jobs run at the same frequency...
<james_w> vila, hmm, ok, I was misremembering then
<james_w> it is odd that it is usually add-import-jobs then
<vila> no worries, yeah weird
<vila> both should run at the same time, may be one is blocking the other in "normal" circumstances
<vila> james_w: which reminds me another question: you mention 30 seconds delay for sqlite and I recently realized that's the case in your proposal, but what was it before ?
<james_w> vila, 30 seconds
<james_w> it has been for months/years
<james_w> it crept up as the load went up
<vila> you mean: implicit before and explicit in your proposal ?
<james_w> vila, nope, it was explicit before as well
<james_w> vila, https://code.launchpad.net/~james-w/udd/fix-auto-retry/+merge/113409
<vila> wow, just a misplaced is not None ?
<james_w> vila, yeah
<james_w> and missing tests :-)
<vila> indeed :)
<vila> james_w: approved
<james_w> thanks
<james_w> rolling it out
<vila> james_w: I have to go in a few minutes,
<vila> yeah, roll out, kill whatever is in the way but keep refraining from requeuing until you have a good feeling you nailed that one good ;)
<james_w> yeah
<mgz> I'll be around a bit longer, so feel free to bug me instead for anything urgent
<fullermd> mgz: My lawn needs mowed...
<vila> james_w: the fix is convincing and rules out the data so that's encouraging
<james_w> vila, yeah
<james_w> vila, yeah, and testing with local dbs shows that the same data gives the correct behaviour now
<vila> \o/
 * mgz seeds fullermd's lawn
<vila> james_w: back for a tiny bit, you did deploy with no down time ? ;)
<james_w> vila, I did
<vila> cute :)
<james_w> though mass-import should really be restarted
<james_w> otherwise it may start to think that LP is down when it isn't
<vila> to etect , yeah
<james_w> I can do that before I go if you like?
<vila> or even now, so it will just have to be restarted
<vila> hmm, libreoffice...
<vila> well, the web page shows that the fix is effective, since no data was harmed, we can requeue, so mass-import stop and the killed ones should just restart IIRC
<james_w> vila, stopping...
<vila> I see, driver said db locked, not sure if anything can be wrong there (I don't think so, bit surprising though)
<james_w> vila, finally started again after a few kills
<james_w> I have to leave now, I'll check in later
<vila> james_w: mass0import stop (not grateful-stop) didn't kill them ?
<james_w> vila, it did not
<vila> weird
<james_w> nor a normal kill
<vila> Weird
<james_w> I have to get out the bigger hammer in the end
#bzr 2012-07-05
<syst3mw0rm> hi
<syst3mw0rm> I need some help related to bzr fast-import.
<syst3mw0rm> Anyone willing to help
<syst3mw0rm> ?
<syst3mw0rm> I want to import git repo into bzr repo..but not in trunk branch
<lifeless> just rename it afterwards ?
<lifeless> theres nothing special about individual branches in a bzr repo
<syst3mw0rm> lifeless: when I see bzr log it says the branch nick : trunk
<syst3mw0rm> what should I rename?
<syst3mw0rm> there is no folder named trunk..
<syst3mw0rm> and when I try to push to repository whose branch nick isn't trunk..it gives me error that the branches have diverged.
<syst3mw0rm> lifeless: there?
<lifeless> syst3mw0rm: not really, dinner time for family, sorry.
<lifeless> in the output of the import there should be a subdirectory called trunk, if you imported the whole repo
<lifeless> if you used bzr branch from git, then it outputs a single branch to the folder of your choice.
<lifeless> jelmer, who wrote this, will be coming on line soon
<syst3mw0rm> lifeless: no problem. and thanks for help.
<syst3mw0rm> hi jelmer!
<_science> So if i want to see a diff for a specific file in a specfic commit how would i go about that? :)
<lifeless> bzr diff -c commitnumber path/to/file
<_science> cheers.
<mgz> morning!
<jelmer> syst3mw0rm: hi
<syst3mw0rm> Hey jelmer
<syst3mw0rm> I need a little help with bzr fast-import
<syst3mw0rm> I have a git repository..and I commit my code to this repo. But at regular intervals..I want to push this code to a bzr repo as well..
<syst3mw0rm> Initially there was only one bzr repo, I created git repo using git fast-import from this bzr repo..because I like GIT (and github) more than bzr.
<syst3mw0rm> but I want the original bzr repo to reflect the changes I am pushing to github.
<syst3mw0rm> I have two questions..
<syst3mw0rm> 1. Do I need to rebuild the whole bzr repo from git repo everytime I want to push changes to remote bzr server? or incremental changes can work?
<syst3mw0rm> 2. When I create bzr repo using bzr fast-import it imports changes in trunk branch..
<syst3mw0rm> I don't want that.
<AfC> I love how people keep coming here asking how they can _not_ use Bazaar.
<syst3mw0rm> I want changes to be imported to some other branch...otherwise I get error message that branches have diverged.
<jelmer> syst3mw0rm: yes, fastimport supports incremental imports
<syst3mw0rm> AfC: haha..:) Its not like I don't like bzr..the main reason is we don't have something like github for bzr.
<syst3mw0rm> jelmer: ok. how to tackle the branch issue? my second question.
<AfC> syst3mw0rm: well, since bzr works on top of a git repo (or better yet you can branch from a git repo to a bzr one and work there) there's really not much reason not to use bzr as a front end at least, and a working tree optimally.
<jelmer> syst3mw0rm: what is the problem with the branch being named 'trunk' ? you can do the import in some other repository too and then pul thje trunk branch from there into whatever branch you want to have locally
<syst3mw0rm> jelmer: I don't know how to do it..can you please explain me the steps to follow. I didn't find much documentation about it.
<syst3mw0rm> Git repo : https://github.com/syst3mw0rm/hyperkitty
<syst3mw0rm> bzr repo : http://bzr.fedorahosted.org/bzr/hyperkitty/gsoc/changes (bzr://bzr.fedorahosted.org/bzr/hyperkitty/gsoc)
<syst3mw0rm> I have both repo on my system.
<syst3mw0rm> Git repo is having more commits..I want to copy all the commits from git repo not in bzr repo and paste it in bzr repo..so both will have same data.
<syst3mw0rm> I am using bzr fast-export-from-git /git/repo/path project.fi
<jelmer> syst3mw0rm: I haven't done this myself either, though I know it is possible
<jelmer> I would usue bzr-git to mirror a git repository into bzr
<syst3mw0rm> but then it exports all commits and don't ignore the commits already there in my bzr repo.
<syst3mw0rm> jelmer: ok
 * syst3mw0rm checks out bzr-git
<syst3mw0rm> I can't find the documentation for this project..
<syst3mw0rm> only launchpad project page
<jelmer> syst3mw0rm: it just adds support for git repositories as a branch format supported by bzr
<jelmer> so you can just use 'bzr branch' and 'bzr pull' for mirrorring
<syst3mw0rm> how do I use it?
<syst3mw0rm> oh..I see.
<syst3mw0rm> I am getting error when trying to push to original bzr repo, the branches have diverged..
<syst3mw0rm> How to resolve it?
<jelmer> syst3mw0rm:bzr-git and bzr-fastimport are incompatible
<jelmer> so if you want to use bzr-git you'll have to start the bzr branch from scratch
<mgz> shelve ignoring +x is annoying
<bloodearnest> heya - I have a question regards the launchpad --fixes  interaction - is there a way to just reference (link) the bug without changing the status to "Fix Released" on push?
<mgz> that's the default behaviour
<mgz> bloodearnest: as in, just pushing a branch with a bug linked does change task status, so launchpad does what you want
<jelmer> mgz: s/does/doesn't/ ?
<bloodearnest> mgz, sorry, I meant "Fix Commited", and I don't want the status changed
<mgz> launchpad doesn't change the status.
<mgz> people run little helper bots against launchpad if they want to automatically change statuses
<bloodearnest> mgz, right - we have one of those bots to sync with kanban cards, so I must be seeing the status changed via that and getting confused
<bloodearnest> thanks
<mgz> you should be able to remove the lp bug number from the kanban card, or set a description to prevent syncing
<bloodearnest> mgz, I think the kanban sync is ok - it just happend at the same time I pushed a --fixes comment, so I thought that had done it
<bloodearnest> mgz: we have a custom leankit sync bot - is there a general sync option available?
<mgz> no, but lots of people have bots
<mgz> how does yours compare to lp:lp2kanban for instance?
<bloodearnest> mgz: not sure, I've not worked on it, but it's a two way sync
<bloodearnest> seems the App Store haz issues: http://www.marco.org/2012/07/04/app-store-corrupt-binaries
<psusi> is there a bzr equivalent to git describe?
<psusi> i.e. tell me what version this tree is
<mgz> `bzr revno` and `bzr revno --tree` depending on what exactly you want
<psusi> ahh, thanks
#bzr 2012-07-06
<jam> vila, jelmer: bzr's PQM seems to be working again, so if you want to submit your approved patches, go for it. I tried to send some things through, though at least one had a genuine failure in the test suite.
<vila> jam: thanks, did send mine yesterday, worked fine
<vila> jam: what was needed in the end ?
<jam> vila: we needed python-testools reinstalled, then finally 'subunit' itself to have 'subunit-stats' available.
<jam> oh, and *not* have bzrtools installed
<jam> because it complains to stderr about not being compatible
<vila> weird, wonder how this got messed up (-stats and bzrtools)
<jam> vila: not sure, uninstalling python-pkg_resources chained to some stuff we needed (like python-testtools), it is possible the re-install process brought more than we wanted.
<jam> also bzrtools is only complaining because it is the system 2.5.1 version, and bzr.dev is now 2.6.?
<vila> possibly
<joey> any blue/bzr team awake here?
<joey> Need some help with https://bugs.launchpad.net/bzr/+bug/1021537
<ubot5> Ubuntu bug 1021537 in Bazaar ""missing referenced chk root" while merging gcc into gcc-linaro" [Undecided,New]
<vila> jelmer: did you ever reproduce this one ?
<jelmer> hi joey, vila
<jelmer> yeah, it's fairly easy to reproduce
<vila> jelmer: isn't the revid hinting that it was created with bzr-git ?
<jelmer> vila: no, bzr-svn
<vila> close ;)
<joey> howdy, thanks jelmer and vila for being awake and being work-aholics
<jelmer> there is invalid data in one of the two branches caused by an old bzr-svn bug
<vila> >-/
<joey> is there a way to suck the branch down and run a cleanup script on it?
<joey> and then push it back up
<jelmer> joey: ideally 'bzr reconcile' would take care of this cleanup, but alas it doesn't yet
 * joey nods in agreement. 
<joey> if it was anything other than gcc or equiv I don't think we'd care as much but since we push out gcc regularly it's a pita and got kiko's attention now
<jelmer> joey: if you don't care about the actual history of gcc-linaro, then the simplest thing to do would be to take the last revision from lp:gcc that was merged into lp:gcc-linaro, "rsync --delete -avz" over the existing contents from lp:gcc-linaro and commit it in a single commit
<joey> hmm I'd have to have michael hope about that.  It may be possible for us to start a new series as part of normal ops and then fix it that way
<joey> I'll update the bug
<jelmer> I started looking at this bug a while ago after talking to ams_cs, but then we were pulled away on other stuff
<joey> he's in NZ so I think he's off until sunday
<jelmer> There should be another bug elsewhere with more details, but I can't find it at the moment.
<joey> jelmer: gotcha. If we can't resync because we need history, is there another method we can use?
<jelmer> joey: I think you would have to replay the history and make sure text revisions are recorded consistently with the way they are in lp:gcc
<joey> ok thanks
<jelmer> (it would probably involve some scripting on top of bzrlib)
<joey> sounds like a pita ...
<jelmer> yeah, that would be fairly tricky :(
<joey> Ok I've updated the comments in the bug for Michael and we'll see what he wants to do with it.  Hopefully the resync will be viable.
<joey> Thanks for your time
<jelmer> np
<tgm4883> How do I revert a revison that I have already pushed to a shared branch in the shared tree? I've done a bzr uncommit locally which removed the bad commit, but I don't see a nice way to push this change since I'm now technically a commit behind the shared tree
<glyph> tgm4883: you have to do a reverse-merge
<beuno> or push --overwrite
<beuno> but make sure there's no subsequent revisions  :)
<tgm4883> ok, the reverse-merge sounds more like the way to go if there are multiple people capable of doing commits
<tgm4883> the push --overwrite sounds better if it's just me
<glyph> tgm4883: yes, exactly
<glyph> tgm4883: I believe the appropriate voodoo is 'bzr merge . -r -1..-2'
<tgm4883> glyph beuno that works. Thanks for the info
<glyph> tgm4883: Glad to help :)
#bzr 2012-07-07
<Christopher1> What would cause the error "'error', 'JailBreak', "An attempt to access a url outside the server jail was made" " when trying to use the automirror plugin?
#bzr 2012-07-08
<AmberJ_> Hello
<jelmer> hi
<AmberJ> I committed some major changes to my personal branch (and pushed changes to my Launchpad branch). But when I showed the code to other developers, they found out that these changes have some serious disadvantages.
<AmberJ> And, I agree with them now that these changes are not needed in the code.
<AmberJ> So, how do I revert/undo pushes to Launchpad? I can think of 2 possibilities:
<AmberJ> 1. Repeatedly do 'bzr uncommit' and 'bzr push --overwrite' until all changes are uncommited (locally) and pushedTo/deletedFrom launchpad branch
<jelmer> if you do (1) then anybody following your branch will have to "bzr pull --overwrite" to actually get the new tip
<AmberJ> 2. Keep the unwanted revisions (say revision from x to y) in the the launchpad repo (no need to undo/delete them from launchpad). Simply delete/edit the files that were modified (in rev x to y) and commit/push next revision (rev y+1)...so that rev y+1 is exactly same as rev x
<jelmer> AmberJ: you can use 'bzr revert' to do (2) for you
<AmberJ> Oh, I didn't knew that others will have to do "bzr pull --overwrite" to get the new tip if I do (1)...
 * AmberJ reads 'bzr help revert'
<AmberJ> jelmer, If I use 'bzr push --overwrite' to undo/revert some pushes. Then I make other change/push to my code. And, now if this code is merged with project's main developement branch, will the users of main dev branch have to do 'bzr pull --overwrite' as well?
<AmberJ> I'm more inclined towards using 'bzr push --overwrite' since I'll prefer NOT to keep changes in version controlled history.
<jelmer> AmberJ: yes, they'll have to 'bzr pull --overwrite' as well in that case
<jelmer> AmberJ: without --overwrite they'll get an error saying the branches have diverged
<AmberJ> ok
<AmberJ> What do you recommend to users if they pushed some sensitive information (e.g. passwords) to Launchpad repo (and now they want to remove those revisions)?
<jelmer> AmberJ: then you really want to use --overwrite
<jelmer> AmberJ: that said, please note that the data is still actually there even with --overwrite
<jelmer> AmberJ: it's just not referenced by the branch
<jelmer> AmberJ: so you want to clean the repository if you've ever pushed sensitive data there
<AmberJ> Ah right, the sensitive informaton does not applies in my case (I asked just out of curiosity). I guess 'bzr revert' is better suited for my job.
<AmberJ> Thanks jelmer :)
#bzr 2013-07-01
<jelmer> Azendale: great, glad that worked for you
<tlonim> anyone hitting https://bugs.launchpad.net/bzr/+bug/1177521 .. if so, any  workarounds?
<ubot5> Launchpad bug 1177521 in Bazaar "missing chk node(s) for id_to_entry maps" [Undecided,New]
<jelmer> tlonim: that's almost certainly a dupe of an older bug that has some possible workarounds
<LeoNerd> bzr-git++   Just managed my first  bzr dpush git://...  was shockingly painless :)
<LeoNerd> Heh.. though it didn't convert my .bzrignore into a .gitignore but I guess I can't -reeeallly- blame it
<jelmer> LeoNerd: thanks :)
<jelmer> LeoNerd: usually you can just copy them over, but proper conversion is near impossible
 * LeoNerd nod
<LeoNerd> Upset that I can't  bzr bind  to it though
<jelmer> LeoNerd: yeah, there is no roundtripping support for it
#bzr 2013-07-02
<tlonim> jelmer: ah, the older ones which I saw similar to them were fixed already but I could still repeat this
<jelmer> tlonim: https://bugs.launchpad.net/bzr/+bug/1021537
<ubot5> Launchpad bug 1021537 in Bazaar ""missing referenced chk root" while merging gcc into gcc-linaro" [Medium,Triaged]
<tlonim> so 'bzr reconcile --canonicalize-chks' ?
<jelmer> tlonim: unfortunately that's not sufficient - it takes about 6 months to run that on the gcc repo, and it doesn't fix all instances
<tlonim> and that seems to be due to broken repo..if we know the possible commits which caused this, is it possible to fix only those?
<jelmer> tlonim: the broken commits are the commits in the existing gcc repositories, on which lp:gcc/1.8 gets stacked
<tlonim> hmm
<jelmer> tlonim: so in order to fix this, you'd have to do a fresh import of all existing gcc branches in Launchpad, or disable stacking somehow
<tlonim> in my case there is no svn bridgeetc.
<jelmer> tlonim: the essential problem is that both repositories disagree about the contents of an inventory (most likely a spurious file revision)
<jelmer> tlonim: I can't think of any easy workarounds
<tlonim> jelmer: so the "missing text keys:" are what caused the issue there?
<tlonim> I mean the contents of that list
<jelmer> tlonim: not really the texts themselves, rather that the text keys are slightly different in one or more revisions somewhere in the history of the two branches
<tlonim> hmm. which two branches, I am not doing a merge here
<jelmer> tlonim: you're copying them both into the same repository
<tlonim> yeah.. shared-repo
<jelmer> tlonim: right, so that repository has only one copy of each revision
<jelmer> tlonim: if other data you try to import into that repository references a bit of the ambiguous revision(s), things break
<tlonim> jelmer: so there may be something wrong with that branch itself - can I ask the people who merged into that branch to check
<jelmer> tlonim: right, so the problem is that one of the two branches has some revisions in it that were imported with an old version of bzr-svn that was buggy
<jelmer> tlonim: IIRC it was the linaro branch that actually had the issue in it
<tlonim> I don't think we use bzr-svn in my case.. did you see anything related to that in mine
<tlonim> jelmer: if I branch it as a non-shared clone, that should fix it for now right
<tlonim> btw, I am running
<tlonim> bzr reconcile -v  --canonicalize-chks lp:~percona-core/percona-server/release-5.5.32-31.0
<tlonim> let me see how long it takes
<jelmer> tlonim: that will allow the "bzr branch" commands to complete, but you won't be able to merge the two branches
<tlonim> jelmer: btw, this reconcile can be killed anytime without leaving repo inconsistent right
<jelmer> tlonim: the lp:gcc-linaro branch was actually created by bzr-svn originally (either bzr-svn directly or a launchpad import)
<jelmer> tlonim: the reconcile doesn't help IIRC
<jelmer> see my comment on that bug
<tlonim> ack
<tlonim> anyways, I got this with reconcile http://paste.wnohang.net/f45a3c :) (I guess that is because it is not on sftp or local right)
<spiv> tlonim: right
<spiv> tlonim: doing it locally will be much faster
<jelmer> it'll still be quite slow locally judging  by the comments on that bug report..
<spiv> jelmer: "faster" is a relative term :)
<jelmer> spiv: fair 'nough :-)
#bzr 2013-07-03
<thumper> hmmm...
<thumper> I have some changes deep in a branch that I want to remove
<thumper> so effectively removing those changes from the files and reverting the files back to the trunk revsion
<thumper> how do I do this?
 * thumper took a stab
<thumper> bzr revert filename -r branch::parent
<thumper> seems to work
#bzr 2013-07-04
<bigjools> thumper: ooo that's nice to know
<bigjools> had no idea revert could take -r
 * thumper nods
<thumper> bigjools: yep, been talking to myself all day
<bigjools> in multiple channels :)
<fullermd_> Don't call it talking to yourself.
<fullermd_> Talking to yourself is a mental disorder.  If you call it a soliloquy, it becomes fine art!
<idnar> I'm getting a cert verification failure trying to branch from Launchpad; brand new OS install
<idnar> I've never had to do any bzr/ssl configuration, any suggestions as to what might be broken with my setup?
<idnar> (OS is Debian unstable)
<mgz_> does `ssh -vv YOURLPUSERNAME@bazaar.launchpad.net` say anything of note?
<idnar> mgz_: this is ssl (https), not ssh, so I don't think that's relevant
<mgz_> you can branch over bzr+ssh
<idnar> I can't run bzr lp-login (for the same reason, SSL fails)
<idnar> I assume I can work around this by disabling SSL cert verification, but I'd prefer to actually fix it
<mgz_> you can just fill in the details in ~/.bazaar/bazaar.config
<mgz_> *.conf
<idnar> I guess I should check what CA cert Launchpad's cert is signed by
<mgz_> launchpad_username=
<mgz_> under [DEFAULT]
<mgz_> you can also just try curl
<idnar> hmm, good point
<idnar> looks like curl fails as well, so this isn't bzr-related at all
<mgz_> so, using bzr+ssh will avoid the issue
<idnar> (turns out the system clock was wrong, so it was rejecting a certificate because it was only valid in the future)
<mgz_> ah, cute
<mgz_> thanks for saying what the issue was :)
#bzr 2013-07-05
<bobweaver> how to make a bzr ignore file ?
<xnox> bobweaver: bzr ignore file
#bzr 2013-07-07
<lifeless> vila: we really should feed those gzipfile tunings upstream
<vila> lifeless: right, would have been easier when we had the resources to handle that, tech debt...
<lifeless> vila: yeah
#bzr 2014-06-30
<thrustcore> how do I mark a file as local-only?
<thrustcore> i.e. I have a modified file that is in version control but I don't want to ever accidentally commit it
<thrustcore> I changed it locally because I'm a special snowflake
<fullermd> 'd take hackery.  Maybe a plugin could arrange it.
<thrustcore> fullermd: got any idea what kind of hackery?
<fullermd> Not really.  You'd have to intercept the commit process somewhere along the path.  And probably the stat and diff processes too.
<thrustcore> aww, sounds like a pain
<fullermd> May be that you can find a bottleneck somewhere in there that hits 'em all.
<thrustcore> yeah but going through the process of dissecting everything will take too long, better to just "be careful"
<fullermd> Yeah.  It would probably not be a particularly quick process unless you already have bzrlib in your head.
<jelmer> thrustcore: generally what people do is just not check the file in and have bzr ignore it
#bzr 2014-07-01
<thrustcore> jelmer: how can I ignore the file?
<jelmer> thrustcore:  "bzr ignore FILENAME"
<thrustcore> thanks jelmer :) that's exactly what I wanted
<thrustcore> jelmer: now it says These files will continue to be version controlled unless you 'bzr remove' them. to the file I ignored though, is that right?
<spiv> thrustcore: right, "bzr ignore" doesn't provide a way to have a file be both versioned *and* locally modified.
<thrustcore> spiv: is there any way to do it?
<spiv> Not built-in.
<spiv> In principle it's something that could be added, but the bzr core doesn't have that concept so it'd likely be a pain to write a plugin to do it.
<thrustcore> what's the plugin language for bzr
<spiv> PYthon
<thrustcore> how do bzr plugins work?
<spiv> (There's also the UI challenge of adding yet another state a file can be in)
<thrustcore> I don't use the UI
<spiv> The "bzr" command line tool is still a UI :)
<jelmer> thrustcore: I think spiv also means the command line UI :)
<thrustcore> ah, indeed
<spiv> The best description of how plugins work is in the docs.  It'll be more complete and more accurate than I can describe on IRC :)
<spiv> Probably clearer too ;)
<thrustcore> all right then
<thrustcore> honest opinion, should writing such a plugin take more than 2 hours?
<spiv> If you're unfamiliar with bzrlib, I'd expect so unfortunately.
<spiv> (If you were, I reckon it'd be borderline; something hackish but sufficient for you might be possible in that time.)
<thrustcore> fair enough :)
<spiv> Probably a commit hook of some sort.
<spiv> But it'd probably need to do funny things with the WorkingTree objects passed through that hook.
<thrustcore> yeah, if I weren't using bzr as a part of my job I would probably just edit the source myself
<thrustcore> to just change the single place where it's committed
<davidbutler> hello
<davidbutler> I am trying to figure out how to get bzr integration wtih KDEâs dolphin, it seemed to work on a previous installation of ubuntu, but it doesnât seem to work this timeâ¦ I apt-get installed the plugin, do I need to do anything else to enable it?
<davidbutler> i solved my issue, btw
#bzr 2014-07-02
<DalekSec> So why is it when I use bzr lp-propose (with or without target branch), it seemingly randomly targets whatever it wants, not what I specify?  Most recently, I targetted nothing and it errord out, I targetted branch/utopic and it tried to submit to branch/trusty.
<SamB> DalekSec: I have no clue
<SamB> #launchpad may or may not have more clue
<DalekSec> This has been the cause of a fair amount of frustration for me, as I found out the only way to cancel is to killall bzr (kill the process.)
<SamB> SIGINT doesn't work?
<DalekSec> Not tried.
<mardy> I have a serious issue with bzr (bug 1336682), looks like git imports are not working anymore
<ubot5> bug 1336682 in bzr (Ubuntu) "bzr crashed with KeyError in get_raw(): '66531594d8745e0ae7bdeeffea2a6c51c0506cf3'" [Medium,New] https://launchpad.net/bugs/1336682
#bzr 2014-07-03
<DalekSec> SamB: Oh, and yes, I did get the answer in there.
<SamB> heh
<SamB> I wouldn't have a clue what you were talking about if this channel wasn't so dead ...
<DalekSec> FWIW, https://bugs.launchpad.net/bzr/+bug/1078211 it looked like.
<ubot5> Ubuntu bug 1078211 in Bazaar "lp-propose $BRANCH always prefers the parent branch" [Low,Confirmed]
<camako> Is anyone using changelog_merge? It's supposed to be for GNU-format ChangeLog files. Can it be used for debian/changelog as well?
<jelmer> camako: no, there is a separate merge hook for debian/changelog
<jelmer> which is a part of the bzr-builddeb plugin
<camako> jelmer, o cool... I'll check it out
<camako> jelmer, specific issue I'm trying to solve is changelog merge conflicts due to developer commits editing the file at/around the same place...
<camako> jelmer, I'm not sure if this plugin helps
<camako> I don't want to change how we manage packages.. just need help with merging...
<jelmer> camako: that is what the hoek does
<jelmer> camako: the plugin contains various tools (including this hoek) for managing Debian packages in bzr
<jelmer> Grr, Dutch autocorrect
<jelmer> I meant hook rather than hoek, obviously
<camako> jelmer, the documentation goes into talking abt complex package mgtmt discussion, so it wasn't obvious to me how I could use it to merge...
<jelmer> camako: I think the hook is enabled by default if you have the package and Debian devscripts installed
<camako> jelmer, specifically I have a branch with a one-line changelog addition, while the trunk (let's say) has another one-line commit that got ahead causing a merge-conflict... how would one use this hook to merge cleanly? If you know of any examples of this, it'd greatly help
<jelmer> camako: the hook should take care of that automatically while you merge
<camako> jelmer, sounds like exactly what I need... I'll dig more
<camako> thanks
#bzr 2015-06-30
<throstur> if I check out a bzr repository inside a folder which is in a bzr repository, how do I say "bzr update the repository I just checked out, not the `big one`" ?
<LeoNerd> Uhhm... "inside" ?
<throstur> imagine /foo/ is a bzr repo and CWD is /foo/bar/baz
<throstur> and I check out a different bzr repository there
<LeoNerd> Do you mean repository? I suspect you don't.
<LeoNerd> You probably mean branch
<throstur> I mean repository
<LeoNerd> A "repository" is not a thing that one checks out.
<LeoNerd> Branches are checked out
<throstur> ok, whatever, it's something I 'bzr export'ed
<LeoNerd> Uhm.
<throstur> but now I want to bzr commit it
<throstur> the changes I made
<LeoNerd> OK well if it's exported, the exported copy lacks all of the metadata
<LeoNerd> That being the point of an export :)
<throstur> Ah, okay, I see
<LeoNerd> 'bzr export' creates a snapshot of the controlled files at some moment in time, minus all the control information.
<throstur> ahh, okay
<LeoNerd> Useful for making release tarballs and such
<throstur> okay, then I'm thinking about this the wrong way
<LeoNerd> If you have some edited files, you could copy them into place over a new checkout, and then you'll see the differences by 'bzr diff', and you can commit as usual
<throstur> yeah but then I have to actually check out the whole thing with metadata
<throstur> I'm kind of afraid of doing that, last time I repacked I think I truncated some 30 GB away
<throstur> or maybe that was with removing obsolete packs, I'll see what the boss wants
<throstur> ok, so what if I want to check out the repository and update a single file?
<LeoNerd> Surely: checkout, update, commit...?
<LeoNerd> But again: it's "branches" that one checks out, not repositories
<throstur> but how do I make sure I'm working on the right branch or whatever?
<LeoNerd> By the URL you check out
<LeoNerd> URLs specify a branch
<throstur> ok, so normally I do "bzr export foo -r revno:-1 bzr://url.goes.here/path/to/repo"
<throstur> instead I would replace export with checkout?
<LeoNerd> bzr checkout bzr://....
<throstur> (and leave out -r revno)
<LeoNerd> Again, that's not a "repo". that's a branch
<LeoNerd> You gave it a path to a *branch*
<throstur> right
<LeoNerd> If you happen to have named it using the word "repo" then that's just a bit confusing. ;) It is a branch.
<throstur> roger that
<LeoNerd> (the distinction lies in that normally, when you create a new branch somewhere, bzr will create a repository at the same location to store it in. So *normally* it's correct to say that both the branch and the repository live there)
<LeoNerd> But nonetheless, it is the branch that almost all operations act on
<throstur> so how do I specify that I'm working on THIS repository and branch and not the one that starts in ../../..
<LeoNerd> Hrm?
<LeoNerd> Branches don't nest
<LeoNerd> If there's a branch at that location, then that's the branch. Period.
<LeoNerd> It's not like e.g. in SVN, wherein you can check out any subtree of the (SVN) repository
<LeoNerd> In bzr, if you've checked out the branch, then the branch arrives as one big atomic lump, with subdirectory structure of files. But that's still one atomic *thing* as far as bzr is concerned
<throstur> does checkout always take much longer than export?
<LeoNerd> It has to create the entire local copy of the branch in *addition* to a local snapshot of the files, so yes. that's expected
<throstur> but LeoNerd, I've already checked out a branch. If I type bzr update, I start updating something. Now I type bzr checkout bzr://... and it starts checking something else out. Now if I type bzr update, what am I updating?
<LeoNerd> Uhm..
<throstur> is it not possible to push a single file to be merged remotely?
<LeoNerd> bzr checkout   creates a branch new set of things locally on your disk
<LeoNerd> You'd usually do that into a brand new empty directory
<LeoNerd> *brand new
<throstur> like I'm literally on the 4th GB fetching revisions and I'm trying to add a 4kb file
<LeoNerd> If you already had it checked out, why are you checking it out a second time? :)
<throstur> it was only exported
<LeoNerd> <throstur> but LeoNerd, I've already checked out a branch. If I type bzr update, I start updating something. Now I type bzr checkout bzr://...  <==  I see "checked out" at the beginning
<LeoNerd> An export is not a checkout
<throstur> yes, that's not the same branch
<throstur> or repo
<LeoNerd> Again: an export is a snapshot of the current content, minus all of the control information and any history and any metadata sufficient to create and commit new revisions
<LeoNerd> If you want to create new revisions (which from "and I'm trying to add a 4kb file" it sounds like you do), then you will need a checkout. Not an export
<throstur> I'm on server A that has repository A checked out in folder A. I'm actually in folder A/foo/bar/baz and if I bzr update I update *something* (in this case, definitely repo A). NOW I check out repository B (whatever branch I don't know there is only one branch afaiac) and I want to work with B, but if I type bzr update, *something* will get updated, but I have no idea what
<LeoNerd> OK.. so if  bzr update  can do something,. then you do have a local checkout
<LeoNerd> Just typ   bzr info   to see what you have
<throstur> ah okay
<throstur> so if I'm writing this as a part of a library (don't ask why) I can just parse bzr info for "branch root: ." to ensure I'm in the *right* bracnh
<throstur> or rather, that i'm working in the bzr repository that I want to be working in, and not the one that I shouldn't be touching
<throstur> or I could check the bound to branch thing... that might be smarter
<LeoNerd> You could. (though also be aware of bzrlib, if you're writing this in python, as using the lib is nicer than trying to parse command output intended for humans)
<throstur> gosh though... a full checkout... I'm only up to 6 GB :(
<LeoNerd> You might be able to get away with a lightweight checkout. I forget quite what those involve and what they lack
<throstur> does bzr lib work for python 2.6.6?
<LeoNerd> I'd hope so
<throstur> oh yeah
<throstur> I remember that, no history
<throstur> it's like 20Gb smaller
<throstur> thanks for reminding me :D
<throstur> wow that took so much less time, 1.6 GB and almost done
<LeoNerd> History isn't cheap ;)
<throstur> looks like when I commit from python it doesn't work but when I commit from bash it works
<throstur> from python it tries to commit to "the other" repo
<throstur> actually I'm wrong, it just things the file isn't versioned
<throstur> but it is
<throstur> oh lol
<throstur> it's because I chdir one dir up
<throstur> to be in the right repo
<throstur> how do I bzr commit to ./this_thing instead of cd this_thing bzr commit ../path/to/file
<throstur> thx4the help I g2g got a workaround going, will see if it breaks something overnight
#bzr 2015-07-05
<logicalguy> Hi, what is the command to ignore a directory and all subdirs/files in it?
#bzr 2016-07-04
<throstur> I updated a versioned file, but `bzr diff FILENAME` shows no changes, trying to commit says "nothing to commit", what's going on?
<throstur> found a workaround, nevermind...
#bzr 2016-07-05
<josharenson> Is there a way to force a removal of a remote lock? I keep getting an error when trying to push my branch to LP...
<josharenson> My connection dropped halfway through my first attempt and now it seems stuck
<josharenson> this is my specific error http://pastebin.ubuntu.com/18562666/
<josharenson> trying bzr break-lock <remote>
