#bzr 2007-09-10
<igc> morning all
<Odd_Bloke> Ack, I know I should be in bed when igc shows up. :p
<igc> Odd_Bloke: :-)
<lifeless> real    2m0.424s
<lifeless> user    1m47.271s
<lifeless> sys     0m5.912s
<lifeless> creeping down
<Odd_Bloke> \o/
<nvictor> hello all
<nvictor> I want to setup bazaar and use it with a friend on a small website project, how do I start?
<Odd_Bloke> nvictor: 'bzr init', 'bzr add', 'bzr commit -m "Initial import."' will get you to a Bazaar branch which you can then start using.
<Odd_Bloke> nvictor: You then need to decide on what sort of development process you want to use, as Bazaar is able to model several effectively.
<nvictor> Odd_Bloke: I'm new to all this
<nvictor> Odd_Bloke: just need simple version control for our project
<nvictor> with messages mailed to each of us
<nvictor> when changes are made
<nvictor> with information and all...
<Odd_Bloke> nvictor: I'm not at all familiar with using Bazaar in such a distributed manner.
<Odd_Bloke> If you hang around, someone better able to help you should pop their head up...
<nvictor> Odd_Bloke: tell me how you use it then
<lifeless> the bzr email plugin will send emails
<nvictor> lifeless: does it require linux?
<Odd_Bloke> nvictor: Well, just about everything I use Bazaar for is Free software so there's no problem using Launchpad to serve my branches.  I assume that this is a private website project.
<nvictor> yes
<nvictor> so I guess that means I can't use launchpad
<Odd_Bloke> No, there's no provision for keeping a branch private.
<Odd_Bloke> Except possibly for internal Launchpad devlopment, but that obviously doesn't apply. :p
<Odd_Bloke> nvictor: I'd look at the email plugin. :)
<nvictor> I see
<nvictor> yes
<nvictor> but I'm under windows
<nvictor> we are both
<nvictor> but the web server is under a linux machine
<nvictor> so I think it would be better to set bazaar there
<nvictor> right?
<Odd_Bloke> nvictor: Ah, if you have a server then life becomes easier. :)  You will still need Bazaar installed locally though.
<Radtoo> If you want a "centralized" sort of repository, ye the server would be the natural place for it.
<Radtoo> (or more than one such repositories)
<nvictor> ok
<Odd_Bloke> nvictor: You're probably better reading through http://bazaar-vcs.org/Workflows than us trying to explain all its content to you.
<nvictor> ok
<nvictor> thanks guys
<nvictor> see you guys
<spiv> Good morning.
<igc> morning spiv
<lifeless> real    1m47.917s
<lifeless> user    1m36.566s
<lifeless> sys     0m5.336s
<lifeless> igc: ^
<igc> cool. Bit drop from even 2 hours back .Well done!
<igc> s/Bit/Big/
<igc> awesome!
<igc> lifeless: I'll review your patch later today btw
<lifeless> thats bzr.dev + packs + using PlainText rather than annotated texts
<lifeless> so a ways to go to get this end user readyt
<igc> true. But the point is we now *know* what's required to reach that time - that's a big step regardless
<lifeless> oh,I'm not done yet ;)
<igc> I know that. :-)
<igc> I'm looking forward to this week - should be a good one
<lifeless> igc: how much time does your work shave off a packs branch ?
<igc> I'd need to remeasure
<lifeless> only takes a couple of minutes :)
<lifeless> oh, what is 'saving data locally' around ?, I've been meaning to look that up ;)
<lifeless> its about 7 seconds long
* igc food
<igc> lifeless: bug in your commit stuff in the pack branch: http://rafb.net/p/Y0R9wG44.html
<igc> lifeless: fyi, merging my changes into the pack branch is currently a slight loss performance wise on initial commit of a moz tree. I had expected most of the gain to disappear but not all of them so I'll dig a little and check that I did the merge correctly
<lifeless> igc: already fixed
<lifeless> thanks for checking the perf results
<igc> lifeless: can you push the fix please
<abentley> lifeless: I think we are likely to encounter bugs due to badly-split lines in the future if we apply your change.
<abentley> I certainly encountered problems when implementing bundle 4.
<abentley> In fact, I wouldn't be surprised if the check you found dates to that.
<lifeless> abentley: it dates way back, 0.11ish timeframe I think, or before
<lifeless> abentley: its a huge performance hit to do all the time, but I could make it an optional check that can be turned on/off if you want to be able to do it
<lifeless> while that still costs, it doesn't cost as much
<abentley> I'm really torn.  Because I know people will use it wrong, because I used it wrong.
<abentley> I don't know how people would know to turn it on.
<abentley> And maybe we can't afford to guard against it.
<abentley> But I don't think it is widely known that ''.splitlines is bad.
<lifeless> I agonised on it too
<lifeless> here are some thoughts
<lifeless> have it a disablable check, that our code disables
<lifeless> or have the test suite turn it on automatically for all knit objects during test execution
<lifeless> or allow people enough rope to shoot themselves, and trust that people using the knit api directly will do enough testing to realise they can't get data back out
<lifeless> woot
<abentley> Turning it on during testing sounds reasonable.
<lifeless> pack push is really getting quite slick
<lifeless> 2 minutes to push a few commits to people.ubuntu.com via sftp
<lifeless> including two ssh connection opens to connect
<abentley> But I can easily imagine cases where people don't test knit code thoroughly with LF data.
<lifeless> whats the real exposure though
<abentley> s/LF/CR
<lifeless> foreign branches
<lifeless> core code is less of a concern IMO we have solid reviews
<lifeless> anyhow, I'm open to mitigating the risk, but its a 5-10 second win to not check every line
<abentley> I'm not sure whether Bundle 4 was reviewed.  I tend to think not.
<abentley> I've had consistent problems getting things reviewed, so sometimes they get merged without review.
<lifeless> well, thats not your fault
<lifeless> but I do take the point
<lifeless> also more philosophically its really a symptom of api design that we conceptually have to do this check
<abentley> Yeah.
<lifeless> but
<abentley> MPDiff only takes strings as input.  Not sure if that's better API, but at least it's safer.
<lifeless> taking other things also has different tradeoffs
<lifeless> taking a callback to get the lines is equally breakable
<lifeless> take a string means we have to do the split ourselves, with another mem copy of every string
<lifeless> taking a call to open a file object will be tricksy for things like mpdiff, you'll end up writing a thunk which is still fallable
<lifeless> back later
<lifeless> ciao
<abentley> l8r.
<Drago84> hola
<Drago84>  bzr co bazaar.launchpad.net/~awn-core/awn/trunk avant-window-navigator
<Drago84> bzr: ERROR: unknown command 'co'
<Drago84> help me please?
<Drago84>  bzr co bazaar.launchpad.net/~awn-core/awn/trunk avant-window-navigator
<Drago84> bzr: ERROR: unknown command 'co'
<lifeless> Drago84: 'checkout'
<lifeless> Drago84: or 'branch'
<lifeless> also your url is invalid - you need a protocol on it
<lifeless> 'bzr help' will tell you the commands available
<poolie> Drago84, you need either http:// or bzr+ssh:// or sftp:// before the hostname
<ubotu> New bug: #138600 in bzr "`bzr mkdir` create new dir before it checks is branch/checkout exists" [Undecided,New]  https://launchpad.net/bugs/138600
<matkor> Will bzr 0.14 work with 0.90 repos ? I can not see anything more fresh in mandriva I have to work with ?
<AfC> matkor: just install from source. 0.14 is ancient.
<AfC> matkor: (or manually bump your package, or whatever)
<matkor> AfC: thanks
<Odd_Bloke> Using WorkingTree.merge_from_branch doesn't seem to merge tags.  What internals should I use to replace a call to merge that should be transferring tags (in the blackbox testing)?
<ignas> how do i change the email that is shown in commit info ? now it is "committer: Ignas Mikalajunas <ignas@my-machine-name>"
<ignas> i'd like it to point to my actual email
<radix> ignas: bzr whoami "Christopher Armstrong <radix@twistedmatrix.com>"
<ignas> radix: thanks
<ignas> is it a global setting or a local one?
<radix> ignas: global, if I understand your meaning
<radix> it's not per-branch
<radix> oh
<radix> but apparently you *can* set it per-branch
<radix> bzr whoami --branch "foo bar etc"
<ignas> i see
<ignas> thanks
<radix> those wacky bzr developers, always adding nifty features ;-)
<markvandenborre> I want to recursively remove a directory from a checkout
<markvandenborre> but bzr rm --force dir_to_be_deleted
<markvandenborre> complains about a non-empty dir
<ubotu> New bug: #138716 in bzr "RFE: Smart Server logging" [Undecided,New]  https://launchpad.net/bugs/138716
<Enquest> while doing a commit my internet connection was lost...
<Enquest> now I want to do the commit again.... however I get something about locked
<Enquest> can I remove the file repository/lock ?
<luks> `bzr break-lock` is probably a better solution
<corporate_cookie> is there an issue with paramiko in python2.5 ?
<Peng> Works for me?
<corporate_cookie> alas .. i do not seem to be able to import it ...but I an see the bugger in site-packages
<corporate_cookie> but im glad to know it works Peng
<corporate_cookie> thanks
<seanhodges> does anyone here use bzr-svn over HTTPS?
<jelmer> seanhodges: yeah
<jelmer> seanhodges: 0.4.1 had some issues with http repositories unfortunately, all other releases should be fine
<seanhodges> hey jelmer, i'm having trouble getting it to work. I'm getting the 401 authorisation error (getting the error now to paste it here)
<seanhodges> i'll check my version whilst i'm at it
<jelmer> are you using it against a google hosted project by any chance?
<jelmer> or does the repository really require authentication?
<seanhodges> no. its hosted by the company i work for
<seanhodges> over Apache SSL
<jelmer> if it requires authentication, you have to access it using svn itself somehow
<jelmer> e.g. 'svn ls <url>' should ask you for that password and store it in the cache
<jelmer> which can then be used by bzr-svn
<seanhodges> i understand. so if i check out using svn i should be able to use bzr-svn after that - giving it a go
<seanhodges> well it didnt fix my immediate problem, but at least i know svn has stored the password permanently now
<jelmer> it's still complaining about the 401 ?
<seanhodges> yeah:  Unable to handle http code 401: Authorization Required
<seanhodges> using this command: bzr co https://svn/svn/nina/trunk
<jelmer> that should work if it stored in the password in svn correctly
<jelmer> you can try prefixing the url with svn+ so it will bypass the check for the repository type
<jelmer> (bzr co svn+https://svn/svn/nina/trunk)
<seanhodges> i'll admit now i'm using a pretty old version of bzr-svn... 0.3.2. the reason for this is the bzr-svn website matched that version to my version of bazaar (0.15.0)
<seanhodges> that gives me this error: "bzr: ERROR: Unsupported protocol for url "svn+https://svn/svn/nina/trunk""
<jelmer> I'd really recommend upgrading, 0.3.2 is really really old
<Enquest> I'm doing a commit but bzr always stays stalled at "Uploading data to master branch - Stage 3/5"
<Enquest> why would that be...
<jelmer> Enquest: it may just be slow, especially in older versions
<Enquest> is the latest version
<Enquest> how slow would that be... 10 minutes?
<Enquest> its only a webproject...
<seanhodges> jelmer, i did something stupid: took my svn dir out of ~/bazaar/plugins to try the latest build, but didnt put it back.
<seanhodges> i've just recified that and tried the svn+https:// approach again and it looks like it's working
<seanhodges> i think saving the password did the trick. thanks a lot for your help. - i'm gonna go shout at myself and make a tea
<jelmer> Enquest: bzr+ssh is faster than sftp
<jelmer> seanhodges: cool
<jelmer> Enquest: what size is the project in ters of number of files / number of revisions?
<Enquest> jelmer, with bin some 30 M
<Enquest> its a first commit
<jelmer> hmm, wouldn't know why it's so slow then, sorry
<seanhodges> Enquest have you checked it's not a firewall issue? does it download quickly just downloading the directory using the sftp program?
<Enquest> it simple stalles each time... I'm restarting the whole process
<Enquest> It is the first time I use bazaar. I used SVN before
<luks> don't, it just looks it stalled, it's actually doing something
<seanhodges> same here, afraid i was mostly guessing
<luks> restarting will not help it :)
<seanhodges> thats true, my https download paused for nearly a minute before it started fetching
<luks> initial push/pull is always slow, over bzr+ssh it's a bit faster, but not much in the current version of bzr
<seanhodges> luks is the delay related to building the bzr repository? just interested
<luks> no, it needs to check and upload many files
<luks> which causes many roundtrips
<seanhodges> ok, cool
<luks> so most of the time you spend waiting for connection, not actually uploading
<luks> at least that's my understanding of the 'official excuse' :)
<fullermd> I blame it on gnomes, personally.
<seanhodges> haha makes sense. I'm just waiting for my checkout to complete - does each push back to the svn server have a similar pause? or are the roundtrip checks related to the init?
<seanhodges> fullermd, i think thats one excuse i havent seen on bash.org
<fullermd> Well, it's sensible.  That's why you haven't seen it there   :p
<seanhodges> lol
<loswillios> hi guys
<loswillios> I can't install the latest bzr on my debian system
<loswillios> error in control file: `Files' value not specified at /usr/sbin/install-docs line 701, </usr/share/doc-base/bzr> line 10.
<loswillios> ugh, the sources.lst entry has changed. there's -2 out already
<fullermd> I'm pretty sure that's a known thing in the packages...
<fullermd> Something about being built on a version that didn't need the Files, though other versions do?
<loswillios> yeah, 0.90-2 fixed it.
<loswillios> I didn't update my sources.lst
<dato> fullermd: yeah, something like that
<loswillios> thanks guys
#bzr 2007-09-11
<igc> morning
<NfNitLoop> evening!
<NfNitLoop> :)
<poolie> hello
<lifeless> hi
<jelmer> 'morning igc, NfNitLoop, poolie, lifeless
<poolie> hi
<igc> morning jelmer
<lifeless> wow
<lifeless> so much wiki spam
<poolie> yeah, sucks
<poolie> lifeless, i'm reading your commit overhead patch
<lifeless> poolie: ...
<poolie> ?
<lifeless> you said you're reading the patch
<lifeless> and then nothing
<poolie> i voted +1
<poolie> for 0.91
<lifeless> ok
<keir> lifeless, did you end up pulling my branch?
<lifeless> keir: sorry no I haven't yet
<lifeless> I *meant* to but ended up tweaking performance of commit more
<lifeless> igc: shall we chat shortly about how we combine branches?
<igc> yes - I call in 10 minutes?
<keir> lifeless, no problem; i fixed some idiocy in it on the bus
<lifeless> igc: please
<poolie> lifeless or igc, would you please look at http://bundlebuggy.aaronbentley.com/request/%3Cm2wsuyzoy3.fsf@free.fr%3E
<lifeless> igc: I don't think my patch needs to change, I've replied with why.
<lifeless> igc: would appreciate you checking back on it so I can merge for 0.91 as per poolies ok.
<igc> lifeless: I'll look now
<igc> lifeless: no email reply through yet btw
<lifeless> poolie: I've looked at it
<poolie> i was not disagreeing with igc's comment about naming, btw
<poolie> i have not seen your reply yet
<lifeless> poolie: its already +2 AFAICT, but it looks fine to me, I agree with your comment on the review
<lifeless> poolie: igc: the reply just got through now
<igc> just got it
<lifeless> can we get a captcha on the wiki add-user page ?
<igc> so lifeless, if you add a comment above the call to add_lines_with_ghosts explaining what it's being called instead of add_lines, I'd appreciate it
<igc> s/what/why/
<lifeless> igc: so there are two reasons;
<lifeless> one is that its the right api to use, because it supports committing with ghosts
<igc> I got the reasons ...
<lifeless> the other is that its a slightly cheaper call
<igc> I just want it in the code
<lifeless> sure
<lifeless> I'm just noting that I didn't mention the former in the patch at all
<igc> ok
<igc> poolie: do you need more feedback on Vincent's patch?
<lifeless> It seems a strange thing to comment on is all I guess
<lifeless> kindof like saying 'we use .readlines() because it gives us the file lines with \n'
<lifeless> its true, but redundant
<igc> not IMO ...
<igc> the name _with_ghosts suggests ghosts :-)
<lifeless> its a convention across the code base for apis that support ghosts
<lifeless> and this api supports ghosts
<igc> ok - merge it and we'll move on
<igc> ping me when that's done and I'll call you
<igc> poolie: anything else you want from me before I call lifeless?
<lifeless> did my knits patch seem ok for 0.91 ?
<igc> lifeless: I didn't review it because abentley had concerns on IRC
<igc> if those concerns are resolved, I'll look closer
<igc> it looked ok at first glance yesterday
<lifeless> I don't think they are resolved
<lifeless> abentley: care to reply to my knits patch ?
<lifeless> igc: the patch is away with a comment added
<igc> thanks
<lifeless> so ring anytime
<igc> Right now. Some quick feedback on your other patch emailed just now.
<ubotu> New bug: #138787 in bzr "revspec paths don't interpret user refs" [Low,New]  https://launchpad.net/bugs/138787
<lifeless> === modified file 'bzrlib/repofmt/pack_repo.py'
<lifeless> --- bzrlib/repofmt/pack_repo.py 2007-09-09 23:45:05 +0000
<lifeless> +++ bzrlib/repofmt/pack_repo.py 2007-09-10 07:11:39 +0000
<lifeless> @@ -1032,7 +1032,8 @@
<lifeless>          return knit.KnitVersionedFile('text:' + file_id, None,
<lifeless>              None,
<lifeless>              index=knit_index,
<lifeless> -            access_method=self.repo._text_knit_access)
<lifeless> +            access_method=self.repo._text_knit_access,
<lifeless> +            factory=knit.KnitPlainFactory())
<lifeless> igc: ^
<igc> thanks lifeless
<lifeless> like I say, trivial :)
* igc food
<lifeless> poolie: ping
<poolie> pong
<lifeless> you seem to be marking bugs as fix released before they are in a release
<lifeless> our convention documented on the wiki is fix committed until its actually in a release, isn't it ?
<poolie> is it?
<poolie> i thought we had decided to mark them FR when they were merged, because there is no way to bulk update them
<lifeless> oh, I'm confused
<lifeless> yes you are right, bzr.dev == FR
<poolie> i would much prefer to do it the other way but it's not feasible atm
<poolie> well, i guess we could write a script that would generate status-changing mails
<fullermd> Is it a bug that bzr rm'ing a file/dir with conflicts doesn't resolve the conflicts (nor does 'resolve' auto-resolve them)?
<poolie> yes, but it may not be a known bug
<poolie> fucking spammers
<lifeless> you can update many bugs with one mail
<lifeless> poolie: can we get a captcha on the wiki user creation page ?
<fullermd> Mmm.  Don't see it.
<poolie> s/mails/mail
* bitmonk wonders if anyone has tested bzr with alternative python implementations at all
<fullermd> Search does bring bug 5140 though.  I'm not sure that should be on bzr...   bzr-email, maybe.
<ubotu> Launchpad bug 5140 in bzr "Merge emails blow my mind" [Wishlist,Confirmed]  https://launchpad.net/bugs/5140
<lifeless> poolie: also, I think we want more grnularity than lp offers
<Verterok> bitmonk: I tried with Jython and Jythonx (now dead). but no even closer to do a; import bzrlib :(
<bitmonk> worth a try with pypy, i suppose..
<lifeless> as if bzr isn't slow enough already
<poolie> lifeless, more granularity in bug state?
<poolie> or ironpython
<lifeless> poolie: yeah, fix in my branch, fix in bzr.dev, fix in tarball
<fullermd> Funny.  You can notice how much faster commit has gotten the last few versions, even on tiny branches, when writing and testing bug reproduction scripts.
<fullermd> Obviously, we need more bugs, so the speed improvements are visible   :] 
<beuno> anyone up to helping me solve a small glitch in a feature I'm trying to add to xml-output plugin?    I want to capture some of the output from 'bzr missing' to put it into the XML, but I can't seem to figure out how to capture the 'Using last location:' bit
<ubotu> New bug: #138802 in bzr "tag deletion does not propagate" [Medium,Triaged]  https://launchpad.net/bugs/138802
<ubotu> New bug: #138803 in bzr "rm'ing conflicted files doesn't resolve conflicts" [Undecided,New]  https://launchpad.net/bugs/138803
<fullermd> beuno: I would presume it's going to stderr...
<beuno> fullermd, sorry if the questions are a bit too obvious, I'm still finding my way around python (and bzr code). I'd have to capture that differently then I capture the revision info?  (I'm currently wraping that fine)
<fullermd> Oh, well, I dunno anything about catching it in python.  There's probably a standard arg for however you capture stdout to cram stderr in with it, or at least a way to access the fd.
<lifeless> beuno: how are you hooking into the command ?
<beuno> lifeless, builtins.cmd_missing
<beuno> http://codebrowse.launchpad.net/~beuno/bzr-xmloutput/xml-beuno/annotate/argentina%40gmail.com-20070902215621-wiq1c4ssihnfestz?file_id=__init__.py-20070406035637-ac26bagfmjgniyko-1
<beuno> line 96 is the function
<beuno> or class  :D
<lifeless> ok
<lifeless> the thing you want to output is not partof the log
<lifeless> you just need to do it yourself
<poolie> fullermd, thanks for the bug updates
<lifeless> you will probably want to file a patch for bzrlib to make it easier
<lifeless> e.g. a helper method to factor out that logic
<poolie> lifeless, i crave your review of my tag bug patch
<beuno> lifeless, I was suspecting that was where it would en up...  :/      Because antoher option would be not to display that for now, since it breaks the XML, but do I have a way to do that?
<lifeless> beuno: yes, copy the body of the bzrlib method and change it
<lifeless> beuno: I recommend giving us a patch ;)
<poolie> lifeless, trust you to know of the http Warning header
<lifeless> poolie: ok, will lunch first
<lifeless> poolie: :)
<poolie> i have never encountered such a athing
<beuno> lifeless, argh, you're going to make me fly away into crazy bzr/python world for the next two days...
<lifeless> I'm not aware of any client that actually shows it; though I haven't tested in about 3 years
<beuno> I never pick the easy stuff...   :p
<lifeless> beuno: you could start by filing a bug
<lifeless> maybe a python dev will be kind to you
<poolie> lifeless, let's talk after that? i might go for a ride in the meantime
<lifeless> k
<beuno> lifeless, ok, I'll file a bug and try and approach it until I run everyone here out of patience   :D
<lifeless> poolie: ok
<sabdfl> evening all
<beuno> evening sabdfl
<lifeless> hiya
<igc> evening sabdfl
<beuno> lifeless, I'm going to go ahead and reimplement missing in the plugin itself, and then see how we can improve it in bzrlib itself
<lifeless> poolie: ring me at your convenience
<lifeless> igc: repository branch fixen pushed
<lifeless> 2759
<igc> great - thanks
<lifeless> not entirely failure free;
<lifeless> but enough to benchmark reliably again
<igc> understood
<abentley> lifeless: I've decided to abstain.  If someone else reviews it and decides the tradeoff is worth it, that's fine by me.
<ubotu> New bug: #138812 in bzr "no tag --local operation" [Undecided,New]  https://launchpad.net/bugs/138812
<lifeless> abentley: did any of the compromises we chatted about seem reasonable ?
<abentley> Enabling the tests during test suite runs seems like an improvement.
<keir> lifeless, does the transport layer buffer reads automatically? when i read the preamble, i'm reading in 2 chunks, then finally a larger chunk
<keir> if the transport would go ahead and grab 4k after the first read, and then i didn't have to deal with buffering that data, that would be great.
<abentley> That would mean that a careful tester would catch bugs in this area.
<abentley> I think I could live with that.
<lifeless> keir: transports have no buffering in general
<keir> so i have to implement my own buffering layer?
<lifeless> so if you want 4K + preamble, guess at the largest size of preamble and read preamble + 4K
<lifeless> well
<lifeless> buffering is one way of doing it
<lifeless> but buffering on local disk has very different tradeoffs to dealing with a tcp connection
<keir> alright. for now i'll just leave it. 1 extra round trip per index is not a big deal
<keir> i have single-item get working with caching
<keir> but it does a single readv() on every miss
<keir> so next i'm going to do fetch-many-keys lookup, which iterates between passes which readv() blocks, and descends them
<abentley> keir: On your structure, is it expensive to determine that a key is not present?
<keir> no different than if it is
<keir> actually, it may be cheaper
<keir> depending on the key
<keir> but i suspect in most cases checking if a key is present is the same as if it's there
<keir> for most packs, i expect it to be only one tree lookup + another 4k block fetch
<keir> abentley, is that a very common check?
<abentley> I'm not sure.  I just realized it wasn't something we'd discussed.
<keir> generators are wacky. i think i'm going to use them to accumulate read vectors. are they slow?
<fullermd> Oh look, no useful header to filter launchpad's blueprint mailings on.
<abentley> keir: generator iteration is faster than function calls, but slower than a tight loop.
<abentley> They are typically a good choice, but if every last drop of performance matters, doing it all in a loop may be better.
<abentley> As always, profile.
<keir> in the end, i'm using recursion *ducks!*
<lifeless> poolie: done
<lifeless> poolie: your branch is made
<Stevage> hello everyone
<Stevage> could someone answer a couple of questions for me?
<beuno> Stevage, sure, we'll try
<Stevage> coolies - I'm evaluating using bzr for work
<Stevage> is it possible to checkout a single file, and not a whole directory?
<lifeless> ciao
<Stevage> eg, file /docs/doc1.txt - I just want to checkout doc1.txt into a normal directory
<lifeless> no but you can cat it - bzr cat url/docs/doc1.txt
<igc> lifeless: ping
<igc> lifeless: some quick Qs re your branch ...
<igc> content_summary is always returning a sha of None ...
<lifeless> ring my mobile in 2 mintues please
<igc> because it's running the one in workingtree, not workingtree4
<igc> cool
<Stevage> ah interesting
<Stevage> so I can do a kind of one way check out
<Stevage> but then not check any changes back in
<Stevage> ok next question: say I have a file (versions.h) that is used by two different projects, and should be checked out by both of them. how can I set that up?
<jamesh> Stevage: "bzr cat" is roughly equivalent to "cvs update -p"
<jamesh> Stevage: for the second question, Bazaar's answer would probably be nested trees
<jamesh> the shared files would be in their own branch, and that branch would be nested in the two projects' branches
<Stevage> how do I nest?
<Stevage> I tried doing it with a checkout, but those files didn't get added to the parent branch
<Stevage> as in, I created /shared and /proj1 and in /proj1 did bzr checkout ../shared
<Stevage> so then I have /proj1/shared - good. but when I update /work1 which is bound to /proj1, it didn't pull in /shared
<jamesh> I am not sure how much of the nested tree stuff is in mainline yet
<jamesh> so at present you need to do it manually (this will likely change in the future)
<Stevage> yeah looking at ConfigManager atm
<Stevage> I'm on windows, so looks like a pain to build
<jamesh> or use ConfigManager
<jamesh> Stevage: the version of ConfigManager you want is written in Python
<jamesh> grab the branch listed here: http://bazaar-vcs.org/3rdPartyDownloads
<Stevage> yeah?L
<Stevage> that one is C++
<Stevage> with a python wrapper
<jamesh> the branch contains both the old C++ implementation (which doesn't support bzr, iirc) and the new Python implementation
<Stevage> oh yes there is some code in /lib
<Stevage> have you tried setting it up on windows?
<jamesh> nope.
<jamesh> do "bzr branch http://www.robertcollins.net/config-manager/trunk/ config-manager" to download it
<jamesh> the files you see when browsing it in a web browser are likely out of date
<Stevage> sweet
<Stevage> will I need to install python then?
<Stevage> bzr comes with the python dll but that's all I have
<jamesh> Stevage: no idea.
<jamesh> Stevage: but probably.
<Stevage> ok
<Stevage> might actually be simpler for me to just hack up a couple of batch files that do the job
<Stevage> do you know if it's possible to commit several files at once, specifying individual commit messages for each one?
<jamesh> Stevage: commits are tree wide, so it isn't possible to do separate messages for separate files within a commit
<fullermd> Is there some reason we don't have a Branch.open_containing_from_transport?
<poolie> fullermd, it would seem reasonable to have one
<fullermd> It'd need direct tests, wouldn't it...
<igc> night all
<matkor> Hi !
<matkor> >>> local_branch.missing_revisions(parent_branch)   ->    bzrlib.errors.DivergedBranches: These branches have diverged. Use the merge command to reconcile them
<matkor> How can I get information what revisions are missing on both branches ? TIA
<spiv> matkor: bzr missing
<spiv> matkor: you can see the implemenation of that command in bzrlib.builtins.cmd_missing
<matkor> spiv: Thanks
<vila> fullermd: the reason should be historical, the _from_transport methods began to be added when we tried to avoid multiple connections
<vila> fullermd: where do you encounter the need for it ?
<matkor> Can I browse recent bzr source on web somewhere ? http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.builtins.cmd_missing.html does not give hints and I have only pyo/pyc files installed ...
<mwh> matkor: http://codebrowse.launchpad.net/~bzr/bzr/trunk/files
<matkor> mwh: thanks !
<fullermd> vila: Well, I was trying to fix up pull to be more forgiving, but that's sounding like a lot bigger bite than I can chew.
<vila> fullermd: bug ref ? More forgiving about ? (can't relate that to a recent topic, please refresh my memory :)
<fullermd> Well, just what you'd expect an open -> open_containing switch; more forgiving about being given a location other than a branch root.
<fullermd> No bug ref or topic I recall; just something I ran into earlier tonite and thought (erroneously, perhaps) might be simple enough that I could pull through.
<matkor> Is remote_branch.lock_read() expensive ? 2) What may happen if I operate over unlocked branch ? 3) How it is done over http ?
<vila> fullermd: hmm, Branch already have an open_containing method
<vila> this method already offers a 'possible_transports' parameter so _from_transport should not be needed
<fullermd> Well, pull uses open_from_transport() now.  I'm far too wildly unknowledgeable about the differences between funct...  er, methods, and data struc.... er, objects, to have any clue how/if I can turn one into another.
<vila> fullermd: b.open_from_transport(location_transport) ~= b.open_containing(location, possible_transports=[location_transport] )
<vila> fullermd: for fuzy values of ~=
<fullermd> Right, see, I have no business being involved in fuzzy   :p
<fullermd> I don't have any business being involved in sharp and clear either, but I like living on the edge.
<vila> even with a single 'z' which implied less fuzzyness ? :D
<fullermd> Sounds to me like having one eye poked out instead of two   :|
<fullermd> Holy squat, bundle is fast now.
<matkor> Hmm. One can't add '@" to info_dialog content message ?
<dato> AfC: re the scm-gnome thread, I think it'd be better to give each project an independent shared repo, where trunk and branches are kept.
<AfC> dato: yeah, duh that makes sense - above that level, revisions are never going to be shared
<dato> right.
<AfC> [at least, not until we go WAY further down the nested branch and my project uses your project's sources paths] 
<AfC> dato: [please do point that out in an email] 
<dato> AfC: okay
<matkor> jelmer: Could you please review and merge olive-gtk bugfix from https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? TIA
<jelmer> matkor: I'll have a look this evening
<matkor> jelmer: Szilvester is testing it right now, but more eyeballs - the better ...
<Enquest> If I want to delete a branch in my repo how do I do this?
<Enquest> rm -R branch ???
<dato> Enquest: yes, knowing that revisions belonging to that branch will stay unreferenced in the repo
<Enquest> dato and is there a more clean way ??
<Enquest> I made some big mistakes starting a branch... And want to start a new
<dato> not at the moment.
<Enquest> a new branch same name
<dato> Enquest: but I think rm -r it's okay, unless you committed some very big files or something.
<Enquest> so rm -R is realy ok!
<jelmer> matkor: I don't run olive myself but am happy to review
<mwhudson> crap
<mwhudson> jelmer: bzr-svn just did this to me http://rafb.net/p/FGNzoK46.html
<asabil> hi all
<asabil> what is the bzr commit --fixes for ?
<asabil> is it for bugzilla integration ?
<Odd_Bloke> asabil: Launchpad integration, certainly.  I don't know about Bugzilla.
<asabil> ok thanks
<luks> it isn't integrated with launchpad at the moment, though
<luks> http://doc.bazaar-vcs.org/latest/en/user-guide/bug_trackers.html
<Enquest> how do I rename a dir with bzr
<luks> bzr mv
<Odd_Bloke> Enquest: Or if you've already renamed it, 'bzr mv --after'.
<Enquest> thanxs
<AfC> Enquest: (you use that to rename {,after} files as well)
<Enquest> thxs
<AfC> Enquest: watch out for moving symlinks though... as I recall, it might choke on those. You might have to remove/add still. [Maybe that's been fixed] 
<Enquest> no symlinks in this
<Enquest> I'm just starting with bazaar
<jelmer> mwhudson: hmm, will have a look this evening
<mwhudson> jelmer: okidoke
<mwhudson> jelmer: path is a bytestring path with non-ascii characters btw
<mwhudson> 'pypy/extradoc/talk/22c3/speaker-beatriced\xc3\xbcring.txt'
<mwhudson> in fact
<mwhudson> (which looks like utf-8 to me)
<matkor> During bzr update of checkout of branch: sftp: I have to provide password three times ... is it bug ?
* netjoined: irc.freenode.net -> kubrick.freenode.net
<AfC> Hm. In bad old CVS land, if you have a repository with 20 modules, and you do a change (simple refactoring, say) in each one, does that imply the need to do 20 independent commits? I believe so. Anyone remember?
<LeoNerd> Noy really
<LeoNerd> *Not
<LeoNerd> CVS considers each file individually, nothing bigger.
<LeoNerd> If you've changed 20 files, you need to commit 20 files.
* Odd_Bloke is too young to have used CVS. :D
<LeoNerd> Either 20 individual "cvs commit" commands, or one, or whatever.
<AfC> LeoNerd: yeah yeah... but if you're in a given checkout, and you type naked `cvs commit` it storms off recursively, right, same as every other VCS tool. But there's no `cd .. ; cvs commit` that would recurse across 20 directories that happen to be modules from the same repository, is there?
<LeoNerd> Not normally, no...
<LeoNerd> I don't know about most people, but I have a whole tonne of wrapper scripts for that though
<LeoNerd> cvs eachroot commit -m "Here's some changes"     would do that for me ;)
<corporate_cookie> I'm having some issues installing bzr 0.90 The problem lies with importing paramiko which i've recently attempted to install. I downloaded paramiko's src and ran python setup install  ..which executes without error. However when I run paramiko's test.py i get an error.  I also get an error when I run python -c "import paramiko"
<corporate_cookie> ...this is on a Red Hat ES4 server running Python 2.5.1 and paramiko 1.7
<corporate_cookie> any ideas ?
<NfNitLoop> corporate_cookie: on what platform?  ..
<NfNitLoop> aah.
<NfNitLoop> do you have pycrypto installed?
<corporate_cookie> i do
<corporate_cookie> python -c "import Crypto"  yields no error
<NfNitLoop> what is the "problem" you get when you do python -c import paramiko?
<corporate_cookie> File "<string>", line 1, in <module>
<corporate_cookie>   File "/usr/local/lib/python2.5/site-packages/paramiko/__init__.py", line 69, in <module>
<corporate_cookie>     from transport import randpool, SecurityOptions, Transport
<corporate_cookie>   File "/usr/local/lib/python2.5/site-packages/paramiko/transport.py", line 36, in <module>
<corporate_cookie>     from paramiko.compress import ZlibCompressor, ZlibDecompressor
<corporate_cookie>   File "/usr/local/lib/python2.5/site-packages/paramiko/compress.py", line 23, in <module>
<corporate_cookie>     import zlib
<corporate_cookie> (pardon the mess)
<NfNitLoop> is that all of it?   The last lines would probably be the most relevant.
<dato> seems some line is missing
<corporate_cookie> pardon me ... the last line is
<corporate_cookie> ImportError: No module named zlib
<NfNitLoop> well, there ya go.
<corporate_cookie> which is also strange ..as zlib is up2date
<NfNitLoop> Oh.
<NfNitLoop> Yeah, that is strange.
<thatch> did you build python yourself since it's in /usr/local ?
<NfNitLoop> wait, the zlib rpm?   you probably want something like python-zlip.
<dato> corporate_cookie: the zlib module is provided by python itself
<NfNitLoop> Aaah.
<dato> corporate_cookie: so something's broken in your python instalation
<thatch> ...when you compile python with --with-zlib
<dato> thatch: good catch
<corporate_cookie> ah .. i did not compile python with the --with-zlib option
<corporate_cookie> thanks : )
<asabil> hi all
<asabil> how do you benchmark bzr ?
<Odd_Bloke> asabil: How do you mean?  You could use the 'time' command if you're running GNU/Linux...
<asabil> Odd_Bloke: I wanted to run the benchmarking test suite
<Odd_Bloke> asabil: OK, I'm not sure how to do that.
<Odd_Bloke> Sorry. :(
<asabil> bzr selftest --benchmark
<asabil> is it possible to run only the commit benchmarking ?
<Odd_Bloke> asabil: Try 'bzr selftest --benchmark commit'?
<Odd_Bloke> That's how you'd run only the commit tests...
<asabil> :D thanks
<asabil> I didn't see that
<james_w> siretart: hi. Are you around?
<siretart> james_w: yes. how you're doing?
<james_w> good thanks. How are you?
<siretart> fine, too! (well a bit tired from work, but anyway..) :)
<siretart> hmm.. bzr: ERROR: Repository KnitRepository('file://....') is not compatible with repository SvnRepository('svn+ssh://...')
<siretart> what repository would be compatible?
<james_w> siretart: may I /msg you, my question is not really on topic for this channel.
<siretart> sure!
<james_w> as for the error have you just updated bzr-svn to the .4 branch?
<siretart> I just upgraded bzr and bzr-svn, not the branch
<luks> siretart: `bzr upgrade --dirstate-with-subtree` on the local repo is probably what you need
<james_w> and probably bzr svn-upgrade as well, but this is a watershed change for the branch.
<james_w> though with-subtree is as well I think.
<siretart> hm. I see
<siretart> this means with the newer bzr-svn the dirstate-with-subtree repo format is mandatory?
<luks> yes, afaik
<james_w> yeah I believe so. I think jelmer added svn:externals support using subtrees, but I guess it is mandatory rather than as-needed.
<NfNitLoop> siretart: No, but if someone has created a repository with that dirstate, you have to use it to be compatible.
<NfNitLoop> Oh, yeah, it's mandatory with bzr-svn.
<asabil> can a bzr plugin add some option flags to an existing command ?
<beuno> asabil, sure it can
<luks> by overwriting the original command
<beuno> yeap, you can override the current one
<asabil> let's say I want to add --with-feature-x to the existing commit command
<asabil> is that possible ?
<beuno> asabil, yeap
<asabil> awesome
<beuno> you could probably check if that parameter exists, and run X function, and if it doesn't, run the original
<beuno> that's what we do on the xmloutput plugin
<ddaa> Is there a way to create BranchReference with bzrlib without opening it?
<ddaa> I mean, a branch reference on disk, not the object.
* beuno steps aside and lets the pro's answer this one  :D
<james_w> ddaa: I don't see such an object in bzrlib.
<ddaa> bzrlib.branch.BranchReferenceFormat
<ddaa> there's actually no BranchReference object, it's just a format
<ddaa> as I said, I do not care about the actual object, but about the filesystem data.
<james_w> ah, they should be easy to create.
<ddaa> my problem is that BranchReferenceFormat.initialize opens the created reference
<ddaa> and for the Launchpad test suite I need to create branch references that point to example.com...
<james_w> ah, ok. Sorry, I thought you just wanted to create a one-off reference with your editor.
<ddaa> I know how to do this :) I wrote the "bzr switch" command.
<james_w> I guess you will have to carry a subclass, or ask for a initialise_without_opening method.
<ddaa> right
<ddaa> I wanted to check first before filing a bug.
<james_w> well, I can't speak for the project, but the code offers no way to do so. I would go ahead and file it.
<ddaa> creating a subclass that overrides open() for this purpose is NOT going to pass the Launchpad code review :)
<ddaa> Thanks.
* ddaa heads off
<lifeless> ddaa: bzrdir.get_branch_reference?
<lifeless> ddaa: didn't we have this discussion already?
<asabil> is there any bookmarking system for bzr branches ?
<asabil> so that I can give names to the different pushing locations ?
<asabil> something like
<asabil> bzr push location://stable-branch ?
<james_w> asabil: no that's not available.
<asabil> ok thanks
<asabil> you suggest I implement that as a plugin ?
<james_w> It shouldn't be too hard to add. You could file a bug if there is not one already.
<james_w> a plugin would also be easy.
<asabil> ok :)
<james_w> I can give you some pointers if you would like.
<NfNitLoop> I'd love it if someone did that as a plug-in.
<asabil> yeah, that would definitely help
<lifeless> ddaa: meh, sorry, I see - you want to create a pointer to a non-existent reference.
<lifeless> ddaa: you could use a mock branch to do that
<lifeless> ddaa: subclass branch to give you a branch you can construct with a url that you can't normally open
<ddaa> I believe there was a specific test for which I needed to go through the whole stack, not use a mock.
<lifeless> you can use the mock to setup the test
<ddaa> but I cannot remember which right now and I am off work
<ddaa> uh
<lifeless> ofter that you will have a regular branch reference on disk and not be using your mock
<lifeless> so it will fail to open the reference if you try to open it
<lifeless> etc. but as you say, you're done for the day.
<ddaa> I cannot see how you can use a mock object to make BranchReferenceFormat create a reference that it cannot open...
<ddaa> especially because it does "real_bzrdir = bzrdir.BzrDir.open(location)"
<lifeless> hmm
<lifeless> I suggest, if you don't want to talk work after-hours, that you drop a mail to the list and we can have an async discussion on this
<ddaa> I'll look at the code again it might be that I do not need to create unopenable branch reference anymore
<ddaa> since I needed to create a proxy method for get_branch_reference anyway for testing.
<ddaa> Thank for making me question my assumptions :)
<lifeless> lol, np
<lifeless> abentley: ping
#bzr 2007-09-12
<luks> asabil, NfNitLoop: http://rafb.net/p/6eZRXW13.html :)
<james_w> luks: nice work.
<igc> morning all
<asabil> hmm, luks nice but maybe having it per branch can be more handy ?
<luks> well, I was just playing, it's nothing serious. per-branch bookmarks wouldn't be so easy as these global ones
<luks> http://rafb.net/p/H4YUxG13.html if you want more complete version
<asabil> that;s awesome already :)
<asabil> I was also wondering if there any way to attach some kind of metadata to a branch
<asabil> I was hacking on loggerhead a bit
<asabil> and what I did was to add a branch-info file inside each branch
<asabil> and that file contains variables like description = "branch descriptio"
<asabil> this is particularely useful for auto discovered branches
<asabil> is there any clean way to implement this feature ?
<abentley> asabil: I have implemented a VCS frontend that used per-branch aliases, and I found it had poor usability.
<abentley> Because you were never sure what aliases were set where.
<asabil> hmmm
<abentley> And which ones were global, versus local.
<asabil> I don't think that global aliases are useful
<Odd_Bloke> I think it would only work if they were either all global or all local...
<abentley> They're very useful.
<asabil> I agree Odd_Bloke
<asabil> then maybe the ablity to specify shorthands for servers ?
<abentley> Most of my work is done against two or three branches.  Having shorthands would be quite nice.
<asabil> then maybe the ability to say
<asabil> myserv/bzr/branch.x
<abentley> Well, just set it up so that you can append to the alias.
<asabil> where myserv is a shorthand
<abentley> So you can alias example.com/bzr to myserv, and just specify "myserv/branch.x"
<Odd_Bloke> I know that git have some sort of aliasing because I was reading a blog post about it.  No doubt that'll have disappeared into the depths of reddit by now.
<abentley> As for per-branch descriptions, I think it would be reasonable to stick them in branch.conf.  The branch nick is already there.
<Odd_Bloke> The example they used would have me specifying, for example, 'abentley' to point to your branch so if I want to pull your changes I literally type 'git pull abentley'.
<asabil> abentley: where is branch.conf ?
<abentley> Ow!
<abentley> asabil: in .bzr/branch/
<Odd_Bloke> I think that then pulls the changes to a local cache which you can then treat as a branch.
<asabil> ok thanks abentley :)
<Odd_Bloke> So I was thinking, if there were a smart-server or something running at the other end, it generates a merge-directive and sends you that.
<Odd_Bloke> But that was just an idea that flitted through my mind at some point.
<Odd_Bloke> Quite hard to form exactly what the use case for that would be, because I don't do any development that's distributed to that extent.
<abentley> The smart server can take a more direct approach than a merge directive.
<asabil> hmmm, I think it can be a very nice feature
<poolie__> hello
<lifeless> poolie: should I do debs of the rc2
<poolie> yes, please
<poolie> lifeless, so can we expect 0.90final to go into gutsy? how about rc2?
<lifeless> I need to do the request as per discussion with mdz
<lifeless> that I cc'd you on
<poolie> k
<lifeless> bzr-svn is now in debian
<lifeless> so I should have the request put up today
<lifeless> abentley: I presume bzrtools 0.91 is imminent ?
<lifeless> jelmer: bzr-gtk 0.91 coming soon
<abentley> Yeah, I'll get that out soon.
<lifeless> abentley: with nested trees, does the parent entry file id need to match the subtree root id ?
<abentley> Yes, that's the current design.
<lifeless> interestingly that isn't enforced by commit
<lifeless> ok, bug fixed in fetch for subtrees.
<lifeless> poolie: bzr.dev still has all the 0.91 changes in its in development section
<lifeless> poolie: this seems wrong ?
<poolie> i
<poolie> i haven't committed a change to bump the version
<poolie> should do that now
<poolie> lifeless, i see gutsy claims to have 0.90 already
<poolie> or at least '0.90-1'
<lifeless> I thought the version bump commit was in the release process?
<lifeless> yes, 0.90 has reached gutsy
<poolie> it is, i haven't finished the process though
<lifeless> I think mdz has got someone to do the sync I asked for anyhow
<poolie> my point is, that seems to be the wrong version number, should it not be 0.90rc1?
<lifeless> no
<lifeless> 0.90 got released remember
<lifeless> you're working on 0.91
<poolie> oh right
<poolie> just coincidental
<lifeless> if you count a missing digit :)
<jelmer> lifeless: Will do so by the end of the week
<lifeless> jelmer: I can't really upload debs of the 0.91 rc's without fixed plugins
<jelmer> lifeless: I'm considering stopping doing synchronized releases
<jelmer> lifeless: I'm a bit busy at the moment, can't really put the effort into testing bzr-gtk at the moment
<lifeless> jelmer: perhaps you could share the responsibility
<jelmer> lifeless: I've been trying to get Szilvester to do a release for the last couple of releases :-)
<jelmer> lifeless: If you feel like doing it, you're more than welcome
<jelmer> lifeless: btw, thanks for uploading 0.4.2
<lifeless> well
<lifeless> is there any reason not to just say 'its released' ?
<jelmer> The only two things in it I've used since I did the previous release are viz and gcommit
<jelmer> but there has been a lot going on, merged by other people
<jelmer> so I don't really feel comfortable releasing it without testing, especially since there are so little unit tests.
<jelmer> another option would be to simply upload a copy of bzr-gtk 0.90 but mark it as being compatible with 0.91
<jelmer> because none of the important API's have changed
<abentley> jelmer: You're not concerned about Branch.last_revision / WorkingTree.last_revision?
<jelmer> abentley: ah, I wasn't aware of that..
<lifeless> abentley: whats happened to those apis ?
<abentley> They now return NULL_REVISION instead of None
<lifeless> ah right
<lifeless> poolie: that bug I found last night? I've done a regression test for it and mailed to the list right now
<lifeless> I think this is critical enough for 0.91
<poolie> thx
<lifeless> jelmer: I think you should ask for help on the list
<lifeless> jelmer: you maintain two plugins that are version locked that I know of
<jelmer> lifeless: bzr-svn isn't version locked - it contains a list of versions it knows it is compatible with and will warn if it sees an unknown version but will still work
<lifeless> jelmer: and its bad for bzr to have mismatches during release; there is a week of freeze for plugin authors to know there are no changes incoming that will bust api's
<lifeless> jelmer: warning confuses and infuriates users
<jelmer> lifeless: there have been too many api changes to not have those warnings in
<jelmer> lifeless: for bzr-gtk I can see a point in not having the warnings - that's why I was suggesting desynchronizing the releases
<lifeless> jelmer: well, the warnings are not useful when a user is using the plugin and no newer release has happened
<lifeless> I'd argue that they *are* useful when a user experiences a bug
<lifeless> and reporting plugin versions in bzr's error output supercedes that warning IMO, because you, the author, will be able to tell
<jelmer> lifeless: so far, bzr has broken bzr-svn every release
<lifeless> ok
<lifeless> well, its your domain
<jelmer> I'm also confident enough to do a bzr-svn release, as I'm the sole maintainer of the main branch and it's very well tested
<jelmer> bzr-gtk has almost no tests, several different people committing to mainline, no review, out-of-date NEWS...
<jelmer> so doing a release for it is more work
<lifeless> can you change your process
<lifeless> for instance, set policy like bzr does for NEWS
<lifeless> require review like bzr does - perhaps ask Aaron to setup a prefix like [bzr-gtk/MERGE]  for a different bundle buggy instance?
<abentley> lifeless: I'd agree with Jelmer; before plugin authors will remove the warnings, they need to trust Bazaar not to break the API.
<igc> lifeless: review sent to the list on 'knit text add reductions'
<igc> lifeless: I'll send through some more feedback on http://bundlebuggy.aaronbentley.com/request/%3C1189034650.27751.10.camel@lifeless-64%3E as well - I'd really like to see this one land soon
<lifeless> which is that
<igc> the 'move stuff into CommitBuilder' one
<igc> (0.92 targetted)
<lifeless> right
<lifeless> that needs an update
<lifeless> massive bugs that I fixed last night
<igc> :-)
<igc> I saw the changes in your commit branch
<jelmer> lifeless: we did talk about bundle buggy at some point, but never got around to it. I agree it would be a good idea to use it for bzr-gtk.
<igc> lifeless: with path_content_summary, why did you not make file-id a parameter?
<lifeless> igc: because it has no use for one
<abentley> jelmer: I'd be happy to chat about BB at some point.
<lifeless> its unneeded overhead to pass one in
<igc> won't same trees benefit from it??
<igc> s/same/some/
<lifeless> 'some' trees?
<lifeless> if you are doing a commit from a tree that has no path orientated data structure - e.g. committing from something like a revision tree.
<lifeless> but yagni
<lifeless> working trees have disk
<jroes> hey guys, anyone else think the sftp example at http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html is a bit misleading?  on a default setup, you need to specify the absolute path to the dir you want to push your revisions to (I doubt most user accounts have write access to /)
<lifeless> memory trees have a transport with path data
<jelmer> abentley: Szilveszter and have been talking about setting up a separate copy of it somewhere, but if it's possible to have one up on the main site, that'd be awesome
<jdub> yo folks
<jelmer> hi jdub
<igc> I was thinking about workingtree4 where lookup by id would save a path -> id conversion from the little I know of that code
<jdub> lovely to see bzr so versionly close to 1.0 8)
<lifeless> igc: the api does not use id at all
<lifeless> igc: so why would it do a path->id conversion at all ?
<abentley> Jelmer: in theory, I'd be happy to.  But I'm a bit worried about performance on that machine.
<jdub> have an svn-upgrade issue to ask about...
<jdub> $ bzr svn-upgrade
<jdub> Using saved location: http://svn.automattic.com/wordpress-mu/trunk
<jdub> bzr: ERROR: Unable to import bzr-rebase (required for svn-upgrade support): No module named rebase.rebase
<jdub> 
<igc> lifeless: path_content_summary() in workingtree_4.py has an implementation for DirStateRevisionTree but not WorkingTree4. Just thinking out loud about a potential implementation ...
<lifeless> igc: I really don't understand what you are thinking about
<jelmer> abentley: ah, ok
<lifeless> igc: what fileid keyed data are you thinking it would want?
<jelmer> jdub: Do you have trunk of bzr-rebase installed as ~/.bazaar/plugins/rebase ?
<igc> sha1. I really need to know that code better. I plan to look at it today so I can ask more intelligent questions.
<lifeless> igc: sha1 is keyed by path
<jdub> jelmer: no plugins installed -- bummer
<igc> ok - that's good to know
<lifeless> igc: if there are multiple fileids at a given path, only one of them will be present in tree 0 - the working tree
<lifeless> so thats the one to use
<jelmer> jdub: trunk of bzr-rebase is at http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/
<jelmer> though if you have no local changes, it's probably faster to just 'bzr branch' from scratch rather than svn-upgrade
<lifeless> jelmer: aptitude install bzr-rebase
<jdub> jelmer: so the new bzr-svn breaks svn but bzr doesn't include the bits to fix it yet? :-)
<lifeless> jdub: its in a separate plugin, which bzr-svn recommends
<jdub> lifeless: hrm, not available to me yet
<lifeless> hmm, whoever synced bzr-svn missed the new recommends
<lifeless> jelmer: *why* doesn't it depend on bzr-rebase?
<elmo> in 10 minutes escudero.canonical.com, the machine hosting www.bazaar-vcs.org, will be shut down for some necessary maintenance, ETD is 5 minutes
<jelmer> lifeless: it's only needed for svn-upgrade
<lifeless> thanks elmo
<lifeless> jelmer: all the same
<lifeless> :)
<pygi> lifeless, sync pickups entire package, so nobody *missed* it, the debian maintainer did it
<pygi> or am I missing something? :)
<jdub> i guess if you don't forsee svn-upgrade being used regularly, you'd only need bzr-rebase on these odd occasions
<jelmer> lifeless: svn-upgrade is only necessary for those upgrading from bzr-svn 0.3
<lifeless> pygi: I think you are missing several emails, irc discussion and the debian maintainer has done nothing wrong
<lifeless> jelmer: I see this as a purity vs do-the-right-thing situation
<igc> lifeless: more feedback on the 'knit text' stuff - 32 unit tests are failing because of parameter count mismatches. Do you want a pastebin or email?
<jdub> but with the break in this upgrade, having all the tools available would make users less surprised
<lifeless> igc: its all fixed here
<lifeless> igc: like I said, massive fixes needed
<igc> cool
<lifeless> jdub: I'm with you
<jdub> btw, the message i get from bzr merge wouldn't hint me towards svn-upgrade
<igc> lifeless: just to be clear, I'm talking about the patch I reviewed this morning (random_id etc.), not the other one
<lifeless> revno: 2810
<lifeless> committer: Robert Collins <robertc@robertcollins.net>
<lifeless> branch nick: knits
<lifeless> timestamp: Tue 2007-09-11 14:05:11 +1000
<lifeless> message:
<lifeless>   Unbreak weaves.
<lifeless> poolie: you know you could have just changed the product rather than marking invalid and filing a new task
<lifeless> FWIW
<abentley> lifeless: That's a humdinger of a bug you found with fileids_altered_by
<lifeless> abentley: yah
<lifeless> abentley: totally by accident too
<abentley> Such an ugly hack, that code.  I'm surprised we haven't found more bugs.
<elmo> (escudero / www.bazaar-vcs.org is back)
<lifeless> abentley: well its reasonably well tested; the glitch here was no direct testing of nested tree fetching
<poolie> lifeless, i din't realize it was possible to change the product of a task
<lifeless> oh
<jelmer> lifeless: well, it's a bit more hackish than that... bzr-rebase 0.2 isn't out yet.
<lifeless> so click on the thing to expand it
<poolie> ah, i think i saw the greyed out text as "you can't change this"
<lifeless> and there is a field
<lifeless> you can edit it
<jdub> lifeless: whoa, that crazy stuff still afflicts launchpad?
<jelmer> lifeless: which I admit is ugly
<lifeless> jelmer: seems difficult for users:)
<jelmer> lifeless: trunk works fine for bzr-svn, but has two bugs that block it from being uploaded as an official bzr-rebase release.
<abentley> poolie: someone mailed me saying they want to put bzrlib/patches.py into the standard library.  I wrote all but 14 lines, but Canonical has joint copyright.  Are you in favour of relicensing it in principle?
<jdub> elmo: what's the appropriate way to request ubuntu.com alias changes?
<lifeless> jelmer: still difficult for users to have to choose between 'working bzr-rebase' and 'working bzr svn-upgrade'
<jamesh> jelmer: ran into a crasher bug with bzr-svn.  I've filed a bug with all the information I have, but I'd be happy to provide more on request
<jamesh> "svn_path_basename: Assertion `is_canonical(path, len)' failed." then a segfault
<elmo> jdub: outside of the LP-automagic ones?  rt@ubuntu.com
<elmo> jdub: (as in, send a mail to that address)
<jdub> yeah
<jelmer> jamesh: where did you file it? The latest bug report from you I have here is from 25 october last year
<jamesh> jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/139020
<Ubotu> Launchpad bug 139020 in bzr-svn "assertion error segfault when branching from svn+http://svn.effbot.python-hosting.com" [Undecided,New] 
<jdub> elmo: i think my jeff.waugh is not LP-automagic (how do they work?)
<elmo> jdub: -> privmsg
<jamesh> jelmer: the email will probably go out in 5 minutes (LP waits a little to batch changes)
<jdub> sorry :0
<jdub> :)
<jelmer> jamesh: ah, 3 minutes ago.. that explains it :-)
<elmo> it's okay, we're just off topic
<poolie> abentley, i don't see any problem with that
<jamesh> jelmer: I managed to pull out a Python stack trace from the segfault if that helps ...
<jelmer> jamesh: seems I can reproduce it here
<jamesh> might just be a weird SVN server
<abentley> poolie:Okay, I'll mail you something more formal if/when we get there.
<jamesh> although (assertion errors seem unexpected)
<jelmer> lifeless: yes, that's true
<jelmer> jamesh: the subversion library asserts on invalid paths
<abentley> jdub: Oh, hi Jeff.
<jdub> hey abentley
<abentley> Next time you're in Toronto, give a shout.
<jdub> !
<jdub> i'm in toronto atm!
<abentley> Dude!
<jdub> <- asshat.
<jdub> i am in sydney
<jdub> which looks a little bit like toronto
<jdub> it is very sprawly
<jamesh> concrete fences around the CBD?
<abentley> PyGTA showed me pics of your visit.
<jdub> but our security is VERY NICE! HIGH FIVE!
<lifeless> jelmer: bzr-rebase isn't in debian even is it ?
<jdub> jamesh: bah!
<jdub> pygta?
<lifeless> I think the concrete fence was entirely appropriate; it is an island of convicts after all
<abentley> Yeah, Sydney wasn't to hard to get my head around.
<lifeless> igc: new patch version, want to confirm you're happy with what I did?
<jelmer> lifeless: 0.1 is in debian
<lifeless> jelmer: hmm, madison isn't showing it. whats the source package name?
<jamesh> you don't want all the world leaders escaping and overstaying their visas too
<jelmer> lifeless: bzr-rebase
<jamesh> better to keep them locked up
<abentley> http://linuxcaffe.ca/node?page=3
<lifeless> hmm, madison crackness
<jelmer> lifeless: it's both in sid and lenny
<igc> lifeless: sure, I'll look now
<igc> thanks for the fast turnaround
<abentley> jdub: PyGTA meet at linuxcaffe.
<jdub> oh, that was ages ago, after i spoke in toronto on the badgerbadgerbadger tour
<jdub> it was just random
<abentley> Hehe.
<lifeless> poolie: is there anything in bzr.dev yet that shouldn't be in 0.91 ?
<poolie> i have not merged anything like that yet
* poolie looks
<poolie> no, there is nothing that can't merge to 0.91
<lifeless> ok
<lifeless> I'll merge my branch trivially then
<poolie> i was going to merge the version bump, but will hold off
<poolie> ok
<jelmer> jamesh: fixed in trunk.
<jelmer> thanks for the bugreport :-)
<lifeless> igc: I think 'saving data locally' might be better as 'Finalizing commit' or something
<igc> lifeless: sounds better to me
<jamesh> jelmer: thanks.
<poolie> lifeless, let me know when you're done and i'll open things for 0.92
<lifeless> they are both in pqm now
<lifeless> back shortly
<lifeless> poolie: lol you and your committed pdb lines :)
<jelmer> lifeless: so, what should we do with bzr-gtk 0.91 ? when are you going to upload the .debs?
<poolie> :)
<poolie> i need a precommit hook maybe
<poolie> specifically what happened though is that  i started from an unclean tree and should have checked that
<jelmer> lifeless: s/going to/would you like to/ :-)
* ..[topic/#bzr:poolie] : The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 and 0.91rc2 are out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d
* beuno wonders if 0.92 will have packs in it
<poolie> they should be in as an experimental format
<NfNitLoop> Mmmm.
<beuno> great, I'll be experimenting with them then
<lifeless> jelmer: if poolie is going to do an rc3 I'll wait for that, otherwise I'll start on them in a couple hours
<beuno> I keep hearing good things about it
<poolie> i'm going to just use the break command rather than set_trace() for a while :)
<poolie> lifeless, wait for rc3 to make debs?
<poolie> when should we do rc3? today? tomorrow?
<jelmer> lifeless: it's ok to wait until the weekend with bzr-gtk 0.91 though?
<jelmer> lifeless: otherwise, feel free to take a snapshot and call that 0.91~rc1 or something..
<lifeless> jelmer: well as soon as I upload debs to bazaar-vcs.org, the other plugins will break
<lifeless> thats my concern
<lifeless> bzrtools is good now, as abentley has done a release
<lifeless> poolie: so, my fetch fix - do you want to do an rc3 with that immediately, or wait a bit., If you are waiting I'll do debs of rc2, otherwise I'll do the debs after you do rc3
<jelmer> lifeless: I'll do bzr-svn 0.4.3 tomorrow, release is already tagged just not packed and uploaded yet
<jelmer> have fun
<jelmer> g'night
<Vantage13> anyone have any tips/guides on importing in a large cvs repo into bzr?
<poolie> Vantage13, is it an open source tree?
<Vantage13> poolie:  nope...
<poolie> Vantage13, http://bazaar-vcs.org/BzrMigration?highlight=%28import%29#head-4b8472ce65e228eb1e87383ff908129305df9dee
<poolie> cvsps-import is probably a good way to go
<Vantage13> poolie: thanks.  I'll give it a shot
<poolie> please let us know if you have any problems/questions, or if it works well
<lifeless> poolie: my patch causes an error in a different test
<lifeless> just debugging now
<poolie> k
<jroes> anyone ever accidentally try bzr pushing to sftp://blah.net/blah/blah without a username@?  bzr (or maybe it's the paramiko dependency) crashes pretty hard on win32
<lifeless> I don't use win32, but we do that all the time without a username
<lifeless> by crash do you mean you get a backtrace
<jroes> yup
<jroes> I get a python bt that is
<lifeless> could you file a bug then?
<jroes> sure, looking for the bug tracker now
<lifeless> launchpad.net/bzr
* igc food
<jroes> doesn't look like an already existing one, surprisingly
<jroes> I hope it's repro-able
<lifeless> poolie: the test fails cause of another bug AFAICT
<lifeless> abentle1: are you still up ?
<abentle1> lifeless: yeah
<lifeless> with nested trees
<lifeless> should we have a knit TREE_ROOT ?
<abentle1> A knit *for* TREE_ROOT?
<lifeless> yes
<lifeless> fileids_altered_by_revisions()
<abentle1> We do have one
<lifeless> returns {'TREE_ROOT':['ghost'] }
<lifeless> in the test test_fetch_all_fixes_up_ghost
<lifeless> when the source and target repo's are both KnitRepository3
<lifeless> but there is no such source weave in the test case
<lifeless> I'm not sure if the test is invalid
<abentle1> That's strange.
<lifeless> if you apply my patch to fix the regex, then run ./bzr selftest test_fetch_all_fixes_up_ghost
<lifeless> you'll see the failure
<abentle1> The only case would be if there were no revisions to store.
<abentle1> I'm sorry, but I'm not feeling so hot tonight.
<lifeless> :(. Get well soon
<abentle1> Tx.
<abentle1> It's toothache.  Very distracting.
<lifeless> its a test that sets up a manual repo
<lifeless> rather than using commit builder
<abentle1> Ooooh.
<abentle1> Then it sounds quite likely it's setting up an invalid knit3 repo.
<lifeless> yes
<lifeless> thats my conclusion, I'm upgrading it to commit builder
<jroes> oh, now launchpad is cool.  I was able to say "this also applies to paramiko" :)
<poolie> lifeless, btw is configmanager in launchpad?
<poolie> i couldn't find it the other week
<lifeless> uhm don't think so
<poolie> k
<NamNguyen> hi, the http smart server guide says "this feature is EXPERIMENTAL and is NOT SECURE. It will allow access to arbitrary files on your server." i wonder how is that done?
<nxsryan> hello
<lifeless> NamNguyen: I think that is outdated, spiv can comment more
<lifeless> nxsryan: hi
<nxsryan> i installed the plugin to send emails on commit -- i want this to happen anytime anyone commits. but where do i put the conf variables, then?
<NamNguyen> nxsryan: in ~/.bzr/locations.conf
<lifeless> nxsryan: bzr help email has documentation about this
<nxsryan> lifeless: i looked at that
<lifeless> nxsryan: you can put them in ~/.bazaar/bazaar.conf
<lifeless> or ~/.bazaar/locations.conf
<nxsryan> lifeless: i know that, i'm trying to figure out how to configure it so it happens for every user
<nxsryan> lifeless: system-wide
<lifeless> the configuring-bazaar document has more details on the configuration system
<poolie> i just pinged spiv, he should be on in a bit
<lifeless> nxsryan: bzr does not have a system wide configuration system at the moment, only per-branch, per user and per-user-location
<nxsryan> hm :/
<poolie> it'd be reasonable to read something like /etc/bazaar/bazaar.conf i guess
<NamNguyen> hello spiv, is the http smart server still prone to security problems?
<poolie> there does seem some potential for unwanted disclosure if email is turned on globally
<lifeless> poolie: one can always disable it per user
<poolie> if people are also keeping personal files say
<nxsryan> poolie: definitely it'd be better to have the option and decide not to use it!
<spiv> NamNguyen: I don't think so, but I haven't thought closely about it recently.  I think with the ChrootTransport it should be fairly trustworthy.
<fullermd> Well, that calls for /etc/bazaar/locations.conf (rather, /usr/local/etc/bazaar/ for some of us) too...
<NamNguyen> spiv: the docs @ http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/http_smart_server.html says abitrary files might be read, i wonder how it is done? at the HTTP layer or at the bzr layer?
<spiv> NamNguyen: I should re-read the documentation and update it.
<nxsryan> blah. this plugin uses a weird switch to mail -> "mail: illegal option -- a"
<NamNguyen> it could have used smtplib
<Ubotu> New bug: #139031 in paramiko "bzr push via sftp without username crashes on win32" [Undecided,New]  https://launchpad.net/bugs/139031
<abentle1> NamNguyen: We actually have some nicer stuff on top of smtplib also.
<NamNguyen> abentle1: does it support utf-8 on SMTP headers and message body?
<NamNguyen> i noticed your BB does support utf-8 in the message body
<nxsryan> so. does anyone know a different plug-in to mail about commits?
<nxsryan> this one doesnt work on freebsd
<lifeless> NamNguyen: smtplib requies *much* more configuration
<lifeless> NamNguyen: 'mail' is a fine interface for fire and forget mailing
<lifeless> nxsryan: it can be configured to work on bsd
<NamNguyen> lifeless: agree
<lifeless> nxsryan: How emails are sent is determined by the value of the configuration option
<lifeless> 'post_commit_mailer':
<lifeless> nxsryan: look for that in bzr help email, and read down
<lifeless> nxsryan: you can either use a wrapper to your real mail, or smtplib as per the documentation
<nxsryan> lifeless: ok, thanks
<lifeless> poolie: submitting with a fairly trivial fix ok  ?
<abentle1> NamNguyen: the higher-level code supports utf-8.  See email_message.py
<abentle1> lifeless: I do wonder whether we should support calling mail/sendmail from bzrlib.smtp_connection or similar.
<lifeless> possibly; I haven't looked at that code et
<lifeless> *yet*
<lifeless> food time
<poolie> lifeless, i guess
<lifeless> poolie: it was only test code that was problematic
<lifeless> igc: ok, take #45 -> list now
<igc> lifeless: what's #45?
<igc> latest patch?
<igc> got it
<lifeless> poolie: ok, bzr.dev has my fix now, so you can do the 0.92 openening shuffle
<lifeless> igc: I've pushed the latest commit branch code, which was passing all tests for me
<igc> great! I'll grab it now
<lifeless> I'm also pushing the repository branch
<igc> please - that's the one I want ( http://people.ubuntu.com/~robertc/baz2.0/repository/)
<lifeless> its pushed
<lifeless> hmm, dunno if thats entirely fixed yet.
<lifeless> probably just a merge awawy
<igc> 2759 is the last revno I have on that branch and it claims nothing to pull
<lifeless> thats probably why it was so quick to push
<igc> :-)
<lifeless> pushing 2760 now
<lifeless> haven't tested, but it should be good
<igc> np - I'll test :-)
<lifeless> puthed
<beuno> Verterok, :D
<Verterok> hiya
<beuno> Verterok, I'm going real quick to walk the dog, but I solved the problem yesterday and pushed it to my branch
<beuno> the missing function should be completely implemented
<Verterok> beuno: great!
<Verterok> beuno: so, can be merge it in trunk?
<beuno> Verterok, take a look and see if it's in shape to merge with the trunk, and I'll move on to the next feature
<beuno> :D
<beuno> that would be your call
<beuno> brb
<Verterok> :D ok I 'll take look to it
<igc> lifeless: +1 with those changes - voted on BB accordingly. Thanks
<beuno> back
<Verterok> beuno: hi there!
<beuno> Verterok, so?  the code could be cleaner, but for a first try, I'm pretty happy with it
<lifeless> yay
<lifeless> another 2 seconds off
<Verterok> yes, it works as advertised :)
<Verterok> beuno: I'm getting <log> </logs> tags at the end of the xml (maybe a copy&paste bug?)
<beuno> Verterok, even when no logs are present?  (it probably is a copypasta error)
<Verterok> beuno: should I expect <logs> and <log> tags in the xml?
<beuno> Verterok, only if it shows you revisions
<beuno> Verterok, could you copy and paste the output somewhere?
<Verterok> sure
<Verterok> beuno: http://rafb.net/p/cUlESQ51.html
<beuno> Verterok, that would be wrong
<beuno> let me fix that real quick
<Verterok> beuno: maybe you can alse merge your branch with the last changes in trunk ?
<beuno> Verterok, sure, seems reasonable
<beuno> Verterok, the problem comes from the "workaround", why does it print out the closing tags, but no the opening one right above it?
<Verterok> beuno: ups? :D
<beuno> Verterok, I'm sure it's as much my fault as it's yours
<Verterok> beuno: ahh, you have the previous version of __init__.py (in the current the workaround, actually "work around" it )
<beuno> I'm just trying to understand *why* it doesn't print out the opening tag when it's specified right above the other ones
<beuno> Verterok, aaaah, so I should merge first, then complain  :D
<Verterok> the openeing tags are printed from inside XMLLogFomatter
<beuno> let me merge and take a look
<lifeless> igc: I see 7 seconds in 'saving data locally'
<lifeless> 3% in index serialisation
<lifeless> 85% in _update_builder_with_changes
<igc> yup
<igc> I'm seeing 3% in set_parent_trees
<igc> 3.6% in add_inventory of which 2.8% is serialise_inventory
<igc> (those figures from yesterday's branch of yours and today's total time is the same)
<lifeless> I would expect that
<Verterok> beuno: I known it's ugly, but is the only way I can close the </logs> tag, and the last </log>, because when XmlLogFomatter do log_revision(...) it doesn't know if is the last one (or how much left to print, XmlLogFomatter recieves one revision at a time)
<lifeless> if yo uapply my most recent commit branch patch from the commits list you should see a further 1% drop
<beuno> Verterok, yeap, the newer version makes it easier, applying the new format now, should be fixed in a sec  :D
<Verterok> cool
<beuno> Verterok, merged, fixed and pushing as we speak
* Verterok waiting before pull & merge
<Verterok> beuno: it's a worksforme(tm), merging..and pushing to trunk
<beuno> Verterok, yay!  one thing less to implement  :D
<Verterok> beuno: I wonder what you do think about enclosing all missing xml output in a root tag, I'm not an xml expert.
<beuno> Verterok, I was hoping you where, I wasn't sure what approach to take either
<Verterok> jeje
<beuno> either seems fine to me, parsing it is almost the same, I just don't know what the cleanest method would be
<Verterok> I presume (need to check it) that a well-formed xml should have a root tag, but I'm not 100% sure
<Verterok> yes, the parsing don't change
<beuno> Verterok, so you want me to enclose all the information as childs of a missing-specific tag?
<Verterok> I'm not sure, let me check with the XML spec
<Verterok> beuno: any problem to add a root element? :P look (2) in: http://www.w3.org/TR/REC-xml/#sec-well-formed
<beuno> Verterok, none at all, I'll add'n'push
<Verterok> beuno: great, thanks!
<Verterok> beuno: I'm tempted to write a DTD/XSD, do you think is  usefull in any way to you/others that use the plugin?
<beuno> Verterok, I'm sure having a DTD would be useful on many cases, just not mine specifically
<Verterok> ok
<beuno> but it does seem like a must-have at some point
<beuno> so go with what you feel like doing  :D
<Verterok> I'll try to write it when I have some spare time or if a user need/request it :D
<beuno> that's the spirit, hehehe
<beuno> Verterok, where you looking for something like this?   http://rafb.net/p/Q2kh9R50.html
<Verterok> beuno: yes, the root tag, if you want it to be <missing> o something else, that's your call :)
<beuno> Verterok, then it's done, let me just fix a bug I introduced and I'll push again
<Verterok> ok
<beuno> I might change the tag's name to <beuno> (?)
<Verterok> sure :D
<beuno> heheh, not yet, I'm saving that one for when it's part of bzr directly  :p
<Verterok> jaja
<beuno> argh, the missing code is terribly hard to work with, I'll try and refactor it later on if some bzr dev has the time to help me a bit
<Verterok> I encounter similar problems working with the other comands (as is shown in my copy&paste form bzrlib :P )
* beuno eyeballs lifeless and poolie_
<mkanat> bzr co bzr://bzr.everythingsolved.com/vci/trunk
<mkanat> bzr: ERROR: Tags not supported by BzrBranch5('file:///home/mkanat/unzip/trunk/'); you may be able to use bzr upgrade --dirstate-tags
<mkanat> And both server and client are 0.18.
<mkanat> Is that fixed in 0.90?
<mkanat> It works fine over SFTP, but not over bzr:// or bzr+ssh://
<fullermd> Not fixed on 0.90.  Not _fixed_ in 0.91 either, just sorta OBE.
<poolie_> mkanat, it should be ok in 0.91rc
<mkanat> poolie_, fullermd: Okay. :-)
<mkanat> fullermd: OBE?
<fullermd> Overtaken By Events.  0.91 still doesn't properly inherit the format of the parent branch, but the default is now dirstate-tags, so...
<mkanat> fullermd: Ah, okay.
<beuno> Verterok, pushed
<mkanat> Is bzr log -v ever going to be fast, or should I just rely on it never being fast?
<Verterok> beuno: ok, merging & pushing. then directly to bed
<mkanat> It's a matter of an architecture decision for the VCI driver for Bzr.
<mkanat> Because "bzr log" is super-fast.
<beuno> Verterok, sounds like a plan, I would love to follow as soon as I finish moving this 6gb mess-of-a-website from one server to the other
<Verterok> uh, good luck with that!
<Verterok> seeya!
<beuno> Verterok, thanks, sleep well
<Verterok> thanks
<Verterok> bye
* beuno wonders why he was deactivated in the bzr team in LP
<lifeless> beuno: you were?
<lifeless>  whats your lp name?
<beuno> lifeless, beuno
<beuno> I hadn't noticed until now
<beuno> not that it's important, just curious  :D
<lifeless> real    1m41.819s
<lifeless> user    1m33.066s
<lifeless> sys     0m4.940s
<fullermd> They found out you were writing XML stuff.  The stigma will follow you forever.
<lifeless> another 4 seconds nuked
<fullermd> So you're just killing time?   :p
<beuno> fullermd, hahaha, I knew I shouldn't of gone down that path...   it's just so tempting to write xml...   :/
<lifeless> fullermd: bleh
* fullermd takes a bow.
<lifeless> igc: another 4 second improvement pushed to my repository branch
<lifeless> and I'm done for the day.
<igc> great ...
<igc> just fyi ...
<igc> my reporting changes are a slight win still for your stuff
<igc> but the iter_changes stuff is not
<igc> I'll grab your stuff now
<igc> lifeless: does the latest stuff fix selftest or just performance improvements?
<igc> that's just in a nice way :-)
<lifeless> its just faster
<jdub> poolie_: around?
<poolie_> jdub, hi
<jdub> poolie: got a moment for a phone call?
<jdub> poolie: bzr related, but not support ;-)
* igc food
<jolex> hi. is it possible to replace an earlier commit if this is not the last in the branch and I would like to preserve newer commits?
<Peng> No.
<johnf> Can anyone point out anything that would be missing from my patch in https://bugs.launchpad.net/bzr/+bug/128456 that would help me get someone to apply it :) Its a trvial patch to enable bzr+https
<Ubotu> Launchpad bug 128456 in bzr "bzr+https is not a supported protocol" [Low,Triaged] 
<jolex> peng: what about cherry picking with commit history?
<jolex> i'm planning to use bazaar in the following working model: two parallell branches (production and working). production contains only public releases (common source code base for projectmembers). working is my "private" branch where I keep track of all my changes. my changes in working is applied to the common source code. when all the project members changes has been added and the common source is released I can again commit this to my production branch. and I w
<jolex> ant to merge this (my own changes plus other members' changes) into my working branch. Is there anyone with experience from a similar usage of bazaar?
<dato> jelmer: do you know why doing bzr pull with 0.92.dev would raise a 'Version mismatch' exception coming from bzr-svn in some branches, and not in some others?
<jelmer> dato: bzr-svn only warns when it's invoked
<dato> I wonder why it's being invoked for a branch of bzrtools, then.
<jelmer> bzr first tries to find a .bzr directory, if that isn't found it will try other formats
<dato> so I can't understand what's happening with this bzrtools branch.
<dato> ah
<dato> updating bzr-svn seems to help
<dato> well
<dato> obviously, d'oh
<jdong> schplee! I just tried pushing th LP over bzr+ssh for fun, and to my surprise it worked.
<jdong> when has this been the case?
<Peng> Ack.
<Peng> I was just thinking of responding to jolex.
<dato> jelmer: ok, seems like for all branches in shared repos the svn format will be tried on them, dunno if that's a bug or not
<jelmer> dato: doing what exactly?
<Ubotu> New bug: #139109 in bzr "No API to create a branch reference without opening it" [Undecided,New]  https://launchpad.net/bugs/139109
<dato> jelmer: bzr pull
<Lo-lan-do> Hi all
<Lo-lan-do> (Uh-oh, says jelmer)
<Lo-lan-do> Thanks for bzr-svn 0.4.2 in Sid, but...
<Lo-lan-do> http://paste.debian.net/36917
<brmassa> guys, using olive (bzr-gtk) on Kubuntu, everytime i push my branch to launchpad it breaks (i think its because ssh). Does it happen on Ubuntu?
<luisbg> how do I revert to an old version? I'm in 96 and want to go back to 90
<luisbg> I meant revision not version
<dato> luisbg: bzr revert -r 90
<luisbg> dato, thanks a lot =)
<luisbg> couldn't find it in the bzr man
<james_w> Lo-lan-do: is that the first commit in the branch?
<Lo-lan-do> james_w: No.
<Lo-lan-do> (Sorry, was away for dinner)
<corporate_cookie> is there a rpm version of BZR for RHEL4 ?
<Lo-lan-do> I tried re-pushing, but then I get another assertion error: http://paste.debian.net/36935
<jelmer> re
<jelmer> Lo-lan-do: is the gforge svn repository publicly accessible?
<Lo-lan-do> jelmer: Not anonymously :-(
<Lo-lan-do> But if you care to register on gforge.org, you should at least get read access.
<Lo-lan-do> (Unless Tim Perdue is growing more and more paranoid)
<jelmer> ok, just registered
<lifeless> hi
<Ubotu> New bug: #139202 in bzr ""Could not acquire lock" error doesn't tell you how to fix it" [Undecided,New]  https://launchpad.net/bugs/139202
<jelmer> 'morning lifeless
<lifeless> so, how many seconds can I save today.
<jelmer> Lo-lan-do: ok, trying to pull now..
<Lo-lan-do> jelmer: The initial "bzr get" takes me about three hours on my DSL link.
<jelmer> the repository doesn't seem to be very fast, indeed :-(
<Lo-lan-do> If you need an initial branch, I have a mirror on alioth
<Lo-lan-do> (Looking for the public URL)
<Lo-lan-do> http://alioth.debian.org/~lolando/bzr/gforge/upstream-svn/trunk/
<jelmer> lifeless: I'm looking forward to the packs stuff landing!
<jelmer> Lo-lan-do: thanks
<Lo-lan-do> It's not quite up-to-date (since I'm not eager to publish stuff there that's not really in SVN), but you'll only miss a handful of versions.
<Lo-lan-do> What I'm trying to push to SVN is basically a merge into that branch of http://alioth.debian.org/~lolando/bzr/gforge/debian/sid/
<lifeless> jelmer: dogfoodink yet ?
<NfNitLoop> so, what are packs?   Just a way to compress your repository?
<NfNitLoop> Didn't see anything about it on the wiki, but I suppose that's because it's still being implemented. :)
<jelmer> lifeless: not yet, though I plan on trying it out on my Samba branches
<jelmer> lifeless: I'll migrate bzr-svn as soon as packs enters bzr.dev
<jelmer> as it has to have the latest bzr anyway
<lifeless> well
<lifeless> entering bzr.dev won't freeze the format immediately
<lifeless> so I'd encourage you to dogfood irrespective of bzr.dev merging
<jelmer> Lo-lan-do: I'm unable to pull as the alioth apache server appears to be executing .php.knit files
<jelmer> http://alioth.debian.org/%7Elolando/bzr/gforge/.bzr/repository/knits/82/184%406d150e1c-e21c-0410-8b89-9ee68aed362b%253atrunk%253agforge%25252%2546www%25252%2546account%25252%2546register.php.knit
<Lo-lan-do> I thought I had fixed that...  I'll have a look.
<Lo-lan-do> Damn, I must have lost the .htaccess when I erased and reinstalled the branch.
<Lo-lan-do> And I obviously forgot what it contained :-(
<Lo-lan-do> Oh hey, I copied it on my blog :-)
<Lo-lan-do> Try again?
<jelmer> Lo-lan-do: ok, thanks
<james_w> lifeless: there was a discussion recently on the git list about packing. It started when it was realised that users can't be expected to ever pack their repos. Am I right that you have implemented automatic repacking?
<lifeless> abentley: ping
<lifeless> james_w: yes we pack automatically
<lifeless> james_w: every 10 commits we pack 10 revs, every 100 we pack 100 etc
<lifeless> james_w: so we have sum(digits) packs as an upper limit at any point in time.
<Lo-lan-do> Nice.  Will that work with remote branches/repositories too?
<lifeless> Lo-lan-do: yes it operates an all mutating transactions
<Lo-lan-do> Lovely.
<lifeless> using bzr+ssh is better cause it won't have to repack over the wire, but it will work :)
<Lo-lan-do> I guess that'll mean fewer round-trips to branch HTTP branches?
<james_w> lifeless: that sounds pretty good to me.
<lifeless> Lo-lan-do: yes, we auto pack to provide an upper bound on latency overhead that scales (O(log10)) with repository commits
<lifeless> if we didn't you'd slowly degrade
<Lo-lan-do> That's great news :-)
<jelmer> Lo-lan-do: what version of bzr-svn are you using, 0.4.1?
<Lo-lan-do> 0.4.2 now
<Lo-lan-do> 0.4.1 didn't let me push.  0.4.2 did, with the aforesaid results.
<Lo-lan-do> jelmer: Maybe some more information would help, I guess.
<Lo-lan-do> I had several versions waiting to be pushed when 0.4.2 came out.
<jelmer> Lo-lan-do: I think I've figured out what the problem is
<Lo-lan-do> So I tried a push, got the first assertion error (assert self._new_revision_id is None or self._new_revision_id == revid)
<lifeless> looks like thats another 3 seconds
<Lo-lan-do> But one SVN commit still happened.
<lifeless> meh, actually no change
<Lo-lan-do> It contained the contents of the first revision I wanted to push.
<jelmer> Lo-lan-do: it looks like it truncated the svn-revid property
<Lo-lan-do> http://lists.gforge.org/pipermail/gforge-commits/2007-September/000548.html
<jelmer> Lo-lan-do: which triggered that after-commit assertion
<jelmer>    - 4865 lolando at debian.org-20070903205903-1g307x3ja2b9o0zw
<jelmer> that line shouldn't have been remvoed
<Lo-lan-do> Should it be a multiline property?
<jelmer> yep
<Lo-lan-do> Hm.  I guess I can fix it by hand, but won't another push truncate it again?
<jelmer> I'm trying to figure out what is causing the truncation
<Lo-lan-do> (You really must come visit southern France one of these days, my beer debt towards you is growing daily)
<jelmer> (-:
<hsn_> bzr 0.91 works with Trac?
<jelmer> not sure
<hsn_> 0.90 does
<jelmer> it doesn't use any exotic API's so I think it should work ok
<hsn_> cvs2bzr is still recommened method for moving away from CVS or better tools gets coded lately?
<lifeless> cvsps
<lifeless> there is a plugin on the bazaar plugins page
<Lo-lan-do> jelmer: I'm off to bed, for now.  Thanks for your help, feel free to leave the problem aside for now, or to email me (lolando@d.o) for extra information.  I'll probably come back tomorrow anyway :-)
<Lo-lan-do> 'night all
<jelmer> 'night Lo-lan-do
<hsn_> bzr: ERROR: cvsps-import can only operate on a local copy of the cvs repository. But i dont have shell access to CVS server..
<radix> if I've merged a branch, committed some other stuff, and then decide the branch merge needs to be reverted
<radix> how can I revert the merge, while still being able to bring back those changes later?
<hsn_> bzr shelve?
<radix> in SVN I revert the revision that merged the branch, and then just remerge again, and it works, because SVn doesn't track merged revisions. But bzr will go "oh, you already have those revisions!"
<radix> hsn_: that's for working tree changes...
<hsn_> you have branch - merge - changes and want to make branch - changes? make bzr diff for changes, then bzr uncommit and aply diff
<radix> That was kind of incomprehensible, but I'll pick out some things: I can't uncommit because I've already made some unrelated commits.
<radix> (and the branch already got distributed to other developers, etc)
#bzr 2007-09-13
<lifeless> radix: you can't unmerge
<lifeless> radix: you need to commit the reverse change; then later use a reverse-merge of your commit that reversed it out
<lifeless> hsn_: cscvs should be able to convert for you in that case
<radix> I think I just figured out how to do it
<radix> lifeless: what I did was: cd $TRUNK; bzr merge -r 430..429 .; bzr commit -m "unmerge $CRAPPY_BRANCH"; cd $CRAPPY_BRANCH; bzr merge $TRUNK; bzr revert *; bzr commit -m "HACK commit: merge unmerge without textual changes"
<radix> lifeless: now $CRAPPY_BRANCH is mergeable to trunk again
<radix> (making sure that $CRAPPY_BRANCH and $TRUNK were both up-to-date with other unrelated $TRUNK changes first)
<radix> lifeless: is that how you would've done it?
<radix> (I'm not sure if that's what you meant by "reverse-merge"
<abentley> lifeless: pong
<hsn_> lifeless: you are talking about this? http://www.gnuarch.org/gnuarchwiki/cscvs
<abentley> radix: "bzr merge -r 430..429 ." is an example of "reverse merge".
<radix> ah, ok
<radix> so yeah, that's the obvious thing: it's the "merge *that* reverse merge, and then revert the textual changes" that's the tricky bit
<lifeless> radix: thats close enough
<lifeless> abentley: hi, tree-reference's always have a reference-revision, its never NULL right ?
<lifeless> erm None
<lifeless> (at inventory serialisation)
<lifeless> hsn_: no, http://launchpad.net/cscvs
<abentley> Yes.
<lifeless> good; I've just grabbed another 10-15% on xml serialisation
<lifeless> I gambled I had it right :)
<abentley> It should be the value of the contained tree's last_revision.
<lifeless> I've made the serialiser aware of what attributes each kind should have
<lifeless> so it now requires that field to be non-none on tree-reference kinds, and ignores it otherwise.
<abentley> Sounds good.
<lifeless> unfortunately my time looking into that was a little wasted as there is only a second total to win there
<lifeless> so I grabbed something like 100ms if I merge it into the pack branch; worth it but not big
<hsn_> bzr get http://bazaar.launchpad.net/~launchpad/launchpad-cscvs/rocketfuel fails with bzr: ERROR: bzrlib.errors.KnitHeaderError: Knit header error: '\x1f\x8b\x08\x...
<poolie> hello
<poolie> hsn_, is that a public branch?
<lifeless> poolie: yes
<lifeless> poolie: we open sourced our cscvs changes
<abentley> lifeless: well, blow me down.  I thought I'd never see the day.
<radix> didn't that happen like half a year ago?
<lifeless> yes
<lifeless> abentley: about 12 months ago IIRC
<radix> welcome to 2007 guys ;-)
<luisbg> UnlockableTransport: Cannot lock: transport is read only: <bzrlib.transport.http._urllib.HttpTransport_urllib ...
<luisbg> why? and why in a commit?
<poolie> because you're trying to commit to an http branch
<poolie> you may have used checkout when you wanted to use 'branch'
<lifeless> luisbg: when you checkout, bzr commit pushes the results back to the place you checked out - like svn/cvs
<lifeless> luisbg: but http is readonly, so it fails. You can either bind to a writable url, if working like svn is what you wanted, or you can unbind to give yourself a stand alone branch, which will operate independently of the source branch
<luisbg> poolie, you are correct... I did the mistake of checking out and not branch :S
<luisbg> how do I fix this withour erasing and branching?
<poolie> i think just saying 'bzr unbind' in that directory will do it
<luisbg> lifeless, how do I unbind?
<luisbg> ahhh cool
<NfNitLoop> Hmm.   Tried to check branch a bzr-svn repo onto a windows box, and got an error:
<NfNitLoop> bzr: ERROR: File exists: u'<shared-repo>/.bzr/repository/knits/c1': [Error 183]  Cannot create a file when that file already exists
<NfNitLoop> s/check branch/branch/
<lifeless> hmm, why does osutils.split_lines exist, isn't s.splitlines(True) the same ?
<lifeless> NfNitLoop: is c1 a file or directory?
<igc> morning all
<lifeless> hi
<abentley> lifeless: No.
<abentley> s.splitlines() will also split on \r or
<abentley> \r\n
<lifeless> abentley: ah thanks. we should note that
<lifeless> oh, and
<lifeless> 0.92: first post!
<abentley> It is precisely this issue that made me uncomfortable with your recent patch.
<lifeless> me too :(
<abentley> Because people don't tend to realize that.
<abentley> I think the final patch handled it pretty well, though.
<lifeless> cool
<NfNitLoop> lifeless: a directory.
<lifeless> NfNitLoop: thats strange then
<lifeless> NfNitLoop: perhaps the exception raised by python has changed, wasn't alexander mentioning something like that last week ?
<lifeless> (we expect mkdir to fail when the dir is already made so we catch an exception there)
<NfNitLoop> NfNitLoop: Not that I recall... but I only vaguely keep watch in here.
<lifeless> NfNitLoop: what version of python do you have ?
<NfNitLoop> 2.5.1
<lifeless> can you try with 2.5.0 ?
<luisbg> poolie, and lifeless, thanks a lot =)
<NfNitLoop> lifeless: Hmmm.    I guess so... I can install it in its own directory, right?
<lifeless> I think so
* NfNitLoop tries.
<NfNitLoop> downloading.  lallaa.
<NfNitLoop> I'm looking forward to svn 1.5 when the python bindings will be fixed across all platforms. :p
<NfNitLoop> I'm not going to build my own on my windows box.
<NfNitLoop> So until then I'm (trying) branching off of my linux box to the windows one.  all commits back to svn will have to go back through the linux box.
<NfNitLoop> a bit of a pain, but it's still awesome that that's a viable workflow.  :)
<lifeless> spiv: is chain C or python ?
<NfNitLoop> lifeless: same error with 2.5.0
<NfNitLoop> lifeless: I've successfully done this from Linux -> OSX
<NfNitLoop> I'm actually now doing it from OSX -> WinXP.  Since my mac laptop is handily located next to my computer here. :)
<spiv> lifeless: chain?
<NfNitLoop> so it seems a windows-specific issue.
<spiv> lifeless: you mean functools.partial?
<NfNitLoop> where does .bzr.log go in WIndows?
<lifeless> NfNitLoop: bzr version will tell you
<lifeless> spiv: itertools.chain
<lifeless> NfNitLoop: please file a bug
<lifeless> NfNitLoop: you can work around by copying the .bzr directory by hand
<spiv> lifeless: everything in itertools in CPython is implemented in C.
<lifeless> spiv: thanks
<Ubotu> New bug: #139253 in bzr "bzr branch fails with "File exists" error." [Undecided,New]  https://launchpad.net/bugs/139253
<Ubotu> New bug: #133989 in bzr-svn "svn-import reports a File exists error (dup-of: 139253)" [Undecided,New]  https://launchpad.net/bugs/133989
<AfC> Would it be correct to say that Bazaar doesn't depend on RCS (as Git does) because Bazaar has more advanced (ok "different") algorithms for doing and presenting diffs?
<poolie> really, Git depends on RCS?!
<poolie> it is correct anyhow
<poolie> we have a diff algorithm described by Bram Cohen as "by far the best" or something similar
<poolie> (lunch)
<AfC> poolie: apparently the Debian package does. I seem to recall seeing that from the Git pages.
<AfC> Needless to say, I'm going to blog a one liner about that if I can verify my facts.
<Ubotu> New bug: #139273 in bzr "test case leaves behind temporary log files" [Low,Triaged]  https://launchpad.net/bugs/139273
<AfC> Maybe it's just the cogito UI that depends on it. Oh well.
* igc lunch
<jelmer> the GNOME DistributedSCM page says bzr is lacking guaranteed content history, is that true?
<lifeless> what does that mean ?
<igc> it means we don't look up revisions via SHAs I think
<lifeless> we have testaments, they can be signed
<jelmer> I'm not quite sure what it means. Also talks about (disk?) corruptions in the repository and stuff
<lifeless> really, is this imaginary or experienced ?
<asabil> jelmer: I think the whole sha1 thing started with monotone
<asabil> monotone does heavy checking and verification on the changesets, and the consistensy of its sqlite database
<asabil> this can make some sense, because it allows you to know if you database is corrupted (for example after storing it for 5 years on an optical disk)
<lifeless> we have that
<lifeless> for content we know the sha
<jelmer> lifeless: looks like somebody confused revids with checksums somewhere
<asabil> it also allows to detect if someone was trying to do some funky stuff with a database (trying to corrupt it for example)
<lifeless> for the content of the tree we have a sha of that
<lifeless> jelmer: is it a wiki page, can you correct it ?
<asabil> yes it is a wiki page, I have been updating it recently
<asabil> (I have to admit that there is a huge bias in that page toward git unfortunately :'( )
<jelmer> lifeless: yeah, sure, I'll add a comment
<jelmer> hey, I didn't know git was slower than both bzr and hg on windows...
<lifeless> not surprising
<lifeless> git is awful tuned in its design to what linux and ext3 do from everything I've read
<igc> btw, on Wikipedia, signed revision support is listed as 'partial' for Bazaar: see http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Features
<lifeless> someone needs to write better verification support is all; not huge or hard
<lifeless> asabil: are you a git advocate? or bzr?
<igc> this whole area was heavily pushed by Linus in his Google talk video as well
<asabil> lifeless: I bloody hate git
<lifeless> :)
<asabil> I have been trying to keep the page unbiased, but there is too much hype around git
<asabil> it's life a fashion thing
<lifeless> :(
<jelmer> lifeless: still, it's main design goal is speed and it's written in C so I'd expect it to be faster
<asabil> I am really wondering if the FOSS community is turning into some fashion oriented community
<lifeless> jelmer: C is not a panacea; I agree that their priorities are broken
<mneptok> asabil: check out my new Yves Saint-Laurent wireless card!
<asabil> lol
<mneptok> binary blob drivers, though. they don't want to reveal the WPA subroutine code or the floral extracts they use. :/
<asabil> oh
<asabil> lol
<mneptok> yeah. "free as in cologne." :/
<asabil> jelmer: I was the one putting that bzr is lacking revision verification
<igc> asabil,jelmer,lifeless: there aren't a lot of responses (~100) but I'm a little surprised by the results to date of the Bazaar user survey: http://www.surveymonkey.com/sr.aspx?sm=FDeDsLzaZ0AKNEATuA0QklWayMZKGfHcrP1U4V55jAY%3d
<asabil> I removed it now
<lifeless> asabil: so we have shas from the revisions down; we have a canonical form that gets signed called a testament
<jelmer> asabil: cool, thanks
<igc> neither Git nor Hg are as liked as much as Subversion by Bazaar users
<lifeless> asabil: revision ids are not shas because that forces history rewriting if you want partial conversions to be interoperable (e.g. its fugly)
<jelmer> lifeless: Writing in C may not necessarily make something faster, but writing things on a lower level usually makes it easier to optimize
<jelmer> (no conversion for bindings involved, no byte-compilation, etc)
<lifeless> jelmer: I find the reverse :)
<igc> despite that fact that "distributed" is a major reason for choosing Bazaar
<lifeless> jelmer: After one accounts for the baseline speed difference, I find it easier to make something in python twice as fast as to make something in C twice as fasst
<lifeless> igc: this is something to put on the Gnome vcs page I think
<lifeless> asabil: ^ jelmer: ^
<mneptok> igc: "What I basically want is the exact same thing, but completely different? Can you do that?"
<lifeless> mneptok: "Yes"
<mneptok> *bounce*
<asabil> lifeless: http://live.gnome.org/DistributedSCM
<asabil> you can read and suggest updates
<lifeless> asabil: I'm going to let others do that
<lifeless> right now I'm fighting the key performance battle that currently we're whipped at
<asabil> lifeless: yeah I can do it, just give me some feedback
<asabil> igc: lol, I am the only one who voted that I know monotone the best :D
* mneptok is also not going to update that page for political reasoens
<mneptok> -e
<asabil> :)
<jelmer> I'm only adding comments, won't change any actual data..
<jelmer> igc: I'm surprised at the amount of Windows users
<igc> jelmer: yes, there are quite a few surprising results in there
<lifeless> what, less users than you expected?
<lifeless> We decided windows was strategic way back
<jelmer> lifeless: I always tend to write faster code in C if I write it twice in both Python and C
<jelmer> lifeless: no, more
<jelmer> lifeless: 39% (out of 95 people)
<jelmer> (people can select multiple os'es)
<lifeless> that feels right to me
<jelmer> beats everything but ubuntu
<lifeless> igc: call ?
<igc> sure
<igc> one minute
<lifeless> igc: split_lines on inventory is 100msec
* lifeless goes to fix
<Stevage> Question: if you rename a versioned subdirectory manually (eg, "ren foo bar" in windows), is bzr supposed to detect that and do something appropriate?
<lifeless> Stevage: no, but 'bzr rename --after foo bar' should tell bzr about it for you
<lifeless> Stevage: I think if you have the bzr tortoise plugin I'd expect bzr to be told, or something appropriate
<Stevage> cool. the documentanio for 'commit' is a bit misleading then
<Stevage> there's a bzr tortoise plugin??
<Stevage> cool :)
<lifeless> Stevage: hmm, can you point at the misleading bit ?
<Stevage> http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#commit
<Stevage> the example at the end of that
<Stevage> It says "In the example above, the last commit will fail by design. This gives the user the opportunity to decide whether they want to commit the rename at the same time, separately first, or not at all."
<Stevage> I took that to mean bzr will detect the rename and commit it.
<Stevage> but actually all that happens is it detects a deletion and an unknown file.
<lifeless> well
<lifeless> if you look at the example 'bzr mv' is used to do the rena,e
<Stevage> oh!
<Stevage> yeah oops you're right
<Stevage> thought it was just mv
<lifeless> ":)
<Stevage> I still don't get this text from the front page though:
<Stevage> For that reason, Bazaar is specifically engineered to be as tolerant of user decisions as possible, and to allow ANY operation on your code tree that is possible using UNIX and Windows filesystems. As a primary example, Bazaar is extremely tolerant of renames of directories and files, even when multiple different contributors are renaming files and directories differently in their branches,...
<Stevage> ...and then merging from one another.
<Stevage> that was what originally got me thinking that somehow you could just rename files at will and it would detect it
<lifeless> Stevage: ah
<lifeless> Stevage: what we mean is 'when two users of bazaar perform renames [using bazaar]  in separate branches, we try very hard to Do The Right Thing'
<lifeless> what you are trying to do, we are also tolerant of, but we clearly don't /know/ whats happened if you don't tell bzr about it. We can guess, but that generally gives worse results
<Stevage> yeah, I guess I was just confused by the references to unix/windows filesystems, followed immediately by [Bazaar]  renames.
<Stevage> it's all good.
<Stevage> is there a way to commit with a date other than today's? (other than changing the system clock...)
<poolie> Stevage, there is at the api level, i don't know if it's exposed on the cli
<poolie> rather i think it's not
<poolie> it would be a trivial addition
<Stevage> hmm
<Stevage> I'm trying to do a quick and dirty repository migration here
<Stevage> might be easier to just set the system clock, but that can have ugly side effects
<poolie> that doesn't sound like a really great idea...
<Stevage> yeah I know :/
<Stevage> what do I need to compile/build bzr on winxp?
<poolie> if you just want to modify the python source you only need python
<poolie> if you want to build the binarios, see http://bazaar-vcs.org/Win32ReleaseChecklist
<poolie> or rather http://bazaar-vcs.org/BzrWin32Installer
<lifeless> Stevage: what format are you trying to convert from ?
<Stevage> from this ancient system called TLIB
<lifeless> oh wow, ok
<lifeless> in python
<lifeless> if you do 'import bzrlib.workingtree'
<lifeless> tree = bzrlib.workingtree.WorkingTree.open('path')
<Stevage> poolie: what do you mean by building binaries? if I'm just rebuilding it for my own purposes, what will I need?
<lifeless> tree.commit(message=... )
<Stevage> sadly I don't know python at all (yet)
<lifeless> there are parameters (pydoc bzrlib.commit.Commit lists them all)
<poolie> Stevage, just python will do, there is no compilation step
<Stevage> so the python dll that came with bzr is sufficient?
<lifeless> poolie: well, there is an optional one ;)
<Stevage> or is there an interpreter?
<poolie> yes, there's an interpreter
<poolie> i should have said, there's no mandatory compilation step
<poolie> if you run the command 'python'
<Stevage> but if i want to be able to run 'bzr commit' etc from the commandline I'll need to compile?
<poolie> no
<poolie> do you have bzr installed from a package at present?
<Stevage> this is xp
<poolie> i mean, from one of the windows installers
<Stevage> yeah
<lifeless> later all
<Stevage> ok, so now that I have python installed, how do I compile/interpret bzr?
<Stevage> can anyone help me get started running bzr from source on winxp?
<beuno> Stevage, I believe now you just have to execute the "bzr" in the folder where the source is
<Stevage> come to think of it I don't think I actually have the source
<Stevage> I have /lib and /doc but no /source or anything
<beuno> Stevage, were did you download it from?
<Stevage> bazaar-vcs.org, the 'windows standalone installer' link
<abentley> SteveA: You should have 'bzrlib', not 'lib'.
<Stevage> it's called lib for me
<Stevage> in lib there are some .pyd's, a .zip and a .dll
<abentley> It doesn't sound like you're taking the run-from-source steps.
<spiv> The standalone installer doesn't install the source AFAIK.
<beuno> Stevage, if memory serves me right, you should be able to fire up a command line prompt and execute "bzr", you should know it's a command-line program
<Stevage> no, I wasn't - I originally downloaded the binaries. now I realise I need the source too.
<abentley> All you need is the bzr tarball and python.
<Stevage> yeah that's ok, I've had bzr running for a couple of days. it's just now that I want to modify the source...
<spiv> It installs the compiled .pyc files bundled into a zip file I think.
<abentley> Compiling is an optional step-- it increases performance a bit.
<beuno> Stevage, then you should download http://bazaar-vcs.org/releases/src/bzr-0.90.tar.gz
<Stevage> yeah just got that
<abentley> But that's all compiling does.
<beuno> Stevage, then uncompress, edit, go into the folder and execute "bzr", that should be it
<beuno> it doesn't need to be compiled to work
<beuno> as abentley mentioned, all that does is speed things up a bit
<Stevage> erm, I'm on windows here, that's not going to work
<Stevage> bzr. is a shell script
<beuno> Stevage, it's a python script, it should run fine
<beuno> if it doesn't, then try "python bzr"
<Stevage> ok that worked
<beuno> :D
<Stevage> there should be a bzr.bat included, since that package is supposed to work on all platforms
<beuno> surprising how much effort the bzr devs here put into multi-platform compatibility
<beuno> Stevage, it does, and a .bat would be windows-specific
<Stevage> yeah but there's a "bzr." which is unix specific...?
<abentley> Well, that's bundled with windows installers.
<beuno> Stevage, nope, the tarball you downloaded is the same for all platforms
<Stevage> yeah I know
<abentley> Sticking it in the main source tree wouldn't kill us, though.
<Stevage> I'm just saying, there's a unix shell script, but no windows batch file
<abentley> No, there's no shell script.
<beuno> Stevage, there isn't a unix shell script, it's a python script
<abentley> There's only a python script.
<abentley> The .bat file is just a more convenient way of running that python script.
<Stevage> heh, ok it's a python script that starts with #! /usr/bin/env python
<Stevage> which is code understood by the unix platform but not by windows
<Stevage> hence, "unix script"
<Stevage> it doesn't matter anyway
<abentley> Shell scripts start with #!/bin/sh
<beuno> but you seemed to convince abentley to add the .bat in the main tree, so you made progress  ;)
<Stevage> lol
<abentley> Stevage: The last VCS I worked with started as a collection of shell scripts.  It wasn't pretty.
<Stevage> ok so where do I look to add a new command line argument?
<Stevage> ugh
* beuno steps down from this and heads to bed
<Stevage> you should see what I'm migrating from, it considers directory trees an "advanced feature"
<beuno> g'night all
<abentley> You would edit bzrlib/builtins.py and find cmd_commit.
<Stevage> awesome
<Stevage> if there's a .pyc should I delete it?
<Stevage> or will it recompile itself automatically?
<abentley> It will recompile automatically.
<Stevage> hey awesome I added a new option and it worked :)
<Stevage> (well, it doesn't do anything yet...)
<Stevage> Usage:   bzr commit [SELECTED...] 
<Stevage> Options:
<Stevage>   -h, --help            Show help message.
<Stevage> ...
<Stevage>   --date=COMMITDATE     Commit as if it were this date.
<Ubotu> New bug: #139247 in launchpad-bazaar "bzr+ssh:// cannot be used to branch" [Low,Invalid]  https://launchpad.net/bugs/139247
<Stevage> where would I go to add the implementation of that option?
<Stevage> oh, commit.py duh :)
<lifeless> well commit.py already has it
<lifeless> you just need to glue it into the parameters passed to workingtree.commit() in builtins.py
<lifeless> e.g. all your changes will be in builtins.py + any test changes
<Stevage> ok. I'll need to parse a date from the command line, but I can't understand how to add that code to Option.py
<Stevage> is there already a date parsing function?
<poolie> Stevage, i believe there is one in the time module
<poolie> Stevage, http://docs.python.org/lib/module-time.html
<poolie> see strptime
<Stevage> ok just found that
<Stevage> so how does the option parsing stuff work: when an option is set to type 'str', where is the call that makes it get parsed as a string?
<Stevage> and what is 'str' - an enum, or a language primitive?
<Stevage> (I don't know Python at all :( )
<igc> heading off a bit earlier today
<igc> night all
<Ubotu> New bug: #139318 in bzr "`bzr send --mail-to` failed with UnicodeEncodeError" [Undecided,New]  https://launchpad.net/bugs/139318
<pitti> hello all
<pitti> since the last upgrade of bzr (0.18 to 0.90), pulling from a bzr+ssh:// fails with [Errno 13]  Permission denied: '/.bzr.log'
<pitti> is that me doing something silly?
<pitti> pulling from sftp:// or http:// works
<pitti> might also be a problem on the remote end (bzr+ssh://bazaar.launchpad.net)
<pitti> indeed, pull bzr+ssh:// from my own server works
<matkor> Assuming I have checkout of branch. I want to know if I am up to date with checkout - is it bzr missing <checkout_branch> right way of checking it ?
<Lo-lan-do> matkor: I think you can just do "bzr missing"
<matkor> Lo-lan-do: I get bzr: ERROR: No peer location known or specified in 0.90
<Lo-lan-do> Hm.  Then yeah, use the full syntax :-)
<matkor> Lo-lan-do: Thnx :)
<matkor> I think I will fill wishlist about that if it so obvious ...
<matkor> It is so obvious so there already is wishlist about that ;)
<matkor> I Have checkouted my WT to revno 50. But it indroduces errors. Can I have it back to revno 49 ? TIA
<jelmer> james_w, siretart: are there any plans in merging the hooks branch for bzr-builddeb?
<BasicOSX> doing a bzr checkout --light-weight, is there a way to convert(?) that to a full branch?
<jelmer> BasicOSX: A patch was posted to the mailing list yesterday that adds support for doing that
<jelmer> I don't think it's possible in a released version yet
<BasicOSX> that's actually "good" since I as pounding my head abou tit
<Jen> Hi, I just found Bazaar and is trying it out locally. I read this (great) guide (http://doc.bazaar-vcs.org/latest/en/user-guide/centralized_workflow.html#initial-setup) and is wondering if there is any way to perform a 'hook like' command. When commiting I would like 'centralhost' to update to an folder placed in the webscope.
<beuno> Jen, sure, you can write a plugin for that
<beuno> their are plenty of existing plugins: http://bazaar-vcs.org/BzrPlugins
<beuno> you can look at one of those for examples
<Jen> beuno: Great. Thank you. Am I right that I whould have to do something like 'bzr checkout sftp://server/tree/branch /webroot/folder' and then 'bzr pull sftp...' when updating?
<Lo-lan-do> The URL should be remembered, so just "bzr pull" should work.
<beuno> Jen, if you want to have a svn-like workflow, yes
<dato> I think it's bzr update for checkouts.
<Jen> beuno: oh my bad that's wrong. That will checkout the branch to my computer - I would like it to be checked out to a folder on the central server
<Jen> dato: thanks ;)
<james_w> jelmer: it needs updating. If you have a need for it then I can move it up the TODO list.
<james_w> Jen: either ssh to the server and checkout, or you can supply sftp://... as the second argument and do it remotely.
<beuno> Jen, you would like to checkout from your PC to a directory on another PC?
<james_w> however that will be slow if both ruls are remote. If they are on the same server then doing it after ssh to the server will be a lot faster.
<jelmer> james_w: There's some C-based packages I have it would be very useful for
<james_w> and using bzr+ssh:// will speed it up.
<james_w> jelmer: you wanted to run autotools correct?
<jelmer> james_w: yep
<Jen> beuno: no - when I commit I would like 'centralhost' to do a checkout to itself (i.e. move the files to a webscope)
<james_w> jelmer: on a native package?
<jelmer> james_w: nope, in normal mode (with export-upstream)
<beuno> Jen, right, I understand, you can hook it and make it do that, it will take some work to make everything run smoothly (specifying where it should checkout, por example), but it's perfectly doable
<james_w> jelmer: was your need satisfied by the old branch? I don't even remember if it worked at all for you.
<jelmer> james_w: yeah, that worked, though I'd rather just specify the command to be run rather than having to create scripts
<Jen> beuno: great - thanks for your time
<jelmer> the use case for hooks probably differs per person though..
<james_w> jelmer: in a config file?
<jelmer> james_w: yeah
<beuno> Jen, no problem, have fun with that  :D
<jelmer> just 'export-upstream-hook = ./autogen.sh' in the same place as where the other bzr-builddeb settings are
<james_w> jelmer: I'm not sure how easy that would be to authenticate, but it seems like a reasonable request.
<jelmer> james_w: where is the authentication stuff for exactly? Don't you have to trust the data in the branch anyway?
<james_w> I'm not sure how important authentication is as you have to run debian/rules anyway, but I wanted to avoid the surprise of having a hook run and do something nasty.
<jelmer> ah, k
<keir> hi all
<jelmer> 'evening keir
<james_w> as in someone new to the plugin probably wont know about hooks, but may check debian/rules and still be surprised. I realise it's perhaps a little perverse though. I'll re-evaluate when updating the branch.
<keir> can someone perhaps vote on my patch? http://bundlebuggy.aaronbentley.com/request/%3Cef5675f30709041204j276ce48biaa5095a939bc5749@mail.gmail.com%3E
<keir> it's already approved by aaron, it'd be nice to get it in for .92
<jelmer> james_w: it'd at least be nice if it was disableable
<jelmer> on a per-user basis
<james_w> so you enable hooks once and by doing so promise to vet all hooks from then on?
<jelmer> yeah, something like setting '[builddeb] \ndont-authorize-hooks = True' in ~/.bazaar/bazaar.conf
<james_w> yeah, that sounds like a good idea to me. Thanks.
<jelmer> keir: I'll have a look later this evening if it hasn't been approved by then
<keir> jelmer: thanks!
<keir> is there a 'standard' way to write tests which should work for multiple implementations of the same interface?
<keir> i'd like to factor tests which work against the GraphIndex layer such that I can use them against my own code
<keir> then any implementation-specific tests go elsewhere
<james_w> keir: yes there is
<LaserJock> I've got a merging question
<james_w> workingtree_implementations is one set.
<LaserJock> if I've got two branches that have common parts, can I just merge the common parts
<james_w> keir: you want adapt_modules from bzrlib/tests/__init__.py
<keir> ok
<james_w> keir: and bzrlib/tests/workingtree_implementations/__init__.py for an example.
<james_w> LaserJock: can you be more clear please? They are unrelated branches that have some of the same files?
<LaserJock> I guess they could be considered unrelated
<LaserJock> so there's some directories that are common to both (actually several branches)
<LaserJock> basically, can I merge just a directory in a branch or do I have to merge the whole branch
<NfNitLoop> If they're unrelated branches, you can't use 'bzr merge'.
<NfNitLoop> you'll probably just want to use 'patch', then commit.
<LaserJock> hmm
<NfNitLoop> if two projects share the same directory, though, it sounds like that directory is a library?
<NfNitLoop> You might want to move that library into its own repo.
<NfNitLoop> (or suggest it to the project maintainer, if that's not you.)
<LaserJock> well, it's actually documentation
<LaserJock> the Ubuntu Documentation project
<LaserJock> and I'm trying to figure out how we'd handle common directories
<LaserJock> right now we have it all in one SVN repo
<NfNitLoop> What format is thet documentation in?  HTML?
<LaserJock> docbook
<NfNitLoop> ah.  Not familiar with that one.   Was wondering if you could just link to the relevant parts.
<NfNitLoop> so you wouldn't have to maintain your own copy.
<LaserJock> it's all our stuff
<LaserJock> I'm wondering if we'd have to do a separate branch for the common stuff
<LaserJock> but that's not very good because then people have to get 2 branches to get the docs
<keir> i just co'd blender trunk, and there's now a blender/ and a lib/ directory. do i need to import those both? or can i just take the blender/ directory?
<james_w> dato: your hookless-email seems to have died for pkg-bazaar.
<james_w> keir: import?
<keir> james_w, i'm setting up a parallel svn repo for a branch
<james_w> you checked out svn or bzr? and you are setting up an svn repo?
<keir> sv
<keir> svn
<keir> bzr is impractical for a couple of reasons, namely lack of a really stable windows gui
<keir> (i don't use windows, but the students i'm working with are)
<james_w> you checked out svn and are setting up svn? Is this really a question for #bzr?
<keir> GAH
<fullermd> Pshaw.  Think of it as an opportunity to enlighten them   ;p
<keir> wrong window
<keir> sorry
<james_w> np
<ubotu> New bug: #139456 in bzr "failed to open trace file: [Errno 13]  Permission denied: '/.bzr.log'" [Undecided,New]  https://launchpad.net/bugs/139456
<dato> james_w: right. it dies on commits without a valid email address. restarted, and noted in the TODO to fix that case.
<james_w> dato: thanks.
<james_w> I didn't think that ExternalBase tests would give you a branch to work from when you start as a lot run init or similar first, but apparently you get a branch.
<jelmer> lifeless: ayt?
<lifeless> jelmer: jo?
<lifeless> keir: you tried bzr tortoise?
<keir> lifeless, no
<keir> lifeless, the issue is that i have absolutely no time to debug their problems if it doesn't Just Work Every Time
<keir> i'm certain tortoise svn is rock solid, so that's what it'll be for now
<fullermd> My impression from looking at the tortoise and olive/win32 is that they may work well, if you make it through the install process.
<lifeless> keir: I see
<lifeless> thats fair enough
<keir> lifeless, in addition i don't have time to mess with tracbzr. so svn it is
<keir> the students are not of the 'i'll try to use it because it's oss despite some problems' types (at least as far as i can tell)
<jelmer> lifeless: I'm hitting an assertion in Repository.add_inventory() in the packs branch
<keir> i feel killer trac integration is important. i know launchpad should eventually be good enough, but many projects want to self-host
<jelmer> lifeless: self.is_in_write_group()
<jelmer> removing it doesn't seem to cause trouble
<lifeless> keir: yah, I know some folk using tracbzr
<lifeless> keir: tim hutch, abentley IIRC
<lifeless> jelmer: whats the call stack when you hit that assertion? You *really* want to leave it in place and not trigger it.
<keir> lifeless, cool, glad to see it's usable. until it's in upstream trac though, it's harder to justify.
<jelmer> tim never did any tracbzr work afaik
<keir> anyway: mkdir bzrlib/trac/index_implementations?
<lifeless> jelmer: I didn't claim he was an author :)
<jelmer> lifeless: doh, I should read better
<lifeless> keir: well, we're using moin;
<lifeless> jelmer: tim is a trac corish dude though
<keir> lifeless, i'm going to separate out the tests for graphindex such that we can try different ones
<asabil> keir: I am using bzr at work
<jelmer> we use trac-bzr for bitlbee - http://bugs.bitlbee.org/bitlbee/
<asabil> keir: I am a linux devel, but most people in my team are windows developers
<keir> lifeless, moin is nice, but trac's integration is amazing. in particular, the timeline is *so* useful
<asabil> keir: maybe you wanna try QBzr for windows
<jelmer> lifeless: it was triggered from bzr-svn, let me see if I can find the backtrace...
<lifeless> jelmer: then its a bug in bzr-svn for 0.90 and up; I'll help you debug it
<keir> actually the thing i miss most from trac to launchpad is the timeline and wiki, in that order.
<keir> the current launchpad timeline is at the appropriate granularity for typical users, but is not as useful for devs
<jelmer> lifeless: I'm calling Repository.add_revision()
<jelmer> but I don't use write groups at all myself
<lifeless> jelmer: then thats the bug
<lifeless> jelmer: you are an implementor of fetch basically, so you need to manage the write group yourself
<jelmer> lifeless: ok, I guess that makes sense
<jelmer> though I've never had to do so before
<lifeless> its an API change, in NEWS
<lifeless> locking is about mutual exclusion
<lifeless> write groups are about transactions
<lifeless> you want to minimise the number of transactions you do, but you could do one per rev if you want
<lifeless> each transaction generates one pack and matching indices
<jelmer> ahh
<lifeless> at the end of each transaction autopack is run which will combine packs as needed to prevent linear growth
<jelmer> and no data gets written before the write group is committed?
<jelmer> or, at least, not necessarily?
<lifeless> with packs data is written to .bzr/repository/upload/lock-token.tmp
<lifeless> at commit time the pack is finished, indexed, and then its all renamed into place and finall the pack name is added to pack-names
<lifeless> abentley: are you around ?
<jelmer> ok, so I would want to create a new commit group every X revisions
<lifeless> jelmer: if you expect people to abort things and want to be resumable yes
<jelmer> so that hitting Ctrl+C halfway through fetching a 20k revision branch won't lose all data
<jelmer> lifeless: cool, thanks
<keir> so the XXXX_implementations/ directory actually holds blackbox tests (aka tests that only use the interface?)
<keir> i'd probably have named them workingtree_blackbox/
<keir> i expected the opposite (that ..._implementations/ would contain tests for specific implementations)
<jelmer> lifeless: InventoryDirectory.snapshot() is no longer available - is that intentional?
<lifeless> jelmer: yes
<lifeless> keir: we may rename them to per_workingtree or something
<lifeless> keir: but yes, the *_implementation directories yes that 'each implementation meets the interface'
<jelmer> lifeless: it's not in NEWS
<lifeless> jelmer: its not in bzr.dev either
<lifeless> jelmer: look at repository.py's CommitBuilder
<jelmer> lifeless: may not be used, but it is still available
<lifeless> jelmer: snapshot ?
<jelmer> yes, http://bazaar-vcs.org/bzr/bzr.dev/ still has InventoryDirectory.snapshot() in bzrlib/inventory.py
<lifeless> jelmer: 'the patch to remove snapshot is not merged to bzr.dev'
<lifeless> my clarity was absent
<jelmer> ahh
<jelmer> should I be complaining about API breakage in packs that's not in NEWS at this point?
<jelmer> or wait until later?
<lifeless> you're welcome to complain
<lifeless> complaints with patches are better
<jelmer> I feared that would be your reply..
<lifeless> :)
<lifeless> so snapshot is part of my commit refactoring branch
<lifeless> I'm moving responsibility for storing entries to the CommitBuilder
<lifeless> so it can vary between repository more cleanly
<jelmer> so the idea is to have fetchers use CommitBuilder as well?
<jelmer> s/so//
<lifeless> well
<lifeless> converters do you mean ?
<jelmer> yeah, the generic fetchers
<lifeless> it would be nice if we *had* generic fetchers
<lifeless> right now the most generic is still very versioned file centric
<keir> pdb is so slooooooow. is there a way to say 'don't load pdb, unless an exception is thrown'?
<keir> for the selftests?
<lifeless> but yes, using CommitBuilder is the right thing to do if all you have is a tree shape and need to store a representation of that from first principles
<lifeless> however, doing targeted converters is the way to better performance
<lifeless> keir: hmm, are you running under pdb ?
<jelmer> lifeless: I may be interested in writing a generic fetcher if I want to try out packs + bzr-svn
<jelmer> since bzr-svn's fetcher is very VersionedFile-centric atm
<lifeless> jelmer: your current knit converter should work (unless you were using inventory.snapshot)
<jelmer> I /am/ using Inventory.snapshot :-)
<lifeless> heh
<lifeless> ok, well I'm trying to land this change in 0.92
<keir> lifeless, pdb ./bzr selftest ...; however, it's useless because the testing framework is catching the exception
<lifeless> I'm also overhauling commit builder for more strict separation between repository and tree
<lifeless> keir: eek.
<lifeless> we should enable the debug option
<lifeless> which unittest has but we don't present. anyway -
<lifeless> I do import pdb;pdb.set_trace() in the test that fails
<lifeless> then ./bzr selftest failingtestname
<keir> lifeless, but it only fails in one specific case
<keir> lifeless, sorry, that wasn't clear
<lifeless> keir: so only run that test :)
<keir> yeah, ok
<keir> sorry. set_trace() launches a debugger where you put the set_trace()
<keir> i don't want that
<lifeless> because ... ?
<keir> i want a debugger exactly where the exception is thrown, which is way down past a bunch of iterations of the search
<lifeless> ok
<lifeless> sometimes its whack
<lifeless> but you can do
<lifeless> try:
<lifeless>     thing
<lifeless> except:
<keir> aah right
<lifeless>     pdb.pm()
<keir> nasty
<lifeless> not really nasty, its what BZR_PDB=1 does for non-test-suite code
<keir> i see
<lifeless> but pscyo IIRC really breaks it
<ubotu> New bug: #139478 in bzr "bzr: ERROR: bzrlib.errors.UnlockableTransport" [Undecided,New]  https://launchpad.net/bugs/139478
<james_w> hmm, it's odd that came from an update isn't it?
#bzr 2007-09-14
<lifeless> unlockable, sounds like an old tre format too
<lifeless> we don't use oslocks anymore except in dirstate, and there we don't use the transport api to them
<mneptok> is bzr compatible with my relaxed and debonair lifestyle?
<mneptok> because it turn out my lifesyle has library issues with Reality 2.4
<fullermd> I just uninstalled Reality.  I don't really have any use for it.
<mneptok> i gave up trying to port it years ago, but after a few weeks talking to our customers, sabdfl pretty much insisted i update.
<keir> lifeless, so i'm implementing iter_entries()
<keir> lifeless, what's the expected behaviour if a key is missing?
<asabil> hmm, I would like to contribute a small patch to bzr
<asabil> and am lazy to send it to the ML
<asabil> any developer wanna help me in my laziness :D ?
<keir> lifeless, it appears from the tests it is skipped in the resulting iterator. correct?
<asabil> anyone ?
<lifeless> keir: it gets skipped
<lifeless> asabil: file a bug with it then
<lifeless> asabil: it still has to be reviewed
<lifeless> list is probably easier for you, just bzr diff > foo
<lifeless> and send a mail [MERGE]  thing, attach foo to the mail
<asabil> lifeless: I created a bundle
<asabil> lifeless: it i a tiny feature, basically adds branch description support
<lifeless> asabil: or you could just bzr send --mail-to bazaar@lists.canonical.com
<lifeless> asabil: with tests?
<lifeless> asabil: e.g. does push/pull propogate it, does 'branch' reset it ?
<lifeless> asabil: documentation as well ?
<asabil> with tests
<asabil> is the branch nick propagated ?
<asabil> lifeless: it is implemented in the same way as branch nick
<asabil> that's what someone suggested to me yesterday, is that wrong ?
<fullermd> nick isn't propogated anyhwere...
<lifeless> asabil: its not a matter of right or wrong
<asabil> :/
<lifeless> its a matter of deciding how it should work and making that clear to the user
<asabil> I would have prefered if it was propagated
<lifeless> if its undefined its hard for writers to document it
<lifeless> also it will need a new branch format
<asabil> I will patch my bundle to the ML
<asabil> and maybe we can have some discussions over there
<asabil> no ?
<lifeless> I guess Im' saying in short - 'chances are you are not finished yet; you should be the one to take it to the list as you will need to be involved in further discussions'
<asabil> yeah will do
<asabil> thanks for the tips :)
<asabil> sent to the ML
<keir> lifeless, iter_entries() can return the items in arbitrary order, correct?
<asabil> good night all
<lifeless> keir: yes
<keir> excellent
<keir> what i've written does one pass over the keys, collecting any blocks it needs to read
<keir> any keys that are already there get yielded
<keir> then it iterates until no one is reading
<keir> so it's breadth first, but this is the right thing for reducing round trips
<lifeless> right
<lifeless> the interface was crafted to allow this sort of optimisation :)
<lifeless> real    1m38.122s
<lifeless> user    1m30.430s
<lifeless> sys     0m4.600s
<lifeless> sneaking down
<keir> is it insane to write mykeys = set(keys)? that copies the list of keys, but i need to store which ones are still incomplete
<lifeless> profile profile profile
<lifeless> its very hard to predict just what will or won't be faster in python
<lifeless> if keys is a set, copying it is probably quite speedy
<igc> morning
<lifeless> hi igc
<lifeless> real    1m38.122s
<lifeless> user    1m30.430s
<lifeless> sys     0m4.600s
<lifeless> latest figures
<igc> wow!
<lifeless> softly softly catchee monkee
* fullermd had never considered using bzr for such a task.
<fullermd> lifeless: Do I recall correctly that since/aside from that adding-fields-to-index change, the pack disk format has been stable?
<lifeless> fullermd: yes. planned future changes are annotation d isabling (which is where those figures come from) and a new index layer
* keir waves :)
<lifeless> :)
<keir> i have unit tests, but they are not really hardcore grind-the-implementation-into-the-ground type tests
<keir> if i swap in my own graphindex code, are the existing tests pretty good at puking when there's a data format error?
<beuno> lifeless, fullermd, I'm starting to translate bzr's documentation to spanish for internal use in my company, are you considering including other languages for docs?   Because if you are, I'll just translate it all, and probably in a more formal way
<lifeless> beuno: yes we are
<lifeless> keir: the current tests are two-layered; physical layer, and logical layer
<beuno> lifeless, great, so I should create an "es" dir under docs, add em' and send for merging?
<lifeless> yes please
<beuno> lifeless, perfect, will be sending the first bit in a few days then, thanks  :D
<lifeless> keir: I suggset you look at the first class in the test_index.py file, which covers teh physical layer, and transcribe those tests to your physical layer (where they make sense) as well as considering outher things that could go wrong in your index
<lifeless> keir: the logical layer tests test the overall behaviour and *may* be sufficient for you; but do have a look/think about the ways it could go wrong
<igc> that sounds wonderful beuno - can't wait!
<beuno> igc, :D    I didn't know translations where welcome already, I'll try and poke other translators and see if we can get other languages in too
<igc> cool
<igc> beuno, the tree is setup to accommodate multiple languages for all the main documentation set
<igc> each language should have it's own index ...
<igc> for docs not translated, point back to the English ones I think
<beuno> igc, yeah, it certainly looked that way, but I think I recall someone saying that it wasn't the time yet
<beuno> could of been six months ago though  :p
<igc> it depends on the maturity of the various docs ...
<igc> the main one still needing work is the User Guide ...
<igc> which unfortunately is the one most people would want translated :-(
<igc> so doing the User Reference first (for example) may be better?
<beuno> yes, I'm planning to get some work done on the english ones too, but after looking at it, I'm not sure I enough understanding of bzr to do such a thing
<igc> the Mini Tutorial and Quick Summary are ready to translate as well
<beuno> I already have some parts of the user-guide translated, mainly the conflicts and configuration, the ones people have requested most in here
<igc> that's great
<igc> I'm not saying don't translate the User Guide stuff ...
<igc> I'm saying expect some churn there in coming months
<beuno> the index for other languages would be index.XX.txt, right?
<igc> or XX/index.txt might work as well
<igc> poolie might have an opinion on that
<beuno> igc, understood, it will be easier to edit the parts that have changed then to start from scratch, so I think most of the work won't be thrown away
<igc> yes - agreed
<beuno> alright, I'm going out on my daily run, I'll read the backlog when I come back  :D
<igc> the issue with the User Guide isn't extra content, it's lack therefof
<BasicOSX> major major mistake in a file, haven't committed it, how can I got back to the committed version?
<radix> bzr revert
<radix> bzr revert <filename> to only revert the particular file.
<spiv> lifeless: have you seen http://glyf.livejournal.com/72505.html ?
<lifeless> spiv: I hadn't, but it lookslike he gets it
* spiv nods
<lifeless> igc:
<lifeless> real    1m35.311s
<lifeless> user    1m28.602s
<lifeless> sys     0m4.600s
<lifeless> 16 seconds to go
<igc> sweet - let me know later today when you've pushed the branch and I'll test here
<igc> lifeless: your merges are spamming the ML btw
<igc> I've got one 4 or 5 times now
<lifeless> es
<lifeless> actually you have had pairs
<lifeless> new, last
<lifeless> several times
<lifeless> its a bug in bzr send
<igc> I saw that
<fullermd> I see at least one fourple.  Dup from your mail server, hop out to internode is getting new ones.
<igc> if I review tuned_gzip.bytes_to_gzip, will you stop emailing it to me :-)
<lifeless> fullermd: bleh evo suckification
<lifeless> igc: as I'm not the one sending it I make no assertions
<Odd_Bloke> Heh.
* fullermd builds a totem of lifeless's server in an attempt to appease it.
<lifeless> even lsprof runs are under 2m now
<igc> lifeless: I'm curious about incremental commit ...
<igc> your branch had a bug where shas were always coming back as ''
<lifeless> I don't see much point moving onto incremental until initial is sorted
<lifeless> yes thats right
<lifeless> its pushed
<igc> once that's fixed, many of the wins you're making will improve both
<lifeless> feel free to fix that :)
<igc> I'd love to  - I'm reviewing abentley's reconfigure stuff right now though
<lifeless> k
* igc food
<lifeless> poolie: I have a trivial patch to rearrange where CommitBuilder is that would be useful to merge to reduce conflicts
<abentley> lifeless: around now.
<lifeless> abentley: I have forgotten what it was about; I've probably handled it in a patch I sent in anyhow
<abentley> Okay.
<abentley> BTW, were you saying there's a bug in bzr send?
<lifeless> yah, its in lp
<lifeless> evolution specific AFAICT
<abentley> Are you using the direct evo implementation or xdg-email?
<lifeless> how do I tell
<abentley> Do you have "mail_client" set to "evolution" in bazaar.conf?
<lifeless> I haven't put any setting in
<abentley> Then it must be using xdg-email.
<abentley> You could try setting mail_client, to see if that works any better.
<lifeless> ok, just mail_client=evolution ?
<abentley> Yeah.
<abentley> Or mail_client=editor if you want to go old-skool ;-)
<lifeless> meep
<lifeless> no I want evo so it goes to my imap folder
<lifeless> hurry up and wait time :)
<lifeless> poolie: I'm wrapping up shortly, do you want another call ?
<lifeless> hah!
<lifeless> another second bytes the dust
<lifeless> real    1m39.626s
<lifeless> user    1m27.449s
<lifeless> sys     0m4.528s
<lifeless> spiv: please pass that onto poolie
<lifeless> and with that, I'm out for the weekend. Damn early start:)
<spiv> lifeless: done
<spiv> <poolie> cool
<igc> well done lifeless - enjoy the weekend
<Stevage> hi all
<poolie> Stevage: hi
<poolie> spiv: hi
<Stevage> can anyone help with the traceback I just sent to the list?
<poolie> spiv, it was pretty blustery but seems to have blown over
<poolie> Stevage, i'll look
<Stevage> it's this one: TypeError: sequence item 1: expected string, NoneType found
<Stevage> also, is it normal that when I do a commit after some local commits, it first attempts to delete all the files I've added?
<spiv> poolie: it rained pretty hard here, but only for a few minutes.
<Stevage> ie, add a file. commit --local. then update. immediately it deletes the file I added, then fails with that traceback.
<Stevage> (should have said, "when I do an update" rather than a commit...)
<poolie> Stevage: ok, i see the traceback, i'm looking at the corresponding code
<Stevage> thanks
<Stevage> there's nothing weird in my sequnce of actions is there?
<Stevage> init, checkout, add, commit --local, update (in original directory)
<poolie> steveage, those commands look ok
* Stevage nods
<poolie> ok, so for anyone else who might be looking at it, the error happens because the dirstate thinks its first parent is None
<poolie> ah
<poolie> Stevage: are there any commits in the branch that you're bound to?
<Stevage> no, that .bzr.log is complete
<Stevage> it starts from a clean slate
<poolie> right
<poolie> ok, i bet the bug is today with trying to update to the null revision
<poolie> s/today/todo
<poolie> s//to do
<Stevage> so should I try adding and committing a file prior to all this?
<poolie> just let me see if that's correct...
<poolie> bang
<poolie> that's it
<poolie> Stevage: well, how about if you just commit the files, rather than committing --local?
<Stevage> well, I do actually want it to do it this way eventually
<Stevage> because I want the grouped commits
<poolie> oh, you're using this to represent changesets that come from tlib?
<Stevage> as in, I want to commit each file once, then commit a group of files
<Stevage> yep
<Stevage> if I only commit at the higher level, I won't have as much precise information on each individual file, like the revision number it represented in TLIB
<Stevage> though I could always fake that if necessary
<poolie> i think making one commit on the main branch before you start committing locally will avoid the problem
<poolie> even if it's just
<poolie> bzr commit --unchanged -m 'nothing'
<Stevage> yeah trying that now
<Stevage> is that really odd doing a checkout from an empty branch?
<Stevage> yep that worked!
<poolie> i don't think getting the checkout is odd, but doing an update from it is...
<poolie> well, it's a reasonable thing to do, but
<Stevage> well bzr won't let me commit until I've done the update
<poolie> i guess it just wasn't tested
<poolie> really?
<Stevage> yeah
<Stevage> it says I'm out of date
<Stevage> which is kind of bizarre by itself
<poolie> that is
<poolie> Stevage: ok, that's the best workaround for now then i guess
<poolie> i'll file bugs about the two aspects of it
<Stevage> great thanks
<Stevage> that solves my problem anyway
<poolie> oh it looks like this is already known, bug 120968, reported by spiv
<ubotu> Launchpad bug 120968 in bzr ""bzr update" in checkout of empty branch tracebacks" [Medium,In progress]  https://launchpad.net/bugs/120968
<Stevage> heh, when I click on "bug 120968" it goes to bugzilla's bugzilla
<Stevage> or rather, mozilla's bugzilla
<poolie> hm, well, click the one ubotu said
<Stevage> yeah
<Stevage> hard to fix do you think?
<poolie> Stevage: wouter may be online later, he currently has this bug assigned
<poolie> no, i think it should be fairly straightforward
<mdke> is there no way to commit just changes to a particular directory in the tree? bzr seems to be forcing me to commit all changes in the working copy
<poolie> mdke, you can, except not after a merge
<mdke> argh
<mdke> poolie: is that going to be fixed? the merge and my working copy changes were completely separate in this case, it would have been nice to commit them together
<mdke> i mean, not to
<mdke> ah, I can still get a diff, that's ok
<poolie> it's better to commit in your wc before you merge
<mdke> poolie: in this case I did a merge yesterday, encountered a conflict, left it along because I didn't have time, then only remembered it when I had already made other changes to another part of the tree this morning and tried to commit them
<Stevage> anyone know how to get tortoisebzr going?
<Stevage> I'm getting "No module named win32com.server"
<spiv> Stevage: that suggests you haven't got the pywin32 package installed.  (http://sourceforge.net/project/showfiles.php?group_id=78018)
<Stevage> ok thanks
<poolie> Stevage: so it does work to get a checkout, then immediately commit
<poolie> you'd hope so
<Stevage> yep, even with a blank commit
<poolie> ok
<ubotu> New bug: #139549 in bzr "commit to empty master branch after local commits fails" [Undecided,New]  https://launchpad.net/bugs/139549
<igc> have a good weekend all
<NamNguyen> hi, how do i apply a merge-directive?
<dato> NamNguyen: `bzr merge ../path/to/merge_directive.diff`
<dato> NamNguyen: or you can try `bzr pull` first if you'd like
<NamNguyen> can it read from https?
<NamNguyen> ah, it can
<NamNguyen> awesome
<matkor> phanatic: Hi ! It would be easier here instead of exchanging emails
<phanatic> hey matkor, indeed :)
<matkor> phanatic: Should I comment out revision details code (I would like save it for my futher reference), or delete completly that source part ?
<matkor> I have not seen much commented out code in olive-gtk
<phanatic> commenting it out should be fine, as i've suggested in my last mail
<matkor> phanatic: OK, pushed
<Theuni> gnah
* Theuni sighs
<phanatic> matkor: thanks, i'll merge it as soon as it syncs to http :)
<Theuni> I'm not quite sure what I'm doing wrong, but I keep loosing my committed revisions because I loose track of branches ... bah.
<matkor> phanatic: Any idea how hunt those: "/home/users/matkor/.bazaar/plugins/gtk/checkout.py:148: PangoWarning: Invalid UTF-8 string passed to pango_layout_set_text()" ?
<phanatic> matkor: no idea, i don't get any warnings like this
<matkor> phanatic: 2) Do You also have menus: branch/ initialize get checkout  dimmed but allowed to select when out of working tree ?
<matkor> I have to start olive-gtk inside WT and than go up out of WT to see it ...
<phanatic> matkor: no, they work as expected for me...
<phanatic> they should be inactive in a working tree
<matkor> they are
<matkor> but pls check my scenario. Start olive-gtk in WT, go up out of it, are they working but dimmed ?
<phanatic> matkor: checked. started olive-gtk in a WT, went up one level (no WT), and they are working + not dimmed
<matkor> phanatic: Tnx, seems sth fuxored here, not much hurt to me though ;)
<phanatic> hehe :)
<matkor> phanatic: OK. I am leaving to my work - thanks for help (and TIA for merge ;) )
<matkor> c'ya
<phanatic> matkor: thanks for helping out, laters :)
<matkor> phanatic: Any idea how to work that case out: Unable to obtain lock ... locked 1 hour, 58 minutes ago Will continue to try until 11:32:15 in olive-gtk ?
<Lo-lan-do> Wait for two more minutes :-)
<matkor> Lo-lan-do: yeah...  gui users will be delighted with frozen app ;)
<phanatic> matkor: there is a wishlist bug filed by jelmer to implement some GUI stuff for breaking locks
<phanatic> but no progress on that i guess...
<matkor> phanatic: Does bzrlib calls return with info about held locks ? Or hold control and wait to next try ?
<phanatic> i guess (but i'm not sure) that bzrlib raises an exception if something is locked and cannot be accessed
<schierbeck> hi guys
<phanatic> hey schierbeck
<schierbeck> i'm making some fixes to bzr-gtk, but this is the first time i've used bzr for such a purpose, and i just want to know how to go about submitting my fixes
<schierbeck> i've registered a branch on launchpad, but should i let the devs merge from that branch or give them a bundle?
<phanatic> schierbeck: here's the workflow i'm using for bzr-gtk: 1) create your own branch of trunk 2) modify it locally 3) push it to lauchpad as your own branch 4) request merge
<phanatic> giving the pointer to the branch is enough
<schierbeck> phanatic: thanks, i'll do that
<scorpioxy> Hey guys. I have a question, i branched from a repo on Launchpad and i need to update the branch with the changes. Isn't the proper way to do that is via  a bzr pull?
<Lo-lan-do> Depends if you made local commits.
<Lo-lan-do> If you did, you need bzr merge.  If you didn't, bzr pull will work.
<scorpioxy> nope, nothing. I just want a copy of the development.
<scorpioxy> but bzr pull complains about a location
<scorpioxy> why doesn't it just use the branching location?
<Lo-lan-do> You can bzr pull --remember <location> once, and it'll reuse it later
<scorpioxy> Well, i did that and it threw a stack trace at me. The error was that the transport is read only. Let me try that again maybe i got the url wrong.
<scorpioxy> yup. I just checked
<dato> scorpioxy: did you do `bzr branch http://...` or `bzr checkout http://...` ?
<scorpioxy> oh by the way, it was a check out not a branch at the first operation
<dato> right. so you want `bzr update`, not `bzr pull`
<Lo-lan-do> Ah.  It should be bzr update then, I think.
<scorpioxy> ok, so a bzr update also throws the same error
<scorpioxy> transport is read only
<scorpioxy> Its for the awn project on launchpad, so nothing really strange here. So am i doing something wrong?
<beuno> is there anyway I can *just* push a working tree?    I would like to upload websites without having to double their space usage by having the repository online too
<fullermd> Well, I do it with make   :p
<dato> yeah, make & rsync here.
<beuno> so "not with bzr" would be my choice, right?
<dato> yes
<dato> gotta use the right tool for each thing
<fullermd> Considering there's no way to push a working tree period, I doubt there a way to push _just_ a WT...
<beuno> what do you use "make" for?  the rsync part I can understand...
<dato> to type 'make' instead of 'rsync --foo --bar --baz hihi haha:hoho'
<fullermd> Well, I don't use rsync.  95%+ of my deployals I have local access to, so I use install(1) wrapped with make.
<LeoNerd> 'make upload'  is the usual suggestion
<beuno> I have gone as far as saving which was the last revision I pushed, ran a bzr log -vv to find out which files had changed and uploaded those, but it seems like too many points of failuer
<fullermd> Recursive, with Makefiles at each level of the tree defining which files are to be installed and any special perms etc.
<beuno> s/failuer/failure
<fullermd> That's why I charge double-time for anything I have to talk to over ftp...
<beuno> anyone mind pasting my an example Makefile for that?
<LeoNerd> rsync is good enough to be able to cope with not pushing the same files again if they're not changed
<fullermd> Mine don't tend to be good examples.  They're pretty intricate, and rather specialized to my peculiar needs.
<beuno> fullermd, no worries, thanks, I'll bang my head at it for a while
<fullermd> Essentially, there's a Makefile.inc at the root with all the target defs to installing (and comparing my tree against the live location, to see what I'm about to do, etc), and each subdir has a Makefile that lists the files, the subdirs, any special adjustments that dir needs, and the like.
<fullermd> Then an 'install' type target installs all the files, and recurses into the subdirs.
<beuno> fullermd, sounds like a lot to explain to a web gfx designer, I need something that requieres *no* interaction on their part
<beuno> just click a nice button on the web interface which uploads what they've pushed to the repo
<keir> is it possible to 'generate' test cases?
<fullermd> Just toss 'em an neon-colored iPod once in a while, that'll keep 'em happy.
* fullermd gives more snark for your buck.
<fullermd> You could just make the button fire off 'make install'.
<keir> aka, i want to run one test case for a bunch of different index block sizes; but they're really seperate tests. i'd rather have the test suite report the particular failing, rather than the whole test
<keir> py.test and nose have something for this, but i'm not sure if unittest does
<beuno> hahaha, instead of reproducing mp3, the ipods can read em the "make" manual
<beuno> fullermd, the thing is, if they add a new file/dir, they will have to touch makefiles, eeeewwwwwwww
<dato> beuno: is the structure of the tree in the repo equal to the structure in the web?
<beuno> dato, yeap, I just need to exclude some files/dirs automagically
<dato> then I'd recommend rsync
<dato> with --recursive and --exclude, it should do what you want, but try it with care to make sure it really does
<beuno> dato, sounds like the right tool, for some reason I didn't think of it, I was convinced I could/should do it with bzr
<beuno> dato, thanks  :D
<dato> sure :)
* dato leaves now
<corporate_cookie> is there an RPM for bzr-90 ?
<Radtoo> looks like fedora provides the rpm, not bazaar-vcs.org...
<Radtoo> You should look into your dists repository, I guess
<corporate_cookie> ... i've been trying to build on ... but i'm running into some problems with bzrlib/_dirstate_helpers_c.c
<corporate_cookie> some deep seeded gcc magic which I do not understand  : )
(keir/#bzr) lifeless: when you're up, if you have a minute, i'd like to to take a gander at the CompactDictionary code. it's all working. i'm currently implementing GraphIndex.
(beuno/#bzr) asac, I don't like that either, causes me all kinds of headaches
<asac> yeah
<asac> i accidentially now committed and publised a .moved file
<asac> thats stupid
<beuno> asac, yes, and the fun thing is when some random person keeps on pushing & updating until you have 17 .moved.moved.moved.moved.....
* beuno hates his gfx designers
<asac> ;)
<fullermd> It doesn't add the .moved file.  It just moves it.
<beuno> fullermd, the first time, then it starts creating .moved.moved.moved.moved.moved
<beuno> it's fun when someone calls me "bzr did something weird"
<fullermd> Only if you had more conflicts.
<beuno> fullermd, they just keep on pushing until they decide it's enough
<beuno> so resolving all that tends to be fun :D
<fullermd> And it never adds, it just moves.  Path conflicts aren't created just for fun, they're created because you have conflicts   :p
<beuno> right, I'll try and get together a few reproducible steps to show you how to end up with 46 .moved.moved files  :D
<siretart> jelmer: any idea whats going wrong here? http://paste.debian.net/37140
<siretart> jelmer: ignore me
<ubotu> New bug: #139688 in bzr "BzrDirFormat.__str__ assumes last character of format_string is \n" [Undecided,New]  https://launchpad.net/bugs/139688
<ubotu> New bug: #139691 in bzr "converter relies on control dir being named '.bzr'" [Undecided,New]  https://launchpad.net/bugs/139691
<GreenDad> I want to use bzr in a large organization. My main bottleneck is the ticket-management program. Have you had experience in deploying bzr in a large organization?
<jelmer> siretart, ok :-)
<jelmer> GreenDad, not sure I understand your question. Where is the size of the organization important?
<GreenDad> Perhaps I should rephrase.
<jelmer> Or do you mean large history, etc?
<GreenDad> The size is not relevant, but its management style. They're basically looking for something equivalent to ClearQuest for process-control.
<GreenDad> The only alternative is trac, and I have the feeling it's not ready for primetime.
<jelmer> GreenDad: you're looking for ticket-management systems that integrate well with bzr?
<jelmer> *integrates
<GreenDad> jelmer, Yup.
<nDuff> GreenDad: My employer (100<employee_count<200) is using trac, though not in conjunction with bzr. that said, for tight process control I'd expect that a PQM and some glue would be necessary.
<jelmer> Greendad: trac is the only I'm aware of that has bzr support, but it's not really used for process control.
<nDuff> GreenDad: do you just want to prevent merges without a valid / signed-off ticket# attached, or stronger requirements (like folks locking files before they're allowed to change them)?
<jelmer> GreenDad, launchpad also integrates with bzr, but I'm not sure whether it supports non-public projects
<GreenDad> nDuff, Nah. File locking is just annoying. I'm looking for a ticket-management system, like trac, only not trac. :)
<GreenDad> We use a human PQM.
<GreenDad> That is, all changes must go through the reviewr, and he performs the merge himself with the mainline branch.
<nDuff> GreenDad: I'd urge you to rethink the "only not trac", at least as long as the bzr integration tests out as being usable.
<nDuff> GreenDad: trac is quite stable, and with the next release out (w/ its workflow customization features) will have just about every major feature on our wishlist.
<GreenDad> nDuff, A missing major feature is the ability to customize your own ticket fields.
<GreenDad> But I can implement that myself
<nDuff> GreenDad: that's there.
<nDuff> GreenDad: you don't need to implement it yourself, it's there in the current released version
<GreenDad> Oh?
<GreenDad> Cool.
<GreenDad> BTW, has anyone used StarTeam?
<GreenDad> (It's currently the main competition for bzr at my organization)
<nDuff> GreenDad: not used it personally, but I've heard things about it. Run, run, run run-away type things.
<GreenDad> Anything more concrete?
<GreenDad> nDuff, It looks bad, judging from its feature list.
<GreenDad> You can tell a tool is bad when it implements a gazillion unrelated features in a single package.
<nDuff> GreenDad: not personally, but I might be able to find contact information for someone who could do that. We're not really on speaking terms, but he might answer questions from completely unknown strangers emailing him. :)
<nDuff> (the last SCM guy we had on staff came from a company using StarTeam)
<fullermd> Or when it comes from Borland   ;>
<GreenDad> Oh. We use StarTeam as well, just not at my department.
<hstuart> or Microsoft. Team systems is a royal pain.
<GreenDad> We're 800+ people, out of which 200 are developers, using ClearCase.
<mneptok> GForge?
<mneptok> yes, it's ugly. but at least it's not a Borland or MS product.
<mneptok> which means when it sucks, it's at least somewhat unexpected.
<GreenDad> I think I'll shower.
<GreenDad> Later.
<GreenDad> Thanks.
<mneptok> discussing Borland products makes me feel dirty, too.
#bzr 2007-09-15
<synic> failed to open trace file: [Errno 13]  Permission denied: '/root/.bzr.log'
<synic> I get that when trying to perform most operations
<synic> I assume it's a common error?
<jelmer> synic: nope - are you running bzr as root?
<synic> no
<synic> never have.
<synic> it just started happening, on all my machines
<jelmer> since when ? upgrade to a new version of bzr?
<synic> I haven't upgraded anything, unless a security release broke it
<fullermd> Sounds more like it's running as a non-root user, who has /root as $HOME.
<jelmer> I suspect something else has changed in your environment.. does "printenv | grep /root" print anything?
<synic> no, nothing
<ubotu> New bug: #139722 in bzr "Bzr not installed into path via windows installer" [Undecided,New]  https://launchpad.net/bugs/139722
<spiv> Anyway here have a live.gnome.org wiki login already?  http://live.gnome.org/BzrForGnomeDevelopers says "bzr 0.9" when it means "bzr 0.90".
<fullermd> I dunno.  I'd like to see somebody using bzr 0.9 and bzr-svn 0.4.2...   it just takes a little hacking.
<jelmer> spiv: I've got one, will fix it
<spiv> jelmer: thanks!
<spiv> (I have more than enough accounts on random wikis and things already...)
<jelmer> :-)
* mneptok arrives 3 minutes too late
<sri> so.. how is performance these days.. can we compete against git?  just curious
<sri> and btw hi, long time no see.
<D-Pain> performance is a lot better IMO for day to day usage...
<D-Pain> stuff like status, diff, ci are a lot more acceptable
<D-Pain> but networking speed still needs work IMO
<Peng> Commit is "a lot more acceptable"? Is it better than it was a month ago?
<Peng> Say, ten times better?
<spiv> Peng: talk to lifeless when he's around
<spiv> Peng: he's been making some massive improvements to commit, although most of that won't be seen until the 0.92 release in about a month.
<Peng> A couple months ago, I had 3-minute commits for my homedir. I converted it to hg and now they're 15 or 20 seconds.
<Peng> Commit improvements and the C patiencediff should help.
<Peng> (bzr diff took 30 seconds)
<Peng> (on one file)
<Peng> 4.5 seconds or so with hg diff.
<AfC> I bet it's using the short cut of only diffing if it sees the mtimes are different.
<Peng> The mtimes are different.
<Peng> Anyway, it's one file.
<Peng> What do you mean?
<Peng> When committing?
<Peng> Hg only checks files with different mtimes, while bzr checks everything?
<AfC> I believe so
<Peng> Either way, 4.5 seconds vs. 30 seconds for diff isn't because of that.
<AfC> This being the more correct behaviour - you can't really trust mtimes.
<Peng> Right
<Peng> .
<AfC> Peng: (but many systems do)
<Peng> Hg uses a regular old sucky diff algorithm. :(
<AfC> Peng: (and I'm talking about more than just VCS here)
<AfC> Peng: there's that too.
<Peng> Diff algorithms don't matter when committing, though, unless you use --show-diff or whatever
<Peng> .
<AfC> I am generally convinced that Bazaar performs more "correctly" than most of the other systems, but the nature of competition is that it's hard to establish this and justify it.
<Peng> I know. I love Bazaar. It's great.
<Peng> Except it's extremely slow.
<AfC> Peng: that's down from glacially slow, though :)
<Peng> In fact, I've run into a couple integrity issues with hg that I didn't experience with bzr. But 3 minute commits are just too much.
<Peng> Also, bzr doesn't support copying files.
<AfC> [copying?] 
<Peng> As in cp?
<Peng> On the other hand, bzr has just abotu perfect rename support.
<Peng> about*
<AfC> Peng: still not quite sure what you're needing there
<Peng> AfC: What do you mean?
<AfC> COPYING
<Peng> What about it?
<AfC> {sigh} What about copying files are you trying to achieve, and how is Bazaar supposed to somehow contribute to this?
<Peng> Sometimes I want to copy a file. Bazaar can't do it.
<Peng> If I want to 'cp fileA fileB', I can't do it and preserve history in Bazaar.
<Peng> Hmm. I'm not sure how much history is preserved across copies in other VCSes, or how much it should be.
* Peng wanders off.
<schierbeck> any bzr-gtk people in here?
<schierbeck> hi guys
<schierbeck> do you know if there's a recent build of bzr for win64?
<ubotu> New bug: #139803 in bzr "Bazaar does not run on 64-bit Windows systems" [Undecided,New]  https://launchpad.net/bugs/139803
<ubotu> New bug: #139824 in bzr "`bzr co .` in branch with WT gives error FileExists" [Undecided,New]  https://launchpad.net/bugs/139824
#bzr 2007-09-16
<Peng> It could be useful if you and the other Python VCS people (Mercurial, Codeville, ???) got together to create a "vcsutil" or something package, with stuff like patiencediff and lazy_import and hg's C diffing and patching and whatnot, and Codeville's merging algorithm...
<Odd_Bloke> Peng: Why?  Everyone's going to be using bzr soon enough. ;)
<Peng> Heh.
<Peng> Well, it would still be nice to help out those crazy Mercurial guys, then. ;)
<Odd_Bloke> :D
<Peng> Is Codeville's merge algorithm easily portable to other VCSes?
<jelmer> Codeville, is that Bram Cohens' VCS?
<Peng> Yeah.
<Peng> I don't think it has much momentum, but it has a cool merging algorithm.
<jelmer> Peng: See http://bramcohen.livejournal.com/37690.html
<Peng> jelmer: Yeah, I've read it.
<jelmer> Peng: Those implementations all make different assumptions about inputs / outputs
<jelmer> some are line-based, some binary, etc
<Peng> Aww.
<Peng> bzrlib.lazy_import would be good, though.
<Peng> mercurial.demandload is kind of yucky. It catches all imports, not just ones passed to it.
<Peng> That does make it easier, though.
<jelmer> Yeah, some things could definitely be shared, indeed
<jelmer> I guess lazy_import would even be useful for non-vcs python apps
<Peng> Yeah.
<ubotu> New bug: #139863 in bzr-dbus "" [Undecided,New]  https://launchpad.net/bugs/139863
<matkor> Hi !
<matkor> Does revision: <Revision id foo@bzr-123-xxxx> should have get_apparent_author() method ?
<matkor> For me annotate fails becouse of that
<matkor> I see such members: 'committer', 'get_history', 'get_summary', 'inventory_sha1', 'message', 'parent_ids', 'parent_sha1s', 'properties', 'revision_id', 'timestamp', 'timezone
<matkor> But docs say sth completly different: http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.revision.Revision.html#get_apparent_author
<dato> jelmer: do you want a bzr-svn upload?
<matkor> jelmer: Could you please merge few more fixes fro bzr-gtk from https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? Please take look at gannotate fix becouse I am not sure if it is proper. It makes gannotate work though... TIA
<seanhodges_> hey does anyone know how to add bookmarks in the Olive GUI?
<seanhodges_> I'm running the latest released bzr (0.90.0)
<pygi> seanhodges_, phanatic is your folk
<pygi> he's the olive's author
<phanatic> morning people
<pygi> phanatic, :
<pygi> <seanhodges_> hey does anyone know how to add bookmarks in the Olive GUI?
<pygi> <seanhodges_> I'm running the latest released bzr (0.90.0)
<seanhodges_> hey sorry just got back
<phanatic> seanhodges_: the problem is that you can add bookmarks by right clicking in the file list, and right mouse click doesn't seem to work in 0.90.0 for some reason :(
<seanhodges_> ah ok, i thought i was going mad ;)
<phanatic> seanhodges_: try trunk, it shoudl work
<phanatic> *should*
<seanhodges_> i was about to ask that
<seanhodges_> cool, i'll try it out and get back 2 u
<phanatic> great :)
<seanhodges_> i'm a little confused about the whole bzr-gtk thing tho, do i want to check out and compile all of bzr-gtk? or can i take the Olive code and compile it against bzr 0.90.0 release?
<phanatic> seanhodges_: they are bundled together, so the best would be to get all of bzr-gtk
<seanhodges_> no problem, i'll do that
<seanhodges_> thanks
<phanatic> yw, i hope it helps
<phanatic> pygi: thanks for pinging me :)
<pygi> phanatic, you are welcome
<seanhodges_> yeah thanks pygi - was definitely helpful
<jelmer> dato: Yes, please :-)
<seanhodges_> phanatic, the latest in trunk works great. Just one thing: it wouldnt work until i modified /__init__.py so the version_info said "0.90.0" instead of "0.91.0"
<seanhodges_> I renamed my olive.conf but must have missed some other config files for bzr-gtk?
<phanatic> seanhodges_: that's the only one... and the version incompatibility check just sucks, but we have to use it to avoid unexpected behaviour
<seanhodges_> thats ok, i'll just modify it if/when i update again
<seanhodges_> seems to be working fine now tho, thanks for your help
<dato> jelmer: do you have an opinion on 442171?
<jelmer> bug 442171 ?
<jelmer> or debian bug 442171?
<ubotu> Debian bug 442171 in bzr-svn "bzr-svn: please use "Depends: python-pysqlite2 | python (>= 2.5)" instead of "Recommends: python-pysqlite2"" [Wishlist,Open]  http://bugs.debian.org/442171
<dato> yeah, that
<jelmer> dato: Think that'd be a good idea
<jelmer> Assuming python-pysqlite2 depends on python :-)
<dato> er, sure it does
<dato> python (<< 2.6), python (>= 2.4)
<dato> so it should be fine
<dato> jelmer: I'm going to have lunch. will change it and upload when I come back, feel free to change it yourself in the meantime.
<jelmer> dato: fixed
<sandrot> any ideas on how to push via sftp to a different port number
<jelmer> sftp://host:port/... doesn't work?
<sandrot> think the colon specifies the remote directory...
<jelmer> no, that's only in scp location specifiers
<sandrot> so then, sftp://me@host/directory:port
<jelmer> the port should be after the host, like sftp://me@host:port/directory
<sandrot> worked like a charm, thanks!
<dato> jelmer: you kept python-pysqlite2 unconditionally in build-depends(indep)
<dato> jelmer: I'd apply http://rafb.net/p/aPgodP42.html
<jelmer> dato: looks good
<jelmer> should I apply that patch or will you do so before upload?
<dato> jelmer: I'll do it
<Jamon> What are the options for bzr web interfaces?
<Jamon> and are there specs for figuring out how to build one from scratch?
<keir> Jamon, check out loggerhead
<keir> Jamon, see the plugins page
<Jamon> There is "webserve" on the plugins page.
<Jamon> https://launchpad.net/loggerhead/
<Jamon> http://www.lag.net/loggerhead/
<jelmer> dato: thanks!
<dato> np
<Jamon> This is loggerhead in action... http://www.lag.net/branches/loggerhead/loggerhead_dev/
* Jamon waits for it to load
* Jamon waaaaiiits
<Jamon> sheesh, this will take all day
<matkor> jelmer: phanatic: Could you please merge few more fixes fro bzr-gtk from https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? Please take look at gannotate fix because I am not sure if it is proper. It makes gannotate work though... TIA
<jelmer> matkor: Thanks
<Jamon> "The proxy server received an invalid response from an upstream server. "
<Jamon> Does anyone have a loggerhead branch up for viewing?
<jelmer> Jamon, launchpad runs it
<jelmer> Jamon: Are you looking for an example of how it looks like or the source code?
<Jamon> How it looks
<Jamon> So I know if I want to use it
<dato> Jamon: http://codebrowse.launchpad.net/~mvo/apt/main
<Jamon> thnx
<dato> (for one example)
<abentley> seanhodges_: get_apparent_author was recently added to Bazaar.
<abentley> At the same time, I added it to gannotate.
<Jamon> Is it easy to change the style?
<abentley> Oops, should have been matkor
<Jamon> Is it easy to read this info from the .bzr dir? Ideally I'd like to make something like this using simple PHP functions.
<abentley> matkor: The Revision.get_apparent_author method was added to Bazaar recently, and I added it to gannotate at the same time.
<abentley> I respectfully suggest that you're running the wrong Bazaar version;.
<phanatic> yeah, latest bzr-gtk needs latest bzr.dev :)
<matkor> abentley: OK. You are right. I will revert that patch. Sorry for problem
<matkor> I think I have to stat using trunk versoin of bzr ....
<matkor> How you guys do that ? I bet you do not download snapshot, install it etc ?
<phanatic> matkor: you don't have to install bzr to use it
<matkor> But I have to build some modules, right ?
<phanatic> so you can have multiple instances, and use what you want (stable for system-wide stuff, bzr.dev for testing)
<matkor> How can I have trunk only for one user ?
<phanatic> use alias in your .bashrc
<Jamon> Is TracBzr any good?
<phanatic> Jamon: people are using it, and it works :)
<Jamon> I don't suppose you know of a live site using it?
<jelmer> Jamon: http://bugs.bitlbee.org/bitlbee/ does
<matkor> phanatic: I have link ~/.bazaar/plugins/gtk -> /home/users/matkor/src/bzr-gtk/trunk-matkor/ so how to make that versionn use bzr checkout somewhere in ~ ?
<phanatic> matkor: sorry, i can't help here, since i'm one of the lazy bastards who installs bzr.dev system-wide :)
<Jamon> jelmer: Thanks. Looks like it works enough for use.
<jelmer> matkor: I just have an alias set in my shell called bzr.dev:
<jelmer> bzr.dev='PYTHONPATH=/usr/local/lib/svn-python LD_LIBRARY_PATH=/usr/local/lib BZR_PLUGIN_PATH=/home/jelmer/.bazaar/dev-plugins $HOME/bzr/bzr.dev/bzr'
<jelmer> you wouldn't need the PYTHONPATH or LD_LIBRARY_PATH overrides
<matkor> phanatic: OK :) How you do that ? Checkout recent trunk to /usr/share/python2.4/site-packages/bzrlib ?
<matkor> jelmer: but will it make olive-gtk use those bzrlib ?
<jelmer> matkor: if that's what you're looking for, just run:
<jelmer> something like: PYTHONPATH=$HOME/bzr/bzr.dev ./olive-gtk
<matkor> jelmer: Yeah. That sound great thanks !
<Jamon> "The most up-to-date version of trac+bzr is Aaron Bentley's multi-branch version  (Bazaar Branch)" This link is empty btw
<Jamon> The most up-to-date version of trac+bzr is Aaron Bentley's multi-branch version  (Bazaar Branch)
<Jamon> http://panoramicfeedback.com/opensource/trac+bzr/
<abentley> It is a Bazaar branch.
* jelmer is still confused by the trac+bzr/trac-bzr stuff.. it's DVD-RW all over again
<Jamon> abentley: Oh so I have to use bzt to see it, ok thnx
<Jamon> bzr
<jelmer> Jamon: it's also packaged in debian and ubuntu
<Jamon> Hmm what's the package name for Ubuntu?
<jelmer> trac-bzr
<Jamon> Maybe it's not in dapper
<jelmer> gutsy is the first version in which it was present
<Jamon> Ok, this server is dapper.
<jelmer> In that case, the version of trac is also too old - trac-bzr needs at least 0.10
<Jamon> Oh
<Jamon> I just need a simple way for allowing the public to download the source for websites, and submit patches. I thought Bazaar looked better than Mercurial and DARCS, but is it best for what I need? I use PHP and just need a nice web interface.
<jelmer> jamon: It shouldn't be too hard to install a newer trac on dapper
<Jamon> http://trac.edgewall.org/wiki/TracOnUbuntu
<Jamon> Is it easier to upgrade to a diff ubuntu ver? :)
<jelmer> abentley: What do you think about supporting multiple projects in one bundlebuggy instance?
<jelmer> that would have some advantages (need to login only once, views with data from multiple projects, etc)
<jelmer> at the expense of code complexity
<matkor> OK. Is https://code.launchpad.net/~bzr/bzr/trunk version of bazaar which I should use to develop olive-gtk ?
<phanatic> matkor: yes
<matkor> Can one having branch with revisions r1,r2,r3  remove changes made by r2 ?
<Jamon> Why isn
<Jamon> Why isn't there something like launchpad for download?
<Jamon> Why does SCM seem so complex? How do most people do this?
<Jamon> Maybe giving everyone a SSH shell, and they put their branches their?
<Jamon> What is the standard simple method
<jdong> I usually just give ssh or sftp access
<pygi> ssh is better, faster
<pygi> sftp is a bit more secure and easier to setup (me thinks at least :P)
<matkor> Hmmm when I turned to trunk version of bzr olive-gtk seems to hang in busy loop when doing log ...
<pygi> phanatic, ^_^
<matkor> bzr log works at once ...
<phanatic> pygi: thanks, but no need to ping, i get notified about olive and bzr-gtk related stuff automatically ;)
<pygi> phanatic, shhhh! XD
<phanatic> matkor: it hangs for me for bzr.dev as well, but smaller trees seem to work (like bzr-gtk)
<Jamon> Do you guys also offer web features for your devs? Or just SSH/SFTP?
<matkor> phanatic: for me it hangs in my version of bzr-gtk :/
<phanatic> hmm :/
<matkor> How can I see diff of given revison ? Preferably as in olive-gtk ?
<phanatic> matkor: currently olive-gtk doesn't support diff between any two revisions (it's still on the todo list)
<abentley> jelmer: my first reaction is that it would be messy-- both codewise and for UI.
<matkor> phanatic: I was thinking about single revision view .. like  bzr diff -r -2..-1  but in that usuall diff window ...
<matkor> phanatic: Anyway when lp syncs pls review and apply simple push fix from https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor... TIA
<phanatic> matkor: i will do, thanks :)
<jelmer> abentley: Ok
<jelmer> abentley: Any chance we can have the bzr-gtk bundle buggy up on the main site somewhere? Or would you rather see it running on a different location?
<jelmer> It would be nice if you could host the bzr-gtk one, I don't have access to any potential hosts.
<abentley> Hmm.  We can try it, I guess.
<jelmer> how hard is it to migrate an installation?
<abentley> Not hard.
<jelmer> I can do the basic installation and run it on one of my hosts that's not on 24/7 for now
<abentley> Data is a single sqlite file.
<jelmer> ah, sweet
<jelmer> if it's becoming annoying for people that it's not available, we could talk about migrating
<abentley> Yeah.
<abentley> My server's a virtual machine, so it doesn't have tons of resources.  You may have noticed BB is slow from time to time.
<seanhodges_> abentley, thanks, i'll update and give it a try
<abentley> seanhodges_: cool.
<keir> i wonder if launchpad will ever get bundle buggy type functionality
<keir> i definitely prefer the workflow of just sending a mail via bzr send, rather than filing tickets
<jelmer> abentley: Ok, I'll do that then. Thanks
<abentley> keir: AIUI, launchpad has rich support for creating/updating bugs by mail.
<jelmer> abentley: Do you perhaps know what might be causing this error: http://145.97.196.157:8089/ ?
<jelmer> It still doesn't support attachments (with patches, etc) to such emails
<keir> abentley, but it doesn't show nice diffs for merge directives, does it?
<abentley> jelmer: I don't know the cause, but that indicates a problem loading a Kid template.
<abentley> I've seen that during development with other TG projects.
<abentley> keir: Sorry, I thought you were talking about the fact that BB was mail-controlled.
<keir> i have a question regarding debug prints. right now my code is littered with many extraneous prints; obviously those need to be removed. however, i've committed many times to my own branch.
<keir> if my code goes in (obviously cleaned), then those nasty print statements will still be in the history. is this a problem?
<abentley> No, it's not a problem.
<keir> ok
<abentley> If you're using Python, I'd recommend using "import pdb; pdb.set_trace()" instead of printing, though.
<keir> abentley, that would be true, if it was just one spot to check. however, i need to see a bunch of data at different points in the building / reading process
<keir> i do use pdb when i'm ready to poke at a particular point
<jelmer> abentley: it seems to complain about "<?python ?>" in the .kid files, which seems odd
<abentley> Which Kid is this?
<jelmer> there are also deprecation warnings from kid - what version of python-kid do you have?
<jelmer> ii  python-kid     0.9.6-1        simple Pythonic template language for XML ba
<abentley> 0.9.5
<abentley> I just upgraded to 0.9.6 and I get those deprecation warnings, but it works.
<jelmer> ok, thanks - I'll keep looking
<zbrown> How stable is the bzr+eclipse plugin?
<LaserJock> Husio: did you ask you question in here? I'm interested in your question as well
<Husio> my question?
<Husio> those from ubuntu-devel?
<LaserJock> yes
<Husio> actually, I've got answer
<Husio> but I've got also some error :)
<jdong> Husio: do you just want to undo the entire merge, or "zap out" the changes represented by it?
<Husio> yes
<Husio> I think so
<jdong> that's not a yes or no question.
<jdong> that's a pick first part or the second question :)
<LaserJock> I just wonder what you're supposed to do if say you have  a merge that changes 10 files and you only want the changes from 3
<Husio> ok, so I've just merger project and then afret diff I've realized that I don't want to commit it
<LaserJock> you commit it and then revert the 7 files you dont want?
<jdong> LaserJock: persoanlly I'd just revert the 7 files, then commit
<LaserJock> k
<Husio> hm, didn't think about commiting single files..
<LaserJock> but you still have to dig out the stuff you *don't* want rather than the stuff you *do* want
<jdong> true
<LaserJock> if you want most of it that makes sense
<LaserJock> but if you only want a little then it's not so fun
<Husio> it probably depend on the project
<jdong> well if you only want a little, it might be worth the time to cherrypick those revisions you do want....
<jdong> then merge the rest, and nullify that merge with a patch -R
<LaserJock> how do you do that?
<jdong> bzr merge -r a..b remote_branch
<jdong> and then once you're done doing that and committing, do a bzr merge remote_branch, then bzr diff | patch -R, then commit
<Husio> anyway, I've created some 1 file project made a few change+commit and then uncommit all the changes
<LaserJock> I'm trying to figure out how to merge common piecies of two unrelated branches
<Husio> bzr diff show all the changes but commit gives me en assert exception
<LaserJock> jdong: why would I want to merge after cherry-picking?
<jdong> LaserJock: if you intend to continue following that branch's changes, it's more convenient to merge and zap it out, so bzr doesn't continue bugging you about those revisions
<jdong> the cherry-picking workflow is pretty confusing/awkward though :)
<LaserJock> seems like that might lead to a lot of cruft
<LaserJock> seems like there should be a way to merge subdirs
<james_w> jelmer: http://bzr.debian.org/pkg-bazaar/bzr-builddeb/people/jdw/dev may be of interest
<jelmer> james_w, thanks, will check it out
<james_w> jelmer: I'm just writing the docs, but if you can't figure it out I can give you some hints.
<jdong> LaserJock: agreed, more forms of subset merging would be nice....
<LaserJock> can you have a branch within a branch?
<jelmer> james_w: Ok
<jdong> LaserJock: apparently with the new format yes
<ubotu> New bug: #139987 in bzr "bzr send should retrieve mail-to address from submit branch" [Undecided,New]  https://launchpad.net/bugs/139987
<jelmer> james_w: Works like a charm :-)
<james_w> jelmer: great. I just pushed the docs, so it's your fault if it goes wrong now :).
<james_w> jelmer: let me know if you are missing anything.
<zbrown> Anyone have thoughts on bzr clipse?
<jelmer> james_w: A wishlist thing that I mentioned earlier is support for $DEBIAN_VERSION in export-upstream-revision
<jelmer> james_w: so that I can set it to 'tag:bzr-svn-$DEBIAN_VERSION' for example
<jelmer> zbrown: Probably better to ask on the mailing list, none of the bzr-eclipse folks seem to be around
<james_w> jelmer: ah yes. ConfigObj has interpolation support, but I'm not sure whether it will do what we want. Let me check it out.
<james_w> jelmer: do you mean $UPSTREAM_VERSION? We can obviously support both.
<jelmer> james_w: Sorry, yes - that's what I meant
<jelmer> the upstream version derived from the version in debian/changelog
<james_w> jelmer: yeah, I think that could be useful in hooks as well.
<zbrown> jeoh ok
<zbrown> woops, jelmer
<zbrown> jelmer: Ya, I'm just curious because I like bzr better than svn, and we've been using Subclipse since it makes for easy management within Eclipse since most of our devs use that. Thanks
<zbrown> (I get to make the calls on things like that)
<james_w> jelmer: thanks for the [MERGE] .
<james_w> jelmer: the ConfigObj in bzr is quite out of date and only support %()s interpolation. I would prefer ${} I think, so I will propose updating it.
<jelmer> james_w: makes sense
<james_w> I would pull a copy in to builddeb, but I guess bzr can update for the next release, which is the earliest this would land in builddeb. Can you wait a little longer?
<jelmer> james_w: Yup, I'm using bzr.dev anyway
<schierbeck> are there any bzr-gtk guys in here?
<pygi> schierbeck, phanatic is your folk!
<phanatic> schierbeck: me :)
<pygi> phanatic, where do you collect so much people? :P
<pygi> are you breeding them? :D
<schierbeck> wohoo!
<schierbeck> i've just added some fixes to bzr-gtk, and have been asked to add an entry to the NEWS file
<phanatic> pygi: let it be my secret ;)
<phanatic> schierbeck: yeah, it was me :)
<schierbeck> having never done such a thing before, i'd like to know where to place it
<schierbeck> oh, hi phanatic :)
<schierbeck> should i put it in the newest section?
<phanatic> schierbeck: i guess this kind of change should go into the 'UI' section
<pygi> phanatic, evil!
<pygi> you can't say things like that to your mentor :p
<phanatic> schierbeck: yes
<schierbeck> phanatic: cool
<phanatic> pygi: :D
<schierbeck> i was thrown off by the date stamp
<schierbeck> :)
<schierbeck> i'll just do that and push it to lp
<phanatic> schierbeck: oh wait
<phanatic> i was wrong... didn't notice that we don't have an UNRELEASED entry in NEWS
<schierbeck> yup, that's what threw me off
<schierbeck> should i create one?
<phanatic> yes, please... it should say "0.91.0 UNRELEASED"
<phanatic> and just under that, start an UI section with the description of your change, your name and bug number (see other entries for a template)
<schierbeck> ok
<schierbeck> phanatic: it's pushed to lp :)
<phanatic> schierbeck: thanks, i'll merge it tomorrow and i'll also have a look at matkor's branch...
<Goshawk> hi
<schierbeck> phanatic: cool. i'm off to sleep then, bye!
<Goshawk> i've a problem, i did a branch of a repo and changed some things, now i wanna publish my changes upstream, but when i do bzr pull it says "No revisions to pull" and the upstream branch is not modificated
<Goshawk> what's wrong?
<Goshawk> i've committed and merged on my branch
<luks> I think you want 'bzr push' if you want to publish your changes, or am I misunderstanding something?
<matkor> Goshawk: There are no extra revision since you branched , so nothing to pull - thats seems OK
<matkor> If you want publish do "push"
<Goshawk> ok doing push
<Goshawk> This transport does not update the working tree of: ftp://bzr@vincenzo-ampolo.net/sites/
<Goshawk> and then many ftp temporary error 451
<Goshawk> Append/Restart not permitted, try again. Retrying.
<Goshawk> is it a problem related with the ftp?
<luks> yes, the ftp server doesn't support appending to files
<luks> does the server support sftp?
<Goshawk> no it's disabled but i can enable it
<luks> but that will not help you with the "This transport does not update the working tree of" issue, anyway
<luks> bzr will not update the working tree using any protocol
<Goshawk> i've changed the server configuration
<Goshawk> thanks for your help guys
<Goshawk> works :D
<Goshawk> This transport does not update the working tree of: ftp://bzr@vincenzo-ampolo.net/sites/
<Goshawk> what does it mean?
<luks> that is changed only the files inside .bzr
<luks> *it
<Goshawk> i'm pushing my changes... so why there changes are not propagated? (looking in the upstram branch for confirms)
<luks> only the branch is propagated, that is the revision data
<Goshawk> ah then i must do bzr update
<Goshawk> in the upstream branch
<luks> yes, you can run 'bzr up' on the server if you have ssh access to it
<Goshawk> cute... so there will be no unauthorized changes
<luks> there is a plugin that can do it using one command
<Goshawk> from client?
<luks> yes - https://launchpad.net/bzr-push-and-update/
<Goshawk> thanks
#bzr 2008-09-08
<lifeless> GaryvdM: the index layer does have a cache of its own, and the majority of the cost of traversing is disk io and parsing, yes.
<GaryvdM> Ok
<lifeless> GaryvdM: but with a big enough data set, the cache can be exhausted, which would lead to duplicate IO
<poolie> good morning
<GaryvdM> So should I send a patch?
<lifeless> GaryvdM: if you've written the code, sure - we can examine it
<GaryvdM> ok
<poolie> spiv, lifeless, call in a sec
<Spaz> ya but that's at the cost of higher latency
<Spaz> whops
<Spaz> *whoops
<Spaz> wrong channel
<mwhudson> Spaz: that would be an appropriate comment in here /quite/ a lot of the time :)
<Spaz> haha
<Spaz> mwhudson, it was related to OS dev
<Spaz> not sure you would be interested :p
<lifeless> poolie: sure, call is fine
<poolie> calling you...
<Macarse> hi, which is the best way to: If I delete a file, to get it back?
<poolie> Macarse, bzr revert FILENAME
<Macarse> poolie: thanx
<thumper> poolie, spiv: how is the work on the smart server working with stacked branches?
<spiv> thumper: poolie knows the most about that I think
<thumper> spiv: ok, thanks
<mwhudson> afaik the branch is approved
 * mwhudson pokes around in bb
<mwhudson> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480809050416r72b3f857h4a664a2cc4e157b0%40mail.gmail.com%3E
<poolie> thumper, not sure if you saw that
<poolie> my net connection seems to be flapping again...
<poolie> thumper, bug 261315 is in review, i'll merge it for 1.7
<ubottu> Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,Fix committed] https://launchpad.net/bugs/261315
<thumper> poolie: great
 * igc lunch
<BahamutZERO> Hello fellow Bzr users. I have a strange problem, and would need some assistance.
<BahamutZERO> I setup a shared repository with the 1.6.1-rich-root format.
<BahamutZERO> My partner created a local branch on his machine with just bzr init, and then pushed to that repository.
<BahamutZERO> Doing a bzr info on this remote branch (inside that shared repository) indicates the branch format is "unnamed"
<bob2> they're using 1.6?
<BahamutZERO> Trying to branch that remote branch on my machine then yields a ERROR: KnitPackRepository (url) is not compatible with RemoteRepository(url) error.
<BahamutZERO> Yes, they should be.
<BahamutZERO> They downloaded the latest Bzr for Windows binary.
<BahamutZERO> So, after that first failure, I bzr upgrade --format 1.6.1-rich-root inside the shared repository branch
<BahamutZERO> It seemed to succeed, and a bzr info on it now reports the format is 1.6.1-rich-root
<BahamutZERO> however, trying to branch from that yields the same error, with the addition of the error message "different rich-root support"
<bob2> you get that error when trying to branch using 1.6.1?
<BahamutZERO> correct
<spiv> Is there a shared repository locally?  Why are you using 1.6.1-rich-root?
<BahamutZERO> The shared repository is on my machine, so it is "local" in that sense
<BahamutZERO> I have no idea :p
<BahamutZERO> It seems it is required for bzr-svn support, but I am quite new at Bzr. Should I just leave it at the default format?
<spiv> THe "different rich-root support" message is saying that the local repository is in a format that's incompatible with the remote format.
<BahamutZERO> hum
<spiv> Ah, if you're using branches from bzr-svn, then yes you do need a format with rich-root support such as 1.6.1-rich-root.
<BahamutZERO> if there is no local repository, will the branch command create one?
<BahamutZERO> And if so, it would likely pick the default format
<BahamutZERO> leading to that error
<spiv> Right.  (Even a standalone branch has a repository, it just isn't shared with any other branches.)
<BahamutZERO> And my current situation is a pure Bzr scenario; in that case, which format is preferable?
<spiv> If you're not using any plugins, then the default format created by "bzr init" is fine.
<BahamutZERO> yeah, so I would have to bzr init --format... then branch from inside there, provide the --format to the branch command
<BahamutZERO> noted, thank you
<spiv> Choosing a non-default format is really a "you should understand why you are doing this" situation :)
<BahamutZERO> haha, or a RTFM :p
<vila> goood morning bazaar !
<lifeless> hola
<poolie> hello vila!
<poolie> lifeless, i finished your book, it was pretty good
<lifeless> cool
<vila> poolie: that's the second time you said so, now I'm curious :) What is this book about, what's the title ?
<poolie> "Leadership and Self Deception"
<lifeless> http://www.amazon.com/Leadership-Self-Deception-Getting-Out/dp/1576751740
<vila> thks :)
<poolie> i can give you a synopsis but i think robert is reluctant to disclose any spoilers
<poolie> the narrative form perhaps makes it a bit hard to express other than in examples but i think the key message is
<poolie> consistent with writers about mindfulness
<vila> hehe, just read the abstract and bookmarked it for later, if you both enjoyed it, it's quite enough reviews to try it :)
<poolie> that if you notice you're doing something unpleasant, (making yourself) feel bad, or frustrated with other people
<poolie> it may be a clue that you're twisting yourself up to justify something that's not actually true, or a decision you don't really believe in
<vila> 'doing something unpleasant" ? Because *you* feel that unpleasant or others feel that unpleasant ?
<poolie> well, either, but i had in mind
<poolie> the former
<vila> I see
<poolie> for instance, sometimes i keep working late on something in a bloody-minded way, without really enjoying it or necessarily being more productive
<poolie> if you asked me at this moment i'd say it's because i really want to fix this bug or whatever it is
<poolie> they suggest that if i thought about it more clearly, my motivation might really be to prove to myself that i work hard, or something like that
<poolie> lifeless, would you agree with that summary?
<vila> quality vs quantity, a life's work ;)
<lifeless> poolie: its an interesting take on it, its not the take I have
<lifeless> vila: I suggest grabbing it and reading it :)
 * vila stretch his arm across earth but fails to grab :D
<kwwii> so what does one do when bzr says that it is unable to obtain lock (for 65 hours, 53 minutes) and the bzr break-lock command doesn't work?
<spiv> kwwii: break-lock should work
<spiv> Does it give an error, or just silently fail to break the lock?
<kwwii> spiv: it says bzr ERROR: Unsupported protocol for url ...
<spiv> kwwii: ah, let me guess, this is on Launchpad?
<kwwii> spiv: yes :-)
<spiv> kwwii: Don't use the "lp-1234://..." URL with bzr break-lock, just use the regular URL you use to access the branch.
<spiv> e.g. "lp:foo" or "bzr+ssh://bazaar.launchpad.net/...".
<mwhudson> spiv: going to need a bzr dev's help to fix that bug :)
<spiv> The error message that suggests break-lock is a bit misleading, it's a known bug.
<spiv> mwhudson may even have the bug number handy ;)
<spiv> (The error message that suggests *the wrong URL* for break-lock, that is.  Suggesting break-lock is entirely appropriate.)
<mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/250451
<ubottu> Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [Undecided,Confirmed]
<kwwii> spiv: wonderful! that worked, thanks :-)
<kwwii> you made my morning
<spiv> Who needs search APIs when you have lp devs to find bugs for you? :)
<spiv> kwwii: glad I could help.
<mwhudson> spiv: i'm sure you know this, but the programmatic api for locks in bzr is *terrible*
<spiv> Yeah.
<spiv> "Patches welcomed."
<mwhudson> unfortunately it smells like an area which risks "patches argued about for weeks"
<spiv> That's why I didn't say "Patches accepted" ;)
<lifeless> meh
<lifeless> I don't think it would be argued over
<spiv> Actually, I don't think it's so terrible.
<AfC> Oh boy, I'm totally going to use that in my next big public keynote rant :)
<mwhudson> (also, no time, as usual)
<spiv> (But I wouldn't want reality to get in the way of a joke)
<AfC> spiv: (no fear :))
<lifeless> night everyone
<poolie> mwhudson, what kind of thing are you talking about with the lock api?
<mwhudson> poolie: breaking a lock requires installing a ui factory and using a specific lock id requires setting an environment variable are the ones i remember
<lifeless> mwhudson: environment variable?!
<mwhudson> lifeless: BZR_EMAIL iirc
<lifeless> lock ids should be random always
<mwhudson> well not lock id perhaps
<mwhudson> the <whoever> in "this branch was locked at 8:54pm by <whoever>"
<lifeless> oh sure
<poolie> biab
<markh> heh - 'bzr co -v' doesn't appear very verbose - it is still silent if the checkout succeeds.
<jml> if a working tree falls in the woods etc etc
<lifeless> jml: its a bear ?
 * jml could do with a beer
<jml> not sure what I'd do with a mute, narcoleptic forest bear though.
<jml> lifeless: want to talk about testresources?
<poolie> jml, want a quick call?
<jml> poolie: sure, why not.
<lifeless> jml: if we're quick, raid is at 6
<poolie> i prefer raid 1...
<lifeless> sunwell time :)
<lifeless> >>>>> raid 1
<jml> lifeless: poolie got me first. some other time.
<lifeless> hokay
<d3ko> Hi to all!
<d3ko> I don't know if this is the right place, but I have a very strange error using bazaar and I didn't found anything on google or forum....
<d3ko> This is the error:
<d3ko> darkstar:/opt/ezechiele# bzr check
<d3ko> Checking working tree at 'file:///opt/ezechiele/'.
<d3ko> bzr: ERROR: not well-formed (invalid token): line 10892, column 74
<d3ko> Any suggestion?
<poolie> d3ko: please file a bug on launchpad.net including the traceback from ~/.bzr.log, and post the number here?
<d3ko> ok, I do it asap and I post the number. Thank you very much.
<jonnydee> hi, I tried to use "bzr shell" on windows but invoking this command returns with "ERROR: No module named readline". I did some research and it turns out that the python installation for windows does not ship with such a library (http://pypi.python.org/pypi/readline/2.5.1): "[...]f you are using Windows, which also ships without GNU readline, you might want to consider using the pyreadline module instead, which is a readline replace
<Odd_Bloke> jonnydee: You got cut off at 'readline replace'.
<Odd_Bloke> But that sounds like something worth filing a bug for.
<Odd_Bloke> Assuming, of course, that one isn't already there.
<jonnydee> Odd_Bloke: what do you mean with "cut off at 'readline replace'"? Is it the python line in Bazaar which produces this error?
<mwhudson> jonnydee: each line in irc can only be so long
<mwhudson> jonnydee: so your long line got truncated
<jonnydee> ok, I see. So here is my complete text again:
<jonnydee> hi, I tried to use "bzr shell" on windows but invoking this command returns with "ERROR: No module named readline"
<jonnydee> I did some research and it turns out that the python installation for windows does not ship with such a library (http://pypi.python.org/pypi/readline/2.5.1)
<jonnydee> "[...]f you are using Windows, which also ships without GNU readline, you might want to consider using the pyreadline module
<jonnydee> instead, which is a readline replacement written in pure Python that interacts with the Windows clipboard."
<jonnydee> that's it :)
<Odd_Bloke> Right.
<Odd_Bloke> File a bug. :)
<jonnydee> ok, so I will look for a corresponding bug and file one if no one does exist
<jonnydee> thanks for your help :)
<d3ko> poolie: ok, I posted the bug. Bug number is 267670, link: https://bugs.launchpad.net/bzr/+bug/267670
<ubottu> Launchpad bug 267670 in bzr "bzr check and revert fails with "ERROR: not well-formed (invalid token)"" [Undecided,New]
<jonnydee> Odd_Bloke: I've posted the bug now: https://bugs.launchpad.net/bzr/+bug/267674
<ubottu> Launchpad bug 267674 in bzr "Invoking "bzr shell" on Windows returns "bzr: ERROR: No module named readline"" [Undecided,New]
<Odd_Bloke> markh: ^
<awilkins> Anyone know of a way of making urllib NOT use a proxy on windows?
<awilkins> jonnydee: You need to install pyreadline then it works.
<jonnydee> so pyreadline is compatible with gnu readline?
<awilkins> jonnydee: I can't recall, I did this a while ago
<jonnydee> ok, I will try it... thanks a lot for your help
<awilkins> http://ipython.scipy.org/moin/PyReadline/Intro
<awilkins> But possibly not windows...
<awilkins> Oh, wait, PyReadline is for Windows...
<jonnydee> hey, wow!! it works!!! :) :) :)
<jonnydee> So what should I do with the bug report?
<awilkins> Maybe put a comment on it suggesting that Windows users should install PyReadline?
<awilkins> (the error message could say this too)
<jakob> d3ko: what is in the directory in the non-working example??
<jonnydee> Maybe change it such that Bazaar should somehow tell windows users to download and install this library in order to mak the 'shell' command work
<jonnydee> ok
<jakob> d3ko: since the bzr add command gives no feedback, it seems that you're committing an empty branch, which shouldn't work to begin with
<jakob> d3ko: at least, I get  bzr: ERROR: no changes to commit. use --unchanged to commit anyhow
<d3ko> jakob: no, the add command works well and gives me complete output
<jakob> so what is the output??
<d3ko> jakob: in the log there is the complete output, I put the [...] because the project is quite big
<jakob> :P aah, went too fast :P
<d3ko> :)
<jakob> d3ko: could it have something to do with keymapper/priva.####OD#
<jakob> where the #'s are some strange characters that my browser can't print??
<d3ko> jakob: yes, maybe
<d3ko> i try to delete that file, is not fundamental
<spiv> d3ko, jakob: yes, I'd say that filename is likely to be the problem
<d3ko> jakob, spiv: YES! check now is working!
<d3ko> I try some change and then revert
<spiv> I don't think 0x08 in ASCII can be represented in XML files, and bzr uses XML for recording the inventory.
<awilkins> XML? Urrrgh.
<spiv> bzr ought to give a better error in this case, and give it sooner.
<awilkins> And use less XML!!!!
<jszakmeister> awilkins: +1!
<spiv> awilkins: yeah, there's a new inventory format that gets worked on from time to time.
<d3ko> spiv, jakob: yes, all seems working!
<spiv> If you ask on the list poolie or someone can probably post an update on where it's at.
<awilkins> I know that SVN went from XML wc metadata to K/V pairs and gained lots of performance
<d3ko> That was a spurious file, I think too that bzr ought give an error earlier
<d3ko> Thank you all!! So fast :)
<spiv> I think SVN used XML alot more heavily than bzr is using it.
<d3ko> Maybe file names should encoded in some way, like Base64?
<jszakmeister> spiv: yeah, it was littered all through-out the working copy.  It's still used between mod_dav and the client too.
<spiv> IIRC it's certainly visible in the profiles of certain operations, but perhaps surprisingly not as dominant as one's "yuck XML yuck" intuition might lead you to expect :)
<spiv> I haven't looked at that data recently, though.  I know it's something we plan to replace, it just hasn't got to the top of the list of things to do.
<jszakmeister> Oh, I believe you.  I just have a personal disgust for XML... seems to be everyone's hammer in the corporate environment. :-)
<poolie> night all
<spiv> jszakmeister: yeah.  Our working copy state is in mostly in a single binary file, rather than scattered in lots of little files all through the tree.
<d3ko> spiv, jszakmeister, jakob: what I have to do with bug report?
<d3ko> I can give the solution
<d3ko> Have i to do something else?
<spiv> d3ko: please do explain your workaround, i.e. that it was just that one file name that was the problem.
<d3ko> night, poolie! Here is 11:35 AM :)
<spiv> d3ko: that's all you need to do
<spiv> poolie: g'night
<jszakmeister> spiv: Which is a great idea. :-)  I've wanted to switch since SVK showed how keep it more central could be a boon.  But the WC code is more than I can take on right now.
<awilkins> Maybe we should do a protocl buffers version...
<awilkins> I've been meaning to experiment with proto for one of my own concerns - it's presently large, enterprisey, messages in XML
<awilkins> But I'm not sure the underlying technology deserves to have it's life prolonged by being given a good serialization
<awilkins> As far as I'm concerned, the more it sucks, the sooner we can move onto something better.
<awilkins> 
<d3ko> spiv: ok, I've added a comment with the explanation, I cannot change the status of the bug, maybe you can
<d3ko> I don't know if you are also developers, but... i love bazaar :) - great software!
<spiv> Lots of us here are (including me).
<spiv> So, thanks! :)
<spiv> d3ko: I've updated the bug status.  Thanks for the report.
<d3ko> Thanks to you all :) - for support and software. Hope this helps other people.
<speakman> hi! any bzr-trac devs inhere?
<d3ko> Now I have to go (I have to fix some bugs in my own software!). Bye!
<speakman> i've run into a strange bug and I don't know how to make a proper bug report with it.
<speakman> short: I can't see changesets in branches, but in trunk it's ok.
<jakob> does anyone have some experience with setting up authentication.conf files?
<jakob> i'm trying for http, but bzr doesn't seem to do anything with it
<spiv> vila: ^
 * spiv -> food
<Pilky> does anyone know what the state of the bzr-git plugin is?
<vila> jakob: what are you trying to do and what doesn't work ?
<Odd_Bloke> Pilky: Very much alpha still, IIUC.
<Odd_Bloke> jelmer would know more.
<Pilky> ok, thanks
<jakob> vila: from the manual I suspected that if I do eg bzr co http://jakob@host/bzr_repos I wouldn't have to type a password, if I have an authentication.conf file with user=jakob,password=pass
<vila> jakob: that's the idea yes
<jakob> well..... it doesn't work; maybe I need to set somewhere where my authentication.conf resides?
<vila> *what* doesn't work ? :) and authentication.conf is in ~/.bazaar directory
<jakob> aha, the command works, but I still have to type the password
<jakob> (actually.... twice)
<vila> that means bzr couldn't find the right section in your file, how does it look ?
<vila> !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)
<jakob> [bzr-repos]
<jakob> user=jakob
<jakob> password=
<jakob> where I left out the actual pass.... that's all; I removed all the other options, to make things default
<jakob> actually.... I found the answer already
<vila> And it is ?
<vila> I was about to advice using -Dauth so that the section used is shown, that helps debug the authentication.conf file
<jakob> well... I'm not sure yet what the precize answer is...
<jakob> I went on to try to let the name of the section in the auth file exactly match the name of the domain as set in the .htaccess file
<jakob> then i suddenly started working
<jakob> but now I changed things back and it still works :P
<vila> the name in the file is just a comment really
<vila> may be you didn't save your file ? (I hate me when I do that :)
<vila> Does using -Dauth shows you the relevant section name ?
<vila> try bzr info or bzr revno
<vila> with the right location added of course
<jakob> -Dauth doesn't give any extra info....
<vila> sorry, it's in the .bzr.log file
<vila> not on the screen
<jakob> both info and revno work like a charm
<jakob> (I tried them on the remote location; assuming that was what you meant)
<vila> every command should work the same, if revno works and not another, that's a bug
<vila> s/work the same/& regarding authentication :)/
<jakob> well, indeed the [bzr-repos] section is used
<jakob> weird... but what the hey.... things work as expected, so I'm happy now
<jakob> even though it remains a bit of a mystery what was going on previously
<vila> good, so your file is correct, be aware though, that your section is really a catch-all and will apply to all schemes
<jakob> I know.... now that things work again, I'll put in details :)
<vila> ok, let us know how it turns out :)
<jakob> ooh... one thing... can I use wildcards in the authentication.conf file
<jakob> like eg: host=www.*astro.rug.nl to allow catching www.astro.rug.nl as well as www.intra.astro.rug.nl?
<jakob> hmm... apparently not :(
<vila> jakob: hmm, no, but you can use .astro.rug.nl (note the leadind dot) to match the domain
<jakob> vila: aah.. thanks! works like a charm :)
<vila> happy to help ((c) jam)
<gnomefreak> how long should i wait for deletion of a branch? seems like everytime i push it goes to rev. 2 after deleting branch and im trying to make this rev 1
<gnomefreak> i trie --overwrite but still made it rev 2
<awilkins> gnomefreak: When you push, it pushes your local revisions ; if your local branch is at r2, a new branch you push will be at r2
<gnomefreak> ah thats right
<gnomefreak> thanks
<awilkins> gnomefreak: If you want it to be r1, make an empty branch and merge your r2 branch into ti
<gnomefreak> no r2 now that i think since i want upstream r1 and r2 for this comit
<awilkins> Or since it's pretty young, why not trash the .bzr folder and re-init/add/commit
<gnomefreak> commi
<jakob> vila: I see you're one of the main developers of the web-dav plugin?
<vila> yes
<jakob> vila: any idea what the following means:
<jakob> bzr: ERROR: http://www.intra.astro.rug.nl/%7Ejakobb/bzr_repos/repos1/.bzr/branch is permanently redirected to http://www.intra.astro.rug.nl/~jakobb/bzr_repos/repos1/.bzr/branch
<vila> apache2 humor
<jakob> that's what I was afraid of :/
<vila> you asked for 'blah blah', that's a directory, please use 'blah blah/'
<jakob> let me first ask if I use the plugin right: this is what I'm trying:
<jakob> bzr push http+webdav://jakob@www.intra.astro.rug.nl/~jakobb/bzr_repos/repos1/
<vila> if you control the apache2 server you can use 'DirectorySlash Off' to tell him, you're working not joking :)
<jakob> nope, I'm just a user.... that's the whole reason for going bzr
<jakob> I want my repos accessible over http, such that I can let others access them as well, but still have some control over who accesses them through .htaccess
<vila> it shouldn't error then, can you file a bug with the traceback and the relevant part of the log while running bzr push -Dhttp <etc>
<jakob> that's very much impossible with svn
<vila> file it against bzr-webdav, not bzr
<jakob> what error message should I get if the webserver is not webdav-enabled?
<jakob> another one?
<vila> errr, I don't remember exactly, certainly something like 501
<markh> awilkins: you still here?
<vila> but I don't understand why a redirected leads to an error, that's why I ask for the traceback and the log
<vila> s/redirected/redirection/
<jakob> I'll file a bug asap
<jakob> well.... as far as I can tell it's not even a redirection by the way :P
<vila> jakob: one thing you can try is to define a <Directory> section in your .htaccess (if your server allows it)
<jakob> it's just the ~ that is replaced with %7E
<vila> take a look at the NOTES file in the webdav plugin
<vila> hmm, where is that %7e coming from ? Did you type it or does it come from a remembered location ?
<jakob> no, it's something that bzr does all over the place
<fullermd> Seems to me that bzr URL-escapes ~ at the drop of a hat.
<awilkins> markh: Yes
<jakob> vila: what do the Alias /bzr /src/DAV precisely do? Do they need to be changed for my particular installation or is it some standard stuff?
<vila> fullermd, jakob : pedantically speaking '~' in an url should be escaped, that's what bzr does silently (mostly silently) . I'm still wondering why the http server can return an invalid url...
<vila> jakob: forget the alias, it's just a short cut, you don't need it in your case
<jakob> vila: before I actually didn't check the NOTES..... very bad, always RTFM :P
<vila> Well, the fine manual is not that good for that plugin :-) Patches welcome :)
<jakob> vila: but apparently the 'DAV on' is needed? that actually gives me back a 500
<jakob> I'll have to check with system management first I guess :/
<vila> DAV on is what *activates* dav, if the server doesn't support it... yes, you need to check with system management
<vila> but if you do, tell them to use DirectorySlash Off at the minimum, DavDepthInfinity on is also needed to support packs
<vila> jakob: rug == royal university groningen ?
<vila> ha, no, rijksuniversiteit groningen :) Should translate as above though...
<jakob> vila: well, actually we don't have much to do with the university
<jakob> the astro-domain is for astronomy and we have our seperate system
<jakob> linux instead of win***&@#$!#@
<vila> jakob: well, the question was more: *can* you get in touch easily the sys-admins to allow such modifications
<vila> jakob: you connection is noisy, strange chars at the end of your previous message
<jakob> and our own web-server....... which should support dav I was promised some time ago
<vila> apache2 ?
<jakob> vila: aaaah, yes sure, the're right accross the hall :)
<vila> :D
<jakob> but I'm figuring out some details about at least 2 other bugs right now.... sambaserver stuff :P
<vila> Check with them then, and if they are affraid about the DavDepthInfinity, try to find a place where you can store all bzr related stuff, bzr itself uses a depth of max 3 or 4
<jakob> vila: isn't there some nice PHP-function that checks for webdav??
<jakob> the guy that actually admins the webserver is not at the institute today :(
 * vila knows nothing about PHP (not even the meaning of the TLA :)
<jakob> oke... I'll find out....
<jakob> and let you know of course ;)
<vila> but looking at the headers returned by the server should tell you (for which you just have to look at .bzr.log after issuing a bzr command with -Dhttp :)
<vila> except if the server is hiding itself...
<jakob> in the last 2 years the system has been breached 3 times... so it just might do that
<jakob> vila: DAV/2 it says
<vila> full header is ?
<jakob> Server: Apache/2.0.52 (Red Hat) mod_ssl/2.0.52 OpenSSL/0.9.7a PHP/4.3.9 mod_python/3.1.3 Python/2.3.4 DAV/2 SVN/1.1.4
<vila> I don't understand the '500' then :-(
<fullermd> Probably means it doesn't allow fiddling with that setting in .htaccess.
<jakob> I just found a website that also has some tests on it... I'll work through them first: http://www.howtoforge.com/setting-up-webdav-with-apache2-on-debian-etch
<vila> fullermd: was wondering about that, but you know apache better than me :D
<fullermd> Oh, I dunno about that.  But I know how I've provoked 500's before   ;)
<vila> http://httpd.apache.org/docs/2.0/mod/mod_dav.html says 'Context:	directory' for the 'Dav on' directive. Does that forbids .htaccess ?
<fullermd> Not necessarily, but it's probably under Options (seems to be the catchall), and that isn't AllowOverride'd for him there.
<fullermd> (would be my guess, at any rate)
<fullermd> (which is to say; it's not an Apache limitation, so much as a that-Apache-config limit)
<vila> http://httpd.apache.org/docs/2.0/mod/core.html#directory says 'Context:	server config, virtual host'
<vila> I read that at forbidden in .htacess (which doesn't contradict your point)
<vila> On the other hand the Dav Directive example is inside a <Location> 8-/
<jakob> vila,fullermd: this cadaver-program says: 405 Method Not Allowed
<jakob> (that's without the DAV on, just to see that it's maybe automatically enabled)
<jakob> with the DAV on, I immediately get an 500
<vila> For what request ? (-Dhttp... )
<jakob> ooh, that's in another program, called cadaver
<jakob> that's apparently some sort of webdav-
<jakob> interface
<jakob> sort of ftp for http-connections
<uniscript> Is there a way to get bzr-svn to only pull the head revision but keep things in true local .bzr (with no need to reaccess the svn repo) and then to push changes back up?
<uniscript> i.e. without pulling the whole history
<vila> jakob: ok, but what are you trying to do ? 500 is 'internal server error' I doubt you can debug that without looking at server logs
<jakob> vila: that's the problem; server logs are not accessible :(
<vila> jakob: :-/ Even by asking kindly ? :)
<jakob> vila: well, maybe if he is back at the institute... I usually can get a lot done with the admins, because I find many bugs for them, and often I also manage to find a solution, saving them time ;)
<vila> jakob: ok, keep us informed anyway :)
<vila> and thanks for trying that hard :) Hopefully it will helps others once we understand the limitations.
<jakob> vila: I'll keep y'all posted .......
<pickscrape> If I bzr uncommit, should I be able to find the revision uncommitted in the shared repository?
<bob2> yes
<pickscrape> What is the best way to find it? bzr heads doesn't seem to be showing it.
<pickscrape> Ooh, heads --all might help...
<joh> Hi, I'm trying to push my repository to another machine with ssh:  bzr push --remember bzr+ssh://... but I get the following error: bzr: ERROR: Generic bzr smart protocol error: bad protocol marker "error\x01Generic bzr smart protocol error: bad request 'bzr request 2'\n"
<joh> What's wrong? Version mismatch?
<joh> Got bzr 0.15 on the target and 1.3.1 on the client :P
<uws> Why doesn't bzr+ssh://somehost/~/someproject work?
<uws> the ~ is not expanded, and I need to provide a complete path to the branch :s
<markh> awilkins: in case you happen to *still* be up - I'd love your review on my patch to solve the transport clone issues I send to the list on (my) Saturday.  But for now I must sleep...
<Odd_Bloke> uws: It's a known problem, certainly.  Perhaps '~<username>/...'?
<uws> Odd_Bloke: that's just as bad ;)
<PeakerWork> Hey, is it possible to pull all revisions of all branches in some remote repository?
<Jc2k> PeakerWork: there is a multi-pull command in bzrtools, i dont know if that works for your needs or not
<PeakerWork> Jc2k: I am just wondering, in the context of comparing "git fetch" with bzr's pull
<Jc2k> yes, im watching that convo :)
<Jc2k> PeakerWork: i think multi-pull will only pull branches you are interested in
<Jc2k> PeakerWork: so i could get branches from all overthe place (not just the mainline repository)
<Jc2k> PeakerWork: and bzr multi-pull will keep them all up to date
<PeakerWork> Jc2k: but it won't see new branches/etc
<Jc2k> PeakerWork: i think so, but i dont normally care about other peoples branches myself
<Jc2k> of course, when i set up bzr-mirror.gnome.org i did look at what would be needed to let people clone a full repository
<Jc2k> its not much effort, from what i recall
<PeakerWork> I much prefer the bzr approach, but I've only used git for a day..
<PeakerWork> when starting with bzr, it was after trying arch, monotone, and a couple of others. I loved bzr because it was the first time I tried things, and they worked exactly as I'd expected
<PeakerWork> now with git, I'm puzzled by the CLI again
<Jc2k> i set up bzr-mirror.gnome.org, git-mirror.gnome.org and hg-mirror.gnome.org
<Jc2k> thats a lot of repositories
<Jc2k> git caused me the most pain
<Jc2k> and it still isnt set up right
<PeakerWork> maybe Pythoneers minds are wired differently :)
<Jc2k> e.g. http://blogs.gnome.org/johncarr/2008/08/22/git-mirrror-making-it-suck-less/
<Jc2k> PeakerWork: that entire conversation is annoying. does the entire conversation condense to "we think git is the best because everything is in one folder" ?
<PeakerWork> Jc2k: well, there is the pre-fetching of remote branches that might be useful to you later, which is useful..
<Jc2k> PeakerWork: well, tags would be pre-fetched obviously
<Jc2k> PeakerWork: generally the number of branches to number i care about means that im pulling a lot of noise
<PeakerWork> noise is cheap :)
<PeakerWork> you can merge the interesting stuff very quickly which is nice
<Jc2k> i suppose
<Jc2k> im not very familiar with the bzr code, but it looks fairly easy to code this up
<Jc2k> i think the reason it hasnt is that the bzr guys have thought about it and just dont agree with the git model
<PeakerWork> the switch working tree model is also nice for very large working trees
<PeakerWork> performance-wise
<robsta> hi
<robsta> is there a prepare-ChangeLog.pl with bzr support out there?
<LarstiQ> PeakerWork: swithcing working trees is a different problem from "clone a repository"
<PeakerWork> LarstiQ: yeah, it is also useful, though
<LarstiQ> PeakerWork: it is, and bzr does it as well.
<PeakerWork> LarstiQ: that's great, I love bzr.  Its still said that git scales better, so I have to put up with it for this large project, instead of bzr :(
<LarstiQ> PeakerWork: is that your decision, or collaboration with others?
<LarstiQ> PeakerWork: just curious
<PeakerWork> LarstiQ: well, a bunch of coworkers here (including me) want to move from perforce into something reasonable (read, dvcs)
<LarstiQ> PeakerWork: and the next question is then of course, did you try bzr and find it too slow, or was the decision to use git made based on expecting scaling problems?
<LarstiQ> PeakerWork: aha :)
<PeakerWork> I can try to convince them of a different decision, but the project is pretty large, and they're very afraid of having it be too slow with bzr, and being committed to a tool that might be too slow
<PeakerWork> well, what if it grows too slow as the history grows, rapidly?
<PeakerWork> we can't "try" to know that?
 * LarstiQ nods
<LarstiQ> PeakerWork: very understandable
<LarstiQ> PeakerWork: is it already sizeable? Or do you foresee it growing very fast?
<PeakerWork> its pretty large already, file-wise. History-wise, its in perforce and would be hard to extract
<PeakerWork> p4 keeps history on a per-file basis
<LarstiQ> PeakerWork: there used to be a p4 plugin for bzr, no clue if that is maintained
<LarstiQ> PeakerWork: if you have some spare time, I'd be interested to know if that still works (and gives satisfactory results)
<PeakerWork> I'll try to remember to try that, I'll be off work here for a couple of weeks though
<evge> I have create a authentication.conf in ~/.bazaar for sftp host, but bzr keep asking me for password, any ideas ?
<Verterok> evge: I think ssh/sftp allways prompts for user input
<Verterok> evge: if you have pub/priv keys, you can use a ssh-agent
<evge> yeah, this would be a solution for the future, the initial problem was that olive-gtk poped up an error when I tried to update that branch :/
<Snaury__> jelmer: do you plan on improving subversion error reporting in bzr-svn? I just received SubversionException: (None, 170001) and I spent quite some time to figure it was just Authorization error. ;)
<jelmer> Snaury__, it should already convert a 170001 error into a regular "Permission Denied" error
<jelmer> Snaury__, if you get a traceback for 170001, please file a bug about it (and include the traceback)
<Snaury__> Hmm. Then it could be a bug: http://pastebin.ubuntu.com/44642/
<Snaury__> I was trying to svn-push into a repository where I forgot to edit svnserve.conf and add write rights.
<jelmer> Snaury__: Looks like we simply need to catch SubversionExceptions there and raise convert_error(ex)
<Snaury__> So, do you want me to file a bug report or will you just fix it without one?
<Snaury__> jelmer ^^
<jelmer> Snaury__, please file a bug report
<jelmer> Snaury__, I don't have time to look into it atm, and I would otherwise probably forget about it
<Snaury__> jelmer: ok, doing it now
<Snaury__> bug #267899
<ubottu> Launchpad bug 267899 in bzr-svn "svn-push has uncaught SubversionException 170001" [Undecided,New] https://launchpad.net/bugs/267899
<jelmer> Snaury__, thanks!
<jelmer> Snaury[away], should be fixed in 0.4.13 with a bit of luck
<a7p> hi everyone - I'm just wondering why I cannot a bug concerning the bzr-eclipse-plugin (when entering a comment, eclipse crushes regulary) - does anyone know this one?
<beuno> a7p, sorry, you cannot what?
<Verterok> a7p: just going to ask that ^
<Verterok> hi beuno
<beuno> hiya Verterok  :)   how's your first day of vacation?
<a7p> ;) I cannot enter a Commit Comment
<nDuff> a7p, "cannot a bug" -- you mean cannot file a bug? cannot find any references to a previously-filed report on that bug?
<a7p> arg,
<a7p> sry
<a7p> cannot find a bug
<nDuff> *someone* is always first
<Verterok> beuno: it's ok...trying to get up to date with bzr-related things :)
<nDuff> might be you this time.
<beuno> Verterok, that may take you a while  ;)
<a7p> I had this behavior a few month ago, when I tried bazaar-eclipse and is still there, absolutly reproducible - It is impossible to use bzr with eclipse... I cannot believe no one else stubled upon this one.
<Verterok> a7p: please file a bug. also if you have a stacktrace, that would be great
<Verterok> a7p: I'll take a look ATM
<Verterok> beuno: indeed, tons of mails to read
<a7p> but if there is no obvious known reason (which I just did not see), I'll gladly file a bug.
<a7p> Verterok: thx.
<Verterok> a7p: I use bzr-eclipse to work on bzr-eclipse and never get into that bug :p
<a7p> Verterok: okay, now I feel lonley *g*
<Verterok> a7p: but if you can reproduce it, attach <workspace>/.metadata/.log and I'll try to reproduce it
<a7p> I am running 1.7dev with eclipse-gandymede on osx - may be a rare setup.
<Verterok> a7p: not at all. I'm with the exact setup :)
<Verterok> a7p: OS X 10.4, bzr.dev and eclipse 3.4
<a7p> same, but osx 10.5.4
<a7p> Verterok: dcc, mail or should I attach it to a bug?
<Verterok> a7p: please attach it to the bug
<a7p> okay, l'll send you the LP-id in a minute
<Verterok> a7p: great!, thanks
<a7p> LP: 267924
<beuno> bug #267924
<ubottu> Launchpad bug 267924 in bzr-eclipse "Eclipse crushes when a Commit Comment is entered" [Undecided,New] https://launchpad.net/bugs/267924
<beuno> you have to know how to tickle ubottu the right way
<beuno> :)
<a7p> @ Verterok - hope it helps ... if you have any further questions about my setup, feel free to contact me.
<a7p> beuno: been lazy the last months... all work no play ... *g*
<pickscrape> beuno: just out of interest, has the breadcrumbs stuff been looked at? I'm fully prepared to be told that it's naff and needs work. :)
<Verterok> a7p: ok, I'll take a look as soon I finish a new the merge dialog. thanks
<beuno> a7p, you can solve that by getting a job on what you play with
<beuno> pickscrape, ah, I suck. I'll get to it this week, I super-promise.
<beuno> I've been slacking off on Loggerhead stuff
<pickscrape> no problem :)
<pickscrape> I do foresee there being problems with it. The template stuff is new to me, especially the macro side of things.
<beuno> I'm sure we'll work it out pretty quickly, it was shaping up pretty well last time I peaked at it
<beuno> tomorrow seems like a good day for me to do some LH work
<pickscrape> Anyone have any idea how I might track down a segfault when running bzr qlog?
<a7p> beuno: if you are hireing for anything interessting, feel free to tell me *g* - currently I am doing "flash-shit", but the next paid project is going to be zope3-based ... and I am really happily looking forward to that.
<lifeless> actionscript and python have a lot in common
<a7p> lifeless: but not enough ..
<a7p> I also hate the flash-player and the adobe authoring enviroment
<a7p> environment
<spiv> Good morning.
#bzr 2008-09-09
<poolie> spiv, hello
<poolie> spiv, lifeless, igc, jam, call in a sec
<jelmer> 'morning spiv, poolie
<jelmer> how should I figure out what the parent revisions of an existing file text revision are?
<jelmer> CommitBuilder.record_entry_contents() doesn't take any text_parents arguments
<jelmer> lifeless: ^
<jml> abentley: how come I have to do 'bzr up' rather than 'bzr co' in the branches that export-loom makes?
<lifeless> jelmer: it assigns the value itself
<jelmer> lifeless: what if the text wasn't changed but inherited
<jelmer> ?
<lifeless> it may or may not assign a new one based on the per file graph
<poolie> hello jelmer, lifeless
<poolie> spiv, oh well that was probably a good place to wrap up
<lifeless> what's the goal here, reimplementing this, or using it ?
 * jml waves
<poolie> good luck
<spiv> poolie: :)
<jelmer> lifeless: but there's no way for CommitBuilder to figure out what the parents of a text are when recording an existing text
<lifeless> jelmer: it has the parent trees as state
<lifeless> jelmer: read the code :P
<jelmer> lifeless, The parents of the text I mean
<jelmer> lifeless: If you commit a merge for example and the merged revision is a ghost
<jelmer> lifeless, and one of the texts wasn't changed
<lifeless> then it cannot calculate it correctly because the ghost data is absent
<jelmer> lifeless, is there no way to determine what the parents of the text are?
<lifeless> so it calculates it based on the available data
<lifeless> jelmer: you keep repeating this, but I'm really not understanding if you are asking a question, making an assertion, or seeking help solving a problem
<jelmer> all three
<lifeless> the statment doesn't make sense to me
<lifeless> perhaps you could unpack whats going on so I'm not guessing at quite so much at once
<jelmer> So, let me start by explaining the issue I'm trying to solve
<jelmer> bzr-svn needs to make sure that the parents recorded for a text revision are correct
<jelmer> generally, it will induce the parents for a specific text from the information in svn
<jelmer> if that doesn't help, it'll look a specific svn property
<jelmer> lifeless, Never mind, I just answered my own question
<lifeless> :P
<lifeless> jelmer: so commit builder has enough state to look in each inventory that is available to determine the files presence, and last-changed, in that inventory
<lifeless> jelmer: doing a commit with ghosts should never happen except for an importer from tla
<lifeless> ghosting is something that happens deliberately, after revisions are created, not adhoc
<jelmer> lifeless: The thing is, bzr-svn uses the commit code also when pushing
<lifeless> jelmer: when pushing, there should be no ghosts though
<jelmer> lifeless: There can be - when pushing into svn you're not necessarily pushing merged revisions as well
<lifeless> also, there is a hole in our ghost support infrastructure; a last-changed value in an inventory which is the value of a ghost will cause checkout/export to fail
<jelmer> yes, several people have hit that using bzr-svn
<lifeless> yah
<lifeless> back shortly, food calls
<lifeless> spiv: please let me know if my branch hook patch was sufficient unto the tests
<spiv> lifeless: I'll take a look now
<jelmer> lifeless: thanks for playing soundboard (hope that's a correct translation)
<lifeless> jelmer: sounding board is probably more common, but soundboard is totally understandable :P
<spiv> lifeless: looks ok to me.  I can't think of any other worthwhile unit tests to add.
<lifeless> spiv: well, its approved once trunk unfreezes
<lifeless> spiv: I was more meaning 'does it do what you need'
<spiv> lifeless: Oh I see.  Yes, I think so.
<lifeless> right, its now yours, enjoy.
 * LaserJock crosses his fingers
<LaserJock> darn
<LaserJock> lifeless: james_w set me up with a little hacky script to import both debian and ubuntu source packages
<LaserJock> I got one to work fine
<LaserJock> but 2 have died
<mwhudson> ah, hi LaserJock
<LaserJock> hi mwhudson
<mwhudson> LaserJock: i didn't do anything about the matplotlib vs python2.4-matplotlib thing
<LaserJock> oh?
<mwhudson> LaserJock: i just confused about what the right thing would be
<lifeless> LaserJock: oh, shame.
<mwhudson> oh, wrong channel
<mwhudson> except you're not in #launchpad :)
<LaserJock> mwhudson: I'll join #launchpad
<LaserJock> lifeless: well, it would be fun if it just worked without any problems
<LaserJock> lifeless: but it looks like I might be able to help debug bzr-builddeb
<LaserJock> so that's good anyway :-)
<lifeless> LaserJock: cool
 * markh cheers lifeless on his review-athon :)
<jelmer> oops
<jelmer> 95 % of the memory usage of bzr-svn appears to be in reading ~/.subversion/config
<RAOF> jelmer: That's with respect to the crazy "eat 1GB of ram on multi-pull" bug?
<jelmer> RAOF: Yep
<spiv> jelmer: whee!
 * RAOF wonders how one can blow 1gb resident on reading a config file :)
<jelmer> it's parsing ~/.subversion/ for reading every file multi-pull tries to open
<jelmer> and multi-pull tries to open a lot of files
<RAOF> Aaah.  And no GC gets done?
<jelmer> RAOF, Nope
<jelmer> RAOF, Ok, that fixes it..
<markh> lifeless: in the abspath mail you said to add a test that "sets sys.platform to something windows" - can you please elaborate?
<markh> did you mean *checks*?
<LaserJock> anybody got an idea of what http://paste.ubuntu.com/44717/ means?
<LaserJock> it looks like it's trying to make a path with non-ASCII characters
<markh> LaserJock: or possibly even any parent being non-ascii
<LaserJock> is that anywhere in the bzr branch?
<LaserJock> or does that just apply to the root directory of the branch
<lifeless> markh: no, I mean sets
<lifeless> markh: you have conditional code based on the platform right?
<markh> so set sys.platform for the benefit of other platforms to be able to test it?
<poolie> yay bubba :)
<lifeless> markh: set sys.platform so that other platforms test that case, yes.
<markh> heh - I'd figured that might be a dangerous thing to do, but OK...
<lifeless> markh: look for sys.platform in the osutils tests
<markh> will do, thx
<lifeless> probably can be cleaner than that is, but its an example
 * markh goes to wait in line for an hour at the chinese embassy...
<lifeless> markh: off to china?
<markh> yeah - brother getting married there next month!
<markh> I was actually visiting him there earlier this year - quite amazing - but you really need someone who speaks the language close by :)
<markh> (which he does)
<jml> markh: does he *read* the language?
<lifeless> markh: when you get back, I have a branch I'd appreciate your testing
<Verterok> a7p: still around?
<a7p> jep
<a7p> but I won't last more than another 30 minutes
<Verterok> ok
<Verterok> I'll make it short enough :)
<Verterok> a7p: I can't reproduce the crash, also I don't see any related error in the log
<Verterok> a7p: could you check ~/Library/logs/Java?
 * a7p starts up a terminal
<Verterok> if the jvm crashed, there should be a log there
<a7p> jep, got a couple of eclipse-crashfiles here
<a7p> should I attach one to the bug?
<Verterok> a7p: please :)
<a7p> Verterok: done
<Verterok> thanks! I'll keep digging
 * a7p keeps supplying useless treasuremaps
<Verterok> a7p: not so useless :)
<a7p> ;)
<Verterok> a7p: it seems like a bug was fixed in Eclipse 3.3
<a7p> would be pritty bad, if they only introduced new ones... *g*
<Verterok> a7p: http://lists.apple.com/archives/Java-dev/2007/Nov/msg00014.html
<Verterok> a7p: sorry, "it seems that a similar bug was fixed in 3.3"
<a7p> looks, pretty much like my problem.
<Verterok> a7p: the widget used in the commit dialog will be replaced, pretty soon. it's a work in progress
<a7p> wounderful, nice to hear
<a7p> if i understood correctly, this is a osx 10.5 issue - other platforms won't suffer from it.
<Verterok> I'll try to rollout a new build as soon as possible
 * a7p looks happily forward to it - Thanks Verterok, that's Bugreporting the way I like it.
<a7p> and now I'm going to put my tired head to rest
<lifeless> fooding
<Peng_> I should just try this myself, but what does Bazaar do if, when using HTTP, a /.bzr/ directory redirects somewhere else?
 * Peng_ tries it himself.
<lifeless> spiv: http://marc.info/?l=linux-netdev&m=122091500114869&w=2
<lifeless> spiv: details on why coalescing the bytes written to the socket helped
<Peng_> Oh, good, it works.
<spiv> lifeless: that's a nice clear description of things
<spiv> lifeless: It's a pity I learned that stuff the hard way rather than by reading about it :)
<lakin> Is there a pdf version of the html guide?
<lakin> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
<lakin> ?
<lifeless> Peng_: you can redirect a branch, redirecting a repository is likely to die horribly
<markh> jml: apparently well enough to read signs and stumble through things, but not well enough to comfortably read a newspaper for example
<markh> lifeless: how can I help?
<lifeless> markh: test my patch
<markh> which one? :)
<lifeless> the one I cc'd to you
<lifeless> that prominently asks for help :P
<markh> _walkdirs
<markh> oh :)
<jml> markh: when I visited, I found the inability to read the language much more frustrating than being unable to speak it.
<markh> jml: I doubt we would have survived ordering in some of the places we ate at, for example.  We would have ended up having a much more "westerners" experience I think
<markh> I remember once thinking "surely I can order a coffee" - and failed misterably :)
<markh> the "coffee" part was understood, but trying to explain I wanted it to take away was a sticking point :)
<lifeless> just get it, then walk out the door
<markh> yeah, and just keep walking :)
<lifeless> well no, stop and let them change it around now they get the message :P
<Peng_> lifeless: Well, I'm redirecting both the branch and repo (from /foo/... to /bar/...). Hopefully it'll be okay.
<Peng_> lifeless: BTW, this is very trivial, but I think bzr-search's cmd_index wastes a transport. It opens one, and then passes the URL to index_url, which opens it again.
<lifeless> Peng_: patches appreciated :P
<Peng_> lifeless: Heh. But what should I change it to do? Make index_url accept a transport? Rename index_url to index_transport or something?
<lifeless> Peng_: I think there is a transport taking helper already
<lifeless> Peng_: if there isn't, split the current one in two, and call the helper
<markh> lifeless: is there a subset of the tests I can specify?  Otherwise things get lost in the noise...
<lifeless> ./bzr selftest --no-plugins osutils win32 walkdirs
<markh>   File "O:\src\bazaar\bzr\bzr.lifeless\bzrlib\tests\branch_implementations\test_parent.py", line 95, in test_win32_set_parent_on_another_drive
<markh>     base_url = b.abspath('.')
<markh> AttributeError: 'BzrBranch6' object has no attribute 'abspath'
<markh> x7 times
<lifeless> heh
<lifeless> well thats unrelated :P
<uniscript> anyone know a way of using bzr on an svn project, but with local storage but not the whole history?
<markh> lifeless: they are the only errors
<Peng_> Hmm, I think it winds up opening the branch twice too.
<lifeless> markh: cool
<lifeless> markh: care to review it ? :)
<markh> having a quick look now
<lifeless> uniscript: branch --stacked
<uniscript> but the docs say that that's just a light checkout or am I reading it wrong?
<uniscript> i.e. can I branch, ci merge etc. with such a branch locally with no access to the svn repo?
<uniscript> and then just push / merge upstream later?
<markh> hrmph - I'm not testing much as I haven't run a build
<markh> things are a little uglier when I do :(
<markh> lifeless: http://pastebin.com/m27ccab4c
<lifeless> markh: could you fix?
<lifeless> markh: the intent should be pretty obvious
<markh> not today :(
<lifeless> sure
<lifeless> No windows dev environment here at the moment, so I can't
<markh> np
<lifeless> uniscript: no, no-access requires full history copied, today.
<uniscript> OK thanks, at least I know not to go chasing after the wind :)
<lifeless> uniscript: partial-local-storage is what you asked for :P, sorry that its not enough
<uniscript> you say "today" is  it in the pipeline?
<lifeless> long term plans, nothing to hold breath over :)
<uniscript> I can imagine that people would like to join an svn repo from some revision onwards
<uniscript> Or I suppose it can be part of the ability to consolidate bzr repos
<uniscript> does that exist?
<lifeless> I'm not sure what you mean
<uniscript> clear out irrelevant history?
<uniscript> say I have 1000 revisions in my repo
<uniscript> and I don't want all that history kept, can I say merge 200-300 as one revision and dump all that history?
<Peng_> Wait, it's just a one-line change to fix this.
<Peng_> Well, that's to stop it from wasting one transport. There are others too.
<Peng_> lifeless: Do you mind if I pass "foo/" to index_url instead of an URL like "file:///path/to/foo/" or whatever?
<lifeless> Peng_: for testing?
<lifeless> bug 248275
<ubottu> Launchpad bug 248275 in bzr "Crash when pulling with --no-plugins" [Undecided,Fix released] https://launchpad.net/bugs/248275
<lifeless> poolie: ^ is that a bubba alias?
<mwhudson> i think it's probably a different mentally ill person
<Peng_> lifeless: No, because it's the least-invasive way to get rid of that wasted transport (it's just used like get_transport(url).base)
<lifeless> Peng_: oh. well foo/ isn't a url, its a url fragment or possibly a unicode path
<lifeless> I'd rather not pass paths to url functions, bad things tend to eventually happen
<Peng_> ok
<vila> good morning bazaar !
<lifeless> man I hate libc maintainers sometimes
<lifeless> st_mtime is a         def __get__(self):
<lifeless>             return self._mtime
<lifeless> bad paste sorry
<lifeless> st_mtime is a defined macro from bits/stat.h now :(
<lifeless> ok
<lifeless> 10% shaving by using a compiled stat object
<jonnydee> hi, I
<jonnydee> 've got a question:  I've got a checkout and did a "bzr ci --local" yesterday. Today I did a "bzr up" and now my local commit from yesterday shows up as a pending merge. Is there any way to get to the previous state where my local commit just will be committed with the next "bzr ci"? without in fact doing a merge?
<jonnydee> (for the case my last sentence got cut):  Is there any way to get to the previous state where my local commit just will be committed with the next "bzr ci"? without in fact doing a merge?
<jonnydee> and what effects does a "bzr update" have on the local repository if it contains local commits?
<Peng_> jonnydee: (Your last sentence didn't get cut. IRC's line length limit is closer to 500 chars, and many/most IRC clients handle it sensibly.)
<Peng_> jonnydee: Sorry, but I don't have experience with checkouts, so I can't really answer your question.
<jonnydee> Peng_: ok thanks for your feedback
<bob2> it's a lightweight checkout?
<jonnydee> no, a normal checkout
<jonnydee> does it make any difference?
<jonnydee> (in my case)
<Peng_> jonnydee: My wild guess would be that you can't avoid a merge, because it would require rebasing, and bzr isn't big on that.
<Peng_> But I don't know the mechanics of local commits in checkouts, so that may be wrong.
<jonnydee> probably you are right... So I'll do a merge... Thanks a lot for your help :)
<jml> lifeless: you raiding tonight?
<sabdfl> bzr diff -r date:2008-09-09,09:00:00
<sabdfl> doesn't seem to work
<sabdfl> any suggestions?
<uws> sabdfl: bzr diff -r date:2008-09-09T09:00:00
<spiv> sabdfl: seems to work ok for me
<uws> with a comma it works for me as well
<sabdfl> ./bzr diff -r date:2008-09-09TO09:00:00        ~/software/bzr.dev
<sabdfl> bzr: ERROR: Requested revision: u'date:2008-09-09TO09:00:00' does not exist in branch: BzrBranch7('file:///home/mark/software/bzr.dev/')
<uws> TO?
<uws> sabdfl: it's a 0, not O
<spiv> sabdfl: There probably isn't a revison after that time, hence the "no such revision" error.
<uws> but with comma it works fine for me as well, as I said
<sabdfl> doh
<spiv> I don't think there's been any commits to bzr.dev since  2008-09-08 07:18:35 +0100
<uws> yeah, I get it with dates in the future as well
<uws> but the error message is at the very least misleading
<spiv> (And "-r date:..." calculates using your local timezone, so comparing is often confusing....)
<spiv> Yeah, the error message could definitely be better.
<bob2> and different output for "no commits since that time to compare to" and "no commits at or after that time at all"
<lifeless> jml: shutdown night
<LeoNerd> lifeless: So.. I mailed the mailing list about my "log" range ideas... no response.. :/
<kinkie> Hi all.. I've made a little mess, by inadvertently deleting a branch from a repo. I have the branch pushed-to in launchpad, is there a way to recover the branch in my repo without branching and merging again? Thanks
<uws> kinkie: if you branch it again, it will (re)use the revisions from your local repo, so it's cheap
<awilkins> kinkie: bzr heads --all will show all tips in your repo
<awilkins> And uws is also correct
<uws> awilkins: What is the difference between "dead" and "alive" heads?
<awilkins> My way is tricksier but requires no network connection ; his way is easy and requires minimal network
<awilkins> uws: "Dead" heads are ones that are not in a branch
<uws> awilkins: well, if you ask on irc i assume a network connection is available ;)
<uws> awilkins: how does it know?
<awilkins> uws: I presume it recurses, but I'm not sure.
<awilkins> uws: I'm going to try it now :-)
 * awilkins randomly deletes a branch
<awilkins> Yup, dead heads are ones with no branch, but still listed by all
<uws> awilkins: it can't know if I have branches somewhere on my machine (or on another machine) that are on that specfic head, right?
<uws> e.g. a checkout on another machine
<uws> eh, s/checkout/branch/
<awilkins> uws: I think it restricts itself to branches within that repo
<uws> ah, that makes sense (common setup anyway)
<awilkins> Probably very wuick in a no-trees repo
<kinkie> awilkins: ok, I found the head. What then? (I'm not so big on bzr recoveries yet ;)
<awilkins> Pretty quick in a trees repo too ; it only has to check .bzr folders
<kinkie> trunk is 'trunk'
<kinkie> let's call the branch 'foo'
<awilkins> You should be able to branch it from the listed revid:
<kinkie> should I just 'bzr branch trunk foo'? And as long as the name matches, it'll just revive the branch?
<awilkins> bzr branch trunk -r revid:<myrevid> foo   ?
<uws> awilkins: heads --all shows me a bunch of revisions that have been committed/merged into my branch ages ago. how come?
<awilkins> uws: because they're all tips of branches that no longer exist in your repo
<awilkins> uws: I suspect if you branch your trunk into another repo and try again they'll disappear
<uws> awilkins: I still don't know how it figures that out
<awilkins> uws: The help says "revisions without descendants"
<uws> awilkins: yeah, but they're merged, so they have revisions on top of them
<kinkie> awilkins: that did it. THANKS A LOT!
<uws> awilkins: (but indeed, creating a new repo makes them disappear_)
<awilkins> There may be more to it than meets the eye then
<awilkins> kinkie: Thanks for helping me practice that, never done it before
<kinkie> I honestly hope it's an one-shot affair ;-)
<awilkins> kinkie: I had a small doubt that it might not work with a revision that was never merged into the branch I'm instructing it to branch, but I just tried it and that works just fine
<uws> awilkins: hmmmm. it could be that revisions I've uncommitted show up as heads
<awilkins> uws: Aha, yes, I think you've put your finger on it
<uws> awilkins: I was triggered by the exceptionally high number of typos in the commit messages :)
<Leonidas> maybe I am too stupid, but somehow bzr commit -x does not exclude anything.
<poolie> night all
<james_w> Leonidas: it works for me, but it doesn't affect the diff shown by --show-diff, which I will file a bug on, is that all you were looking at, or did you look at the committed diff?
<Leonidas> james_w: when I committed it has included the file in the output, so I think it has committed it as well. I did an uncommit, but I'll test it again when I find some time to make sure it is not because I'm too stupid to use it.
<james_w> Leonidas: I saw it was in the diff, but not the "modified foo" lines it prints, and "bzr diff -c -1" afterwards shows only the changes that I wanted
<james_w> bug 268135
<ubottu> Launchpad bug 268135 in bzr "bzr commit -x doesn't change the --show-diff output" [Undecided,New] https://launchpad.net/bugs/268135
<james_w> that's not good: "branch.lock_read()" deleting the branch, there's something fishy going on here
<Peng_> I was just messing around because of the slow startup thread on the mailing list, I ran "bzr revert" on a single file, and it took like 5 seconds. :(
<james_w> ah no, just me being stupid it seems
<Peng_> Stupid hard drives.
<james_w> I have a problem with code I am writing
<james_w> it does "revid = tree.commit()" and then "other_branch.fetch(tree.branch, last_revision=revid)"
<james_w> this works fine when the branches are in separate repositories, but fails when they share one
<james_w> as the fetch detects that it is fetching to the same repo, and just checks that the last_revision is present
<james_w> this check is what fails
<james_w> if I use pdb to pause just before the fetch "bzr log" and "bzr heads" from another process outside can see the revision in question
<james_w> do I need to do something to make the current process see the just committed revision, or am I missing something else?
<foebrian> morning all
<foebrian> is there a way to remove a project from bazaar? to unregister it?
<Odd_Bloke> foebrian: Why do you want to?
<james_w> hi Odd_Bloke
<Odd_Bloke> james_w: o/
<james_w> Odd_Bloke: how's the job?
<foebrian> Odd_Bloke: well i setup bazaar on my home server, and missedtyped the project path, so now 6 projects are considdered one, so i want to unregister it, then fix by adding just one project. if that make sense
<Odd_Bloke> james_w: Not bad.
<Odd_Bloke> Currently work on OO.o. D:
<Odd_Bloke> foebrian: What do you mean by 'projects'?
<foebrian> Odd_Bloke: well i have a single project folder /storage/projects then below that i have my project 'branches' like /project1   /project2  /project3, so now all the folders are commited to one 'branch' even though they are seprate projects
<foebrian> does that make sense?
<Odd_Bloke> foebrian: Right, move /storage/projects/.bzr to somewhere else (just as a backup), and then 'bzr init' in each of the separate project directories.
<Odd_Bloke> If the projects are related, you should consider running 'bzr init-repo /storage/projects' beforehand, it'll save space.
<foebrian> Odd_Bloke: so the removal of .bzr will remove it then? unfornately they are not related, seprated things
<Odd_Bloke> foebrian: Yeah.
<foebrian> Odd_Bloke: awesome, it worked! thanks Odd_Bloke!
<foebrian> chaos is removed!
<james_w> bug 264705 if anyone has any ideas about my problem
<ubottu> Launchpad bug 264705 in bzr-builddeb "merge-upstream fails when shared repository is present" [Critical,New] https://launchpad.net/bugs/264705
<Odd_Bloke> foebrian: No worries.
<Odd_Bloke> james_w: Are you still working on versioning all of Ubuntu?
<james_w> Odd_Bloke: yup
<Odd_Bloke> james_w: How's it going?
<james_w> Odd_Bloke: it's coming along, spending a week or two bug fixing at the moment before Ubuntu beta freeze, and then back to importing and documentation
<Odd_Bloke> james_w: Ah, cool.
<LeoNerd> By the way guys: I've just built myself a WinXP VM in VirtualBox. First thing I did was installed Bazaar, which has TortoiseBZR. I'd like to report it JustWorks. It's lovely ;)
 * kinkie is away: see you later/tomorrow
<Odd_Bloke> kinkie: If you could disable away messages, for this channel at least, that would be appreciated. :)
<jam> lifeless: ping me when you wake up, I need you to make a 1.7 branch so I can do 1.7rc1
 * justizin wonders why the OSX 10.5 installer is an older version of bzr (1.5) than the OSX 10.4 installer (1.6)
<justizin> does the 10.4/1.6 not work on leopard?
<Verterok> justizin: the installers are builded by the community
<justizin> fair enough :)
<justizin> looks like 1.6 installer wants python 2.5 on 10.4, complains i need python 2.5 even though i have it on leopard
<Verterok> justizin: I build the 10.4, and 'ld like to build the 10.5 too, but no leopard nor mac-intel here :(
<justizin> Verterok: can i run the build for you? ;)
<justizin> i've got three intel macs here running leopard.
<Verterok> justizin: the 10.4 installer depends on a user installed python. 10.4 only provides python2.3 by default
<justizin> love to help..
<justizin> yeah i figure as much..
<justizin> how does the checking work?
<justizin> seems it should be possible to look for python in /System/Library/Frameworks as well as /Library/Frameworks or ~/Library/Frameworks...
<Verterok> justizin: let me check
<justizin> but i know this is a challenge for many mac / python installers..
<justizin> np
<justizin> 1.5 will serve my needs for now but i'd love to help make available better installers for mac any way i can.
<Verterok> justizin: the 10.4 installer checks CFBundleShortVersionString property in /Library/Frameworks/Python.framework/Versions/2.5/Resources/Info.plist
<justizin> is it possible to configure alternative checks, or does it only allow one location to provide a dependency?
<Verterok> justizin: I think it's possible, but I dont' know if its going to work
<justizin> hm
<justizin> is source for the installer accessible?
<Verterok> justizin: all the C extensions are compliled against 10.4 dynlibs
<justizin> fair enough
<justizin> i suppose we can just port it to 10.5
<Verterok> justizin: I think phanatic builds the 10.5 installer, and have all the required bits
<Verterok> justizin: check Issues section at http://bazaar-vcs.org/MacOSXBundle
<justizin> got it
<newz2000> in eclipse using bzr-eclipse I've found that if I check out my work into a subfolder of the project (for example, trunk) then eclipse doesn't recognize the project as being managed by vcs. Does anyone know a workaround?
<Verterok> justizin: if you don't have a reply, please let me know and I'll push my installer branch to some public location
<Verterok> newz2000: Eclipse only support project level team provider mappings
<newz2000> oh, too bad
<Verterok> newz2000: what is the layout you need?
<justizin> Verterok: i'd like if you published it..
<Verterok> justizin: at your service ;) http://verterok.com.ar/code/bundle-10.4/
<newz2000> well, I was taught an interesting way to manage my project... create a folder, keep my main trunk branch in a sub-folder, and when I'm fixing problems create a branch for the fix and work on it there.
<newz2000> I've been using it lately and its working out nice
<Verterok> justizin: the pmproj file is a work in progress (tm) to include bzr-svn, just remove both bzr-svn entries and it 'll build ok :p
<newz2000> so my project might include these folders: trunk/ add-openid/ jquery126/
<justizin> ok
<newz2000> all branches
<justizin> i was thinking about that challenge myself.
<justizin> are you just including a copy of svn 1.5 or wha?
<Verterok> justizin: most of the work is there, just need the glue :)
<Verterok> justizin: I acctually build bzr-svn against both versions of subversion (1.4 and 1.5)
<Verterok> justizin: and adds a check like the python-2.5 one
<justizin> interesting..
<justizin> 1.4 needs to be patched to work, though, eh?
<Verterok> justizin: not any more, bzr-svn now provides it own bindings
<justizin> ah-ho
<justizin> neato
<newz2000> oh, Verterok, you're Guillermo! Nice to meet you and nice work on the project.
<justizin> i've just been using bzr-svn on my ubuntu box, then grab a copy using straight bzr from mac or other servers like RH which don't have bzr-svn yet
<justizin> still will keep doing that but it'd be nice to have bzr-svn around other places sometimes :)
<Verterok> newz2000: thanks! it's greatly appreciated! :D
<Verterok> newz2000: maybe your need can be solved if bzr-eclipse provides a way to branch directly from a project
<newz2000> I wonder if it would be better to file a bug/feature request on eclipse, though I'm not sure how responsive they are
<newz2000> so that vcs can just live in sub folders
<Verterok> newz2000: like: right click on on trunk --> branch as new Project. and create add-openid project
<newz2000> ah
<Verterok> newz2000: that could work for your workflow?
<newz2000> yeah, that would work, but the only prob is the directory structure might become a mess
<newz2000> let me think it through for a second
<Verterok> newz2000: you cound place the new project in any directory you want, i.e: like a share repo
<newz2000> so for example, I'm working on a project called XYZ
<newz2000> it would go into workspace/XYZ
<newz2000> and that would be the root of my project (no trunk/ folder)
<Verterok> justizin: poke me if you need some help to get the whole build process working (I know it need documnetation)
<newz2000> and to add a feature I branch from there to a new project at workspace/XYZ-feature23/
<newz2000> does that sound right?
<justizin> np doing a few things atm but will prod a bit and see what errors i get if i try a build
<Verterok> newz2000: that is one approach, actually, you could do taht with current bzr-eclipse
<newz2000> yes, I believe so
<Verterok> newz2000: also, you can place the projects inside /whatever/path/you/like :)
<newz2000> oh, really? I just use the default options usually
<newz2000> then let me try that, it is probably the easiest solution
<newz2000> and fixes another problem I'm about to experience since the python-path in pydev is set per-project
<Verterok> newz2000: also, if you want the "branch from project into a new project", please file a bug :)
<newz2000> ok, thanks for your time Verterok, I appreciate the help
<Verterok> newz2000: np, glad to help
 * newz2000 just tried it - it works!
<Verterok> great!
<ericvw> If I have standalone branch, but I want to migrate it into a centralized development work-flow because I will be on multiple computers, how would I go about migrating?
<fullermd> Push it up to your central location, and use 'bind' or 'reconfigure' to turn its current location into a checkout of the central branch.
<ericvw> fullermd: and it will know from the push where to update from and commit to?
<sabdfl> hey beuno
<beuno> hey sabdfl
<beuno> how's it going?
<sabdfl> groovy here, thanks. you?
<beuno> better now that I have internet again  :)
<fullermd> ericvw: No, from the bind/reconfigure.
<fullermd> ericvw: The push just sets up the data in the central location.
<ericvw> fullermd: thanks!
<strk> can a repository be downgraded to an older version to be compatible with older bzr clients ?
<jelmer> strk, generally, yes
<jelmer> strk: "bzr upgrade --old-format" (where old-format is the name of the format to downgrade to)
<strk> Could not load movie 'http://request/remote.php?theme=touchscreen.swf'
<strk> (sorry)
<willyyam> any reason why bzr is a bad choice as a backend for a versioned backup system?
<strk> willyyam: it's too new for debian stable users :)
<strk> is also slower then CVS
<willyyam> or, to put it another way, are twice-daily large binary blobs a problem over a long time (5+ years)
<willyyam> actually, I use it on debian stable daily
<strk> that one ships 0.11 it seems
<strk> we're using 0.16 and somewhat lost compatibility
<strk> so you can't fetch gnash sources from debian stable, unless you upgrade bzr
<strk> it sucks
<jelmer> strk: Lenny will be out soon hopefully :-)
<jelmer> strk, performance is pretty bad with old formats though
<strk> soon == few monts
<strk> jelmer: I'm talking about performance with 0.16 unfortunately
<jelmer> strk: but yeah, bzr upgrading to an older format should work
<strk> I guess downgrade would make it even slower ?
<strk> it takes from 15 to 30 minutes for a simple commit on a GPRS connection
<strk> about 1 minute on a DSL
<strk> the GPRS experience makes you hate it :)
<strk> but you can commit to a local branch while out-of-the-office and merge when back on high bandwidth, which is a bit harder with CVS
<beuno> pickscrape,
<beuno> "ping"
<beuno> is this what I'm suppose to be looking at?  lp:~pickscrape/loggerhead/directory_breadcrumbs
<beuno> mwhudson, I'm trying to remember what was wrong with lp:~pickscrape/loggerhead/directory_breadcrumbs
<beuno> but everything seems fine
<beuno> do you remember why we didn't merge that in the end?
<pickscrape> beuno: yes, I think that was it
<lifeless> jam: made
<jam> lifeless: thanks
<beuno> pickscrape, it looks fine to me. You fixed everything, didn't you?
<lifeless> the losas have that documented too FWIW
<pickscrape> Probably some hideous use of METAL that would have made the loggerhead codebase horrible :)
<pickscrape> I think I did, but it probably needs a really good test and review to make sure I didn't miss anything or code it into a hole or anything like that
<beuno> pickscrape, fire off the merge request, I'll take a look at the code
<beuno> I've been using it, and can't find any problems with the UI at all
<pickscrape> merge request via LP right?
<beuno> yeap
<mwhudson> beuno: maybe i just haven't got aroudn to looking at the lastest version
<beuno> mwhudson, yeah, me neither, but trying to get up-to-date today with LH stuff  :)
<beuno> thanks
<mwhudson> beuno: good idea
<pickscrape> Merge request sent
<pickscrape> Just reading my commit comments on that branch, I was concerned about having to create an inventory object for the annotate view.
<ivantis> hello
<ivantis> how do i log in with bzr to launchpad? i need to push some code
<ivantis> i already have an account
<beuno> ivantis, https://help.launchpad.net/BzrHowto
<ivantis> thx
<kwah> hi everyone
<kwah> I tried to ask on a mailing list... https://lists.ubuntu.com/archives/bazaar/2008q3/047006.html
<kwah> but got no reply
<kwah> either I could not find relevant information myself
<kwah> or it is the lame question
<kwah> any comments?
<mwhudson> kwah: well, if you have a shared repo upgrading the repository is a separate thing from upgrading the branches
<mwhudson> kwah: the main negative impact of upgrading is that people using older versions of bzr won't be able to access your branches
<kwah> mwhudson, and what about branches that were checked out?
<kwah> not branched, I mean
<mwhudson> the branch/checkout distinction is basically irrelevant here
<mwhudson> or do you mean lightweight checkouts?
<kwah> I am wondering, because some people are working with repo and I do not know, what they will see
<mwhudson> either way, the only impact would be better perfomance :)
<kwah> error message upon checking in
<mwhudson> no
<kwah> no, not lightweight
<mwhudson> ah
<mwhudson> actually, the conversion process is kind of slow
<mwhudson> so using a knit branch that's a checkout of a packs branch, say, might be a little tedious
<mwhudson> but it would _work_
<kwah> so it will be just transparent for the user?
<mwhudson> right
<kwah> hm... I guess I have to experiment myself more.
<kwah> anyway, it would be nice to have some points about this in documentation
<kwah> help messages are kinda cryptic
<mwhudson> file a bug, maybe?
<kwah> mwhudson, thanks for the explanation
<kwah> mwhudson, I may try
<mwhudson> np
<jam> lifeless: you created the 1.7 branch, but didn't give me authorization to commit to it.
<lifeless> jam: fixing
<lifeless> 7am :P
<lifeless> done
<jam> np
<jam> thanks
<lifeless> you forgot to time just python
<lifeless> to get the delta for locale
<jam> lifeless: sure, replied
<beuno> mwhudson, http://launchpadlibrarian.net/17058288/loggerhead_changes_path.diff
<beuno> related to: https://bugs.edge.launchpad.net/loggerhead/+bug/260363
<ubottu> Launchpad bug 260363 in loggerhead "unable to generate a link showing a file changes based on its path" [Undecided,New]
<beuno> we're doing that everywhere else in LP
<beuno> +1 to apply that patch?
<beuno> s/LP/LH
<beuno> I'm starting to get dizzy  :)
<mwhudson> beuno: s/not path is None/path is not None/
<mwhudson> and if we're really doing that EVERYWHERE in LH, i guess it should be in TemplateView
<beuno> I knew this wasn't going to be that easy...
<beuno> let me see how this can be refactored...
<mwhudson> beuno: it seems all the views a pretty consistent about how they handle 'args'
<mwhudson> either it's <revid>/path
<mwhudson> or they ignore it
<mwhudson> so we could change the signature from
<mwhudson> get_values(self, h, args, kwargs, response)
<mwhudson> to
<mwhudson> get_values(self, h, revid, path, kwargs, response)
<beuno> mwhudson, good idea. Let me change that and see how it looks
<mwhudson> beuno: thanks :)
<beuno> mwhudson, LH seems to be acting up again: http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/3697?file_id=setup.py-20050314065409-02f8a0a6e3f9bc70
<beuno> Verterok, w00t!
<beuno> thanks for that
<Verterok> beuno, mwhudson: ^
 * Verterok just send the review request
<mwhudson> ?
<mwhudson> ah right
<Verterok> mwhudson: Bug #243415
<ubottu> Launchpad bug 243415 in loggerhead "Tracebacks go to console but not log file" [Medium,Confirmed] https://launchpad.net/bugs/243415
<poolie> good morning
<beuno> morning poolie
<Verterok> mwhudson ,beuno: the template needs some love, but it would be great to get some early feedback
<james_w> hi poolie.
<Verterok> hi poolie
<beuno> Verterok, I can give it some love. That's the easy part  :)
 * poolie feels welcome
<james_w> poolie: a friend told me that the "topics" thing on the mailing list doesn't seem to be working correctly, merge requests seem to be delivered even if the merge topic isn't desired.
<lifeless> abentley: bb is down?
<james_w> hey lifeless
<Verterok> beuno: it would be *really* appreciated
<abentley> lifeless: restarted
<beuno> Verterok, I'll try and get to that after the refactor I'm doing
<lifeless> abentley: thanks
<Verterok> beuno: no hurry. thanks :)
 * lifeless waves around
<poolie> hello lifeless
<beuno> howdy lifeless
<lifeless> turns out that the vodafone system allows their helpdesk line to be put in as the 'notify me that a bill has been emailed' number
 * lifeless is satisfied
<james_w> if I have two branches which share a repository, and commit to one, should the commit be instantly visible in the branch.repository of the other?
<james_w> https://bugs.edge.launchpad.net/bugs/264705
<ubottu> Launchpad bug 264705 in bzr-builddeb "merge-upstream fails when shared repository is present" [Critical,Confirmed]
<mwhudson> pickscrape, beuno: i think that now History objects only last for the duration of a request, get_inventory should cache the inventories it returns
<lifeless> james_w: if the other branch drops its read lock to 0, then ups it, yes
<lifeless> james_w: but while locked the other repo may not refresh its indices list
<lifeless> jam: ping
<pickscrape> mwhudson: my worry was whether the breadcrumbs code adds an inventory object to the annotate page that was not needed before
<mwhudson> pickscrape: it was created anyway
<pickscrape> mwhudson: in that case I'm not worried :)
<mwhudson> pickscrape: in annotate_file, and possibly in get_file_path
<mwhudson> pickscrape: but it would be better to create it only once, hence the caching suggestion
<james_w> lifeless: thanks. Any suggestions for how to solve this bug?
<pickscrape> mwhudson: oh, you mean it doesn't actually do the caching at the moment?
<mwhudson> pickscrape: right
<pickscrape> ok
<lifeless> james_w: what bug
<james_w> lifeless: 264705
<lifeless> james_w: as I said, drop the references to the branch after the merge operation
<Yasumoto> I'm working with the fiveadayapplet, does anyone happen to know what error code 104 is?
<lifeless> no idea, we don't use numeric error codes
<lifeless> so its either not related to bzr, or coming from the OS
<james_w> lifeless: doesn't that introduce a race condition?
<Yasumoto> kk, that'd make sense why Google wasn't showing anything related to bzr, thank you :)
<lifeless> james_w: you say you have branch A and B, you do something on A, and then B fails to see the data?
<james_w> Yasumoto: /tmp/5-a-day-applet.txt may help you to debug
<lifeless> james_w: if B is locked prior to doing the task on A, B will not see new data introduced by A until B has been unlocked
<lifeless> james_w: what races are you worried about ?
<Yasumoto> james_w: awesome, thanks for the heads up
<james_w> lifeless: well, if B is unlocked and locked again isn't there time for the branch to be modified leading to trouble
<lifeless> is B write locked or read locked?
<james_w> write locked, it needs to do a merge of this new revision
<lifeless> and sure, someone else could grab a write lock
<james_w> perhaps I don't need the fetch there, and can move it up a function
<lifeless> but if you do rev = B.tip, B.unlock();b.lock_write(); check B.tip == rev
<lifeless> you can be sure noone has altered the tip
<lifeless> I don't understand why you would mutate branch A while holding a write lock on B
<lifeless> which branch are you actually working on :P
<mwhudson> pickscrape, beuno: i made a few more changes: https://code.edge.launchpad.net/~mwhudson/loggerhead/directory_breadcrumbs
<mwhudson> take a look?
<mwhudson> pickscrape, beuno: here's the diff of all of em http://bazaar.launchpad.net/~mwhudson/loggerhead/directory_breadcrumbs/revision/216?remember=211&compare_revid=211
<james_w> lifeless: A is the "upstream" branch and B is the "packaging" one, this command commits the new upstream, and then merges it to the packaging one, so we need to write to both
<james_w> lifeless: it locks B early to check there are no uncommitted changes, and get some info from it, but it could do the unlock I think.
<lifeless> james_w: to me they are separate steps, is there any need to make the aggregate atomic ?
<beuno> mwhudson, lovely.  +1
<mwhudson> beuno: i guess i'll merge
<james_w> lifeless: I think having it as one command makes sense. Is that what you mean by atomic?
<lifeless> no
<poolie> abentley, thanks for reading and replying to my mail
<beuno> mwhudson, yes please!
<lifeless> atomic - all-or-nothing
<abentley> poolie: np
<lifeless> indivisible etc
<poolie> i have to admit the content of the reply was at first discouraging
<james_w> lifeless: it doesn't really need to be. However the upstream branch is ephemeral, so currently it "disappears" on any error.
<lifeless> james_w: ok, well I'd either patch bzrlib to have a public refresh-view method to trigger a refresh, or drop and reacquire the lock
<lifeless> poolie: what email was discouraging?
<pickscrape> mwhudson: all looks ok to me
<mwhudson> pickscrape: good, because i just merged it :)
<mwhudson> pickscrape: thanks!
<pickscrape> hehe :)
<poolie> aaron's re what do we do now
<abentley> poolie: I'm sorry for any hurt feelings.  I felt it was important to be frank.
<poolie> it is
<pickscrape> Funny how someone who is picky about whitespace can be picked up on whitespace by someone else who is also picky about whitespace :)
<james_w> lifeless: thanks, it's late now, but you've probably given me enough to fix this tomorrow, thanks.
<poolie> i'd prefer that to folks just smiling and nodding
<lifeless> poolie: ah right
<lifeless> hadn't found that reply at that point
<lifeless> hmmm food, that will make me smile and nod
<abentley> poolie: I was a bit surprised at your suggestion, because I thought we agreed that too many cooks contributed to our problems with stacking.
<Verterok> mwhudson: I added a --reload option to serve-branches (mainly to ease dev's life :): http://bazaar.launchpad.net/%7Eguillo.gonzo/loggerhead/reloader/revision/220
<beuno> Verterok, :O
<mwhudson> Verterok: ah, you look like someone that knows somethign about paste!
<beuno> Verterok, gazillion thanks!!!!
<Verterok> mwhudson: not at all :)
<beuno> mwhudson, we need that merged. Now!
<beuno> millions of hours spent restarting LH....
<Verterok> mwhudson: just readed some docs, and the source ;)
<mwhudson> beuno: you have the powah
<mwhudson> Verterok: :)
 * beuno excercise it
<beuno> mwhudson, don't believe Verterok. He knows plenty, he's just shy
<Verterok> beuno: before merging, let me update serve-branches.1
<Verterok> beuno: hehe
 * Verterok hides
<beuno> Verterok, sure. Push, I'll pull, etc
<igc> morning
<james_w> morning igc
<beuno> morning igc!
<igc> hi guys
<beuno> all the cool people are around today
<Verterok> beuno, mwhudson: it's the --reload help description ok?
<Verterok> hi igc
<igc> hi
<poolie> hello igc!
<mwhudson> Verterok: i guess it should be clear that the application gets restarted when the application changes
<igc> hi poolie
<mwhudson> Verterok: you could possibly think that it was something to do with the branch changing
<beuno> Verterok, and, I'd also add this is only really useful for development
#bzr 2008-09-10
<Verterok> ok, I'm on it, thanks!
<poolie> lifeless, spiv, jam, igc, call in a minute if you want
<spiv> Good morning.
<lifeless> poolie: sure, call me
<lifeless> jam: ping
<jam> lifeless: pong
<jam> poolie: Just made it back into the house, is the call still going?
<lifeless> jam: it is
<jam> lifeless: can someone on the call ring me? I can at least listen in
<jam> (silent jam)
<lifeless> jam: thanks for tweaking my patch; is the rest ok with you? time to land ...
<Yasumoto> thanks for the help guys, turns out I hadn't unlocked my ssh key
 * beuno wished Loggerhead had tests
<jam> beuno: *write* them :)
<beuno> jam, I'm trying wishing first
<beuno> mwhudson, does it seem sensible that TemplatedBranchView finds the last revid if none is provided, instead of each controller?
<mwhudson> beuno:  yes, i think
<jam> markh: was there anything you specifically wanted for 1.7 that hasn't landed? I'd like to cut 1.7rc1 and i just want to make sure things aren't missing.
<markh> jam: those setup changes would be nice
<markh> I just mailed the list
<jam> markh: I did the TBZR ones
<jam> not sure what other ones
<markh> alex's - remove survey etc
<markh> and maybe the icon? ;)
<jam> markh: I did the icon as well
<markh> thx!
<jam> markh: Well, BB says that Alexander's change is already merged
<jam> so I'm tempted to say it is already there
<jam> is it missing for you?
<markh> I guess I was trusting bundle-buggy - lemme look...
<markh> it wasn't a few days ago iirc
<markh> jam: we still on bzr.dev right?
<jam> markh: well, we do have a branch, but it is 99.99% bzr.dev
<markh> oh - I missed word of that too.
<jam> markh: As near as I can tell, it is in bzr.dev
<jam> BB says 8/21 it landed
<markh> jam: yes, it looks to me like it has too - thanks!
<jam> markh: K, cutting tarballs
<markh> yeah, BB says it is merged, but I don't see a mail from BB in that thread saying it was merged.  Oh well, at least it is - thanks!
<fullermd> Well, good thing we did 1.6.1...
<lifeless> jam: thanks for tweaking my patch; is the rest ok with you? time to land it?
<beuno> mwhudson, http://bazaar.launchpad.net/~beuno/loggerhead/abstract_paths/revision/220
<wasabi> Hey. Managed to cause bzr to crash. 1.3.1 on hardy.  I tried to --force remove a directory that had already been removed by hand.
<wasabi> bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: tests/gupnp-test
<wasabi> Now I cannot use bzr status at all
<wasabi> Any way to patch the branch up?
<james_w> hi wasabi
<james_w> "tests/" was what you removed?
<wasabi> no. tests/gupnp-test
<wasabi> tests is still there
<james_w> mkdir tests/gupnp-test; bzr add tests/gupnp-test; bzr st; bzr rm tests/gupnp-test;
<james_w> that should fix it I believe
<wasabi> that did it
<james_w> the bug is fixed in later versions
<james_w> 1.6 I believe
<wasabi> K.
<wasabi> Thanks. ;)
<james_w> no problem
<james_w> happy hacking
<lifeless> spiv: any reason your faster branch isn't up for review?
 * beuno_ -> home
<mwhudson_> gar
<mwhudson_> beuno: the stuff to do with all_same_author is cruft since the new_theme landing?
<mwhudson_> oh right, it says so in the commit message
<mwhudson_> beuno: you don't need to call fix_revid in annotate_ui
<mwhudson_>         path = None
<mwhudson_>  
<mwhudson_>  
<mwhudson_> 81
<mwhudson_>         if len(args) > 1:
<mwhudson_>  
<mwhudson_>  
<mwhudson_> 82
<mwhudson_>             path = args[1]
<mwhudson_> oops
<mwhudson_> beuno: ^ that doesn't look right
<mwhudson_> for e.g. annotate/100/file/in/subdir
 * jml reads the startup time RFC
<jml> it would be nice if that got summarised into a more static document.
<lifeless> I didn't expect *quite* that enthusiastic a discussion
<jml> lifeless: it's an interesting topic :)
<jml> lifeless: speaking of enthusiastic discussions, when can we bury the adsorbSuite hatchet?
<lifeless> lunchtime?
<spiv> lifeless: because it was just idle hackery, and I haven't (yet) re-read what I've done to make sure it's not too hackish.
<jml> lifeless: sounds good to me.
<lifeless> jml: shall we say 12:30?
<jml> cool core.
<beuno> mwhudson_, you're right. I'll fix it
<lifeless> spiv: be useful to write up notes :P
<mwhudson_> beuno: i think that you can just path_info_pop the revid, then take the rest of the environ['PATH_INFO'] as the path
<mwhudson_> beuno: also, there's some confusion about whether path should start with or end with a /
<mwhudson_> beuno: i suggest normalizing it in TemplatedView and then getting rid of the silliness in the subclasses
<beuno> mwhudson_, cool, will do. Cleanups are always fun
<mwhudson_> right
<lifeless> mwhudson: is there a good 'am I leaking references from my C module' tester?
<mwhudson> lifeless: not really
<lifeless> bugger
<lifeless> do you know
<mwhudson> lifeless: there's a trackrefs class somewhere
<lifeless> does PyTuple_SetItem
<lifeless> dereference the old value at that place?
<lifeless> or refuse to set the item altogether?
<mwhudson> i don't know
<mwhudson> but overwriting a tuple item is kinda breaking the rules...
<lifeless> do you know where the tuple code is defined
<lifeless> mwhudson: I'm creating it in a long winded way
<mwhudson> lifeless: Objects/tupleobject.c
<lifeless> and writing to the C api, so kthxblah
<mwhudson> (though it might even be a macro)
<lifeless> ok cool
<lifeless> it dereferences an old tuple item
<lifeless> yay for sanity
<mwhudson> lifeless: it decrefs the old value
<mwhudson> the python/c api is *mostly* sane
<lifeless> I *Love* open source
<lifeless> being able to check that code myself, FTW>
<lifeless> lol
<lifeless> :!PYTHONPATH=. python -m timeit -s "from bzrlib.osutils import _walkdirs_utf8 as walkdirs" "print len(list(walkdirs('../test-repos/mozilla')))"
<lifeless> Traceback (most recent call last):
<lifeless> Command terminated
<Verterok> lifeless: about startup-time, cleaning up a bit xmloutput plugin, 0.20s gain in 'bzr rocks'. WOW!
<Verterok> maybe a major call to plugin developers, could help a bit on that area :)
<lifeless> Verterok: so thats good; better would be 0.2s gained on 'bzr st'
<lifeless> Verterok: which xmloutput also hooks into, yes ?
<Verterok> lifeless: indeed
<Verterok> lifeless: not any more
<lifeless> mwhudson: how do I found out the refcount of an object?
<Verterok> lifeless: xmloutput don't override any builtin :)
<Verterok> now it provides it own hidden command xml*
<lifeless> Verterok: oh cool, its the rpc service one right?
<Verterok> yes
<lifeless> excellent news, thank you :)
<lifeless> can I pull the new one yet ?
<lifeless> revno 99?
<Verterok> lifeless: the point I tried to higlight was that those 0.2s came from not using lazy_import :)
<lifeless> Verterok: ah right
<Verterok> lifeless: what branch?
<mwhudson> lifeless: sys.getrefcoutn
<lifeless> http://bazaar.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc/
<Verterok> lifeless: branch from lp:bzr-xmloutput, I moved xmlrpc branch to trunk
<lifeless> Verterok: so the theory of lazy import is 'defer reading code that is not needed', which is good; but its granularity is limited
<lifeless> Verterok: which is my somewhat more troubling point :)
<Verterok> lifeless: while moving things to lazy_import I foudn some corner cases, like the need to import SimpleXMLRPCServer (the module) and then doing SimpleXMLRPCServer.SimpleXMLRPCServer :p
<lifeless> poolie: down to 888ms
<lifeless> Verterok: yah, moving those to separate modules that you only load when you actually need the subclass might help
<markh> jam: where should I put the 1.7 binaries for windows?
<lifeless> Verterok: but only if you only need the subclass sometimes
<markh> (bzr's launchpad page has the most recent announcement as 1.6rc4 being released...)
<Verterok> because if I lazy_imported SimpleXMLRPCServer (the class), I get: "TypeError: Error when calling the metaclass bases"
<lifeless> Verterok: heh
<lifeless> Verterok: thats a bug in something, I don't recall if its the class machinery or lazy import
<Verterok> lifeless: yes, I did exactly that, moved all cmd_* to __init__.py, and most heavy imports into modules not used in cmd_* declaration
<spiv> poolie: you're welcome to work from here tomorrow, btw.
<Verterok> http://rafb.net/p/7lNeKY31.html
<Verterok> lifeless: the traceback, in case it helps ^
<lifeless> mwhudson: you'll probably shoot me when you see my code :P
<lifeless> 848ms per loop now
<poolie> lifeless, relative to what?
<poolie> spiv, thanks very much
<poolie> spiv, if i'm organized enough to go before rush hour i'll turn up just before the 9am call, otherwise later
<poolie> (in which case i may miss it)
<jml> you could turn up here if you'd like.
<jml> being something close to a midpoint
<lifeless> poolie: 1000ms in bzr.dev
<lifeless> jml: where is here now?
<lifeless> 812ms now
<jml> lifeless: lindfield.
<poolie> i assume he means pymble or lindfield
<poolie> i'm taking my bike to the shop in hornsby, so it's logically closer
<jml> poolie: oh, I see.
<poolie> to get a new shlock absorber so i can cope with robert's puns
<jml> heh
<poolie> but it would be nice to come over some time
<lifeless> poolie: schlock mercenary ftw
<beuno_> damn
<beuno_> I locked myself out of my server
<lifeless> lol
<beuno> damn
<lifeless> real world result:
<lifeless> :!python -m timeit -s 'import subprocess' 'subprocess.call(["./bzr", "st", "../test-repos/mozilla/"])'
<lifeless> 10 loops, best of 3: 3.68 sec per loop
<lifeless> :!python -m timeit -s 'import subprocess' 'subprocess.call(["./bzr", "st", "../test-repos/mozilla/"])'
<lifeless> 10 loops, best of 3: 3.84 sec per loop
<lifeless> I'm going to keep driving it down
<lifeless> jml: now ok?
<beuno> dinner!
<jml> lifeless:  * resource dirty markers on non current resources - ignore? keep a history ?
<mlh> I want to keep some db schemas in a nicely diffable format
<mlh> does anyone know of something good that will do that?
<mlh> (sorta OT I know)
<poolie> mlh, do you mean as an alternative to sql data definition language (if that's the right name)
<poolie> (replying to this naming thread)
<lifeless> 745ms
<lifeless> EFOOD
<mlh> poolie: well ddl defines the db, I want to go the other way; db-> ddl
<mlh> I know of a bunch of products that would do it ok, but I'm particularly looking for a complete, portable (ok, oracle) version
<mlh> mature
<poolie> i don't know
<poolie> aiui launchpad commits to a bazaar branch a series of 'alter table' etc statements which are replayed in order to update the database
<poolie> then from time to time they checkpoint the entire definition
<mlh> yeah that's what we do currently (except the for checkpointing :-)
<mlh> but rather than commit 'alter table' statements, I'd rather commit the state of the db everytime and derive 'alter table' statements from that
<mlh> so I could generate sql ddl but it might not be so easy to derive the 'alter ...' statements
<lifeless> right
<lifeless> in particular explicit relations are not enough to define logical sanity
<mlh> IDEALLY, you'd build the entire database every time, like you'd do a compile
<poolie> mlh, the alter statements have information about how to update existing data that's not present in the creation from scratch
<mlh> but it's just far too expensive for any decent size database
<lifeless> deltas -> snapshot is possible, snapshots -> deltas isn't, unless all possible constraints are defined within the db
<poolie> well, that's not enough if you need to update existing data
<mlh> poolie: example?
<poolie> uhm
<poolie> my syntax will be wrong but
<poolie> alter table customers rename column hair to hair_color;
<mlh> well I won't disagree, but I'm thinking it's not a fundamental restriction
<poolie> well, a diff between the overall ddl would presumably just drop and add that column
<poolie> so, at some level the information about how they relate needs to be captured
<mlh> oh ok.   I could infer a rename, git style :-)
<lifeless> this is what I mean, that you can start with deltas, but not with snapshots
<poolie> and we know how well that works :)
<poolie> but that is kind of a trivial example, suppose you're renormalizing to split a table into two or more
<mlh> well fair enough
<mlh> at a first passt (and possibly ultimate) I was more interested in validating a schema rather than producing it
<mlh> so I upgrade the db as usualy with 'alter ...' and whatever
<mlh> at some point I'd save the ddl
<mlh> I can then double check the upgrade operation by dumping the ddl and comparing to what's in bzr (dumped from the 'official' db)
<mlh> fwiw, in my experience tables hardly ever get normalized .. it's just too hard
<poolie> heh
<lifeless> mlh: theres a bunch of stuff in the xp world on managing db evolution
<lifeless> mlh: basically revolves around having a apply, revert methods on a class per evolution step
<lifeless> you could generate a 'is this correct' by doing that to an empty db and dumping the resulting schema
<lifeless> 3.51 seconds for st now
<lifeless> down from 3.84
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.6.1 now available! please test bzr-1.7rc1 |  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<jam> markh: https://edge.launchpad.net/bzr/1.7/1.7rc1
<jam> I just uploaded the official tarball
<markh> I just saw the svn plugin die a strange death (but it wasn't obvious it was the null-pointer issue in that bug).  I might see if I can repro that again...
<markh> the svn plugin seems very slow doing tests - I'm currently at "[590/982 in 65m26s,..." :(
<jam> poolie: ping
<poolie> jam, oh, hi
<poolie> congrats on the release
<jam> thanks
<jam> I still need to get the email out.
<lifeless> mwhudson: how do people profile extension modules.
<lifeless> mwhudson: its driving me batty
<poolie> jam, shall we talk?
<poolie> i'm a bit distracted by these disk errors tbh
<mwhudson> lifeless: i don't know
<jam> lifeless: I inspect the raw C code to make sure it doesn't have stuff like "PyGetAttr" all over the place.
<mwhudson> lifeless: callgrind?
<jam> poolie: I'd like to talk sometime, but it's almost midnight here, so I'm fine doing it some other time
<jam> poolie: do we have an idea on 1.8 RM?
<lifeless> jam: I know thats what you do; its laughably primitive compared to what I'd do on a regular C program with symbols.
<lifeless> jam: because its slow, manual, prone to errors
<lifeless> jam:
<poolie> jam, i'm happy to do it again, though it sounded like you might want to?
<lifeless> :!PYTHONPATH=. python -m timeit -s "from bzrlib.osutils import _walkdirs_utf8 as walkdirs" "print len(list(walkdirs('../test-repos/mozilla')))"
<poolie> i think we should work out if we want to keep the changes you did or not
<lifeless> 10 loops, best of 3: 695 msec per loop
<lifeless> down from 1000ms
<poolie> like having a trunk freeze period
<jam> lifeless: sounds good, just make sure you have a good test suite behind it :) I've certainly gotten caught up in benchmarking only to find out it was fast because it was wrong.
<jam> poolie: I'm fine relaxing some of that freeze. I think I was mostly coming off of the 1.6 delay and wanting to not have 10 more regression releases.
<jam> I *do* think we want it to be "1 week of minimal disruption"
<jam> And was sort of thinking that way going towards 1.8
<jam> But 1.6rc5 and 1.6.1rc2 was not particularly pleasant.
<jam> (And that was after what, 1.6b3 ?)
<poolie> i'm sure
<poolie> it wasn't very nice for me either leading up to that
<lifeless> jam: thats another reason I want to avoid putting complex C logic in pyrex; its kinda hard to test from python, given that the whole speed thing is about not exposing each logical step to python
<poolie> i guess i'd rather branch earlier and leave trunk open
<poolie> i can understand the temptation to try to make robert work on the release but it didn't seem to work :-)
<markh> jam: uploading now
<poolie> i can't believe Windows has no builtin ability to write an iso to disk
<poolie> amazing
<lifeless> poolie: 'antitrust'
<jam> poolie: I think it started to
<jam> In XP or so
<jam> But no built-in DVD player, etc.
<jam> Even if you *buy* a DVD drive, you always get some random 3rd party tool
<jam> which you may forget about when re-installing.
<poolie> not in vista afaics - you can write single files but not an iso
<markh> imgburn is a reasonable freebie for burning
<jam> poolie: ah, you're right. It supports a different method.
<jam> markh: Is that upload from the official tarballs, or did you use bzr.dev?
<lifeless> jam: I'm currently writing a pure C walk-and-stat-loop
<markh> jam: from the branch
<lifeless> jam: I want to have an accessible 'this is what we should expect'
<jam> markh: I just want to make sure you had the latest tip. I had to fix NEWS as a last commit.
<jam> I accidentally called it 1.7 instead of 1.7rc1
<jam> lifeless: Depending on what you want, I'll wrap the inner functions in a python wrapper so I can test them directly
<jam> but the C code ignores the python form
<poolie> markh, thanks
<jam> cdef versus def
<jam> etc
<poolie> i can get around it, i probably have a copy of nero somewhere, i just think it's bizarre
<poolie> but it's probably antitrust as robert says
<markh> jam: nope, I missed that last change.  I've cancelled the upload.
<markh> should only take a few mins to rebuild
<jam> poolie: Well, I'd rather they had a synaptic style package manager, too... :)
<jam> Getting bootstrapped on win32 is always a pain.
<markh> most nero oem versions know the drive model they were sold with!
<markh> and refuse to work on others
<markh> well - I've seen that more than once, so I'm calling it "most" :)
<jam> poolie: what is our general policy about 3rd-party announcements?
<jam> I just saw a "bzr-gedit" email on bazaar-announce
<poolie> onto our announce list?
<poolie> i think it's ok for plugins
<lifeless> whats its there for really ;)
<poolie> unless you think it's too noisy, in which case maybe ask them to throttle back
<jam> I'm thinking to let it through.
<jam> Just have to be careful, because I almost hit a spam entry.
<jam> Well, *I'm* the noisy one in the bzr-1.6 release.
<jam> With what, 7 announcements in a week?
<jam> Though I throttled myself.
<spiv> jam: that sounds uncomfortable ;)
<jam> spiv: It can be, but you pass out before you cause real harm :)
<poolie> jam, so you should go to bed
<poolie> i'll be working from spiv's couch as i said but just ping me tomorrow
<poolie> and we'll talk
<jam> poolie: sure
<jam> I'm just getting 1.8 opened in bzr.dev
<lifeless> my vote is less stress on releases
<lifeless> let the steady state drive things
<lifeless> if that state is too low, stressful releases won't fix it
<mwhudson> poolie, jam: is the fix for https://bugs.edge.launchpad.net/bzr/+bug/261315 going to be in 1.7 ?
<ubottu> Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,Fix committed]
<jam> I approved it, but I don't think Martin submitted it.
 * jml frowns.
<jam> rc2 is just a release away if it is important :)
<mwhudson> it's important
<lifeless> ok
<lifeless> now this is interesting
<lifeless> :!time ./readdir
<lifeless> Count: 5769
<lifeless> real    0m0.662s
<lifeless> user    0m0.232s
<lifeless> sys     0m0.428s
<lifeless> :!time find ../test-repos/mozilla/ -size 0 -size 1
<lifeless> real    0m0.344s
<lifeless> user    0m0.092s
<lifeless> sys     0m0.236s
<lifeless> ><
<lifeless> still, this is encouraging, that a naive C program is slower in sys time than find :P
<lifeless> (than find's total time)
<lifeless> far out
<lifeless> time to mail this out
<mlh> find caches some stuff dunnit?
<mwhudson> also avoids stat-ing things if it can
<lifeless> mlh: fchdir() is the magic
<lifeless> mwhudson: nothing to do with it
<lifeless> mail to the list, enjoy, taking a breather
<lifeless> 615ms now
<vila> Good morning readdir
<vila> errr bazaar
<Verterok> morning vila
<vila> hi Guillermo !
<samurai> ERROR
<lifeless> and st is down to 3.34 seconds from 3.84
<strk> ERROR: No such file: '/srv/bzr/gnash/.bzr/repository/pack-names': [Errno 2] No such file
<strk> now what ?
<strk> I killed while committing....
<strk> am I lost ?
<strk> can I copy the file from another developer ? or regenerate it ?
<strk> actually, I've no /srv/ dir, so could be on the server side
<speakman> hi folks !
<strk> ERROR: No such file: '/srv/bzr/gnash/.bzr/repository/pack-names': [Errno 2] No such file
<strk> speakman: any idea about the above ? (I killed 'bzr' while committing)
<james_w> strk: hmm, it seems you killed it at a very bad time
<james_w> lifeless: ^
<james_w> strk: and it does sound like it is server side then
<speakman> I've got an issue which I'm not sure how to deal with; If I have one mainline called "trunk" and a branch of that called "new_feature", both laying in my homedir like "~/myproject/trunk" resp. "~/myproject/new_feature". Now, if there has been some greate improvments on the trunk - is it okay to first merge all new stuff from "trunk" into "new_feature", and when all conflicts are solved merge the "new_feature" branch into "trunk"?
<james_w> strk: you can probably regenerate the file
<strk> and it made *every* shared branch unusable :(
<james_w> speakman: yes, that's perfectly fine
<speakman> james_w: is it the prefered way to go?
<speakman> (aka, or are there any other way to do it?)
<james_w> speakman: either way works
<james_w> you could just merge "new_feature" in to "trunk"
<speakman> but i might still need to continue working on the "new_feature" branch, but I also need the improvments from "trunk" to make it work (conditions has changed, and fixes are in "trunk"). Thats my issue right now.
<speakman> the former way seems to do the trick, but I wasn't sure about how messed up the "trunk" log will be when merging "new_feature" branch since "trunk"'s already in "new_feature".
<speakman> I'm pretty new to VCS if it wasn't obvious :)
<speakman> I just wanted to know if it will mess up anything to regulary merge trunk into feature-branches.
<lifeless> james_w: I'm really not here
<lifeless> james_w: please look at the rename code, it probably wrote to a temporary name, so its recoverable
<james_w> speakman: not at all, and it won't mess up your "trunk" log
<james_w> lifeless: thanks
<strk> james_w: can you help with fixing the broken thing ?
<lifeless> james_w: start with the method in pack-repo, which does the insertion, follow it into sftp transport
<james_w> strk: yes, just looking
<lifeless> strk: you're using sftp right ?
<strk> lifeless: yes
<strk> does james_w have access to the server ?
<lifeless> strk: sftp prevent atomic renames (acts likes windows not posix) so there is an an unavoidable race
<strk> I wonder why they switched to it then
<lifeless> strk: he'll learn a little about the guts of this, then probably get you to use 'sftp' or 'hitchiker' or some such to do the recovery
<lifeless> strk: no idea, they did not discuss with me, or any bzr dev I know of
<james_w> strk: so, there should be a temporary file 'at /srv/bzr/gnash/.bzr/repository/%s.tmp.%.9f.%d.%d' % (abspath, time.time(), os.getpid(), random.randint(0,0x7FFFFFFF))
<james_w> there may actually be two
<james_w> strk: lifeless seems to suggest that you don't have ssh access to the server, is that correct?
 * kinkie is away: lunch
<strk> no idea, I might have it
<strk> lemme try
<strk> uhm, Permission denied (publickey).
<strk> never logged before
<strk> lemme ask on #savannah too
<james_w> you clearly have sftp access, which should be enough, but I have never used it to give you exact instructions
<strk> trying to ssh into bzr.savannah tells me I'm not allowed to execute commands
<strk> tried no command and /bin/sh...
<james_w> we'll have to use sftp then, do you have any experience with that?
<strk> entry-level
<james_w> better than me then
 * strk trying to connect in sftp
<james_w> you need to look in /srv/bzr/gnash/.bzr/repository/
<strk> ok, I'm in
<strk> I'm there
<james_w> for files with the pattern "<path>.tmp.<pid>.<random>"
<james_w> there may be more than one
<strk> tmp.pack-names.1221039958.462796926.26759.lg3cf8o308
<strk> pack-names.tmp.1221039957.749309063.26759.1014578531
<strk> END
<james_w> ok, let me get this right
<strk> -rw-rw-r--    0 69570    6469          844 Sep 10 11:46 pack-names.tmp.1221039957.749309063.26759.1014578531
<strk> -rw-rw-r--    0 69570    6469          794 Sep 10 11:39 tmp.pack-names.1221039958.462796926.26759.lg3cf8o308
<james_w> I think we need "pack-names....". I think "pack-names...." will have one more line than "tmp..."
<james_w> ok, so could you rename "pack-names...." to "pack-names" please?
<strk> can I copy ?
<james_w> that will work too
<strk> uhm, sftp doesn't know how to copy, I'll get for backup and rename
<strk> done
<james_w> it got killed just before it renamed that file to "pack-names", just after it renamed "pack-names" to the other one to allow for rollback
<james_w> great, you should now be able to start work again
<strk> it seems to be working
<strk> great. thanks a lot.
<james_w> "bzr log sftp://bzr.savannah/srv/bzr/gnash/trunk" or whatever would be a good sanity check
<james_w> check that the latest revision is the one that you committed when you got the problem
<strk> bzr viz succeeded. wheter there's anything missing I dunno
<lifeless> james_w: the rename code will tell you the difference
<lifeless> james_w: please also file a bug - this 'theoretical' race is clearly a problem
<lifeless> I've been suspicious of this magic method for a while
<james_w> lifeless: the difference in what?
<lifeless> james_w: which is the old and which is the new
<james_w> do you want the bug about pack-names, or about sftp put?
<james_w> lifeless: yeah, I was just double checking I was reading the code correctly.
<lifeless> what ever method failed epically
<lifeless> should not exist as-is
<james_w> ok, I'll file it and you can fix it up appropriately
<speakman> now I got stuck into a strange "resolve" behaviour: Conflict: can't delete languages because it is not empty.  Not deleting.
<speakman> "languages" is a subdir which contained a few files. They were deleted on the "trunk" and now med "trunk" was merged into "new_feature" branch, it said it couldn't delete the subdir.
<speakman> removing it manuallt didn't help
<strk> you don't compile the list of changes for upgrades ?
<speakman> not even recreating it empty will make "bzr resolve" fall trough
<strk> the update manager always says "The list of changes is not available yet. Please try again later." for bzr
<strk> fetching from the 'bleeding edge' repository
<strk> (deb http://ppa.launchpad.net/bzr/ubuntu hardy main)
<lifeless> strk: it looks for a special file,I don't think ppas create it, no
<unangz> hello master2
<unangz> i get stuck probelm
<unangz> how to checkout from windows repository to ubuntu linux
<lifeless> speakman: it probably can't be deleted cause your branch has more files, or local files
<lifeless> speakman: jst bzr resovle  <path> it
<lifeless> speakman: *then* bzr rm it
<unangz> i was tried use ftp to checkout from windows, but when i commit, i get problem
<unangz> the message error indicate bzr is locked
<speakman> hm, that did work, thanks
<speakman> why didn't "bzr resolve" work?
<lifeless> speakman: with conflicts in the text of a file we can tell when you have deleted them
<lifeless> (the <<<< is gone :)
<speakman> unangz: paste your output to a pastebin
<lifeless> with files on disk, we haven't written logic to tell when you've made it go away satisfactorily. It's probably doable
<speakman> lifeless: oh, i see :)
<lifeless> s/files/file-names/
<speakman> one more question; what's your favorite "conflict resolver" tool? ;)
<lifeless> for paths, 'mv' and 'bzr mv/bzr rm' :)
<lifeless> for inside a file, I usually just read with vim
<lifeless> <- not sophisitcated in that area
<speakman> oh, okay :)
<lifeless> I believe aaron uses vimdiff
<speakman> I use kdiff3 alot, but I do all my development in emacs and I think emacs is almost as capable as kdiff3, just havn't had the time to learn how to.
<lifeless> and there is an emacs mode
<awilkins> speakman: I like Beyond Compare 3
<awilkins> speakman: Payware, but cheap, and IMHO the best file/folder compare tool I've used.
<lifeless> awilkins: nice rant :P
<jelmer> lifeless, what happened to your index work?
<jelmer> lifeless, I'm looking at how hard to expose the git working tree and index to the user atm
<lifeless> btrees? its landed
<lifeless> oh, marks.
<lifeless> marks != i
<lifeless> 'index'
<lifeless> 'index' bad
<jelmer> heh
<lifeless> reread the 'marks' thread - 'review support' I think it was
<bob2> btrees is in 'development'?
<lifeless> BTreeGraphIndex is in bzr.dev
<lifeless> night all
<speakman> btw, any trac-bzr ppl here? :)
<jelmer> speakman, hi
<jelmer> james_w, ping
<james_w> hey jelmer
<jelmer> james_w: What's your preferred branch layout for debian packeges in bzr branches?
<james_w> you mean full-source vs. debian only?
<jelmer> james_w: yeah
<jelmer> it seems we're using both for pkg-bazaar at the moment, it would be nice to standardise
<jelmer> at least for new packages
<james_w> I prefer full-source
<james_w> I can't remember the discussion we had at the time to know what the arguments really were
<jelmer> the main thing was disk usage and performance I think
 * LarstiQ would probably lean towards just regular branches of upstream too, nowadays.
<jelmer> LarstiQ, Cool
<jelmer> siretart, Do you prefer either?
<kenyon> We have a problem: this is what happens: http://paste.ubuntu.com/45311/ when I  say "bzr branch lp:~federico-pelloni/ejecter/main"
<kenyon> so i need to activate launchpad's server certificate - but how?
<kenyon> where can i get that cert and where do i put it?
<james_w> kenyon: install ca-certificates if you are on Ubuntu or Debain
<siretart> jelmer: I also prefer full source. I remember that lifeless preferred debian only, though.
<awilkins> Any of you chaps know which/whether "time" is in GNUwin32 and which package?
<siretart> james_w: I think the best argument of 'debian'-only is that it is trivial to mount it over a more recent bzr checkout and build upstream snapshots with it.
<james_w> siretart: yes, I guess it is easier
<kenyon> james_w: thank you - it seems it was already there - dpkg -l|grep cert said:  ii  ca-certificates 20061027-0ubuntu0.2
<kenyon> i would maybe try and disable pycurl cert verification
<siretart> james_w: however, with debian only we now have a very hard time to import the last NMU to the debian package :-(
<james_w> siretart: doing the merge and failing if there are conflicts is more robust in the face of patches to the source
<james_w> kenyon: sorry, I didn't actually look at your error. That's on I've not seen before
<kenyon> cant i just download via ftp or http form lp ?
<james_w> kenyon: do you have a proxy in the way?
<james_w> kenyon: if you run "bzr launchpad-login <your lp id>" and try again it should work
 * awilkins answers his own question ; "time" is a bash command, not a GNU util.
<james_w> awilkins: I think it's both
<awilkins> james_w: Maybe they haven't ported it to win32 then ; I know it's in Cygwin bash but I can't find an obvious package for it in gnuwin32
 * awilkins considers writing a PoSH version
<james_w> awilkins: % dpkg -S /usr/bin/time
<james_w> time: /usr/bin/time
<james_w> so it's in the "time" package on Ubuntu
<kenyon> james_w  thank you  - seems my bzr is too old, it does not recognize the launchpad-login command
<james_w> kenyon: what version are you using?
<kenyon> Bazaar (bzr) 0.15.0 on feisty
<james_w> oh, ok
<kenyon> james_w i think i will give up on this and use a different newer machine
<poolie> vila, hello?
<vila> hey !
<vila> I'm not used seeing you up so late :)
<poolie> heh
<poolie> i shouldn't be up so late
<poolie> vila, meet pmatulis
<vila> his client quited  it seems
<pmatulis> ah
<poolie> ding
<vila> pmatulis: oh, you're here, hi :)
<speakman> jelmer: ure still there?
<jelmer> speakman, yep
<speakman> jelmer: great, i found a bug with trac-bzr, but I just recalled I posted a bugreport on LP: https://bugs.launchpad.net/trac-bzr/+bug/267700
<ubottu> Launchpad bug 267700 in trac-bzr "Can't view changesets on branches" [Undecided,New]
<speakman> updated it...
<HippySurfer> Hi, Newbie Alert. I am trying to work out how to use bzr to enable myself and a friend to collaborate. We are not able to host a shared repository anywhere. So I thought that I could give him a mirror branch and then send him merge directives created from my branch. But it does not work, when he attempts to merge my merge directive he gets an error message: zr: ERROR: Invalid url supplied to transport: "file:///Users/rjt/Tmp/bzr_test/m
<HippySurfer> ain/": Win32 file urls start with file:///x:/, where x is a valid drive letter". This suggests that bzr is trying to access my main branch, which he does not have. I am a bit lost ...
<abwesend_0> http://www.hanf-spiel.de/137695
<abwesend_0> http://www.hanf-spiel.de/137695
<jam> does anyone know what Ubuntu package to install to get man pages for stuff like "stat" ?
<jam> I guess I'll try "manpages-dev"
<LarstiQ> jam: manpages-posix-dev?
<jam> I'm just used to them being installed by default
<jam> from 'ages' ago
<jam> LarstiQ: thanks for the pointer. Weird "manpages-dev" is a standard package, but "manpages
<jam> "manpages-posix-dev" is not
<jam> It's a "multiverse" package
<jam> anyway 'manpages-dev' had what I needed. Now to figure out the exact size of "off_t" :)
<jam> thanks statik, now I can take over the world with bzr nightlies :)
<jam> btw, do you have any plans to abort the build if the revno hasn't changed?
<statik> jam: np, just added the others to the team as well. right now what i think will happen is the PPA will reject the upload if the version hasn't changed
<jam> statik: well I think 'dch' will also abort
<jam> unless you supply the '-b' flag
<jam> otherwise it doesn't let you supply a version string that sorts <= the current string
<statik> in that case, moving from a plain script to a makefile would make this cleaner, so the first failed command stops things
<james_w> set -e
<statik> james_w: will that make my script stop at the first error?
<jam> statik: yes
<statik> awesome
<james_w> statik, if you want to override it for a specific command add "|| true" at the end
<statik> oh nice
<willyyam> is there an easy setting to get bzr to add files with unicode filenames?
<jelmer> willyyam, it should already be able to add files with unicode names
<jelmer> willyyam, perhaps the file names are not valid characters within your current system encoding?
<willyyam> very possibly - I've got windows users putting files into a samba share
<willyyam> bzr is running on the linux side - I'll look into my LANG
<james_w> willyyam: bug 187267 may interest you
<ubottu> Launchpad bug 187267 in bzr "UnicodeDecodeError with non-ASCII character in filename" [Medium,Confirmed] https://launchpad.net/bugs/187267
<willyyam> the bug mentioned by james_w and ubottu seems to be on the money - my LANG is en_CA.UTF-8, which should be allright, no?
<willyyam> is there a way to check the encoding of an individual samba share?
<james_w> I'm not sure
<willyyam> basically, bzr is using the ascii codec to inpret the file list - is there a way to force utf8 interpretation?
<willyyam> s/inpret/interpret
<willyyam> trailing characters :-)
<LarstiQ> willyyam: setting your locale
<LarstiQ> willyyam: at commit time it needs to be correct that is
<willyyam> my locale is correct - en_CA.UTF-8
<jam> abentley: I'm getting 404 errors with wget and bzr when trying to merge a BB patch
<jam> Ah, I might know why
<jam> just a sec
<jam> nope, quoting it wasn't the solution
<jam> ah, single quoting was
<jam> the problem is this one: http://bundlebuggy.aaronbentley.com/request/%3C021201c90ff8$df217e30$9d647a90$@com.au%3E
<jam> It has "$" characters in it
<jam> so you have to use '' around the URL. :(
<jam> Would it be terrible to munge the URL a bit more?
<abentley> jam: I've been meaning to make the URLs be based on numeric ids, rather than message-ids.  With the current mechanism as a fallback.
<abentley> I suspect if I %encoded $, browsers would "helpfully" decode it.
<gotgenes> I bound my bzr branch to my branch on Launchpad. It gave me some business about my format being deprecated, and to run bzr upgrade. I just ran a bzr upgrade, which failed. I moved the file backup.bzr to .bzr. Now Bazaar tells me "no repository present".
<gotgenes> Suggestions?
<lifeless> gotgenes: I am just leaving, but you'll probably need to give the url to people to have a look themselves
<lifeless> gotgenes: also, I encourage you to file a Question on launchpad-code
<gotgenes> lifeless: the problem is on my own machine, not LP
<pickscrape> Could it be that a different .bzr needs moving? i.e. if you're using a shared repository? Just a guess.
<gotgenes> Could be, but I followed the directions to the t:
<gotgenes> http://rafb.net/p/VEHgWf58.html
<gotgenes> Ugh, here's a better paste http://paste.pocoo.org/show/84956/
<pickscrape> Does a .bzr directory exist at all?
<gotgenes> pickscrape: yes
<pickscrape> If so, what's in it?
<pickscrape> I'm betting there's a .bzr in it
<gotgenes> http://paste.pocoo.org/show/84957/
<pickscrape> ok, I think I know what's happened
<gotgenes> There's a "backup.bzr" in it
<pickscrape> mv .bzr/backup.bzr .
<pickscrape> mv .bzr old-bzr
<pickscrape> mv backup-bzr .bzr
<gotgenes> pickscrape: k, giving it a try
<gotgenes> pickscrape: brilliant! http://paste.pocoo.org/show/84958/
<pickscrape> So when you thought you were moving the .bzr back, you were actually moving it under the failed upgrade .bzr, which needed moving away first.
<pickscrape> xcellent!
<gotgenes> ah, well, I see now
<gotgenes> that makes sense
<gotgenes> many thanks, pickscrape!
<gotgenes> BTW what guitars do you play?
<pickscrape> No problem, glad it was so simple :)
<pickscrape> :) I have a Les Paul Studio Lite M-III and a Charvel Model 3.
<gotgenes> Nice!
<gotgenes> I've never played a Charvel
<pickscrape> The Charvel needs new pickups and bridge though. Lovely neck though.
<pickscrape> Did that question stem from my nick?
<gotgenes> Makes a huge difference if you love the neck
<gotgenes> yes, it did
<pickscrape> I think you're the first person to actually get it and not think it's just plain weird :)
<gotgenes> haha
<gotgenes> that's okay, I play some, too, so I saw your SN and said, "Ah, a guitar player!"
<pickscrape> :) I don't play anywhere near as much as I used to (and should). Just don't have time these days
<gotgenes> pickscrape: Same boat, but I still try and get in some playing every day, or at least every two.
<pickscrape> I'm lucky if I play every two weeks :(
<gotgenes> pickscrape: Anything's better than nothing. :-)
<pickscrape> True that
<jonnydee> lifeless: Hi :) I'm glad to see your fix for bug 255656 has been merged into 1.7 series. Shall I change status to "Fix committed" or "Fix released"?
<ubottu> Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] https://launchpad.net/bugs/255656
<rockstar> jam, we need to make sure not to miss TWiB tomorrow.
#bzr 2008-09-11
<markh> jelmer: ping
<jelmer> markh, pong
<markh> hi jelmer - a couple of things - the 0.4 branch is still what I should be using for windows 1.7 builds?
<jelmer> markh, yep
<markh> and have you seen the thread on the mailing list talking about the crash?
<markh> identifying the env var etc
<jelmer> the DLL mess you mean?
<markh> well - its not that bad as it turns out
<markh> "As it happens, on my system APR_ICONV_PATH was set to c:\program files\subversion\iconv (perhaps created by a SVN installer)"
<markh> from the most recent mail in the thread on the mailing list
<markh> which leads to question 2 1/2 :) he suggests using svn 1.5 libs would be a good option
<jelmer> using 1.5 instead of 1.4 would always be a good idea
<markh> and I believe he is suggesting we just ensure to clobber that env var before loading svn
<markh> bb in 20 mins...
<jelmer> I'm not sure that's going to work in all situations
<jelmer> I'm getting some sleep in a few minutes
<jelmer> markh, Will be back tomorrow CET time
<mwhudson> poolie: i don't want to be a pest, but are you going to land http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480809050416r72b3f857h4a664a2cc4e157b0%40mail.gmail.com%3E ?
<poolie> !!
<poolie> i did send it
<poolie> hm that kind of sucks
<mwhudson> i don't think it's in bzr.dev, it's possble bb is out of date
<mwhudson> doesn't seem to have landed
<poolie> it may have bounced
<poolie> we'll need to get that into 1.7
<poolie> thanks for reminding me
<mwhudson> yes please :)
<fullermd> Hm.  http://live.gnome.org/Bazaar says "For best performance, install 1.6b2."
<jml> what do I need to do to serve bzr+http files from my apache?
<jml> or is there a bzr plugin that will create a mini-server that will do the same?
<poolie> jml, i think there is documentation on how to hook it up in mod_python
<poolie> but also tim will know about the mini-codehost project
<poolie> which may help
<jml> well, it's mostly for testing purposes.
<jml> so even something launched a toy web server with support would be fine for me.
<jml> poolie: how do you spell NULL_REVISION for weave repos?
<poolie> it should be the same, but old code might use None
<jml> thanks.
<Peng_> jml: bzr+http is very simple to set up. Take the script from the documentation, put it somewhere, then use mod_rewrite or something to point "foo/.bzr/smart" to it.
<Peng_> It just uses WSGI, so you can use CGI or FastCGI or mod_wsgi or whatever you want.
<jml> Peng_: the docs are in the bzr source tree?
<Peng_> jml: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi
<jml> Peng_: thanks.
<seyacat> hi bazaarmens
<seyacat> please a question
<MolePrince> Evening.  Does bzr support 'forests' well.  ie, I have a dozen projects that I want to maintain individual revisions/logs for, but be able to update/check them all out en masse if I work on a different terminal for instance.
<seyacat> i make a copy of brach, and in copy i make a new file.  I use "bzr merge" to update the parent branch, but merge not copy new file
<jml> MolePrince: the bzrtools plugin has 'multi-pull', which may be close to what you want.
<MolePrince> jml: Thanks, I'll look into that.
<jml> seyacat: did you do 'bzr add <new-file>' and then 'bzr commit' in the copy?
<seyacat> yes i make "add" and "commit"
<jml> seyacat: hmm. can you pastebin the exact commands you used, starting with the copy?
<seyacat> where is pastebin?
<seyacat> F:\bzrtest\copia>bzr status
<seyacat> unknown:
<seyacat>   prueba/newfile.txt
<seyacat> F:\bzrtest\copia>bzr add prueba
<seyacat> added prueba/newfile.txt
<seyacat> F:\bzrtest\copia>bzr commit
<seyacat> Committing to: F:/bzrtest/copia/
<seyacat> added prueba/newfile.txt
<seyacat> Committed revision 4.
<seyacat> F:\bzrtest\copia>bzr merge
<seyacat> Merging from remembered parent location F:/bzrtest/repo1/
<seyacat> Nothing to do.
<fullermd> MolePrince: You're looking for "nested trees".  In-progress feature.
<seyacat> it can be a windows bzr problem?
<fullermd> seyacat: No, you're doing it backward.  That bzr merge is trying to merge new stuff FROM repo1 INTO copia.  If you want to merge new stuff FROM copia INTO repo1, you need to cd ../repo1 ; bzr merge ../copia
<seyacat> yes i can see ita work... and what is difference with pull command?
<fullermd> Roughly speaking, 'pull' updates your copy of another branch.  'merge' merges in changes from the other branch into yours.
<seyacat> aaa i cant make chain checkouts branches
 * fullermd doesn't know what that means...
<seyacat> im very very happy, i understand bzr at last,  its nicer than i think
<seyacat> ty fullermd , you are a good suppot
<fullermd> np  :)
<poolie> well done
<jml> the links to modpywsgi are broken :(
<jml> ok, now I'm getting this error when I try to branch via bzr+http: http://paste.ubuntu.com/45643/
<Verterok> jml: I think it's 1.6b4 problem
 * jml updates that branch
<Verterok> it's fixed in 1.6.1
<jml> ok, now I'm just getting 'not a branch', which makes me happier.
<poolie> markh, re bug 251701 do you know if paramiko is sure to be in the windows binaries now?
<ubottu> Launchpad bug 251701 in bzr "windows stand alone v1.6 does not include parmiko - seriosly breaking expectaions." [Undecided,New] https://launchpad.net/bugs/251701
<markh> hrm
<markh> poolie: that surprises me.  it was in the first few builds I made, and it seems be in the last 1.6 build I made
<poolie> it may be invalide
<poolie> or user erro
<poolie> i'd appreciate if you could look
<vila> Good morning Bazaar
<spiv> vila: Good morning.
<jml> why do the http smartserver instruction say to do: Alias /srv/example.com/scripts/bzr-smart.fcgi /srv/example.com/scripts/bzr-smart.fcgi
<jml> that seems... redundant.
<markh> poolie: it is also certainly there in 1.6.1 and 1.7 builds
<markh> I suspect that bug was user error, but just marking it as "fixed" would work.
<jml> small doc patch on the list.
<jml> massive review karma going for cheap
 * markh just had the brain-wave he could close it, so did...
<spiv> jml: because I suck at configuring apache
<spiv> jml: I twiddle until it works, and then I twiddle some more to tidy up, and things mysteriously break, so I undo that and just go with messy-but-working and get on with more important things.
<jml> oh right.
<jml> spiv: well, my patch makes things a little better.
<jml> Peng: so, I'm looking at a development copy of Launchpad, mirroring branches from a bzr+http server on my own laptop. it makes a lot of posts to .bzr/smart (as well as a few GETs of control and format files) -- I'm guessing that's bzr+http mirroring.
<Peng_> jml: What?
<jml> Peng_: you know about bug https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/245918?
<ubottu> Launchpad bug 245918 in launchpad-bazaar "Puller should use bzr+http when it can" [Medium,In progress]
<Peng_> Right. You got it working?
<Peng_> Could someone do me a favor? Try to 'bzr branch http://bzr.mattnordhoff.com/bzr/imports/lighttpd/trunk/' outside of a shared repo with 1.7rc1 or bzr.dev. I get a format error (it's a rich-root-pack branch). nosmart+http works fine though, and so does branching locally.
<jml> Peng_: well, I *think* it's working, but what I want to know is "how do I know when it's working"
<speakman> I think I found a bug in bzr-svn: Can someone try to branch svn://uclibc.org/trunk/buildroot ?
<spiv> POSTs to .bzr/smart is smart-over-http, yes.
<jml> Peng_: I get http://paste.ubuntu.com/45655/
<jml> spiv: thanks.
<Peng_> jml: Yeah, that's what I get. That would be a bug, then.
<Peng_> Actually, I have the same issue in 1.6.1.
<Peng_> And "bzr info" says it's an unnamed format, so now I'm totally confused.
<spiv> "bzr info -v" is helpful when it says unnamed.
<spiv> It's often just format 5 branch with pack-0.92 repo.
<Peng_> I have a format 7 branch in a rich-root-pack repo.
<Peng_> Is that not how rich-root-pack is supposed to be?
<Peng_> Which is branch 7?
<mwhudson> 'supports stacking'
<spiv> It allows stacking, IIRC.
<Peng_> Oh, really? How did I get that?
<Peng_> Hmm, my local copy is Branch6 as it should be.
<Peng_> So...when does bzr decide to upgrade remote branches to support stacking?
<Peng_> And then not upgrade the repo?
<spiv> I would have assumed when --stacked is used.
<spiv> But that doesn't explain your situation.
<Peng_> spiv: It tries to upgrade the source branch?
<spiv> Check your ~/.bzr.log?
<Peng_> I may have tried to branch --stacked from it as a test, but I don't even remember doing that.
<spiv> I'm not very familiar with this end of things.
<Peng_> spiv: What do I grep for? "Upgrading random branch for fun"?
<spiv> AFAIK bzr never silently tries to upgrade anything.
<Peng_> Right.
<spiv> Maybe search your bzr.log for --stacked?
<Peng_> Oh, good idea.
<Peng_> I am not in the mood for figuring out weird bzr issues. Hmph.
<spiv> So far I'm guessing it's a weird user issue ;)
<Peng_> Grep says I have never used --stacked in my life.
<Peng_> At least in the history of my .bzr.log
<Peng_> OK, here we go. According to .bzr.log.old, I twice tried to "bzr branch --stacked" that branch locally.
<Peng_> But it upgrades the source branch? That makes no sense.
<spiv> I doubt it.
<spiv> Maybe you simply pushed the local --stacked branch up?
<spiv> And bzr push then preserved the format (but not the stacking)?
<Peng_> Both times I tried to "bzr branch --stacked", it yelled at me about IncompatibleRepositories.
<spiv> In that case, no idea.
<speakman> Is the bzr-svn stable, or should I expect vital bugs?
<Peng_> :)
<Peng_> I scared poolie away. :(
<spiv> Maybe check .bzr.log on the server in case someone is did something strange on that end?
<spiv> Peng_: nah, he just hopped on his bike and went home.
<Peng_> spiv: I did check .bzr.log on the server.
<spiv> speakman: it's been stable for me
<spiv> Peng_: dang.  There goes another idea.
<Peng_> On my PC, I have never once used --stacked in the history of .bzr.log and .bzr.log.old.
<speakman> spiv: could you please try to branch svn://uclibc.org/trunk/buildroot ?
<Peng_> On the server, I twice tried to locally "bzr branch --stacked" that branch, and both times it failed.
 * Peng_ blames poolie since he's not here. :)
<spiv> speakman: I don't have the spare bandwidth for that atm, unfortunately :(
<Peng_> How big is that branch? I have spare bandwidth, but not spare RAM. :)
<spiv> speakman: are you getting an error?
<spiv> Peng_: the current bzr-svn release is much friendlier RAM-wise.
<spiv> (compared to early this year)
<Peng_> True
<Peng_> beuno: ping?
<speakman> UnicodeDecodeError: 'utf8' codec can't decode bytes in position 85-87: invalid data
<speakman> can I make bzr run under ipython, and use ipython's more informative traceback?
<speakman> it seems to crash in the "insert_revprop" function in logwalker.py
<speakman> self.cachedb.execute("replace into revprop (rev, name, value) values (?, ?, ?)", (rev, name.decode("utf-8"), value.decode("utf-8")))
<a7p> Verterok: everyting fine - just tested it.
<Verterok> a7p: great! :)
<a7p> should I confirm the bug fixed on lp?
<a7p> Verterok: thanks a fixing it.
<Verterok> a7p: no, I marked it as "Fix committed", but if you encounter any problem, just reopen it :)
<Verterok> a7p: np, this new build also comes with some extra goodies ;)
<a7p> Verterok: I saw that, that's why I asked if futher confirment is needed.
<a7p> Verterok: I am going to check it out as soon as I finished this (ugly) flash project I am suffering from at the moment.
<Peng_> beuno: Never mind about the ping. I just filed bug 268867.
<ubottu> Launchpad bug 268867 in loggerhead "Breadcrumbs ignore PrefixMiddleware" [Undecided,New] https://launchpad.net/bugs/268867
<Verterok> a7p: ok, just let me know if you hit that bug again
<a7p> Verterok: I will.
 * Verterok is off to bed, g'night all
<mwhudson> Peng_: i guess the breadcrumbs should key off SCRIPT_NAME somehow
<Peng_> mwhudson: Oh, hi. :)
<Peng_> mwhudson: They should do it the same way every other link does, cuz they get it right.
<Peng_> I came to the computer to do one thing, decided to read the mailing list and pull new changes out of boredom, and here I am an hour later. Oops.
<Peng_> OK, so how do I upgrade from branch7 to branch6?
<Peng_> "bzr upgrade" doesn't know how. Should I init/pull (I hate that hack).
<Peng_> ?
<mwhudson> bzr upgrade --packs should do it i think
<Peng_> "bzr upgrade --rich-root-pack errored out with "No converter".
<spiv> speakman: file a bug on bzr-svn in launchpad, jelmer is pretty good at fixing those sorts of things
<Peng_> Whew. Over 1 hour, 2355 bytes of IRC conversation, 1 bug and 1 long mailing list post later, I can get back to watching my depressing anime. Why did I decide to pull bzr.dev and get into all this? :(
<Peng_> (Also, why did I spend 10 minutes counting my IRC conversation?)
<Peng_> Anyway, good night everyone.
<spiv> Peng_: good night :)
<spiv> Peng_: thanks for the bug hunting!
<awilkins> Hmm : bug: bzr rocks does not respect "-q" argument
<awilkins> I'm looking for quiet optimism
<awilkins> :-P
<robsta> hi
<robsta> all of a sudden bzr seems unwilling to play with bzr-playground
<robsta> the error message is "bzr: ERROR: exceptions.AttributeError: 'ProtocolThreeDecoder' object has no attribute '_in_buffer'"
<robsta> Bazaar (bzr) 1.6.1, from the ppa
<robsta> can i go after this problem somehow?
<visik7> hi
<visik7> bzr-svn has some problem today
<visik7>  bzr-svn/ra.c:919: undefined reference to `py_svn_log_entry_receiver'
<visik7> what is it ?
<lifeless> robsta: ttry 1.7 perhaps, that looks likea local error, bt will tell you
<lifeless> visik7: no idea sorry, jelmer: may know
 * lifeless waves bye
<visik7> ok solved
<visik7> sorry
<robsta> lifeless: it may be related to the problem Jc2k just pinged you about, in #gnome-bzr
<visik7> I've this error using latest svn-bzr and latest svn http://dpaste.com/77418/
<visik7> sorry
<visik7> latest svn-bzr and latest bzr
<uws> visik7: That message is pretty clear, isn't it?
<visik7> I've the latest version
<uws> visik7: The bzr-svn you have is not compatible with the bzr version you have. you're running development code. stick to bzr 1.6
<uws> visik7: "the latest version" is 1.6.1
<uws> not 1.8dev
<Jc2k> does anyone have the address for canonicals rt?
<visik7> uws: my bzr is bzr.dev http://bazaar-vcs.org/bzr/bzr.dev/
<lifeless> Jc2k: #canonical-sysadmin should
<lifeless> *really* gone now, sorry
<uws> visik7: What's the problem?
<visik7> uws: I dunno I think I was on the devel branch of both bzr and bzr-svn
<uws> visik7: perhaps bzr-svn lags behind a bit?
<uws> visik7: it's called "devel branch" for a reason, namely that it is NOT stable or 'guaranteed' to work
<visik7> oh
<visik7> I misunderstood the error
<visik7> nevermind :P
<uws> visik7: ok
<poolie> vila, hi
<vila> poolie: hi !
<poolie> night!
<hersonls> I need register my RSA key fingerprint, where i do this?
<hersonls> i dont remeber
<Peng_> hersonls: Is this a Launchpad question?
<hersonls> yes
<Peng_> hersonls: There are instructions on the website, and you should ask in #launchpad anyway
<hersonls> sorry :]
<Peng_> hersonls: https://help.launchpad.net/YourAccount/ImportingYourPGPKey
<Peng_> Huh, if I branch an old knit branch over "http", with the bzr+http smart server available, it does most things over plain http and is very quick. If I explicitly use "bzr+http", it's extremely slow, makes a huge number of requests, and doesn't use plain http.
<Peng_> God, you guys *really* killed knits.
<fullermd> I'm vaguely tempted to see what happens if I access a weave branch over bzr+ssh...
<fullermd> Just out of sick, sick curiosity.
<Peng_> Hahaha.
<Peng_> Hey, it's done! It only took 7 minutes and made 1085 requests! That's not excessive, right?
<fullermd> Heck, that's not even 3 a second.  What a yawner.
<Peng_> You know, for a 2 MB branch with about 200 revisions?
<fullermd> That's 5 per revision...  a fifth of 2 megabytes is about 400k...   who'd want to do more than 400k a request either?
<fullermd> (I realize the math may not SEEM right, but...)
<Peng_> fullermd: You're actually right. ...Wait, no you're not. The responses were 435 *bytes*, not 435 KB.
<fullermd> So, see how awesome bzr is?  It's giving you 1000:1 compression!
<fullermd> Imagine how much slower it would be if it did more per request.
<Peng_> Say I file a bug, everyone ignores it for 4 months (ahem), and then when someone finally notices it, it's not reproducable anymore. How should it be resolved? Fixed or invalid?
<fullermd> Ideally, the third choice.
 * fullermd drags his "dammit, I need to write a BTS" out of the closet.
<Peng_> It took precisely 128 days for someone to notice the bug. Nice coincidence. :)
<Peng_> I wonder what Bazaar's average bug response time is?
<fullermd> I'll bet the standard deviation is huge.
<awilkins> Ranges from people who filed bugs so they have something to put a patch in, to bugs that were filed early on and never touched, I'll wager
<proyvind> hoia
<proyvind> anyone knows if it's possible to export just a directory of a repo?
<proyvind> I have a directory in my git repo which I want to export and import to bzr
<gimaker> Can anyone help me with an error I get when trying to branch a branch from LP: Permission denied (publickey).
<gimaker> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<gimaker> I can branch (bzr branch lp:peekabot) from my desktop, but not from my laptop
<gimaker> and they use the same bzr version (1.3.1, Ubuntu 8.04)
<ericvw> gimaker: Are you using public-key authentication?
<gimaker> ericvw, I have my pubkey uploaded to LP, yes
<gimaker> but it never even asks for the passphrase on my private key
<gimaker> (it does on my desktop, though - where it works)
<ericvw> how are you branching from your laptop?
<gimaker> "bzr branch lp:peekabot trunk"
<ericvw> Sorry, i am a bit unfamiliar with lp:peekabot syntax; could you clarify that for me?
<gimaker> lp:peekabot is the same as lp:///~peekabot-devs/peekabot/trunk
<gimaker> e.g. it's the "main branch of development"
<ericvw> I don't `lp` is a URL identifier that bazaar supports
<gimaker> it's supported if you have the Launchpad plugin, which is bundled with bazaar
<ericvw> the only thing I can think of is maybe you have two different private keys going on for some reason.
<gimaker> ericvw: yeah, that was it... I just figured it out too
<gimaker> Uploaded my 2nd one and now it works ok!
<ericvw> gimaker: Sorry, I am a bit new to Bazaar, but I know public-key quite well :D
<gimaker> I still think it's lame that a valid key is needed to branch from a public branch, though :)
<ericvw> is the lp:blah syntax just for the launch pad plugin?
<Odd_Bloke> gimaker: It shouldn't be.
<gimaker> Odd_Bloke: What should be? That I needed a pubkey to branch?
<gimaker> ericvw: yes
<ericvw> gimaker: Thanks, I should read up on that!
<Odd_Bloke> A valid key shouldn't be needed to branch from a public branch.
<Odd_Bloke> Though I suspect that's a known bug once you've launchpad-login'd.
<gimaker> Odd_Bloke: exactly...
<Odd_Bloke> If you remove 'launchpad_username' from ~/.bazaar/bazaar.conf, it should no longer be needed.
<gimaker> Odd_Bloke: well, now that I uploaded a second pubkey it should be ok anyway :)
<gimaker> Though it's still being annonying and demand that I type my passphrase twice after spewing ut an annoying "Server is too old for streaming pull, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)" message :)
<Peng_> gimaker: You should upgrade your client.
<gimaker> ...which is obviously wrong, seeing as LP runs 1.6rc3 :)
<Peng_> Or...I don't know. I think upgrading the client is the right solution.
<gimaker> Peng_: I prefer to stick with what's in Ubuntu
<Peng_> gimaker: What's in Ubuntu?
<gimaker> 1.3.1
<Peng_> gimaker: Well, I'm 99% sure upgrading the client will fix that
<gimaker> Either way, it's no biggie and I should stop whining already
<ericvw> You can add the Bazaar repository into sources for apt-get to have it get the latest and greatest!
<Peng_> Yeah. See https://launchpad.net/~bzr/+archive if you want to do that.
<gimaker> ericvw: does that work with all plugins as well? I use bzrtools, bzr-svn and rebase on a regular basis
<gimaker> s/all plugins/all plugins available in stock ubuntu/
<Peng_> gimaker: A couple plugins are available in the PPA, but not that many.
<ericvw> I believe bzrtools is
<Peng_> gimaker: I think it's just bzrtools and bzr-gtk now. bzr-svn used to be.
<jelmer> John uploads bzr-svn to PPA now as well
<Peng_> Ah.
<Peng_> That's good. :)
<gimaker> maybe when I have some more time on my hands (I'm leaving for the first field-test of our robot in half an hour... a bit stressed atm :)
<gimaker> jelmer: does using the new dpush mean I won't have rebase as soon as someone else does a (non-conflicting) commit on the SVN-repository?
<jelmer> gimaker, No, you will still have to rebase or pull
<Gioacchino> hey all
<Gioacchino> I need help configuring bzr-eclipse
 * beuno pokes awilkins 
<gimaker> jelmer: ok. bummer :) rebase everytime someone else commits it is then!
<jelmer> gimaker, That's not specific to bzr-svn though, you would have to do the same thing if you were using a native bzr branch that other people committed to as well
<Gioacchino> I need help configuring bzr-eclipse someone help me ?
<Gioacchino> I should put  lp:~gmazzurco89/mastro/work  in branch location ?
<gimaker> jelmer: hmm? surely you must jest. native bzr branches I can just pull/merge.
<jelmer> gimaker, there shouldn't be anything preventing you from pulling/merging in the current situation either
<Gioacchino> some one can help em ?
<gimaker> jelmer: merging was fine, but I couldn't push without rebasing - since I had local commits "in between" the two latest revisions in the SVN repos. I thought maybe there was some fancy new feature that automated that for me.
<jelmer> gimaker: You would have to rebase or merge again too if you were in a native bzr branch
<gimaker> jelmer: yeah, I'd have to merge (or rebase, but that hardly seems necessary). But for svn-branches rebase is the only option, right?
<rockstar> jam, friendly reminder about TWiB today.  I've got alerts going everywhere to make sure I don't forget.
<Gioacchino> statik can you help me please ?
<Gioacchino> statik someone tell me you use eclipse
<jelmer> rockstar, Hi!
<rockstar> jelmer, hello
<jelmer> gimaker, No, merge should work too for bzr-svn but not if you use dpush
<jelmer> gimaker, well, it would work but it would do strange (though correct) things to your history
<Gioacchino> can some body help em please ??'
<jelmer> rockstar: were you looking into creating a mirror of the KDE svn repo?
<jelmer> Gioacchino, sorry, none of the bzr-eclipse folks appear to be around
<jelmer> Gioacchino, Verterok is the person you'd want to talk to
<Gioacchino> ok
<gimaker> jelmer: really? What I did was: branch from svn, local commit, local commit, someone else commits to svn, local commit, bzr push. bzr push failed saying the branches had diverged, so I merged from the SVN-repo and then push failed with some error message about "changing the order of commits already in the SVN repository"
<rockstar> jelmer, I was, but we put it off because it was looking like it would be a while before they started the process of choosing a new VCS.
<gimaker> It also suggested rebase to solve the problem
<jelmer> gimaker: Ah, you're committing directly to the repository root?
<gimaker> jelmer: yeah. does that make a difference?
<jelmer> gimaker, Yep, that means you can not change the order of revisions on the mainline
<jelmer> gimaker, and if you "bzr merge" and then push that means the mainline changes
<gimaker> jelmer: which makes sense :)
<jelmer> gimaker, since some revisions from upstream that you merged will disappear from mainline
<jelmer> rockstar, Ah, ok
<jelmer> rockstar, bzr-svn now supports branching KDE branches pretty quickly fwiw
<rockstar> jelmer, I think we could probably set it up easily if we had a box.
<rockstar> jelmer, I saw that actually.
<gimaker> jelmer: gotta run, but thanks for the help
<jelmer> rockstar, some of the Kubuntu folks were asking about mirrors earlier so I think there's some interest in it
<jelmer> gimaker, you're welcome
<rockstar> jelmer, well, then let's find a box.
<pinotree> hello
<ree> Hi! Does bzr join --reference actually works somewhere?
<pinotree> is there a way to "export" some local commits, as in diff+commit log?
<pinotree> (like git am does)
 * pinotree is not a git fan
<Odd_Bloke> pinotree: What do you want to do with said exported commits?
<pinotree> emailing them to another bzr user
<Odd_Bloke> pinotree: 'bzr send'.
<pinotree> i saw that; i was wondering if there was a way to just get the "result", instead of being sent directly
<jelmer> pinotree, "bzr send -o <filename>"
<pinotree> d'oh, i misread the documentation... you're right, jelmer, thanks
<pinotree> i understood like not specifying -o would give the result to stdout, stupid me
 * pinotree headdesks
<ree> Anyone is using bzr join --reference and can confirm it works?
<pinotree> hmm but bzr send does not include the commit log, does it?
<jelmer> pinotree, it does
<pinotree> oh?
<jelmer> Pieter, it includes all revision metadata
<jelmer> s/pieter/pinotree/
<Pieter> hah!
<jelmer> Pieter, sorry!
<Pieter> :)
<jelmer> ree: It does work, but is experimental
<pinotree> jelmer: is it the bundle?
<jelmer> pinotree, It's the base64-encoded data at the bottom of the genreated file
<pinotree> oh i see
 * pinotree is a bzr noob
<lalo> quickie -- how do I upgrade a branch with subtrees?  1.6.1 doesn't know the old format, 1.5 doesn't know the new format
<pinotree> jelmer: another question.. if i ask for a diff of a revno range (eg revno:x..revno:x+4), does the bundle include the commit logs for all of the commits?
<jelmer> pinotree, yes
<lalo> or is there a way to discard the information that the branch has subtrees?  I don't mind losing that info, the sub-branch only has one revision which I can replicate
<jelmer> lalo: 1.6.1 doesn't k now the old format?
<lalo> bzr: ERROR: Unknown repository format: 'Bazaar development format 0 with subtree support (needs bzr.dev from before 1.3)\n'
<jelmer> lalo: Ah, a development format... I guess you could upgrade to "pack-0.92-subtree" with bzr 1.5
<lalo> or maybe there's another format that supports subtrees and that's what I'm missing... but I think I tried all formats that 1.5 supports
<lalo> aha, succeeds
<lalo> yeah and 1.6 can read it :-D awesome, thanks
<lalo> guess I assumed 0.92 had to be older than development?
<jelmer> yes, it is older
<jelmer> you'd never want to use development unless you're interested in hacking on bzr
<jelmer> and losing data once in a while
<lalo> so pack-0.92-subtree is the current "supported" format with subtrees?
<Verterok> Gioacchino: hi
<jelmer> lalo, yep
<jelmer> lalo, you're actually using subtrees?
<lalo> just started, as an experiment
<lalo> I have projects that need subtrees much more seriously than this one
<Verterok> Gioacchino: maybe you are hitting a problem related to Bug #121936
<ubottu> Launchpad bug 121936 in bzr-eclipse "Eclipse hangs in bazaar operations that require user input" [High,Triaged] https://launchpad.net/bugs/121936
<Verterok> Gioacchino: try to use a ssh-agent/pagent to handle ssh keys
 * jelmer would love to see subtrees move out of "experimental" status
 * lalo does grep -i development `find ~SRC -wholename \*/.bzr/repository/format`
<lalo> will take a while with all the crud I have tho :-P
<abentley> lalo: There are no supported subtree formats.  It is not a supported feature.
<lalo> ok
<lalo> yeah I figured it out -- I started using development-subtree because of all the bzr-svn branches I have, then one day a stupidity bug bit me and I thought "I should try subtrees myself"
<lalo> ah well
<abentley> lalo: Good god, why would you use developement-anything?
<lalo> development-repo.html says, possibly incorrectly, that bzr-svn requires development-subtree
<abentley> lalo: That is false in serious ways.
<lalo> "The development-subtree format is required for the bzr-svn plug-in but should otherwise not be used until the subtree feature is complete within bzr."
<fullermd> Poor wording.
<jelmer> lalo, It does say that you only need development-subtree if you want to use bzr-svn *and* assist in testing development formats
<lalo> well, I do have an interest in testing development formats :-P
<lalo> but up until today my "testing" has mostly been "it works perfectly, never had any grief" -- only problem I ever had was today, that the new bzr doesn't read the old development formats, and that was easily solved
<abentley> lalo: Development format are "if it breaks, you get both pieces".
<lalo> and all the stuff I have on dev format is either well backed up, or stuff I don't really care if I lose it (like checkouts of third-party svn stuff from sourceforge and google-code)
<lalo> if my nxhtml branch is lost, boo-haa, I'll rm -r it and branch another :-P
<abentley> lalo: so your answer to "Why would you use development-anything" should be "I have an interest in testing development formats".
<lalo> well I thought I did, but "testing" was so uneventful that I ended up forgetting about it
<lalo> which I suppose is a nice thing
<jelmer> clearly we need less stable "experimental" formats
<lalo> absolutely
 * lalo goes write a "blow up randomly" plugin
<fullermd> They have that; it's called VSS.
<lalo> I could use libephem to crash only on full moon nights
<jelmer> :-)
<lalo> actually bzr is one of the very few projects I stopped contributing to because it's doing so well that I felt my time would be better spent elsewhere :-D
<lalo> (not entirely true -- there's also the fact that it's doing so well, every time I try to do something, there are too many new concepts to wrap my brain around)
<Gioacchino> thanks Verterok
<Verterok> Gioacchino: using an ssh-agent solved your problem?
<Gioacchino> Verterok:  I am looking for how to use ssh agent
<Verterok> Gioacchino: are you on *nix or windows?
<Gioacchino> linux
<Gioacchino> kubuntu
<Verterok> Gioacchino: there is a nice utilily: sshaskpass (gtk), that promtps you a GUI asking your passphrase
<Gioacchino> mm gtk :P
<Gioacchino> I install it
 * Verterok don't know the package name in *buntu
<Gioacchino> is this? under X, asks user for a passphrase for ssh-add
<Verterok> Gioacchino: also there is ksshaskpass (KDE) ;) http://hanz.nl/p/program
<Verterok> but the site seems to be down :(
<Gioacchino> yes..
<Gioacchino> than I have not probelm with gtk..
<Gioacchino> eclipse is also gtk :P
<Gioacchino> than it now work ?
<Verterok> Gioacchino: for the moment, there are soem efforts to port SWT to QT
<Gioacchino> eclipse to QT ?? WOW I am very happy :D
 * Verterok is waiting too :)
<Gioacchino> sshaskpass look very  ugly
<jelmer> Verterok, what's the status of having xml output supported by bzr by default rather than in a plugin?
<Gioacchino> but work
<Gioacchino> very thanks ;)
<Verterok> Gioacchino: the gtk version?
<Verterok> Gioacchino: np, glad to help
<Gioacchino> in repo I found  Xsshaskpass
<Gioacchino> without gtk
<Gioacchino> now I am tryng gnomesshaskpass
<Verterok> jelmer: it ca n be included ATM, but I'ld like to avoid the current code duplication
<Gioacchino> gnomeask is better
<jelmer> Verterok: Ok, just curious if it's worth packaging bzr-xmloutput for Debian or waiting
 * beuno votes for packaging
<Gioacchino> Verterok in eclipse cvs I have the option to add to .cvsignore the file how to with eclipse bazar ?
<Gioacchino> or I should edit manually .bazar ?
<Verterok> jelmer: I don't know the debian process, but I think it worth the packaging right now
<Verterok> Gioacchino: you hitted a not-yet-implemented (tm) feature
<Verterok> Gioacchino: for the moment, you could use: 'bzr ingore <your file>' from the CLI
<Gioacchino> ok
 * Verterok waves beuno
<Gioacchino> you know if soon is implemented this feature?
 * beuno waves back at Verterok 
 * Verterok is wainting a review of his resibmitted LH branch ;)
<Verterok> s/resibmitted/resubmitted/
<jelmer> Verterok, ok
<beuno> Verterok, logging?
<jelmer> Verterok, I'll wait for loggerhead and bzr-search to be accepted into Debian, then I'll have a look
<jelmer> Verterok, Is it possible to build the eclipse plugin without actually starting eclipse?
<Verterok> jelmer: the main blocker to include it in bzr, is a refactoring to some commands (status, ls, etc). So xmloutput can plugin without duplicate code
<jelmer> Verterok, ah, ok
<Verterok> jelmer: yes :D, I have a headless build setup
<Verterok> jelmer: it's still in early stages (a.k.a needs a lot of manual config to setup)
<jelmer> Verterok, Ah, ok - that would be a requirement for debian packaging as well
<Verterok> jelmer: it only requirement is a eclipse install with PDE (plugin development environment)
<Verterok> beuno: yeap, logging
<beuno> Verterok, I'll get to it soon-ish. I'd also recommend poking mwhudson, he may have good insights on it as well
<jelmer> Verterok, Ah, ok. That's doable
<Verterok> Gioacchino: it could be implemented soon, please file a bug :)
<Verterok> bzr-eclispe is bug-driven :p
<Gioacchino> than is more fast if I submit this bug ;)
<Peng_> jelmer: What's the story with bzr-svn and bzr.dev? Last I checked, neither 0.4 or trunk were compatible with bzr 1.8dev.
<Verterok> Gioacchino: indeed
<Gioacchino> hihihi Verterok
<jelmer> Peng_, they are, I added a compatibility marker for 1.7 last night
<Peng_> jelmer: On both?
<jelmer> Peng_, yes
<jelmer> not sure if I've pushed those changes yet
 * Verterok is sseeking LH reviewers for his logging branch
<Verterok> mwhudson: ping ^
<jelmer> let me push just to be sure
<Peng_> jelmer: I don't think you have.
<Peng_> jelmer: Thanks
<abeaumont> hi, i'd like to merge 2 repos, is this possible?
<pygi> hi phanatic :p
<abeaumont> i mean, i have two independent repos, one svn and one bzr, i want to use svn through bzr-svn and integrate the other bzr repo with the svn one throug bzr-svn, is it possible?
<jelmer> abeaumont, yes
<jelmer> abeaumont: If you have a branch of the svn repository, you should be able to copy the bzr branch into it and then merge it into the svn branch using "bzr join"
<abeaumont> jelmer: ahhh, join is the command i was looking for, thanks!
<Gioacchino> how to remove a folder from launchpad branc ?
<abeaumont> jelmer: is there a limitation in the number of trees joinable? i'm trying to join a second tree but it fails
<fattymattyo> is it possible to run a bazar server rather than svn?
<fattymattyo> without using launchpad... it would be for a company website
<fattymattyo> sorry if I'm asking a stupid question
<nDuff> fattymattyo, it's pretty straightforward to run your own bzr server... what beyond that are you asking?
<nDuff> fattymattyo, you don't *really* even need to run a dedicated "bzr server"; bzr can use dumb filestorage (a shared directory, sftp, WebDAV, etc) in place of a dedicated server, though the latter will perform better..
<fattymattyo> nDuff I would probably want to put it on the same machine as the webserver
<nDuff> fattymattyo, you can have the webserver just share a directory over plain WebDAV (no bzr-specific plugins or configuration needed) if you're going for the simplest-possible setup.
<fattymattyo> I just wasn't clear if I could use it on its own without hooking up to launchpad
<nDuff> fattymattyo, yes; you certainly can.
<fattymattyo> thanks nDuff, I'll go look up how to do it, just wanted to make sure I wasn't trying to do something that's impossible.
<Peng_> fattymattyo: Are you using *nix?
<fattymattyo> I am, and the server will be unix
<fattymattyo> one of the users checking in/out will be mac and the other will be you using a yet to be determined OS
<Peng_> fattymattyo: Then the simplest thing to do is use plain old HTTP for read-only access and ssh or sftp for read-write access.
<fattymattyo> I really want them to be able to read and write to bzr
<fattymattyo> I want to use it as a version control system the way its meant to be
<Peng_> fattymattyo: You can use SFTP without installing anything (other than OpenSSH, obviously) on the server. bzr+ssh requires installing bzr too.
<nDuff> *nod*; bzr will work as a revision control system over HTTP or SSH/SFTP.
<nDuff> ...you just give it a http or sftp address when checking things in/out.
<fattymattyo> are there any bzr packages for windoze?
<nDuff> fattymattyo, yes, bazaar-vcs.org has packages to download for win32
<fattymattyo> awesome
<fattymattyo> you guys are great
<rockstar> jam, TWib?
<jam> rockstar: probably have a phone call and a bunch of email to catch up on... but yeah, we need to do something
<rockstar> Okay, when's good for you?
<fm> hm anybody using bzr on opensuse factory?
<fm> the dependencies of the package say python < 2.6 is this really required?
<fm> i have python-2.6b3-2
<lifeless> fm: dunno, I'm not aware of 2.6 breaking bzr, but I haven't explicitly tried
<fm> lifeless: running the shiped version i get http://pastebin.ca/1200339
<fm> that is bzr-1.5-26
<vila> lifeless: It looks like pqm is hung on success: merge lp:~vila/bzr/bzr.integration/ http://bazaar-vcs.org/bzr/bzr.dev ?
 * vila wonders if lifeless is really up at that time...
<vila> fm: sha module deprecated surely rings a bell
<vila> Months ago I tried python2.6, there was a couple of minor fixes needed, if you're still interested let's try to talk about it tomorrow (it's 22h30 here and I will leave soon)
 * vila failed to notice: 'fm has quit (Read error: 104 (Connection reset by peer))', bah, may be he'll read the logs
<ozzloy> " This branch was probably created by bzr 0.15pre.  Create an empty file to silence this message."  what file am i supposed to create?
<ozzloy> i tried creating the directory "branch" with the file "tags" but that doesn't suppress the message
<james_w> ozzloy: .bzr/branch/tags ?
<ozzloy> i'll give that a shot
<ozzloy> nope
<jam> lifeless: PQM appears wedged.
<jam> Looking at http://pqm.bazaar-vcs.org/
<jam> I see it claim that it successfully completed the merge
<jam> but now it is just sitting their
<jam> vila: what did you do to it :)
<jml> I've got a bzr riddle for you all.
<jml> given a standalone branch, how can I make another empty standalone branch with the same format?
<beuno> cp?   :)
<jml> _empty_
<beuno> ah, ah
<spiv> jml: e.g. a format 5 branch with a pack-0.92 repo?
<jml> spiv: yes.
<jml> spiv: if that's what the first branch is.
<spiv> jml: I did this just yesterday.
<beuno> cp and uncommit til your fingers bleed?   :)
<jml> spiv: but the first branch might also be a loom or a weave branch or something pathological.
<jml> beuno: full marks for creativity :)
 * beuno stops making noise
<spiv> jml: bzr init-repo --pack-0.92 temp-repo --no-trees && bzr init --dirstate-tags temp-repo/temp-branch && bzr branch temp-repo/temp-branch empty-branch
<mwhudson> spiv: that's not a standalone branch
<mwhudson> oh i see
<spiv> jml: you can use "bzr info -v" in the empty branch to verify it worked.
<jml> how would you do that in API terms?
<spiv> mwhudson: yeah.  I should add "rm -r temp-repo" to that.
<jml> (please don't say cmd_init_repo().run(...))
<spiv> jml: oh, API terms.  That's easier, in a sense.
<spiv> (less concise to type on IRC, though)
<mwhudson> jml: we can init ok, right?
#bzr 2008-09-12
<jml> mwhudson: I had a little trouble with it yesterday.
<mwhudson> jml: oh, ok
<mwhudson> jml: i thought you were clone('null:') ing
<mwhudson> or am i out of date
<jml> mwhudson: that was my second pass at a solution
<jml> mwhudson: after I couldn't find the repo format controls for create_branch, ISTR
<spiv> jml: tried sprout('null:')? :)
<mwhudson> spiv: blows up with looms and weaves
<spiv> Oh, really?
<jml> spiv: clone('null:') works great except for looms & weaves. haven't tried sprout
<spiv> I'm not totally shocked by looms failing, weaves surprises me though.
<mwhudson> spiv: it might be a null:/None thing
<jml> spiv: weaves raises... RepositoryUpgradeRequired if you force no working trees...
<jml> and NoSuchRevision if you pass 'null:' without caring about working trees.
<spiv> Interesting.
<jml> None works, but I didn't check that the new branch was empty
<jml> (it might have just cloned the whole thing)
<jml> when I found out that looms failed I gave up and moved on to fixing bugs.
<jam> spiv: Is poolie not around?
<jml> spiv: anyway, what were you going to suggest?
<spiv> jam: not that I've seen
<jam> jml: "b = bzrlib.branch.Branch.open('foo'), b.clone(NULL_REVISION)" ?
<jml> jam: rather than bzrdir.clone?
<jml> interesting.
<jam> jml: well, it is something to try
<jam> Looms is a bug in looms
<jml> jam: yeah.
<jam> and I don't care about weaves :)
<jam> jml: you can also "bzr uncommit -r 1"
<jam> And I *think* "bzr uncommit -r 0"
<jam> but I'm not sure about '0'
<jml> jam: I'm not sure if I'm allowed to not care about weaves yet.
<jam> jml: alternatively
<jam> bzrdir._format.initialize('target')
<jam> bzrdir.repository_format.initialize(target_bzrdir)
<jam> bzrdir.branch_format.initialize(target_bzrdir)
<jam> Go back to the raw Format objects
<jam> and tell them to create something new
<jam> It may not work on pre-metadir, though.
<mwhudson> with appropriate care for Remote*
<jam> And I don't have much of an idea about looms
<jam> spiv: ok, so no standup today? Was there one last night? I felt like I missed it, but didn't see any actual chatter
<jml> jam, spiv: thanks. I'll have a play.
<jml> maybe I'll end up patching loom or something.
<poolie> hello jam, spiv, sorry i'm late
<spiv> poolie: hello
<spiv> jam: not so far, but now poolie is here it'd be good to do one...
<spiv> poolie: standup?
<poolie> sounds good
<jam> jml: though you are right, I don't think Branch5/6 (regardless of looms/weaves) truly supported cloning at the NULL_REVISION
<jml> *nod*
<spiv> jam: So about landing my trivial -Dhpss fix on the 1.7 branch...
<spiv> jam: what should I do with the NEWS entry?  Start a bzr 1.7rc2 section?
<jam> spiv: I'm trying to land it now
<jam> look at PQM
<jam> PQM is backed up by a merge from vila
<spiv> jam: ah.
<jam> which says "success" but is still stuck
<spiv> jam: ok, I'll wait for that to sort itself out then :)
<spiv> jam: thanks
<thumper> is there a bzrtools coming soon that won't be tried to be removed with bzr 1.7rc from the PPA?
<abentley> thumper: I'll release bzrtools 1.7 tonight.
<thumper> abentley: cool
<Gioacchino> good night
<jml> can someone land my http smartserver tweaks patch please?
<spiv> jml: If someone unwedges pqm I will...
<poolie> i don't see stubub yet
<poolie> stub
<poolie> i'll ask steve-in-canberra
<jml> poolie: Steve-in-London, I think you'll find
<Yasumoto> Hey guys, is there a way to get just the files when you're making a new branch, rather than all the files inside a folder?
<RAOF> Yasumoto: I'm not entirely sure what you're asking for.  Are you saying that, rather than 'bzr branch foo bar' branching 'foo' into a 'bar' directory, you'd like to branch 'foo' into the current directory?
<Yasumoto> RAOF: actually, I may be asking about bzr branch foo bar
<Yasumoto> (a friend and I are learning how to use bzr for an assignment together)
<Yasumoto> cool, thanks RAOF! :)
<RAOF> Heh!  Remember, 'bzr help <command>' often contains useful information, and 'bzr help commands' will list all the commands :)
<Yasumoto> ooh, cool
<Yasumoto> thank you
 * jml writes a function that does get_stacked_on_url that return None when there isn't one.
<poolie> jml, yeah, i'm not sure if that was the best api
<poolie> to raise an error
<poolie> spiv, how's it going?
<poolie> i'm still trying to get my desktop back up :-/
<jml> poolie: well, the advantage of the current API is that I *can* write such a wrapper.
<jml> poolie: if it returned None and I wanted rich errors raised, I'd be in trouble.
<poolie> hm
<poolie> if it returned None for more than one case, yes
<spiv> poolie: pretty well.  I came across a vim window that reminded that I had a fix for a TooManyConcurrentRequests bug, so I finished that and fired it off.
<jml> right. So I'm returning None if it's NotStacked as well as if one of the formats doesn't support stacking.
<jml> because for most of what I'm doing the two are equivalent.
<poolie> ok, good
 * jml heads out
<poolie> spiv, can you send your startup-time branch too (if you didn't already)
 * spiv re-reads what he actually did in that branch to make sure there's nothing outrageous...
<Yasumoto> hey guys, my friend's trying to push a branch onto launchpad (he just made an account!) but we're having issues with the windows client
<poolie> hi Yasumoto
<poolie> what specifically
<Yasumoto> we found some bugs ( https://bugs.edge.launchpad.net/bzr/+bug/198092 ) about bzr launch-pad login
<ubottu> Launchpad bug 198092 in bzr "Should tell the user to run bzr launchpad-login before push lp:" [High,Fix released]
<Yasumoto> but it's saying Autentication type (password) not permitted.
<Yasumoto> bzr: ERROR: Connection Error: Unable to authenticate to SSH host as user@bazaar.launchpad.net Bad authentication type (allowed_types=['publickey'])
<Yasumoto> we're about to try it from cygwin..
<spiv> Yasumoto: Launchpad's code hosting only allows publickey auth
<spiv> Yasumoto: so you need to add an SSH public key to your Launchpad account
<spiv> Yasumoto: https://launchpad.net/people/+me/+editsshkeys
<Yasumoto> spiv: yeah, we've got the public key on launchpad
<Yasumoto> hm, now in cygwin
<Yasumoto> 1 sec
<Yasumoto> hm, so I've got the private key in ~/.ssh/id_rsa and the public key in ~/.ssh/id_rsa.pub
<Yasumoto> and it's giving us "bzr: ERROR: [Errno 0] Error"
<spiv> Does "sft -v YOUR_LP_USER@bazaar.launchpad.net" show that it is using the key?
<spiv> Er,
<spiv> "sftp" rather than "sft"
<spiv> Also, can you pastebin the traceback in your ~/.bzr.log file corresponding to the "Errno 0" error?
<Yasumoto> spiv: good call on the sftp, it looks like it's giving us permissions errors
<Yasumoto> it's ignoring the private key
<Yasumoto> we'll change those, 1 sec
<Yasumoto> hm
<Yasumoto> it's connecting now
<Yasumoto> however it's not accepting his passphrase
<Yasumoto> spiv: thanks for your help, by the way :)
<Yasumoto> he's playing around with things a bit for now, I'll let you know if we make progress
<TheMuso> .c
<vila> Good morning bazaar (with a special thought for pqm)
<AfC> If you have a file added & committed to a branch, and later add a pattern to .bzrignore which happens to match it, it will still be governed as a versioned file, correct?
<vila> AfC: yes
<jml> hello everyone.
<vila> hi jml
<jml> I would like to suggest that autopack speed become the #1 most important bzr issue.
<jml> kthxbye
<jml> vila: hello. how's things?
<vila> jml: very very good :) Except for the fact that pqm is so proud of my last submission that it don't want to let it go (which is embarassing :)
<jml> ha!
<vila> especially for jam and spiv who are trying to get *their* submissions accepted :)
<vila> pqm: stop thinking, I don't want it to be merged in the 1.7 branch, go go go
<poolie> hee hee
<poolie> is it still stuck?
<vila> poolie: pqm unstuck and my submission was even accepted. Did anybody diagnose the root cause ?
<poolie> vila, stub killed a stuck ssh process
<poolie> he didn't tell me what process it was specifically
<vila> poolie: thks for feedback, I think pqm is just feeling anxious when it hears us talking about running the test suite on multiple platforms, someone should reassure it... I tried to be more gentle next time though
<poolie> heh
<spiv> Turns out it wasn't so hard to cut down the round trips of an empty push.
<poolie> :-)
<poolie> yay
<poolie> guilhembi, hello
<guilhembi> hello poolie
<guilhembi> vila: Bonjour; do you have time for a short question regarding "'bzr missing' does not show merged revisions" ?
<vila> guilhembi: sure
<guilhembi> vila: Thanks. You said, "fix committed", but, so, what does "bzr missing" show now? output similar to "bzr log" indented revisions?
<vila> yes
 * guilhembi rushes to try that
<vila> you can try with the associated branch
 * guilhembi is evil, he tries with another branch
<vila> guilhembi: feedback welcome about response times since this makes missing O(history) when --include-merges is used (but work will continue to remove that)
<poolie> guilhembi, when he said 'with that branch' he meant the fix is in the branch connected to that bug
<poolie> i think it's not in trunk yet
<guilhembi> sigh
<vila> poolie, guilhembi : poolie is right, tweaks were required, I'm working on it right now
<vila> guilhembi: sry, I misunderstood you, I thought you meant that you will merge my fix in your private bzr
<spiv> I think I just found a bug we really ought to fix before 1.7 :(
<vila> so 'fix committed' means that the fix is available somewhere (often in the branch associated with the bug), while 'fix released' means that the patch has been merged to bzr.dev and the series indicates in which released version the fix is available
<guilhembi> vila: but there is time between merge into bzr.dev and building of a release,
<guilhembi> in this time window what is the status of the bug?
<vila> 'fix released'
<guilhembi> vila: isn't this misleading?
<guilhembi> 'fix released' though not yet in a release?
<poolie> yes
<vila> yes, it is
<poolie> the bug statuses are not quite labelled right
<poolie> spiv, want to call me?
<spiv> poolie: just about to finish mailing the list with details
<poolie> ok
<spiv> poolie: short answer: https://bugs.edge.launchpad.net/bzr/+bug/269214
<ubottu> Launchpad bug 269214 in bzr "Branching from shared repository via HPSS does not preserve repo format" [High,Confirmed]
<poolie> thanks for finding it
<vila> For me, 'fix released' means 'this bug is available beginning with the milestone indicated'. If that milestone points to a release "in the work" it means the fix is available in bzr.dev only or in a release candidate if one exists at that point
<spiv> Well, John and someone on the list noticed it really, I just happened to put a couple of pieces together.
<guilhembi> vila: I tested --include-merges on a pair of MySQL branches and it looks like working
<spiv> poolie: mail sent.  I know how to reproduce, but haven't tried to find the cause yet.
<vila> guilhembi: Good.
<poolie> spiv, if you're still here, the failure in the 261315 test is (obviously really) there are tests for what rpcs are done by remote objects
<poolie> and this adds a new one
<spiv> poolie: I'm still here
<poolie> i'm going to call it a night soon but can we talk it over first?
<spiv> Sure.
<spiv> (And me too)
<lifeless> vila: the LOSA's can fix wedged pqm's
<lifeless> vila: I'm not here :P
<vila> lifeless: Sure I can see that :) What means LOSA though :)
<vila> lifeless: enjoy your week-end !
<lifeless> poolie: pqm still wedged?
<spiv> lifeless: no
<spiv> lifeless: so enjoy your weekend :)
<spiv> lifeless: (stub killed a stuck ssh process)
 * vila tries Launchpad Overlord System Administrators. Hmm, sounds good :)
<dereine> is there something like codespaces for bazaar?
<lifeless> what is a codespaces
<james_w> dereine: you might want to look at launchpad.net
<dereine> mh opensource...
<dereine> i would like to publish it but...
<dereine> but thanks for the typ
<frk2> can somebody help me out with the lp protocol please?
<frk2> mine seems to skip the http_proxy variable completely
<frk2> is there an alternate way i can access my launchpad bazaar repo
<james_w> frk2: "bzr launchpad-login <your lp id>" will make it use bzr+ssh://
<frk2> im doing bzr push lp:~fkhan/+junk/test
<frk2> seems like its throwing an exception on python xmlrpc lib
<james_w> bug 186920 for the proxy issue I think
<ubottu> Launchpad bug 186920 in launchpad-bazaar "bzr launchpad does not handle proxy when used for name resolution " [Undecided,Confirmed] https://launchpad.net/bugs/186920
<james_w> using launchpad-login should make it avoid this
<frk2> is there a work around?
<frk2> my dns works fine
<frk2> i have worked around it by using bzr+ssh://bazaar.launchpad.net
<frk2> that works
<frk2> however it says no such user on launchpad
<hsn_> http://pastebin.ca/1200966 you know why shelve doesnt work,  i need to create some directory?
<frk2> my local username is not the same as my lp username
<frk2> am i being retarded here?
<james_w> frk2: run "bzr launchpad-login <your lp username>" and then continue using "lp:"
<james_w> hsn_: you'll need to put it somewhere other than pastebin.ca if you would like me to look at it, I can't access that site
<frk2> james_w, connection refused - same problem
<james_w> frk2: "no such user"?
<frk2> the exception happens in python xmlrpclib
<frk2> no, the earlier problem with lp:
<frk2> i am being a proxy
<frk2> behind
<james_w> but you've run "launchpad-login"?
<frk2> yes
<james_w> odd
<james_w> does the end of the backtrace have "httplib.py"?
<frk2> yes
<frk2> i read somewhere that using lp makes bzr do a xmlrpc lookup
<frk2> which is not proxiable
<james_w> ah, true
<james_w> use bzr+ssh://username@bazaar.launchpad.net then
<frk2> :)
<frk2> thats all i was looking for
<frk2> thanks!
<frk2> done. just trying out bazaar- looks way cooler than svn which is what im using now
<hsn_> is there way to do bzr up --dry-run?
<Peng_> james_w: You can't access pastebin.ca?
<james_w> Peng_: nope
<Peng_> james_w: Hmm. It has AAAA records. Maybe you have messed up IPv6 support?
<james_w> maybe
<james_w> I don't know how I would have "messed it up"
<james_w> It resolves to an IP, and traceroute shows that packets get part way there, but just die after a few hops
<Peng_> Oh. Never mind then.
<vila> hmmm, pqm... what's the problem with merging lp: branches ?
 * vila refuses to believe that pqm has anything against him :D
<vila> Anybody knows someone with a 'stub' nick ?
<vila> poolie said previously: vila, stub killed a stuck ssh process
<james_w> stub doesn't seem to be around at the moment
<vila> when it occured this morning (i.e. ~6 hours ago)
<vila> james_w: if you find him somewhere, tell him that pqm is wedged againg and will be again since I already have another submission in the queue
<james_w> he may well be done for the day
<james_w> John or Aaron will probably know who else has the power.
<vila> damn, do *you* someone that can acces pqm ?
<vila> james_w: ok
<vila> abentley, jam: pqm needs more love ^
<abentley> vila: I don't have any particular power.
<vila> abentley: I know, but may be you know someone who has ?
<abentley> vila: The LOSAs have the power, but they don't have a detailed understanding of PQM.  What's the isue?
<vila> A submission blocked pqm this morning and stub killed a stuck ssh process
<vila> An other submission is now blocking it and I have a third one in the queue
<abentley> vila: blocking how?
<vila> Displaying: success: merge lp:~vila/bzr/bzr.integration/ http://bazaar-vcs.org/bzr/bzr.dev
<vila> i.e. the merge seems to have occured but nothing happens
<abentley> vila: Has the branch actually been updated?
<vila> Not after the submission
<vila> if you look at http://pqm.bazaar-vcs.org/ you'll see that I use two different branches, one for each submission
<abentley> vila: Okay.  Are you on irc.canonical.com?
<abentley> vila: No, I meant has bzr.dev been updated?
<vila> abentley: no. I can't
<vila> abentley: no, bzr.dev doesn't look updated
<abentley> Okay.
<vila> Checked. Not updated
<vila> The only cause I can think of is that I use 'lp:' urls where others use 'http:' urls
<vila> But I shoot in the dark...
<abentley> vila, meet mthaddon.  He is working on unblocking PQM.
<mthaddon> abentley, should be okay now
<vila> abentley: thanks a ton
<vila> mthaddon: hi
<abentley> mthaddon: Thanks.
<vila> mthaddon: hmm, you're fast, its working again :D
<mthaddon> cool
<vila> mthaddon: but I bet it will block again in about 1 hour
<vila> the current submission should be ok, but the next one should trigger the same problem
<abentley> vila: Don't be pessimistic.  Maybe it will block sooner :-)
<vila> abentley: lol
<abentley> Anyhow, it's worth confirming the behavior.
<vila> I hate it when I tickle a bug but have no idea where to look to isolate it...
<vila> mthaddon: what did you do to unblock it ?
<abentley> vila: It looks like killing the process prevented your last submission from merging, as we feared.
<mthaddon> vila, killed the process
<vila> strange, this morning killing it make it complete successfully
<abentley> mthaddon: What version of bzr is running on that box?
<mthaddon> abentley, we're using bzr 1.6 for that PQM instance
<vila> 1.6 or 1.6.1 ?
<abentley> mthaddon: There were some performance regressions with 1.6.0.
<abentley> So this may be related.
<mthaddon> ah, interesting
<vila> abentley: and I were lucky this morning because we wait longer before killing it ?
<abentley> vila: yes, seems plausible.
<abentley> mthaddon: Is it possible to update that box to 1.6.1?
<mthaddon> abentley, lifeless has typically been responsible for that, and last time I did it I broke things, so I'd rather have him to that (as much to approve it as anything else)
<mthaddon> s/him to that/him do that/
<abentley> mthaddon: Well, it probably blocks merging 'till Sunday, but I guess we can live with it.
<mthaddon> bzr 1.6 has been on there for a while, I believe... any idea why it's suddenly become a blocker?
<vila> mthaddon: If I knew I'll be working around it instead of annoying you :-/
<vila> My last submissions have blocked pqm, I have no idea why
<vila> My last submission *before* that problem was  around 2008-09-01
<vila> Except upgrading bzr.dev, I fail to see what I changed
<grutte_pier> vila: remember the discussion about the webdav stuff (when I had nick Jakob, which apparently was registered).....
<grutte_pier> well.... webdav is on, but only for one directory where systemadmin has some svn repos
<vila> astro.rug.nl ?
<grutte_pier> :(
<grutte_pier> yep
<vila> that explains it I think
<grutte_pier> so I have to think of something else :P
<vila> try the smart server instead, the performances ought to be better now and far better tomorrow :)
<grutte_pier> but the whole thing is that I want others to access the repo, with the smart server they need access to the system right?
<grutte_pier> the sysadmin will never setup accounts for people not physically working at the institute, I'm sure
<hsn_> so its simple do: date(256) + XYZ year
<hsn_> ECHANN
<vila> grutte_pier: sry, my window was iconified :-/
<vila> It you setup a smart server, you can then use .htaccess to define your own users/pass (if your server allows that)
<fta> is there a way to cherry pick dis-joined revisions while merging ?
<fta> something like -r 274..275,283..285 ?
<vila> mthaddon: the pending submission passed, did you something ?
<mthaddon> nope
<vila> wow, now that's weird, the one you killed have indeed been merged to bzr.dev
<vila> mthaddon: ok, thanks for confirming and the help, I'll see with jam and lifeless
<mthaddon> cool
<vila> and will refrain from submitting until then :-D
<james_w> vila: sorry, I obviously don't know my http error codes :-)
<vila> james_w: hehe, don't worry. as mentioned, I had to check too :)
<fm> hi i cannot get bzr 1.6.1 or 1.7rc1 to work with python 2.6b3. see https://bugzilla.novell.com/show_bug.cgi?id=425644 any idea?
<ubottu> bugzilla.novell.com bug 425644 in Development "bzr init fails: failed to load bzrlib.repofmt.pack_repo.RepositoryFormatKnitPack1: cannot import name U32" [Normal,New]
<fm> that is 1.5 the later fail with "TypeError: object.__init__() takes no parameters"
<james_w> hey fm
<james_w> fm: please run "python -c 'from gzip import U32'"
<james_w> fm: or python2.6 as necessary
<fm> james_w: ImportError: cannot import name U32
<fm> james_w: there are the following python packages on opensuse factory: http://pastebin.com/mc80b808
<fm> james_w: both my problems seem to be on windows too http://www.python.org/dev/buildbot/community/all/x86 Windows 2003 trunk/builds/66/step-bzr dev/0
<james_w> fm: it looks to me like there is something wrong with python 1.6
<fm> james_w: how can I debug this?
<james_w> fm: well, the failure you reported showed that it can be reproduced with just python
<james_w> so I would find out what changed in python to make that go away, as it probably shouldn't have
<fm> the ""TypeError: object.__init__() takes no parameters" seems to be caused by http://bugs.python.org/file2323/new_init_strict.patch
<pcc1> how do I merge a merge-directive into a repository without a working tree?  currently getting the error message 'bzr: ERROR: No WorkingTree exists for "file:///..."'
<james_w> pcc1: you can't, you need a tree to merge it with
<_fm_> james_w: u32 was removed http://svn.python.org/view/python/trunk/Lib/gzip.py?rev=61821&r1=61813&r2=61821
<james_w> _fm_: that sucks, and may not be intentional
<james_w> _fm_: you should find out if it is and request it to be restored if not
<_fm_> i am just asking in #python
<beuno> Verterok, ping
<Verterok> beuno: pong
 * mvo wonders what he can do about " TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x893616c>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request."
<james_w> hey mvo
<mvo> hey james_w
<james_w> that's normally a secondary error, indicating something else went wrong, and things went from bad to worse as it tried to unwind
<james_w> what operation were you doing?
<mvo> a commit
<james_w> hmm
<james_w> I'm not sure what that would be
 * mvo tries again
<james_w> are you using a lightweight checkout?
<mvo> I don't think so
<james_w> you could try "bzr unbind; bzr commit; bzr push; bzr bind; then
<AmanicA> fwiw, Andrew send in a patch today about: "
<AmanicA> This small change fixes one of the remaining causes of TooManyConcurrentRequests
<AmanicA> errors.  "bzr pull" and "bzr merge"
<AmanicA> "
<AmanicA> so maybe this might be fixed in bzr.dev already, or this patch of andrew might help...
<AmanicA> For details, see: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080912022408.GA9671%40steerpike.home.puzzling.org%3E
<james_w> AmanicA: thanks, but I don't think that code path is involved here
<AmanicA> cool, it was just a stab in the dark..
<james_w> yeah, I was hoping it was that one :-)
<ryanakca> Is there a bzr command to view what would be pulled before pulling it?
<Peng_> ryanakca: "bzr missing"
<Peng_> (Well, it'll also show anything that would be pushed if you pushed, but there are arguments to change that.)
<ryanakca> Peng_: ok, thanks
<ryanakca> Peng_: hmm... could you make it show ``bzr diff'' for those files?
<Odd_Bloke> ryanakca: Look at revspecs, there'll be 'branch' or 'ancestor' or something which'll work.
<Odd_Bloke> bzr diff -r branch:<REMOTE> or something.
<ryanakca> nevermind, I tihnk I found it, bzr diff --new=ARG where ARG is the new branch
<_amanica_> does anybody know why serverside hooks work with bzr:// but not bzr+http://
<Kilroo> So does the Bazaar community pretty much have everything -except- a forum?
<uws> a forum is for degenerate beings
<uws> sorry, did i actually say that? ;)
<_amanica_> whell theres answers..
<_amanica_> https://answers.launchpad.net/bzr
<Kilroo> Pft. I happen to like fora, er, Mathilda.
<uws> Kilroo: who's Mathilda/ :)
<Kilroo> Sorry, I was reading the quotes page. :D
<Kilroo> Hm...thanks, _amanica_. That looks somewhat promising.
<Kilroo> For some reason it still feels more like I'm intruding on people than I usually feel on a forum...
<Peng_> That's true..bzr doesn't have a forum. Huh.
<Peng_> I never noticed.
<Kilroo> I don't think I'm actually going to try to post a question until I've actually tried something, though.
<Kilroo> Considering that what I'm thinking of trying to do is stupid anyhow.
<fullermd> Forum?  Oh, you mean those things like a mailing list with a horrible UI?   :p
<lifeless> fora, those things that will kill you in australia
<Kilroo> See, to my way of thinking, a mailing list is sort of like a forum with a horrible UI.
<Kilroo> Similar to those forums where you have the sort of tree view of the replies.
<Peng_> Forums don't let you mark things as read and unread.
<Kilroo> Not at the post level, no. You have a point.
<Kilroo> Either you've seen that thread since anyone posted to it, or you haven't.
<Peng_> Or your session has expired, so it assumes you've seen the thread.
<Peng_> (Vanilla averts that, but it's not all that great otherwise.)
<Kilroo> I can't think of a forum that does that.
<Peng_> phpBB, but maybe it's improved more recently.
<Peng_> Or, what do you mean?
<Kilroo> Far as I know, on phpBB, if you're not logged in it assumes you haven't read anything except maybe what's in session. If you are logged in it doesn't have to guess.
<Peng_> Hmm... It seems Loggerhead's pages lack a DOCTYPE or charset declaration.
<Kilroo> Maybe I should give mailing lists a try. I'm sure there must be something out there that lets you read an entire thread of messages from a mailing list at once, in chronological order regardless of reply forking, and paginated. I'd be surprised if it can correct for screwy distributions of > characters in multi-quoted responses from people with different numbers of columns in their mail clients though.
<Kilroo> It's all a matter of taste anyhow.
<fullermd> Quite.  I'd hate to read in chronological order.
<Kilroo> In some cases I like to have the option to toggle it, but I don't like being forced to have things show in tree order, and I absolutely despise having to read one post at a time.
<fullermd> But no forum will ever have an interface as customizable as my mail client, and couldn't come within 2 orders of magnitude of the responsiveness.
<Kilroo> True enough.
<fullermd> Heck, I can dispose of a whole mailbox in the time it takes to load one forum thread.
<LarstiQ> Kilroo: a problem with a forum for bzr would be that afaik not a lot of knowledgeable people would read it
<LarstiQ> Kilroo: I for one wouldn't.
<fullermd> KKKKK<center><space>jjjiKKKl<enter>  *done*
<Kilroo> It does begin to sound that way.
<LarstiQ> Kilroo: now, you could try gmane
<LarstiQ> Kilroo: that may come closer to your tastes?
<Kilroo> Not particularly.
<Kilroo> That is, it's better than many things I've seen.
<Kilroo> However, if gmane suited me, I'd be happy using a mail client.
<LarstiQ> Kilroo: I acknowledge there are users (in general, not sure for bzr) who would benefit from a forum
<LarstiQ> but we'd need to have some people to put effort in it to set it up
<LarstiQ> Kilroo: if you're willing to learn about bzr and act as a bridge between the fora and the rest, you're welcome to set one up ;)
<Kilroo> And then it would only really be any help for people like me who would like a forum and don't like a mailing list, and even then only as much help as the people who would like a forum enough to post to it...and then the experts either have to spend time on both, or have to choose which one to follow.
<LarstiQ> exactly
<LarstiQ> so I feel starting up a forum none of us will use would be a disservice to users wanting to use it
<Kilroo> Long story short, a forum would probably be more trouble to the community than it's worth, and there just isn't a medium for asking the kinds of questions I have where I don't feel like I'm intruding on people's time.
 * LarstiQ nods at Kilroo 
<LarstiQ> Kilroo: except, you're free to ask those questions
<Kilroo> I was about to say...why I feel less like I'm intruding by posting a forum thread than by starting a thread on a mailing list or posting a question to the answers thing, I do not know.
<fullermd> In high theory, there's no reason a forum and a mailing list can't 2-way gateway each other.  There are a number of impedance mismatches, though, on levels 6-8.
<LarstiQ> Kilroo: how about asking on irc?
<Kilroo> I also have never figured out why I feel less like I'm intruding by having an off-topic conversation on IRC than by asking stupid questions.
<Kilroo> I think it's #ubuntu's fault.
<LarstiQ> :)
 * fullermd riffles through the definion of IRC for any mention of "topic"...
<Peng_> Posting on a mailing list feels more intrusive to me than a forum. I think.
 * LarstiQ nods
<Peng_> I don't start many threads on forums.
<LarstiQ> but that's the great thing about mailing lists :)
<Peng_> So I'm not really sure.
<LarstiQ> Peng_: how would you compare the thresholds of irc and fora?
<Kilroo> I guess I think of a mailing list as being sort of like a forum where everyone who's registered is subscribed to the entire thing.
<Kilroo> And now I'm trying to remember which forum software it is where you could do that. Invision Power Board I think. Not sure of any others that support that.
<LarstiQ> Kilroo: that is a difference. NNTP has a more granular subscription model.
<Peng_> LarstiQ: I don't know. I usually lurk in IRC channels for 3 months before asking anything. Or I join, ask a question, everybody ignores me, and I leave. :)
<LarstiQ> Kilroo: btw, do you actually have a question yet?
<Kilroo> Oh yeah, the question.
<Peng_> Kilroo: What do you mean by "subscription"? Most forums have email alerts and stuff. IPB's may be better though.
<Peng_> Kilroo: Sorry, you've used up all your time today. Come back and ask tomorrow. ;)
<LarstiQ> Peng_: with a mailing list, you can't selectively watch a particular thread, you get everything
<Peng_> LarstiQ: Oh, that's ture.
<Peng_> true*
<LarstiQ> lukcily, my email client deals with that just fine, and I usually want to see everything.
<Peng_> Which client?
<LarstiQ> mutt
<Kilroo> Actually I'm probably going to come back next week. See, I have a (very vague) idea of what I want to do, but I haven't tried anything yet to see if it'll work, and I don't like asking "hey, can I do this?" without "Here's what I tried so far..."
<fullermd> Well, you already asked _half_ the question...
<Peng_> Kilroo: Well now I'm curious.
<Peng_> LarstiQ: O
<Peng_> h
<LarstiQ> Kilroo: I'll take your reluctance for that as credit and won't be bothered by you not having tried anything yet :)
 * Peng_ can't type right now.
<Kilroo> as an aside...Peng_: If I'm  remembering right, with IPB you can subscribe to the thread, the subforum, or the entire board. With most other packages I don't think I've ever seen a way to subscribe to anything but the thread.
<Kilroo> Ok, you've convinced me. The basic gist is this: I'm working with a team that currently has no source control at all...nor even a real development server. I'm trying to figure out whether there's a way of using bzr with the production server as a dumb server that doesn't require something ridiculously complicated, but yields more benefit than just having everyone keep history on their local working copies.
<Kilroo> And I'm having trouble even grasping what I mean by that because the only thing I've ever used before was an old version of Sourcesafe.
<LarstiQ> bzr doesn't require any extra software on machines you publish your changes on, just file (sftp/ftp/etc) access will do
<Kilroo> It would be relatively simple if not for the fact that I cannot guarantee adoption of bzr across the board
<Kilroo> which means that for example people in other departments might be making changes and pushing them directly via FTP.
<LarstiQ> Kilroo: would adoption be hindered by wanting another solution, or just general aversion to version control?
<Kilroo> larstiq: There are three obstacles. One, I'm not even sure how to get the word out to everyone who currently has FTP access. Two, I suspect the powers that be would want to sit on it for a while before making it a standard, even if everyone who would need to switch understood what was happening. Three, we're actually supposed to be moving to Subversion...but for some odd reason doing this is taking months. Lots of them.
<LarstiQ> Kilroo: I see.
 * fullermd suggests electroshock.
<LarstiQ> fullermd: tsk :)
<fullermd> What?  Hot pokers aren't called for until week 2...
<LarstiQ> Kilroo: so multiple people are collaborating on the same source now without any version control, across departements?
<Kilroo> Yyyyep.
<LarstiQ> nice.
<Kilroo> Well, I take that back.
<fullermd> See?  Electroshock would be more merciful   :p
<Kilroo> Some of them are using lock files with Dreamweaver.
<LarstiQ> Kilroo: aah, web work?
<Kilroo> But not all of them are, I don't think anyone hesitates to override the lock, and those of us who use Eclipse instead tend not to notice the lock files at all.
<Kilroo> larstiq, yep...mostly php.
<LarstiQ> Kilroo: you don't need to get everyone onboard at the same time
<LarstiQ> Kilroo: granted, things will be harder untill you do
 * fullermd uses bzr to manage piles of PHP code, and occasionally has to deal with Dreamweaver droppings.
<LarstiQ> Kilroo: do you work directly on the server, or is there a syncing step to your workstation before you make a change, make a change, and then upload it again?
<Kilroo> Larstiq: Some people work directly on the server. On occasion, I actually have, myself, for quick fixes. Usually, though, what I do is download the remote files if I think there have been any changes to them, make changes to my local files, and then upload.
<LarstiQ> Kilroo: right, so if someone doesn't sync, there is the possibility for overriding others work?
<Kilroo> Larstiq: Yes.
<LarstiQ> I see.
<LarstiQ> Kilroo: what you could do, is start locally using it. 'bzr init; bzr add; bzr ci' your local copy, and then use bzr as you would normally. When you sync from remote, make sure you have no uncommitted changes, sync, and do a commit (possibly add first for new files) as bzr ci -m 'changes made by others'
<LarstiQ> Kilroo: now, that will only give you versioning locally, and ideally you'd like to collaborate with others
<Kilroo> Hmm
<LarstiQ> but it at least gives you some of the benefits
<Kilroo> Yeah
<LarstiQ> and no one else has to know that you're using bzr
<LarstiQ> from there on, you could expand it to whomever is interested
<Kilroo> that's pretty much what I had in mind, actually, except I was having trouble wrapping my head around the entire process.
<fullermd> I think an important step in the process is to never, ever let the idea works its way into your head that a VCS is a deployment mechanism...
<LarstiQ> fullermd: right, but we have `bzr upload` for that
<LarstiQ> Kilroo: which is a plugin btw, you can find it on http://bazaar-vcs.org/BzrPlugins
<Kilroo> I've seen it. It confused me a little.
<LarstiQ> Kilroo: I need to go to bed now, we can talk about how to use bzr with others another time, or someone else can help you.
<fullermd> I stick with my belief that it's a bad idea in general, and imposes uncomfortable constraints on you even when it technically works perfectly.
<Kilroo> Thanks for your help, LarstiQ
<LarstiQ> Kilroo: how did it confuse you?
<LarstiQ> fullermd: you think `bzr upload` is a bad idea?
<Kilroo> Basically, I'm not sure I understand how bzr-upload differs from making a lightweight checkout and putting it on the production server.
<LarstiQ> fullermd: it only works if deployment means having a copy of your tree somewhere
<LarstiQ> Kilroo: the difference is in where the updating happens
<LarstiQ> Kilroo: with the lightweight checkout, you would need to update it on the server everytime you want it to, well, be up to date.
<LarstiQ> Kilroo: and then you'd need to have bzr on the server
<fullermd> A capability is rarely a bad idea.  Only the use of it   :)
<LarstiQ> Kilroo: with bzr-upload, you're just uploading the files that are in your working tree, no bzr required on the server, no cron, no nothing
<LarstiQ> fullermd: don't evade my question :P
<Kilroo> Well, actually what I meant was making a lightweight checkout and then uploading the result. But I see what you mean.
<LarstiQ> Kilroo: convenience.
<fullermd> I don't think I was evading it.  The biggest drawback of having the tool available is that people are more likely to use it, and I think that mechanism is a tool whose value increases the less it's used.
<Kilroo> Anyhow, thanks again for all your help. I need to go eat now. I think I have a good notion of what to do now, though.
<LarstiQ> I see, fair enough.
<fullermd> It ties the deployment process into the committing process, and the versioned tree shape to the deployed tree shape, and I think both of those are bad things.
<LarstiQ> fullermd: aah, good arguments.
 * Peng_ uses a VCS as a deployment tool. Cough.
<Kilroo> That makes sense to me, fullermd
<fullermd> And I'm crankier with it than it deserves, because I can't understand how so many people immediately jump to the assumption that it's a good idea.
<Kilroo> but then, so does being able to deploy FROM version control.
<fullermd> I mean, I used a VCS for over a year before the thought first occured to me, and after a half hour of setting it up once, I figured out it was a bazooka pointed at my foot   :p
<LarstiQ> fullermd: it's lightweight.
<Peng_> Yeah, that's why I do it. I don't have any complex needs, and it means I don't have to learn any new tools.
<Peng_> I only have one server anyway. (Well, two, but they don't share anything.)
<LarstiQ> fullermd: and I've been using it the last couple of days to deploy an oracle install script, for that it worked nicely.
<Kilroo> My ideal notion is to have VCS, and everyone works with VCS, and then pushing to production consists of taking the current production branch in VCS and putting it on the production server. Hopefully by means of some scripted process.
<fullermd> My deployment process is generally a stack of Makefiles.  And my deployed tree shapes _never_ mirror the tree in VCS.
<fullermd> At the least, the deployed tree is a subset of what's in the VCS (e.g., things like database manglement scripts, don't go in a live environment).  And there's usually more differences.
 * LarstiQ nods at fullermd 
<Kilroo> I'm not sure you can really do that so much in web development.
<LarstiQ> fullermd: you use a heavier deployment process, bzr-upload doesn't add anything there.
<Kilroo> Actually I take that back.
 * fullermd does web development   :p
<LarstiQ> Kilroo: zc.buildout!
<Kilroo> Because I immediately thought of four ways that I could.
<fullermd> ('course, I don't do it, by royal decree, when I don't have real access to the server.  I changed double and a half time any time I have to touch FTP)
<LarstiQ> Kilroo: an aside, do you use sftp or ftp?
<LarstiQ> bzr is much happier with sftp
<fullermd> I guess it boils down to I don't think bzr-upload is evil or bad or broken, I just think it [the general workflow, not the specific tool] is used too often by reflex or whim, rather than really thinking through how the workflow should best be.
<LarstiQ> fullermd: right, I can agree to that.
<fullermd> Of course, that doesn't put it in rareified company   :p
<Kilroo> Let me rephrase: I don't think it would be possibly for the company where I work to have the deployed tree be a different shape from the development tree without massive changes to the way most things are done.
<Kilroo> Granted, some of those changes would probably be beneficial. I personally don't like having any php file that isn't supposed to be accessed directly by the web live in a folder underneath the document root.
<Kilroo> Larstiq: ftp, unfortunately.
<Kilroo> I'm not sure what that business with the document root has to do with what I was talking about in the previous sentence, either.
<Kilroo> I think I'm too hungry to think.
<Kilroo> I'm going to go eat dinner. Thank you again for all your help.
<fullermd> Food is not the answer.
<fullermd> Food is the question.  "Yes" is the answer.
<Kilroo> Amen to that.
<LarstiQ> and I'll detach, ciao
<fullermd> Mwahaha.  And I'll stage a coup while you're all distracted.
#bzr 2008-09-13
<meoblast001> hi
<meoblast001> whats the command that lets you commit changes with a changelog that it lets you edit in nano
<Verterok> meoblast001: try: EDITOR=nano bzr commit
<meoblast001> it was something else
<meoblast001> it was like bzr.. and then a 3 letter work or something
<meoblast001> Verterok: any idea what im talking about
<meoblast001> or maybe it was 2 letters
<meoblast001> i remember it being like cv or something
<Verterok> meoblast001: ci maybe? (it's a commit alias)
<Verterok> meoblast001: replace commit with ci :)
<meoblast001> ok
<meoblast001> =)
<meoblast001> oh yeah
<meoblast001> this is it
<meoblast001> Verterok: how do you push again... i forget the exact syntax.. it's been a few weeks since i used bzr
<meoblast001> nvm i got it
<meoblast001> thanx for helping with the ci though
<Verterok> np
<meoblast001> =(
<meoblast001> i see now updates on launchpad
<meoblast001> only 2 revissions
<meoblast001> https://code.launchpad.net/~mysticgalaxies/nickybearracing/devel
<meoblast001> isnt this proper syntax
<meoblast001> bzr push bzr+ssh://meoblast@bazaar.launchpad.net/~mysticgalaxies/nickybearracing/devel
<meoblast001> ok now its working
<Peng_> meoblast001: Yeah, the Launchpad website takes a little while to update.
 * jml would like to fix that.
<jml> but one thing at a time, eh?
<meoblast001> i guess
<toabctl> hi
<lifeless> jml: the lp website is the definition of 'one thing at a time' ;P
<mneptok> lifeless: i hope to have the favicon changed before the US election.
<lifeless> mneptok: which favicon ?
<jfroy> bzr exploded when I tried to branch a svn repository checkout I have on another machine :/
<jml> lifeless: around?
<lifeless> jml: very, food too much
<jml> lifeless: hah
<jml> lifeless: I was going to ask you if you could think of a better name than pyunit3k
<jml> lifeless: but I've already settled on testtools, so it's got to be a lot better :)
<jml> lifeless: I've rolled back adsorbSuite, so tests-meaning-cleanup should be good to land.
<jml> (once I push it)
<lifeless> cool
<jml> pushed.
<lifeless> drop me mail :P
 * jml does something on the LP UI that should send email
<_Jack_Sparrow_> hello, is there any way to use docdiff with bzr? docdiff prints differences in color at line and column level
<_Jack_Sparrow_> I have tried bzr diff --using docdiff --diff-options " --char --utf8  --tty "              but it's not working :/
<bpierre> try something like this: --using='diff -bBu'
<bpierre> both program name and options passed to --using
<_Jack_Sparrow_> o_O is that comment for me? I checked man diff for what those options mean... and that doesn't make sense
<_Jack_Sparrow_> sorry...
<_Jack_Sparrow_> i understand it now :)
<bpierre> :)
<_Jack_Sparrow_> thanks a lot
<_Jack_Sparrow_> it's working
<_Jack_Sparrow_> :)
<_Jack_Sparrow_> bzr diff --using='docdiff --char --utf8  --tty' | less -R
<_Jack_Sparrow_> does the job
<Peng_> Ooh, I didn't know about 'less -R'. Neat.
<_Jack_Sparrow_> neither did I until 5 minutes ago... first I googled but then I remembered, let me check the man page first :p
<_Jack_Sparrow_> I really find docdiff a usefull tool, too bad it's not "advertised"
<kiorky> abentley: hi
<kiorky> abentley: im trying to set up a bundle buggy instance locally
<kiorky> abentley: i have a problem with trackback errors and mail, it seems that i must have a smtp locally, it is not configurable
<Teddy> When I run "bzr check", I get "bzr: ERROR: exceptions.AssertionError: no parent entry for: debian/changelog in tree 0", and a Python traceback.  What should I do?
#bzr 2008-09-14
<libwilliam> Is there a command that will show when a branch was first initialized?
<jml> lifeless: also, I looked at testresources sorting last night... dijkstra's isn't at all what we want, I think.
<jml> libwilliam: interesting question
<lifeless> jml: simulated annealing perhaps?
<jml> lifeless: well, I think we really want TSP
 * jml looks up that other thing 
<lifeless> TSP, expand pls
<jml> lifeless: Travelling Salesman Problem.
<lifeless> oh right
<jml> of course, we don't have to solve it for the tests, just the set of resource combinations.
<lifeless> simulated annealing is one of a class of polynomial approximations for NPC
<jml> libwilliam: 'bzr log -r 1' is close, but it's not the same thing.
<lifeless> we don't attach a datestamp to 'init'
<jml> lifeless: well, I think there's a lot of room for flexibility in the algorithm
<jml> lifeless: since the numbers are small and the same solution will often apply across multiple test runs.
<lifeless> sure
<libwilliam> jml: it is the closest possible thing I think. The only reason I was wanting the branch init date was when using a calendar I want the user to be able to select the range of when to show the status... and since status allows a revision range of revision=.. I don't know where to limit the user if they didnt commit revno 1 until the a different day.
<libwilliam> I'll figure out a workaround.
<jml> lifeless: but a probabilistic solution to the TSP is probably a good default.
<jml> spiv suggested a modified Dijkstra's where the end node only 'appears' on the graph when all the others have been traversed
<jml> but neither of us have bother to look at the algorithmic complexity of that.
<lifeless> jml: uhm
<lifeless> just have a start node with no resources, and an end node with cost infinity
<jml> lifeless: I don't think that would work.
<jml> because the path would still be (start_node, end_node)
<lifeless> right, but the cost of that transition is oo
<jml> unless they weren't connected, in which case, (start_node, cheapest_test, end_node)
<jml> lifeless: yeah, but the cost of any other path from start to end will also be â
<lifeless> right
<jml> lifeless: ok in that case I don't know what your point is.
<lifeless> surely that gives us what we want
<jml> Well, experiment is the ultimate arbiter here, but I don't think so.
<jml> Dijkstra's gives us the cheapest path from A to B, without necessarily traversing any nodes in between.
<lifeless> thats right
<lifeless> if A is no resources
<lifeless> and B is infinitely many resources (a sentinel)
<lifeless> then any resource-set might have a cheaper path from current pos to B
<lifeless> so all resource sets get inspected
<lifeless> the by product of the search was what was interested when I looked at this last
<lifeless> anyhow, I'm interested in overall improvements, not the exact algorithm used
 * jml too
<jml> but I also want to re-enable the disabled test.
<lifeless> ok
<jml> lifeless: do you have a pre-written 'bigger than everything' object lying around?
<lifeless> so my concept was
<lifeless> [no]
<jml> [[maybe it was one of the twisted guys]]
<lifeless> oh yes I do
<lifeless> its in bzrlib
<jml> lifeless: :)
<jml> yay memory
<lifeless> so my idea was that even though djikstra snaps to the shortest path after inspecting everythin
<lifeless> h
<lifeless> g
<lifeless> you know it has inspected it, and there is a by product in the implementation, I don't recall quite what it was
<lifeless> alternatively
<lifeless> if the cost to the final sentinel is not constant, but less by the current cost of the path, it won't snap and you'd get a full traversal, which was cheapest at each individual step
<lifeless> which suffers local-minima problem, but thats frankly not a huge deal in this case, I think
 * jml neither
<jml> either way, the trick is to force it to actually do a full traversal.
<jml> also, you want to take the final teardown costs into account.
<paolettopn> Hi guys....
<paolettopn> there is anyone that can help me?
<mwhudson> doh
<lifeless> mwhudson: "no"
<fm> is there a way to checkout a bzr repo from launchpad without having bzr. My bzr does not work as I am using python 2.6, but how do i get https://code.launchpad.net/~vila/bzr/py26bzr ??
<vila> fm: https://code.launchpad.net/~vila/bzr/py26bzr is useless for now with python-2.6, you need to find a python-2.5
<kiorky> jelmer: ping
<fm> i am afraid suse will not downgrade python for bzr. most other packages are working beta1 is due next week vila...
<kiorky> jelmer: seems that i cant branch over a svnrepo which is on the same filesystem
<vila> fm: I'm afraid bzr will not support python-2.6 next week :)
<kiorky> jelmer: http://rafb.net/p/El3FTn47.html
<vila> It's quite custom for distributions to support multiple versions of python though, I'd very surprised that bzr is the only package not yet ready for python-2.6
<fm> as 11.1 will be the base for the enterprise products, this will probably mean no bzr on them too.
<fm> you may look at https://bugzilla.novell.com/show_bug.cgi?id=425644
<ubottu> bugzilla.novell.com bug 425644 in Development "bzr init fails: failed to load bzrlib.repofmt.pack_repo.RepositoryFormatKnitPack1: cannot import name U32" [Normal,New]
<fm> i will ask
<vila> I've seen that report before updating bug #269535
<ubottu> Launchpad bug 269535 in bzr "bzr does not work with python2.6" [Medium,In progress] https://launchpad.net/bugs/269535
<fm> ok ;)
<vila> Next step will be to analyze how many root causes for the failures=33, errors=35, some may be less important than others
<vila> but the __init__ behavior change is not trivial
<Odd_Bloke> On a slightly related note, does PQM check if we've had any regressions on 2.4 _and_ 2.5, or does it just use one or the other?
<fm> sadly I do not now python vila. I just wanted to try bzr for an assignment I am currenty working on. as it sounded really cool ... But certainly I am willing to test everything ;)
<spiv> Odd_Bloke: IIRC, it just checks with 2.4 atm.
<vila> I don't use opensuse myself so I can't say how to install a python-2.5, but I'd be very surprised if no way exists to do that
<vila> spiv: are you really there or just passing around ?
<spiv> vila: I'm sort here.
<spiv> s/sort/sort of/
<vila> anyway, I'd really appreciate your advice about bug #269535 regarding __init__ behavior
<ubottu> Launchpad bug 269535 in bzr "bzr does not work with python2.6" [Medium,In progress] https://launchpad.net/bugs/269535
<vila> I'm not 100% sure of my diagnosis, but the code path failing is related to RemoteTranport inheriting from Transport and SmartMedium
<vila> s/Transport/ConnectedTransport/
<mwhudson> oh what
<fm> vila: what is the timeframe to expect python 2.6 support, certainly the next ubuntu version will ship it ... or not?
<spiv> vila: FWIW, I don't see any mention of the __init__ change in http://docs.python.org/dev/whatsnew/2.6.html
<vila> spiv: I can't find back the reference but roughly __init__ now complains when receiving arguments
<spiv> vila: in general, using super() when you don't know that all the bases will have a compatible signature is a bad idea I think
<vila> spiv: I think so too, try bzr gannotate bzrlib/transport/__init__.py on Transport.__init__ :D
<vila> object.__init__ doesn't seem to line base=base starting with python-2.6, that's the problem
<vila> bzr: ERROR: exceptions.TypeError: object.__init__() takes no parameters
<fm> vila: spiv http://bugs.python.org/file2323/new_init_strict.patch thats the patch i guess
<vila> fm: Thanks, that's the reference I was searching ! I read that yesterday but I can't find anymore how I went there....
<spiv> fm: yeah, I thought it probably was intentional.
<lifeless> yay
<spiv> It's not clear from the discussion at http://bugs.python.org/issue1683368 if they thought it would cause people's code to break.
<lifeless> clearly, super() is broken by design and this just proves it :)
<jml> spiv: without looking at the bug, I'm pretty sure that it wasn't a priority for them.
<mwhudson> spiv: given that it broke the standard library in three places...
<vila> It seems to me that the intent was to apply the patch to 3k but it leaked into 2.6...
 * LarstiQ reads it that way as well
<vila> hi LarstiQ ! Thanks for the support :D
<LarstiQ> vila: np :)
<vila> Anyway, we'd better fix bzr
<spiv> vila: probably the best fix is to remove the multiple inheritance from RemoteTransport entirely... I'm not sure that it really needs to inherit from SmartClientMedium.
<vila> spiv: That was my intuition and the reason I wanted to ask you :)
<kiorky> uhm
<kiorky> with bundlebuggy
<kiorky> is there a page with all patches for all projects ?
<spiv> vila: the smart client medium is really the underlying connection, so it really ought to be using the ConnectedTransport stuff for managing that, rather than mucking about with multiple inheritance I think.
<vila> so ConnectedTransport as a SmartMedium attribute ?
<spiv> Huh?
<spiv> I mean, ConnectedTransport already has code to manage _shared_connection and the like.
<spiv> For RemoteTransport, that _shared_connection should be the smart medium.
<spiv> For HttpTransportBase, a smart client medium may as well be constructed on the fly as they are needed.
<vila> Some typos are worse than othres s/as/has/ :)
<spiv> Ah, ok.
<jml> vila: typo? I bet you wouldn't even pronounce the 'h' :P
<vila> Damn, uncovered, now everybody knows I use speech recognition while chatting
<jml> :)
 * jml is very tired.
<johan> is it possible to edit commit messages?
<johan> after the commit is done of course
<lifeless> no
<lifeless> you can create a new commit object with a different message
<johan> too bad, I remember that svn allowed me to do that
<spiv> If it's just the most recent commit, then "bzr uncommit && bzr commit" works well.
<johan> right, but it isn't the last
 * spiv nods
<justizin> agh i know i have asked about this before, but forget the name of the feature, i keep hearing there is a comparative feature to svn:externals in dev, or maybe in 1.6, but can't find it in docs or anything.  any word?
<justizin> i don't care about compat with svn:externals in bzr-svn, am moving our deployment from svn to bzr and, though i was able to pull the externals with a bash one-liner, it was not as much fun to write as drinking beer :)
<vila> bzr/python-2.6 down to 10 failures, 1 error :D
<vila> See you tomorrow all.
<fm> vila: thanks for working on it!
<gutworth> does bazar support a bisect-like command?
<Odd_Bloke> gutworth: There is a bisect plugin.
<gutworth> I should have known :0
<unangz> hallo masters
<unangz> how to checkout from windows repository to linux???
<unangz> can all of you help me???
<gutworth> have you tried?
<unangz> yes i have
<unangz> i use ftp protocol
<unangz> but i get problem when i commit
<gutworth> oh?
<unangz> because bzr not support for smb protocol
<gutworth> ftp is not a very good protocol anyway
<unangz> what can i do to solve my problem?
<gutworth> can you use ssh or http?
<gutworth> sftp?
<unangz> if i checkout use http, it's clearly can not for commit back
<unangz> http not support for make directories or files
<unangz> how to installing ssh server on windows
<gutworth> bzr serve
<unangz> u have any tools or applocations ssh servers for windows?
<nekohayo> uh oh
<nekohayo> what happens if someone merges a branches, and makes changes before committing the merge?
<nekohayo> seems one of my devs did just that, and it scares me
<gutworth> the changes are just crammed in with the merge
<nekohayo> gutworth: will bazaar know how to differentiate the two?
<nekohayo> or will it basically screw up interactions with other branches afterwards?
<gutworth> what do you mean?
<gutworth> all that will happen is that you won't be able to separate the commits
<gutworth> nothing horrible
<nekohayo> oh ok
<nekohayo> gutworth: I guess bazaar is smarter than I expect it :)
<AmanicA> does anybod know how to convert chroot--1211347476:///bazaartest/trunk/  to file:///bzrroot/bazaartest/trunk/  ?
<AmanicA> so far I've been able to derive the transport from the url, but that only gives file:///bzrroot/
<lifeless> AmanicA: to do an unlock?
<AmanicA> to get the local file while in hook, to pass to other script
<lifeless> AmanicA: external to bzr?
<AmanicA> I mean to convert the branch.base given to hook, into a branch url which I can pass back to bzr log
<lifeless> you can pass chroot--1211347476:///bazaartest/trunk/ straight to bzr log in the same process
<AmanicA> mm the hook fires a php script which then trigers `bzr log -r ...` to obtain other info
<lifeless> right, so external to bzr ;)
<AmanicA> then bzr log complains: errors.UnsupportedProtocol
<lifeless> transport.local_abspath('.') may work
<lifeless> the chroot-* syntax is a special in-process syntax only
<AmanicA> I think I tried that
<AmanicA> I can try again quickly
<AmanicA> SmartMessageHandlerError: The message handler raised an exception: chroot--1211093524:///bazaartest/trunk is not a local path.
<AmanicA> ok so I obtain the transport with : `tr = transport.get_transport(result.branch.base)`
<AmanicA> which seems correct: `tr: <bzrlib.transport.chroot.ChrootTransport url=chroot--1211093524:///bazaartest/trunk/>`
<AmanicA> then `tr.external_url()` gives `file:///var/lib/gforge/bzrroot/` which is the closest to what I want
<AmanicA> except its only the url to the base of the transport, I need file:///bzrroot/bazaartest/trunk/
<AmanicA> I mean file:///var/lib/gforge/bzrroot/bazaartest/trunk/
<lifeless> uhm
<lifeless> I didn't say external_url :)
<lifeless> I said local_abspath
<lifeless> oh right, and you get an error on that
<AmanicA> I tried that and it gave ` SmartMessageHandlerError: The message handler raised an exception: chroot--1211093524:///bazaartest/trunk is not a local path.`
<lifeless> I think you should file a bug; it is reasonable to want to run an external script on a branch being pushed to by the smart server
<AmanicA> where do you think the problem/solution would be?
<lifeless> we need to look at the security implications
<AmanicA> oh you mean that method should be implemented?!
<AmanicA> oh, so no easy fix :(
<lifeless> and then likely both fix local_abspath to support the chroot transport type
<lifeless> and possibly provide a public method to get the backing location
<AmanicA> ok I will quickly log a bug mentioning youe sugestions.
<AmanicA> in the meanwhile I might manually translate the url to get my stuff working. I can look into fixing the bug a little later if someone which better knowledge about these things doesn't beat me to it
<lifeless> ok, thanks
<AmanicA> thank YOU!
<AmanicA> thanks lifeless, my monkey patch is 2 lines, and works beautifully. I've been trying to figure this out since saturday :( .
<AmanicA> what are we not willing to do in the quest to do things right the fist time..
<lifeless> :>
<poolie> spiv, lifeless, call in 2m
 * jml kills the music
#bzr 2009-09-07
<mwhudson> how big is bzr.dev in 2a format?
<wgrant> mwhudson: Around 40MB here.
<mwhudson> hm, i wonder why getting lp:bzr has transferred 60 odd megs then
<wgrant> The copy I grabbed a few days ago was badly packed.
<mwhudson> oh
<lifeless> mwhudson: lp is running 1.17
<lifeless> mwhudson: additional data added to it will not be packing well
<lifeless> though we did pack the mirror repo
<mwhudson> ah ok
<lifeless> loggerhead is odd ><
<lifeless> I just managed to get a redirect to the branch id space
<lifeless> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/packs/?C=S;O=D
<lifeless> mwhudson: ^
<lifeless> mwhudson: are you branching clean, to a existing-but-empty repo, or to an existing populated repo ?
<mwhudson> lifeless: former
<mwhudson> well, past tense now, it finished
<lifeless> totally clean
<lifeless> hmm
<lifeless> mwhudson: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/packs/?C=S;O=D
<lifeless> look at the link to 'parent directory'
<mwhudson> lifeless: yay apache
<lifeless> so there is about 38MB on disk
<lifeless> I suspect wire protocol shenanigans
<lifeless> I'll file a bug
<mwhudson> lifeless: so finally looking at https://code.edge.launchpad.net/~lifeless/bzr/bug-423818/+merge/11279, i think a tab has crept in perhaps?
<lifeless> its possible; my vim setup on this machine isn't == my laptop
<lifeless> it passes test :P
<mwhudson> yeah, pack_repo.py:2101
<mwhudson> it looked like a syntax error in meld...
<lifeless> mwhudson: I just tried the same fetch you did
<lifeless> 41MB
<lifeless> which is tolerable
<mwhudson> lifeless: strange
<lifeless> what URL did you branch from ?
<mwhudson> lp:bzr
<lifeless> are you logged in?
<mwhudson> yes, it was certainly bzr+ssh
<mwhudson> hm 1.18dev locally, maybe quite old
<lifeless> please upgrade and repeat
<lifeless> other than that tab, its ok ?
<thumper> mwhudson: rinse and repeat :)
<mwhudson> lifeless: well, i'm lacking some context about some things
<mwhudson> lifeless: in particular, i'm not really sure what the test is testing
<mwhudson> lifeless: it seems like the test is assuming that adding 10 revisions is enough to trigger an autopack
<mwhudson> lifeless: will the test start failing if that ceases to be the case?
<lifeless> yes, as the comment says :)
<lifeless> no, it won't; I could add a check that checks it did do an autopack
<lifeless> OTOH that feels like diminishing returns to me: changing the algorithm for autopack requires substantial test checking anyway
 * mwhudson uninstalls plugins at random until apt will upgrade bzr
<rar> upgrade_guide/data_migration is confusing me - is the only way to upgrade my bzr (which is a shared repo with several branches) by creating a new shared repo in 2a format? I ran upgrade the other day and it seemed to be working, but died in a power failure and haven't tried again yet
<lifeless> poolie: ping
<lifeless> rar: if you had a power failure you probably have a partially upgraded repo
<lifeless> you'll want to mv .bzr bzr.failedupgrade
<mwhudson> lifeless: yes, otherwise looks ok to me, but maybe you should get poolie to look at it now he's awake :)
<lifeless> mv backup.bzr .bzr
<lifeless> and upgrade again
<rar> I did that, but I'm reading the doc first this time
<rar> and the doc seems to say what I did was wrong.
<rar> "To migrate branches in a shared repository: ... Create a fresh shared repository in the new format (2a or later)."
<lifeless> rar: I've got no idea why it says that
<lifeless> rar: its certainly not how I upgraded all my shared repositories; I'
<lifeless> ll chat to the upgrade guide author about that later today
 * lifeless times out on the ping
<rar> okay, I'll do what I did last time then... including ^Cing out of the check by the look of it, it's not moved for half an hour or so
<jelmer> SamB: that should also already work
<jelmer> lifeless: hey
<jelmer> lifeless: subunit review is on my radar
<lifeless> jelmer: thanks; its actually the perl stuff I wanted to ping you about
<spiv> lifeless: update that branch to 2a, you mean?
<spiv> lifeless: I have, but there's an LP bug :(
<spiv> lifeless: bug 424136
<ubottu> Launchpad bug 424136 in launchpad-code "Cannot upgrade stacked branches from 1.9 to 2a on Launchpad" [High,Confirmed] https://launchpad.net/bugs/424136
<mwhudson> ah right, i should look at that today
<spiv> mwhudson: yes please!
<mwhudson> gah
<igc> morning
<mwhudson> lifeless: i ran that fetch again, but failed to monitor how much it transferred
<lifeless> :P
<lifeless> h ighc
<lifeless> hi igc
<lifeless> rar: igc wrote the upgrade guide :)
<lifeless> igc: why does the upgrade guide say noty to upgrade shared repos inplace?
<igc> lifeless: hi
 * igc looks
<rar> I'm looking at http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/doc/en/upgrade-guide/data_migration.txt#L128
<rar> (or rather the same thing in the last 1.9 change, but it's the same text)
<igc> rar: the latestdoc is http://doc.bazaar-vcs.org/bzr.2.0rc2-html/en/upgrade-guide/index.html
<igc> rar: which bit exactly are you asking about?
<rar> I want to get the latest copy of bzr.dev and am confused about thr right way of doing this. Robert's email to the list and the upgrade guide seem to say slightly different things.
<rar> http://doc.bazaar-vcs.org/bzr.2.0rc2-html/en/upgrade-guide/index.html#migrating-local-branches-after-a-central-trunk-has-migrated <- this is the right section to be reading for the like-bzr.dev case, right?
<igc> rar: yes
<igc> rar: so poolie and lifeless have migrated bzr.dev to 2a now
<igc> rar: so you don't need to migrate the trunk yourself - just grab the migrated one into a new shared repo
<igc> rar: and pull your branches across as the guide says
<igc> rar: I've just did exactly this last Friday for some branches and I'm pulling/merging others across today
<rar> but, that means downloading some large number of bytes from the internet? then... re-branching all my branches into a new directory?
<igc> rar: 2a compresses data pretty well - my .bzr/repository/packs directory for bzr itself is 34M
<rar> does running upgrade in the shared repo root not have the same effect?
<igc> rar: it should, though I suspect running upgrade will be a lot slower than just grabbing the converted branch for many users
<igc> rar: how's your internet connectivity?
<rar> bad at certain times of day, but you may be right that redownloading is a quicker process than running upgrade
<lifeless> spiv: can you mail me a bundle against 2.0 of your branch please
<rar> looking at each branch seemed like a lot of manual steps I was trying to avoid though (have now gone through them all anyway)
<rar> there's a doc patch from two years ago that I really should have finished...
<lifeless> jelmer: hi, was a phone call sorry.
<igc> rar: to give you some benchmark, I also tried doing a local upgrade of my old shared repo holding bzr.dev last week - it took 83 minutes
<lifeless> jelmer: doing the reviews would be great. Finishing your perl stuff to install appropriately so that users can use it - better!
<igc> rar: that's on a i7 920 desktop with 6G of RAM and 1TB of disk
<lifeless> igc: fast-import; I hit 6G of memory for the netbeans import; jam suggested it might be holding full file texts or something ...
<igc> rar: grabbing the converted bzr.dev is a lot quicker than that for me at least
<lifeless> igc: worth documenting 'easy but slow', 'fast but manual'
<igc> lifeless: the source was hg right? if so, fast-import itself isn't holding fulltexts beyond the time taken to do a given commit
<igc> lifeless: how many revisions do it get loaded? It will checkpoint a pack every 10k
<igc> lifeless: so restarting will start frm the last 10k boundary fwiw
<igc> s/do/did/
<spiv> lifeless: sure
<spiv> lifeless: oh, or pull it from lp:~spiv/bzr/insert-stream-check-chk-root-again
<spiv> lifeless: where is where I repushed to for PQM's sake.
<poolie> spiv, igc, hello
<igc> hi poolie
<poolie> igc, i was planning to look at bug 385879 today
<ubottu> Launchpad bug 385879 in bzr "EOL filter only applied to files when first checked out" [High,Fix committed] https://launchpad.net/bugs/385879
<poolie> i see there was already a long thread with robert
<igc> lifeless: is check on a branch in a shared repo meant to check all branches in the repo?
<igc> poolie: thanks - I was really hoping that would reach the top of your list today
<poolie> should i take that bug from you?
<igc> poolie: yes please
<poolie> also can i suggest you put the bug number in your branch name?
<igc> ok
<poolie> in future that is
<poolie> how's the packaging stuff? it looks like the chm help was welcome
<igc> poolie: a patch for pdf and chm docs has been put up
<poolie> that was a good idea to actually distribute the built files
<poolie> no one would test them if you just put up a patch
<igc> poolie: the main issue is pulling out the foreign language stuff which is kind of part of that other doc packaging bug
<spiv> lifeless: I see PQM now tries to give % progress, do we need to add --subunit to 'make check' to make it work?
<igc> poolie: and I now have a local vista install with 30G to do some serious Windows development/testing (instead of an XP partition with 0.5G spare)
<spiv> poolie: good morning.
<poolie> hi spiv
<lifeless> spiv: yes
<lifeless> spiv: but we need to check the subunit dep is in the chroot
<lifeless> spm: ^
<lifeless> I've mailed the sysadmins back on the same ticket that got pqm upgraded
<lifeless> igc: hmm, re: check one branch in a repo - bug I think
<lifeless> unless you're at the root of the repo
<lifeless> igc: 133K revs
<lifeless> igc: it died ~65K, I killed it and removed the output, I thought it was not resumable as there were no branch objects etc
<igc> lifeless: branches only get created at the very end after it works out the heads in the repo
<lifeless> igc: sure I figured that
<lifeless> didn't realise you could resume though
<lifeless> anyhow, it was very unhappy :P
<igc> :-(
<lifeless> I have a 6G pymemory dump file
<lifeless> and the 129GB input stream
<igc> you can gzip that input stream btw and fast-import will still accept it
<lifeless> yup, its doing that at the moment ;P
<lifeless> it may take a bit :) :)
<igc> lifeless: it will :-)
<lifeless> so, no thoughts about what blew up the memory ?
<lifeless> and when you say resumable, what file stores the resume data?
<igc> Not yet sorry. I need to focus on core stuff and the Windows installer early this week so I can't look into fastimport stuff till the weekend probably
<igc> there's a .bzr/repository created
<igc> it just looks in there, takes the count of revision and skips ahead in the input stream that much, complete with some sanity checking
<lifeless> meep lol
<lifeless> so running it in an existing repo == 'interesting' ?
<lifeless> brb
<igc> lifeless: the input stream and repo need to match exactly fwiw
<spm> lifeless: not in the chroot, no
<poolie> spiv, how's stuff?
<spiv> poolie: good, my chk-root check is finally going to land on 2.0 after some snafus like bug 424136 on Friday.
<ubottu> Launchpad bug 424136 in launchpad-code "Cannot upgrade stacked branches from 1.9 to 2a on Launchpad" [High,In progress] https://launchpad.net/bugs/424136
<poolie> ok
<poolie> and is that the end of that series of bugs?
<spiv> And I have a branch that does checking for all relevant chk pages, which seems to be working and passing a relevant test.
<spiv> This is a bit of a "how long is a piece of string" bug, you can always do more integrity checking... but checking for chk records and checking for the text records referenced by those would be sensible end, I think.
<spiv> Next time someone pokes at this and 'bzr check' they can hopefully unify some of the code between those two places.
<lifeless> spm: I can haz
<spm> lifeless: sure, but I dno't have privs to do so. Super urgent?
<lifeless> spm: not super.
<spm> the rt is still with tom, he should be able to update with one of the handy gsas overnight.
<poolie> ok, so please do make separate linked bugs for each section of that string
<lifeless> spm: please cancel the current bzr pqm job
<spm> oki
<lifeless> thanks
<spm> is done
<lifeless> jml: you were asking what my subunit/pqm patch looked like
<lifeless> jml: http://pqm.bazaar-vcs.org/ shows it in stub form - we don't have subunit in the pqm chroot yet
<jml> lifeless, cool.
<lifeless> igc: what sort of compression ratio do you expect out of gz on .fi's?
<igc> lifeless: 5-10X better typically
<igc> at a guess
<lifeless> thanks
<igc> lifeless: as a guide, some gzipped sizes ... firefox 3.5: 1.7G, kernel: 2.6G, mysql-server 5.1: 7.3G
<lifeless> -rw-r--r--   1 robertc robertc 129G 2009-09-03 21:43 /home/robertc/source/release67.fi
<lifeless> -rw-------   1 robertc robertc  23G 2009-09-07 12:34 /home/robertc/source/release67.fi.gz
<lifeless> still going :P
<poolie> lifeless: i suggest we ask about series etc on the launchpad list next
<lifeless> poolie: ok :)
<poolie> see also #launchpad now
<lifeless> am there ;)
<lifeless> poolie: this seems to be orthogonal to milestones, yes?
<lifeless> poolie: I want to fix the inconsistent docs while its in my head; Ideally I'd only touch them once..
<poolie> k
<poolie> incremental changes are fine
<poolie> i think we should say "bugs that will block a release should be targeted to the relevant release"
<poolie> i don't want to rename milestones
<poolie> iow things that should block us doing the next rc should go into 2.0rc2
<poolie> i'm not sure this is ideal
<poolie> it means there's no single "watch this space" url
<poolie> :/
<lifeless> the only people it doesn't serve are those that want a 'watch this space url'
<lifeless> In myinitial analysis I didn't consider them at all
<lifeless> I'm fine with them losing out for now
<poolie> mm
<poolie> it's probably ok
<poolie> it needs some analysis of "what do they want"?
<poolie> A: a line sloping down to the right :)
<lifeless> Its a good question
<poolie> if it's "are we in ..trouble" then +critical is probably better
<poolie> if it's "are you moving" then the changed or inprogress bugs list may be better
<poolie> meh
<lifeless> it could be 'will they hit the release date'
<lifeless> which critical is [problematic] proxy for
<poolie> mm
<poolie> so "will they hit it" is interesting wrt milestones because
<poolie> it's not so much "how much more for 2.0rc2" but "how many more rcs before final"
<lifeless> if we don't do rc's when there are blocking bugs, its 'how lnog till the rc'
<lifeless> its thorny
<lifeless> poolie: so, if we're going to generally avoid renaming milestones, should we rename 2.0 to 2.0rc2
<lifeless> e.g. undo part of the changes I did
<lifeless> spiv: igc: have you found that a submit branch of lp:bzr/2.0 works ?
<lifeless> or is that hopeful speculation in the dev docs ?
<lifeless> poolie: ^
<poolie> lifeless: it seems to work for me but i'm not sure i did it since the upgrade
<poolie> > merge http://bazaar.launchpad.net/~mbp/bzr/prepare-2.0 http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0
<lifeless> so the http url there
<poolie> at 7pm friday
<lifeless> is what I think we should document, at least until I fix the pqm location aliases support bug
<igc> lifeless: I'm using the http url as well
<poolie> wfm
<poolie> by which i mean, that's fine with me
<lifeless> submitting the merge:-> (Error ID: OOPS-1346ED42)
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1346ED42
<poolie> lifeless: what do you mean by submitting?
<lifeless> poolie: was just random mumbling about lp timeouts :)
<poolie> oh, registering the mp?
<lifeless> yes
<lifeless> did you just think I was sending it pqm?
<lifeless> :_
<lifeless> :)
<poolie> at first i thought pqm might have got an oops hook
<lifeless> hmm, I guess my comment was ambiguous
<lifeless> I'm merging 2.0 to trunk now
<lifeless> spiv: has 423506 landed in 2.0 ?
<lifeless> spiv: if so, please put bug numbers in the pqm message, it helps.
<lifeless> poolie: https://bugs.edge.launchpad.net/bzr/+bug/406687
<ubottu> Ubuntu bug 406687 in bzr/2.0 "insert_stream doesn't check references are satisfied" [Critical,In progress]
<lifeless> If we're on the same page, that bug's metadata will be appropriate for both of us
<lifeless> blocking the next 2.0 release; to be fixed on both 2.0 and trunk.
<poolie> looks good to me
<lifeless> this isn't actually a change at all from our docs :)
<lifeless> but I've tried to make doing this /clearer/ by reading the docs with a fresh eye
<lifeless> poolie: I'd like to rename 2.0 back to 2.0rc2 in light of your desire to avoid renaming at release times.
<lifeless> poolie: unless you think you're going to change your mind it seems trivially right to me to make the current metadata match our process
<lifeless> https://edge.launchpad.net/bzr/+milestone/2.0 three bugs left :)
<poolie> i'd sit on it and see if other people reply to that thread
<poolie> i'm not really happy with any of these options
<poolie> i do want to give people a 'watch this space' link and to have one myself :/
<lifeless> personally I think renaming is the least of all evils
<lifeless> I've filed a bug about the misleading activity log
<lifeless> and a few others today :)
<lifeless> igc: rev props with no value
<lifeless> igc: I commented on the bug; I think None should be illegal; things like fast import should choose either "" or no-property: the core can't really make that choice.
<igc> lifeless: fast-import fold None to '' currently iirc
<lifeless> igc: ok; what does your patch do then? (I saw it go by, but haven't read it yet)
<igc> lifeless: may patch just fixes the error msg so key and value come out in the right place in the msg
<igc> s/may/my/
<lifeless> igc: cool
<lifeless> igc: I'll let this fast import run for a bit, and see if it does better once it starts swapping
<lifeless> igc: if I can offer a performance hint
<igc> lifeless: sure but best in a bug report so I don't forget it
<lifeless> igc: if you use the stream in purely streaming mode, running gunzip -c in a subprocess would let you get two cores working at imports from .gz files
<igc> right
<lifeless> I don't know if you do though
<igc> it's multi-pass by default now so no
<lifeless> well
<lifeless> multipass is one thing
<lifeless> forward-only is orthogonal
<lifeless> do you seek at all within a pass?
<igc> no, only when the first pass completes
<lifeless> and if you seek, do you seek backwards ?
<igc> seek(0)
<lifeless> I'll file a bug then, you can do this
<lifeless> bzr-fastimport is the project, righyt?
<igc> yep
<lifeless> sent
<igc> thanks
<lifeless> my pleasure
<lifeless> I know you like to squeeze speed out :)
 * lifeless is off to finish paying for a sofa
<lifeless> on the mobile if folk need me
 * igc lunch
<lifeless> poolie: PQM looks happy; I'm EODing modulo emergencies. I might touch base with you around 5 to tee up tomorrow's release-related plans.
<poolie> i don't mind but i still boggle at how early your work day is
<poolie> anyhow, jolly good
<poolie> lifeless: http://bzr.pastebin.com/d7e16641f -- i'm not complaning about the change but the way launchpad presents this is a bit suboptimal
<vila> hi all
<lifeless> poolie: re: that pastebin; its partly an artifact of an originally-mis-organised bug, one task not two; the bzr.dev task with a milestone on 2.0 etc.
<lifeless> hi vila
<poolie> hi vila
<vila> hey !
<poolie> vila, regarding bug handling
<poolie> your mail was pretty thoughtful
<poolie> i was going to reply and then i asked myself, "are we just making a big issue out of a small one?"
<vila> poolie: feel fre to disagree, there are various ways to address the problems
<vila> I just express my POV as it was clear in my head :)
<vila> I can adapt to anything we decide to do :)
<vila> poolie: I mean, in the end, if I (and/or others) really feels like assigning new milestones to make them more precise, the RM don't have to do it...
<lifeless> poolie: https://bugs.edge.launchpad.net/bzr/+milestone/2.0
<poolie> mm?
<lifeless> poolie: tomorrow, I'll likely be waking up early again :(
<lifeless> and I have a half day combined w/that
<lifeless> so I'm thinking I might just look at non targeted bugs / polish / etc
<poolie> that sounds good
<lifeless> the three remaining bugs are all either assigned or in progress and not really parallisale
<poolie> maybe nontargeted critical bugs
<lifeless> that sort of thing yes
<poolie> lifeless/vila: i'm wondering if the recent stuff about how to handle release blocker bugs is in fact, um, "bad", for lack of a better word
<lifeless> I have a couple of itches queued up too, that I'd like to do.
<poolie> given that we generally want to just do time based releases with no-brainer release management and no slips
<poolie> perhaps we are making too much of a process for something that should be discouraged
<lifeless> details are easier to bikeshed on :)
<poolie> of course handling rare events well or systematically is still worthwhile
<vila> poolie: well, 2a as default raised many critical bugs, *that's* unsual
<lifeless> poolie: I don't think we've been talking about blocker bugs a lot; my focus has been on the event-of-the-release and what people can look at later; in general.
<lifeless> poolie: though perhaps you mean further back like a week+ ago?
<vila> poolie: the most important for me is to have a clear bug <-> milestone relationship
<vila> and 2.0 blurry things a bit to my taste, it won't matter /at all/ in a couple of months
<poolie> mm
<poolie> >  the most important for me is to have a clear bug <-> milestone relationship
<poolie> looking forward or looking backwards?
<poolie> looking backward, i agree completely
<poolie> looking forward, i question it
<poolie> it seems like it can mean
<vila> looking backwards
<poolie> 1- we will slip (or seriously consider slipping) the release if this is not fixed; if bugs ever get into this state it is a kind of failure
<poolie> 2- we want to do this next; in other words its a proxy for finer-grained sorting
<poolie> 3- we expect it will be done in time for this milestone but if it's not it's ok
<vila> looking backwards *only* in fact
<vila> for forward, yes, I was a fan of 3 but was out-voted, I still like 2, I agree that 1 should remain the exception
<poolie> 4- we've estimated X amount of bugs can be done for this milestone and managers will judge us on whether we hit that or not
<poolie> i think lp used to do some combination of all of these
<vila> On the overall I now weakly think that milestone should be set either for nomination by users (to mean I'd like this) and strongly think only devs should use them to say: fix released there
<vila> 4 is called in French: 'Tendre le baton pour se faire battre',
<vila> in English that would be... given a mean to someone to harm you
<vila> with the idea that it only works that way and not in the intended way
<poolie> i think 4 is poor because you are using something unreliable (estimation) to measure something probably more consistent (productivity)
<vila> and if it can't be reliably related to what you really did, you are sure to lose
<vila> i.e. any necessary work not tracked via a bug is essentially invisible not matter how important it is
<poolie> i'd rather assess progress by looking backwards at the most recent release, or at the timeline of recently fixed bugs
<vila> s/not/no/
<poolie> right
<poolie> anyhow
<poolie> are there more uses?
<poolie> i think 1 is the most useful, and the only one that really needs targeting
<poolie> i think 2 is better done by inprogress
<vila> do you mean 3 for inprogress instead ?
<vila> I feel that way, I don't mark several bugs inprogress, only one at atime
<vila> and most often I just forget :-/
<vila> so it's confirmed -> assigned to me -> fix committed
<vila> That makes me want to file a lp bug about private/public *user-managed* bug lists
<poolie> it'd be good
<vila> tags are not an answer for that and there is disagreement about using assigned to me (plus the later is limited)
<poolie> so
<wgrant> There was a discussion about a "bug bag" concept at UDS Jaunty for just that purpose.
<wgrant> But it never eventuated.
<poolie> i think it's important we be very clear about #1
<poolie> very important
<poolie> you don't want the rm shipping something known to have bugs we shouldn't fix yet
<poolie> the rest of them, don't necessarily matter a lot,
<poolie> because they're not grounds for communication
<poolie> it's just about what each individual developer (or subset of developers) is going to do next
<vila> you mean critical should always have the closest milestone assigned, right ?
<vila> wgrant: bugs were filed for it ?
<poolie> i'm not sure
<poolie> i'm still openminded about whether 1 should be targeted or critical or both
<vila> mm
<lifeless> I think 1 is very important
<wgrant> vila: There are bugs around for that, yes.
<lifeless> I prefer targetting for it, because its a clear single bit; we can target because of impact, or political desire
<lifeless> and its not conflated.
<vila> critical is the red-button to me, targeted/nominated sounds more like wishes (very subjective and personal view here, not what I think we are doing that)
<poolie> conflation is a good word
<poolie> i think there should be some way to look at a bug and definitely tell if it's in that category or not
<vila> lifeless: but do you mean that any targeted bug should block a release ? Or only critical ones, the other needing to be retargeted ?
<poolie> at the moment there are critical non-blocker bugs, and targeted non-blocker bugs
<poolie> that means that neither defines that category
<vila> critical non blocker ? 8-/ Example ?
<poolie> i guess you could say that if *both* are set the bug is in category 1
<poolie> vila: https://bugs.edge.launchpad.net/bzr/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed
<lifeless> vila: targeted should block.
<lifeless> vila: thats what our docs say :)
<lifeless> poolie: we have targeted non-blockers?
<vila> lifeless: you mean with the patch I'm reviewing ? ;-P
<lifeless> vila: I mean in trunk, right now.
<lifeless> vila: my patch just removes some redundant conditionals from the language.
<vila> lifeless: right, I wasn't at the right page :)
<vila> wgrant: thanks
<poolie> i am not convinced bug 421789 or bug 385879 should be blockers
<ubottu> Launchpad bug 421789 in bzr/2.0 "Windows installer should include explorer, qbzr, chm help, etc" [High,In progress] https://launchpad.net/bugs/421789
<ubottu> Launchpad bug 385879 in bzr/2.0 "EOL filter only applied to files when first checked out" [High,In progress] https://launchpad.net/bugs/385879
<lifeless> poolie: then I think you/we should decide. And if they aren't take them out of the list.
<lifeless> poolie: My vote, FWIW is with you, on both of them.
<poolie> on taking them out? or it's just an undirected proxy vote? :-)
<lifeless> I think the installer one is arguable, but the EOL filter is likely jkust the iceberg tip, so I'd rather not make a big noise on content filtering in 2.0
<lifeless> save that for 2.0.1 or so
<poolie> that's what i was saying this morning, i suspect there will be multiple moles
<lifeless> its neither ready yet, nor clearly in cooee
<lifeless> poolie: yes, I agreed with you this morning, and I still do :)
<vila> lifeless: please have a look at my comments before landing lp:~lifeless/bzr/docs
<lifeless> vila: I'm waiting on poolie specifically on that one; there is a parallel list discussion
<lifeless> and he's expressed an interest ;P
<poolie> lifeless/vila: re 1.18 do you agree we should announce what we have or start a 1.18.1 or both?
<vila> both but more importantly any :)
<lifeless> poolie: 1,18 is the new style release right? simultaneous builds ready on N platforms...
<poolie> right
<lifeless> poolie: if it meets the criteria you established, DoIt
<poolie> and a long delay before it's announced, apparently
<lifeless> if it doesn't, red button, debug the process.
<lifeless> I have no particular view on 1.18.1
<poolie> so with your changes to the docs
<lifeless> there weren't any brown bags in 1.18.0 that are not also in 1.16 and 1.17 that I know of
<vila> 1.18 is already used *today* it just miss the announcement
 * igc dinner
<vila> spiv: Are you you still around ?
<poolie> ok, i'll announce it too
<igc> poolie: given there's agreement to take the Windows installer out of the core, bug 421789 not a blocker
<ubottu> Launchpad bug 421789 in bzr/2.0 "Windows installer should include explorer, qbzr, chm help, etc" [High,In progress] https://launchpad.net/bugs/421789
<poolie> cool
<poolie> i still think it's a good one to work on now
<poolie> just not a blocker
<igc> the bit which is core-related though is the doc changes supporting chm
<igc> poolie: I've split out the Russian, Spanish and developer docs today so searching is chm files works as expected
<poolie> nice one
<igc> s/is/in/
<poolie> is there an mp for that, or is there going to be one?
<igc> I'm just typing up the mp now
<lifeless> +        line = client_sock.recv(50)
<lifeless> vila: - thats not a line
<lifeless> call it chunks or something
<lifeless> also, I'm fairly sure that code already exists in smart/ somewhere; would be good to reuse.
<vila> lifeless: already uncommitted, I know, I agree, it's controversial and I want feedback on *why* it's even needed anyway
<vila> I'm separating the controversial parts from the good ones and will make two submissions
<vila> lifeless: but thanks for caring :-D
<lifeless> vila: btw, I taught buildbot about subunit in the weekend
<lifeless> http://buildbot.net/trac/ticket/610
<vila> lifeless: hehe, excellent !
<vila> lifeless: you just want to make my switch to hudson harder or what ? :-D
<igc> poolie: https://code.edge.launchpad.net/~ian-clatworthy/bzr/doc-site-per-language/+merge/11287
<lifeless> vila: :P I don't have an opinion on hudson vs buildbot, tbh.
<vila> lifeless: currently I'd love better reporting, hudson seems better there
<vila> but it's low priority against having more coverage in my book
<vila> lifeless: so back to your remark about line = client_sock.recv(50),
<vila> I called it line because it appears that even if all the bytes should be available a split occurs on the '\n'
<vila> that's not a proper fix, I'd like to understand why it's needed on FreeBSD and not on Linux, where the hell is that difference coming ?
<vila> That's why the commit message want to express :-D
<vila> That's whay the commit message want to express :-D
<vila> That's what the commit message want to express :-D
<vila> damn
<lifeless> vila: its probably just socket buffer timing on that box/os
<lifeless> vila: its strictly correct to do what you do
<vila> lifeless: with the server socket closed 2  lines above ???
<lifeless> yes
<lifeless> well
<lifeless> reading from the client side when the server is closed is impossible if the server was shutdown properly
<poolie> spiv, https://answers.edge.launchpad.net/bzr/+question/81139 shows the hpss session is apparently hanging in "byte part read" of a get_stream call
<poolie> does that mean anything to you?
<lifeless> you actually have to shutdown(rd); client.recv(); client shutdown(); server.shutdown etc
<vila> yeah, well, I don't mind, I'm just surprised, if I get confirmation that it's expected, I have learned a new bit :)
<vila> you confirmed, I'm happy :)
<lifeless> vila: I haven't read the full code of the test
<vila> by the way, I search recv_all but not at the right place first :)
<lifeless> perhaps the socket is set nonblocking or something
<vila> I changed it in the submission I'm doing right now
<vila> I suspect fullermd will have a look at my patches and hopefully will provide some hint
<wgrant> Is there a source of bzrs for Lenny that is less ancient than backports.org?
<vila> I think LarstiQ said this week-end that Lenny isn't supported anymore ?
<wgrant> That seems unlikely -- it's the current stable release, and had a point release yesterday.
<vila> wgrant: right :-) My ignorance is just showing off then
 * wgrant just uses the Hardy nightly instead.
<vila> wgrant: wow, in fact LarstiQ was not only talking about etch but was also wrong about it not being supported :)
<wgrant> vila: etch is barely supported.
<wgrant> Well, it has a few months to live.
<vila> Sep 06 18:21:46 <Lo-lan-do>	LarstiQ: Etch *is* supported by Debian.
<vila> Sep 06 18:22:29 <Lo-lan-do>	At least until 2010-02-14 or Squeeze releases, whichever comes first.
<wgrant> Right.
<gour> pygi: ping
<vila> BAM ! http://en.expreview.com/2009/09/04/ocz-spruces-up-its-z-drive-ssds.html#more-5073
<vila> Now, that's performance :-D In the 1GB/s range for both read and write...
<spiv> poolie: hmm, to me that means we probably have a bug causing the trace file to be buffered :(
<vila> A bit pricey, but that can only go down...
<poolie> heh, :)
<spiv> poolie: I've added a comment/information request to it.
<poolie> vila: did you get my bazaar-announce list?
<vila> poolie: yup
<poolie> great, thanks
<poolie> vila/bialix: silly question maybe but what happens in windows if you run bzr commit with no -m ?
<poolie> it runs wordpad apparently
<rar> notepad for me.
<hno> Is it possible to convert an existing set of branches to a pipeline?
<hno> using a shared repository btw.
<hno> to be exact I have some so far independent branches that I want to pull together as a pipeline as there starts to be dependencies..
<hno> and making them into a pipeline seems like it would make my life easier.
<LarstiQ> vila-lunch: Lenny is current stable, etch is oldstable
<hno> figured out the pipeline by editing branch.conf by hand... seems not supported by the pipeline plugin yet.
<vila> hno: file a bug, I don't use pipeline myself but it sounds like a feature that should be supported
<lifeless> igc:
<lifeless> bzr fast-import ../release67.fi.gz
<lifeless> bzr: ERROR: exceptions.TypeError: __init__() got an unexpected keyword argument 'track_new_keys'
<lifeless> gnight
<visik71> are there plans to support git push inside bzr ?
<jelmer> visik71: eventually
<jelmer> visik71: but the problem is we need to store bzr metadata in git somehow
<jelmer> and haven't really come across anything that is suitable
<visik7> jelmer: could you use the same method used for svn ?
<jelmer> visik7: git doesn't have revision properties or file properties
<jelmer> so the only real alternative is to add that data at the end of the commit message :-/
<visik7> really bad
<jelmer> visik7: dpush already works, thoug
<jelmer> h
<visik7> with what drawbacks ?
<jelmer> it doesn't push the actual revision but a derivative of that revision
<jelmer> e.g. bzr revision properties are lost (since they can't be represented in git)
<visik7> indeed I dunno what a revision properties is :)
<visik7> does bzr git plugin support authentication ?
<t0mm13b> and I cannot push as I get the message that I have insufficient permissions
<bialix> hi poolie, are you summon me up?
<bialix> poolie: if this question still active: on Windows XP notepad will be launched; on Vista/Windows 7 -- I dunno what's default there, either notepad or wordpad
<bialix> bonjour vila
<vila> hi bialix !
<bialix> :-)
<bialix> it's a pleasure for me to say you "bonjour"
<vila> :D
<bialix> how's 2.0 going?
<vila> fine, 1.18 has been announced though :-)
<bialix> people finally gets 1.18 announce, wow!
* vila changed the topic of #bzr to: Bazaar version control system | bzr.dev is in 2a format | 1.18 final released | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<bialix> I see there is 2.1 milestone in lp
<visik7> my workflow: bzr branch git://github.com/visik7/django-counter.git  --> hack hack --> commit --> bzr dpush  got a bzr: ERROR: No push location known or specified.  so I issue the following command: bzr dpush git://github.com/visik7/django-counter.git  --->> bzr: ERROR:  <<- this without any significant error messages
<hno> Argh.. my attempt in turning two branches into a pipeline did not work out.. somehow bzr pump merged the changes in both directions making them all the same..
<jelmer> visik7: I doubt you can push over git://
<jelmer> visik7: you need to push over git+ssh
<visik7> jelmer: I dunno if github supports it
<jelmer> visik7: github doesn't support upshing over git://, only over git+ssh://
<visik7> oh
<visik7> jelmer: mmm I'm pretty sure my rsa public is right but I got a Permission denied (publickey).
<visik7> bzr: ERROR:
<vila> fullermd: ping
<jelmer> visik7: what's the URL you're using?
<visik7> bzr dpush -v git+ssh://github.com/visik7/django-counter.git
<jelmer> you need something like:
<jelmer> git+ssh://git@github.com/visik7/django-counter.git
<visik7> oh
<visik7> jelmer: I think I can't get dpush
<visik7> bzr: ERROR: LocalGitBranch('file:///Users/visi/Documents/workspace/django-counter/', 'HEAD') and RemoteGitBranch('git+ssh://git@github.com/visik7/django-counter.git', 'HEAD') are in the same VCS, lossy push not necessary. Please use regular push.
<visik7> and obviously a normal push returns an error like this bzr: ERROR: This operation is not supported by the Git smart server protocol.
<visik7> (obviously)
<visik7> ops maybe I miss something
<jelmer> is your local branch using git as well?
<jelmer> if your local branch is git you should be able to push
<jelmer> (git to git push works, bzr to git push does not)
<visik7> yes yes
<visik7> I've moth a clone with git and a branch with bzr
<visik7> s/moth/both
<jelmer> if you push from the git clone, use "bzr push". if you push from the bzr branch, use "bzr dpush"
<visik7> so I can use the bzr command inside a git repo ?
<jelmer> yes
<visik7> so I could clone with git and work with bzr ?
<jelmer> yeah, *in theory*
<jelmer> it should all work and I'm using it but there are some rough edges
<jelmer> if you come across any, please let me know
<eLBati> hi all... http://pastebin.com/m1ed6769e
<eLBati> I am behind proxy
<luks> does bzr know about it?
<eLBati> uhm
<eLBati> "whoami" knows
<luks> whoami doesn't do any network operation
<eLBati> what should I set?
<luks> the http_proxy environment variable
<luks> or maybe https_proxy
<eLBati> http_proxy is correctly set
<eLBati> ah sorry
<luks> anyway, you don't really need launchpad-login
<eLBati> luks: I didnt understand your first question
<luks> I was asking whether bzr knows that you are being a proxy
<eLBati> right, I set http_proxy
<eLBati> bzr branch works
<luks> I'd expect https to use https_proxy
<luks> but I might be wrong
<eLBati> uhm
<CameronP> Cool 1.18 released
<luks> maybe it wouldn't work - https://bugs.launchpad.net/bzr/+bug/190209
<ubottu> Ubuntu bug 190209 in bzr "launchpad plugin xmlrpc does not use $http_proxy (branching lp: uris does not use system http proxy) (dup-of: 186920)" [Medium,Confirmed]
<ubottu> Ubuntu bug 186920 in python "bzr xmlrpc client doesn't use http proxy, causing network errors trying to resolve lp: urls" [Unknown,Confirmed]
<luks> but as I said, you don't need launchpad-login
<luks> just use absolute LP urls
<luks> or set launchpad_username in ~/.bazaar/bazaar.conf
<eLBati> don't I need login to commit?
<luks> launchpad-login just sets the launchpad_username configuration variable
<luks> but it tries to be smart and want to verify the the account is correct
<luks> (but fails, because it can't use a proxy)
<CameronP> Hi All - what does the bzr non-admin setup file have missing (windows)
<eLBati> it could be useful
<eLBati> anyway, I'll have to use proxy
<eLBati> so it could be a significant test
<luks> normal bzr operations will use the proxy
<luks> but the launchpad plugin doesn't
<luks> but you can push only over bzr+ssh to launchpad, which you can't easily proxy
<luks> so if you can't connect to port 22, pushing won't work
<eLBati> oops
<eLBati> damned corporate proxy
 * awilkins also hates corporate proxies
 * CameronP loves corporate proxies when you can add an exception for your own pc ;)
<hno> many corporate proxies do allow port 22.these days..
<lvh> hi
<awilkins> hno: We had to ask for special permission to get through the firewall... now they want us to whitelist all the servers we connect to
<lvh> I've checked out two branches from twisted: bzr branch lp:twisted  bzr branch lp:~lvh/twisted/positioning
<lvh> I'd like them to live in the same directory
<lvh> is it safe to just mv them?
<lvh> And by same directory, I mean something like twisted/trunk and twisted/positioning.
<awilkins> lvh: Yes
<lvh> okay, awesome thanks
<lvh> is it possible to get them to share files?
<awilkins> lvh: You may want to instead.
<awilkins> bzr init-repo twisted
<awilkins> bzr branch trunk twisted/trunk
<awilkins> bzr branch positioning twisted/positioning
<lvh> awilkins: Awesome! Thank you :-)
<awilkins> You may have to pick a more modern repo format than the default for optimal performance
<lvh> except: different rich-root support
<lvh> The init did Shared repository with trees (format: pack-0.92)
<awilkins> bzr init-repo --1.14-rich-root
<awilkins> Or --2a
<lvh> Okay. I thought the new recommended fancy format was 2a?
<lvh> Aha! :-)
<awilkins> The format the original branch is in is probably best
<luks> otherwise it has to convert, which might be very slow
<luks> especially for non rich-root => rich-root formats
<lvh> luks: Once, or every time I commit/push?
<luks> every time you pull
<luks> or ush
<awilkins> Hell, anything => 2a seems slow to me
<luks> *push
<luks> use the same format as lp:twisted
<lvh> Branch format:  	Branch format 7
<lvh> Repository format: 	Packs 6 rich-root (uses btree indexes, requires bzr 1.9)
<lvh> That's lp:twisted, and mine is identical.
<lvh> my branch, I mean.
<awilkins> I have some SVN converts with big revisions that just make the memory explode and die when you try to conver to 2a (in the past, not tried it recently, past performance is not an indicator of future etc.etc)
<lvh> so, --1.9-rich-root
<lvh> ?
<jelmer> awilkins: there have been a lot of improvements to 2a recently, I would suggest trying again
<lvh> so the right thing to do would be to use 1.9 now and ask the maintainer nicely to convert to 2a?
<awilkins> lvh: You can use 1.14, the repo format is the same
<awilkins> lvh: Tis just the local working copy stuff that differs
 * awilkins hopes he isn't talking too much out of his secondary orifice
<lvh> we'll find out quickly :p
<lvh> appears to work :-D thanks awilkins
<hno> awilkins: Have you tried doing a CONNECT server:22 HTTP/1.1 request via the corporate HTTP proxy?
<awilkins> hno: My problems are mostly to do with authentication
<awilkins> hno: And it being ISA server (*spit*)
<CaMason> Hi guys. Is it possible for me to grab a copy of a single file at a particular revision?
<CaMason> I want to save it elsewhere so I can send it to someone
<awilkins> CaMason: bzr cat <file> -r <rev>   > that.file
<CaMason> great thanks
<fullermd> vila: Blargle.  Who dares disturb the great and powerful Oz?
<vila> fullermd: sorry forget you were on holiday :)
<vila> So, I sent a couple of patches to have a full test suite passing cleanly on FreeBSD and would appreciate your feedback there
<vila> https://code.edge.launchpad.net/~vila/bzr/controversial/+merge/11295 and https://code.edge.launchpad.net/~vila/bzr/freebsd-regressions/+merge/11291
<fullermd> Oh?  Nifty.  You tracked down what was causing those bizarre "Revision not present" things?
<vila> That doesn't ring a bell >-/
<fullermd> Ruh roh.
<fullermd> I got 80 some of 'em, plus a few of the later failures that sounded like they may be expressions of the same thing.
<vila> That's with bzr.dev... dunno if that changes something
<vila> fullermd: --parallel=fork works nicely with the right python packages installed
<vila> ok, reading your june mail again, I realize I started with far less failures/errors than you reported...
<fullermd> What python are you running?
<vila> may be you can try again with my two patches above ?
<vila> err, the default one :-)
<vila> 2,5,4
<vila> 2.5.4 sry
<fullermd> Hm.  'k.  I'm running 2.6.x on my workstation, where those came from.
<fullermd> But at least once upon a time, I could dupe them on a box with 2.5.  Picking one at random didn't right now, though...
<fullermd> Heh.  Of course, I don't fail some of the ones you do, since I AM in wheel   ;p
<vila> hmm, I'd be suprised by that kind of failures due to python, but highly interested anyway
<vila> damn I'm sure I had some other questions but they escape me right now :-/
<vila> HA !
<vila> bzr reguires GNU make, right ?
<Kinnison> Is it not python setuptools?
<vila> to build the extensions
<vila> oh....
<Kinnison> $(PYTHON) setup.py build_ext -i $(PYTHON_BUILDFLAGS)
<Kinnison> is what the makefile runs when you build extensions
<Kinnison> so roughly python setup.py build_ext -i
<Kinnison> and that's it
<vila> Kinnison: excellent idea... are you using FreeBSD ?
<fullermd> The Makefile for bzr is a GNU Makefile, yeah.
<vila> fullermd: but only for one ifdef /else/endif
<fullermd> But usually, by the time you install 2 or 3 ports, you hit one that needs gmake anyway, so it's pretty much always around.
<Kinnison> vila: God no. I have taste.
<Kinnison> :-)
 * fullermd . o O ( Plan 9? )
<vila> fullermd: if you know how to get rid of that I see no reason to *not* be compatible
 * Kinnison has wrestled with FreeBSD too often to use it by choice.
<vila> oh no please, I'm trying to collaborate here :)
<fullermd> Not easily.  BSD make has very different syntax for it.  You'd pretty much have to find a way to rewrite around the conditions.
<Kinnison> Couldn't we just call the makefile Makefile.gnu
<Kinnison> ?
<Kinnison> then it'd be clear
<vila> FWIW, I setup a VM with FreeBSD and the experience wasn't that bad compared to say... installing Solaris 10 ?
<fullermd> Or alternately, build one Makefile format from the other.
<Kinnison> vila: Oh, the initial setup wasn't painful. It was then trying to do useful stuff with it which hurt
<fullermd> (I've done that; I have projects with a prototype Makefile, and awk scripts to generate bmake and gmake files from it)
<fullermd> Kinnison: GNUmakefile is [one of] the names that gmake checks and others don't.
<vila> fullermd: ok, thanks, that was the answer I wanted, I'm sure we can get rid of that though
<fullermd> But I doubt it's worth putting any effort into.
<fullermd> Only really matters to people working with the source tree, and you can pretty well assume anybody doing that has GNU make.
<vila> next one: I use export VAR=value in my buildbot makefiles, that too, is GNUMake specific and allows one to, duh, export variables to the spawned shells
<vila> I use that to force and control the environment my slaves run under, how do you do that ?
<fullermd> Not sure...  export is sh syntax, not make AFAIK.
<fullermd> There's a bright line between make vars and env vars, except when there's not.  It's one of the real mind-twisting grump-inducers of working with make.
<vila> I thought so too, until I needed a way to impose PATH in the Makefile instead of the crontab (which sucks)
<vila> yeah, I never needed that before and was happy with make inheriting shell vars
<vila> but PATH...
<fullermd> There's a way to override the shell, so you could presumably wrap an env(1) around it.  But that sounds hacky, and probably acts very differently between make's.
<vila> ok, I'll stick with gmake then... the hack is then limited to: ln -s `which gmake` $HOME/bin/make ; export PATH=$HOME/bin:$PATH :-}
<vila> How about being an heretic ? :-D
<vila> fullermd: don't hit me ! It's only for the slave ! Not even for my .bashrc I promise ! :)
<fullermd> Why not just call 'gmake' instead of 'make'?  That link should be present on every platform.
<fullermd> (except those without GNU make, but that's a problem anyway)
<vila> yes and no, *I* searched for gmake by instinct, but it doesn't make sense on a GNU/xxx system ...
<vila> fullermd: that is, in an ideal world I agree with you, I should use gmake, practically, the hack above is easier since only one slave needs it...
<fullermd> How so?  You want GNU make, gmake is how you call GNU make.  I'm pretty sure any system with GNU make has it accessible there...
<vila> accesible as make, yes
<fullermd> As gmake
<vila> but neither linux nor OSX as gmake ...
<fullermd> Sure it is.  I see it on Redhat and (a very old) Slackware, for instance.
<vila> and I'm pretty sure stock Solaris hasn't it either (though when you install it it's as gmake)
<vila> sry, I meant Ubuntu
<fullermd> Oh.  Well, who cares about weird niche systems like that?   ;p
<vila> OSX you mean ? :D
<fullermd> Sure, that too   O:-)
<vila> anyway, thanks fullermd for the quick and clear answers (again),
<fullermd> Have you run the 2a conversion of your bzr branches?
<vila> one last thing: the botnet now includes a FreeBSD slave
<vila> fullermd: they are in 2a yes
<fullermd> Ah, 'k.  I haven't yet, so it'll probably be a little while before I can try out those merges.
<vila> as is their base branch
<vila> shallow feedback by looking at the diffs welcome too :)
<vila> fullermd: one last thing !
<vila> sys.platform.startswith('freebsd') is the correct way to test for freebsd right ?
<fullermd> Ah, that's a python question; beyond my ken.
<vila> but isn't that a bit... unfriendly for the others BSDs ?
<fullermd> But AFAIK they're all "freebsdX", and nothing else would be, so it's probably a good enough trigger.
<fullermd> Well, for things that would need to hit on them too, it would mean chaining more if conditions, yeah.
<vila> ok, may be you know who to ask that question though ?
<fullermd> I dunno if there's some way to ask for "BSD family", if that's really meaningful (or what it means; is OS X BSD family?  Well...)
<maxb> Hmm. I did "bzr pack" and my repository got larger. There is a lot of stuff in obsolete_packs. How does that get cleaned?
<fullermd> It sounds more a python question than an OS one; I'm not sure how sys gets its information.
<vila> maxb: at your next commit/pull/ any write operation to the repository
<fullermd> maxb: They're deleted next time an [auto]pack runs.  Or you can delete them manually if you trust that your FS has the new stuff committed to platter.
<vila> maxb: fullermd says it better than me :)
<vila> fullermd: ok, let's start with freebsd and we'll see how it goes, so far it's only in a couple of tests and in osutils to get the number of CPUs, so really no big deal
<fullermd> Yah.  We may not QUITE be at the final release of bzr ever yet, so there's time to adjust later  :)
<vila> 1.18 is out though :)
 * vila EODing
<fullermd> Yeah, that's why I updated the port like 2 weeks ago...
<lifeless> moin
<Kmos> there is a way to get replaces files by M after an bzr revert ?
<Kmos> *replaced
<lifeless> what do you mean?
<Kmos> I've modified some files in directory A
<Kmos> I've removed directory B
<Kmos> and done an revert
<Kmos> to get files from B back
<Kmos> and it also replaced the A ones
<lifeless> oh ok
<lifeless> I'll just look up the backup rules
<lifeless> but in future do 'bzr revert B' and it won't touch A
<Kmos> thanks for the tip
<Kmos> i know it does backups.. but bzr help revert only shows how to not backup
<lifeless> I think they get called .~1~
<lifeless> have a look for A/*~*
<Kmos> yep, that's it
<Kmos> thank you very much =)
<lifeless> my pleasure, great way to start a morning :)
<Kmos> :)
<Kmos> here is more end of the day =P
<igc> igc
<igc> morning
<lifeless> hi igc
<lifeless> can't sleep?
<igc> lifeless: early night last night for a change
<lifeless> igc: \o/
<lifeless> how is the health
<igc> lifeless: getting better each week
<fullermd> You know how the saying goes...  early to bed and early to rise, and you'll be groggy when everybody else is wide awake   :p
<igc> fulermd: precisely!
<igc> fullermd ^
<igc> clearly it's early for me
<fullermd> 's what you get for going to bed before the sun comes up.
<lifeless> fullermd: have to; sunlight is fatal :P
<fullermd> That's a myth.  It's perfectly safe in small doses.
<fullermd> Say, 10 minutes a year.
<fullermd> (not all at once of course...)
<AnAnt> Hello, is there a way to cherrypick a revision from one branch into another branch ?
<lifeless> AnAnt: bzr merge -c revno
<AnAnt> lifeless: I see, thanks
 * igc food
<lifeless> igc: hi
<lifeless> when you get back; fast-import, and your two patches, I'd like to help as I can on them
<igc> thanks lifeless - that would be great
<igc> lifeless: I'll be a little longer though ...
<igc> getting kids ready for school
<patx> can bzr or git or even svn have static-http options like hg does "hg clone static-http://example"
<lifeless> patx: bzr branch http://foo/ will work without a server - using the plain files on disk.
<patx> ok ty
<lifeless> patx: it attempts to find a smart server but falls back gracefully.
<Goundy> Guys I'm just wondering, someone knows some irc bot or a website offering a irc bot that report bazaar commits into a channel ?
<lifeless> yup
<lifeless> you can use cia
<Goundy> lifeless ow ? CIA works only for svn no ?
<lifeless> and
<lifeless> http://radix.twistedmatrix.com/2007/02/bzr-and-commit-messages-and-irc-bots.html
<lifeless> bzr-cia is a plugin for bzr
<lifeless> that tells cia about commits
<Goundy> lifeless ow interesting, thank you
#bzr 2009-09-08
<igc> lifeless: is finish_commit -> post_commit a tweak or a resubmit?
<igc> lifeless: btw, I choose finish_commit to mirror the other mutabletree hook - start_commit
<lifeless> igc: I can appreciate that; there is some room for cleanup here. I specifically want to reserve finish_commit for a hook that actually is part of the guts of commit
<lifeless> as this hook isn't; it happens afterwards, I think post_commit is the right name
<igc> lifeless: sure
<lifeless> its a tweak, the rest of it looked fine with s/finish/post/
<lifeless> uhm
<igc> this close to 2.0, I'm happy to resubmit
<lifeless> you mimght like to consider getting the delta of the commit into the parameters object or something
<igc> it will only take a minute to check my tweak
<lifeless> but we can do that later
<lifeless> igc: sure
<lifeless> I'll look at it asap
<lifeless> bbs, shower time
<lifeless> also, I'm ~ done for the day - as per my mail a couple of days back, I have a half day leave today and all wed + thur
<fullermd> igc: BTW, something occured to me in skimming past that hook merge...
<fullermd> igc: What happens to my expanded keywords when I uncommit?
<zsquareplusc> is there a visual (GUI) tool to inspect a repo? to quickly look at the different branches?
<igc> fullermd: questions, questions ... I have no idea just yet
<igc> zsquareplusc: qlog
<fullermd> Well, I suspect the answer is 'nothing'.  And it's probably not as big a deal, since uncommit most often will preceed either 'revert' or 'commit', both of which would update them to the appropriate reality.
<igc> fullermd: I suspect that's the case
<igc> fullermd: maybe a post_uncommit hook is needed too
<fullermd> I get uncomfortable combinatoric hot flashes just thinking down that path, though   :|
<fullermd> Anyway.  Just a thought to squirrel away.
<fullermd> Keywords not updating on commit is a flat day-to-day deal-breaker.  Keywords pointing off into hyperspace after uncommit is a weird corner case behavior that will hardly ever matter.
<zsquareplusc> igc: thanks, that displays something :-) i'm not yet sure if the display is complicated or the cvsps conversion was strange (branch names look OK though)
<wgrant> Should bzr not warn during a commit if the whoami doesn't look sane (eg. the default)?
<lifeless> wgrant: the default is sane some of the time
<lifeless> wgrant: it looks up user@mailname for instances
<wgrant> lifeless: HAhahaha.
<lifeless> but perhaps we should revisit this
<wgrant> lifeless: And which normal desktops have the email address set proprely?
<lifeless> A different population of users, I suspect
<wgrant> lifeless: Most people don't realise they need to do it, and those commits sit around forever.
<zsquareplusc> i used cvsps-import. is it save to just delete the unneeded branches it created or is that destroying the repositories integrity (or isn't it a repository at all?)
<lifeless> zsquareplusc: delete what you don't want
<zsquareplusc> ok. that looks good. glog shows the two branches and it makes sense what it shows :-)
<zsquareplusc> how do i get those on launchpad? push each branch separately? or is there a more efficient way to upload the repository?
<AfC> Well, that's interesting. Gentoo has bzr 1.18 now, and they've (re) hard masked bzr 2.0-rc1. So I'll be downgrading apparently (unless I intervene, of course, but this you-can't-upgrade bug in 2.0-rc1 seems pretty frightening). So should I be reverting to 1.18 now that it's released?
<poolie> hi spiv
<spiv> poolie: welcome to the other side (of the netsplit)
<poolie> mm
<poolie> presumably the other side will eventually evolve into marsupial megafauna or something :)
<spiv> AfC: if you aren't using 2a repositories, there's no real difference.  If you're using 2a, but not doing upgrades, then either should be ok I think, but 2.0-rc1 is probably a little better.
<spiv> poolie: how far away is rc2?
<poolie> good question, probably if your change is merged we should do it soon
<AfC> spiv: well we were about to upgrade to 2a everywhere last week but then fortunately we saw Robert's warning and held off
<spiv> AfC: phew!
<AfC> spiv: apparently!
<spiv> Hmm.  Actually, you should avoid 2.0-rc1 if there's any likelihood of doing cross-format fetches between local branches.
<spiv> Which would trip over the same bug as we saw in upgrade.
<AfC> ok, well, in that case I'll let the version downgrade propagate.
<AfC> thanks
<spiv> Yeah.  Better safe than sorry.
<spiv> 2.0-rc2 should be strictly better than both 1.18 and 2.0-rc1, I hope :)
<poolie> igc, i want to say that bug 385879 is not a blocker for 2.0
<ubottu> Launchpad bug 385879 in bzr/2.0 "EOL filter only applied to files when first checked out" [High,In progress] https://launchpad.net/bugs/385879
<poolie> though still appropriate to fix in that series
<poolie> i suspect this will be just the first cut of several similar bugs and i don't want to block 2.0 on all of them
<igc> poolie: I don't want to block shipping rc2 ...
<igc> poolie: but I do want that patch reviewed and landed if it's all ok
<poolie> yep
<poolie>  i'll read it before doing 2.0rc2
<poolie> but if we can't merge it with tweaks, i think we should do rc2 anyhow
<poolie> then i'll do more on that bug
<igc> please
<poolie> igc, oh btw i didn't read your doc patch itself, just the cover letter
<poolie> i saw you moved the developer guide
<poolie> there was some kind of kludge where the source was stored separately from the destination, requiring it to be copied during the build
<poolie> did you get rid of that ? it would be nice to
<igc> poolie: np. lifeless pointed out some tweaks I want to do anyway so I'm 75% of the way through those, ...
<igc> e.g. removing old cruft from the Makefile
<igc> poolie: the doc build in the new Makefile I'm hacking on is very simple now
<zsquareplusc> is it possible to create a new branch, containing only parts of an existing one? i.e. the entire CVS repository was converted and there are some sub-projects that now all shown in one big bzr branch.
<poolie> igc :)
<poolie> zsquareplusc: i think bzr-rebase can help you do this?
<zsquareplusc> hm. maybe. it would be easiest if it was possible to just branch from a path. (bzr-svn can do that from svn repos, so that the new branch only contains files from the given path)
<AfC> zsquareplusc: well, if you branch, then just quickly `bzr rm` everything you don't want, then you'll have a Branch that has just what you want in it. Or, you can start a fresh branch {shrug} All depends on whether you need to preserve history, I guess
<Raim> zsquareplusc: see bzr split
<poolie> spiv, what's the state of https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-references linked to bug 406687?
<ubottu> Launchpad bug 406687 in bzr/2.0 "insert_stream doesn't check references are satisfied" [Critical,Fix committed] https://launchpad.net/bugs/406687
<poolie> is that an abandoned attempt?
<spiv> Yeah.  (It has some code that tries to reuse code from 'bzr check')
<zsquareplusc> AfC: yep but in this case i'd like to have the history cleaned. Raim 's split seems to provide that. but the help output of the command is a bit terse. i'll try it later again.
<AfC> zsquareplusc: Huh. I didn't know about `bzr split`. I wonder what it does. "This command will produce a target tree in a format that supports rich roots" doesn't seem much help.
<poolie> spiv, ok, reading now, and noting in passing bug 426046
<ubottu> Launchpad bug 426046 in bzr "diff against remote branch does many vfs operations" [Medium,Confirmed] https://launchpad.net/bugs/426046
<fullermd> No, split just automates 'branch ; rm a bunch of stuff ; mv remaining stuff'
 * igc lunch
<fullermd> vila_: 'morning.
 * vila waves ;-)
<fullermd> Forgot to ask if you ran into any other problems getting that VM working right.  I guess no serious ones, since you're apparently using it   :)
<poolie> hi vila, you're up early?
<vila> I'm not really there in fact :-) I woke up an hour ago and was just passing around :) I may go back to sleep for another hour
<fullermd> Also, I had a thought on that group permissions thing.  Would it be Bad to just take out the condition and always chgrp it?  Should be a noop on SysV FSen, and would save chaining if's when the next platform needing it comes around.
<vila> I broke a coast biking last Friday so I wake up easily :-/
<vila> fullermd: I was thinking about checking the group explicitely instead of sys.platform (which is ugly)
<vila> but yes, we shouldn't check platforms there
<poolie> a coast?
<poolie> fullermd: there may be some situations where files get a group you can't always set
<poolie> also, this may cause delays over sftp
<vila> hmm, that thing in the upper chest
<poolie> rib
<poolie> ouch
<vila> poolie: it's only in tests not in code
<vila> rib yes !
<vila> not really broken but I don't know how that is said, and it hurts only when I laugh, cough or try to turn in my bed :-)
<fullermd> It WAS comforting to see that all the test failures fixes involved fixing _tests_, not _code_  ;)
<vila> hehe, that's why we are so happy when we see test failures
<timClicks> hi all, how do I change the branch that bzr push is saved to?
<vila> timClicks: bzr push --remember <new_url>
<timClicks> vila: thanks :)
<poolie> i think the muscle is called the intercostal in english/latin
<fullermd> "Hey!  My intercostal clavicle!"
<fullermd> (what a great film...)
<timClicks> vila: works perfectly, thanks for the prompt reply!
<vila> c\^ote is th French word for both coast and rib
<vila> timClicks: always happt to help (tm) :-)
<vila> timClicks: always happy to help (tm) :-)
<vila> fullermd: that's clavicule for you (not pointing any typo of course, not me )
<jml> not canicule, which is something completely different
<vila> much more enjoyable when you're in that kind of hotness
<jml> (I learnt that word on a day in Paris where it was 35 degrees!)
<poolie> > CÃ´te-RÃ´tie can be rendered in English as "the roasted slope" or "the burning coast" and refers to the long hours of sunlight that these steep slopes receive.
<fullermd> Oh, I'm pretty sure it's always 'clavicle' anatomically, whether human or brontosaur.
<vila> poolie: perfect timing to surd on jml joke, I'm impressed :)
<poolie> mm :)
<vila> s/surd/surf/
<jml> heh
<jml> I was wondering what irrational square roots had to do with dog days on the coast :)
<vila> ohhh, clavicle.... one more French word in English
<poolie> spiv, i'm back to your patch, going to send soon
<vila> go on go on... you won't make me laugh
<poolie> oh how mean :)
<poolie> i have some tweaks but i think we can merge it today
 * fullermd delves into his quote file.
<fullermd> ``We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary.''
<jml> vila, actually, it's not a French word in English.
<jml> vila, it's a Latin word in French and English.
<jml> vila, from 'clavicula', arrived in English in the 17th century.
<fullermd> I'm pretty sure it got to English via [Middle] French, though, not via direct transplant.
<vila> jml: Pff, leave us some please
<vila> :)
 * mwhudson lofts the issue of -ise vs -ize and runs away, terribly fast
 * fullermd thinks that just emphasizes the color of the issue.
 * jml throws a copy of Fowler's at mwhudson
<jml> fullermd, the OED says otherwise
 * vila ouch, laughing hurts
<fullermd> Pfft.  OED can be changed; it's not cast out of aluminum.
<jml> haha
<poolie> spiv https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-chks-part-2/+merge/11290 review done
<spiv> poolie: btw, when are you going to disable the [ascii] tests that PQM runs?
<poolie> spiv, i thought it was done in trunk
<poolie> i wasn't going to do it soon for 2.0
<poolie> just out of general risk aversion
<poolie> vila, what's the overall story on shell
<poolie> shell-like tests now? did they merge?
<vila> poolie: waiting for review :-)
<vila> spiv: I think they have been disabled and pqm *is* faster now
<vila> ha, hmm, yeah, trunk :-)
<poolie> boring old trunk :)
<poolie> igc, re bug 402623, it sounds like jam has a good handle on it
<ubottu> Launchpad bug 402623 in bzr ".cix thrashing causes us to re-download the whole index multiple times" [Critical,Triaged] https://launchpad.net/bugs/402623
<poolie> would it be better to reassign it back to him?
<igc> poolie: how busy is he?
<vila> spiv: nudge https://code.edge.launchpad.net/~vila/bzr/controversial/+merge/11295 should be trivial now
<vila> and hi all, here for good now :)
<igc> poolie: I'm knee deep pulling the windows installer out of the core and enhacing it right now
<poolie> mm, that's what i thought
<igc> poolie: I'm happy to do other stuff but getting this out will allow multiple people to work on it
<poolie> therefore probably not active on that patch at the moment
<poolie> i'm not asking you to switch back to this, just the contrary
<poolie> i was just looking at the non-2.0 critical list
<igc> poolie: not today
<igc> poolie: though my list for today did include looking over jam's reply
<poolie> k
<poolie> he seems to outline a patch for it, it might be simpler to let him just actually write it
<igc> poolie: no complaints from me!
<igc> poolie: my personal focus today is anything core related: doc patch, post-commit hook, content-filtering follow-up if any
<poolie> cool
<igc> poolie: so I'm waiting on a review of cf and doc patch
<poolie> ok
<poolie> i'm doing the doc one now
<poolie> i'll read your cf patches and then maybe look for more cf things myself, you never know
<igc> and working on getting the installer out of the core while I'm waiting
<igc> poolie: so my thinking wrt cf is that that particular patch ought to get it 'working in the common cases'
<igc> which is good enough for 2.0 - other fixes can come later
<igc> bzr-keywords needs to use that new hook that landed this morning but, again, that can come post rc2
<poolie> sounds good to me
<poolie> wow that's a huge patch?
<poolie> s/?//
<poolie> also you get some kind of distinction for writing batch files, if you did :)
<spiv> vila: ta, yes.
<vila> spiv: ok for landing then ?
<poolie> ok commented on the docs patch
<KhaZ> Hello!  I'm trying to figure out how best to integrate my bzr depots into my rsnapshot backups.  My first inclination is to simply bzr init a repo on the backup drive for every repo I want, and then simply 'pull' every hour/night/period.  Is this what's normally done?
<KhaZ> Furthermore: if that is the preferred way; is there a better storage type to use to maximize rsnapshot's hardlinking facilities?  (i.e., something that keeps deltas in separate files, so I don't have X copies of non-changing data around?)
<poolie> KhaZ: a recent pack-based format will come fairly close to that behaviour
<poolie> that sounds reasonable
<spiv> poolie: pushing tweaks now, about to submit to PQM for 2.0
<poolie> though maybe you'd rather backup the whole directory, including working trees, from your workstation/laptop?
<poolie> that's what i do
<poolie> woo spiv
<spiv> vila: so the full test suite should pass now on FreeBSD?
<spiv> vila: that's pretty neat!
<vila> spiv: yes, at least on my FreeBSD vm, I'm waiting confirmation from fullermd but that will be easier with both patches landed
<spiv> vila: was it just test suite bugs, or were there real bugs too?
<vila> only test bugs
<poolie> igc, i guess https://code.edge.launchpad.net/~ian-clatworthy/bzr/pdf-chm-docs-for-2.0/+merge/11182 is needed as well as doc-per-site-language?
<poolie> they look like they overlap a bit?
<igc> poolie: doc-site-per-language is a superset of the other
<poolie> so i might mark it superseded then
<igc> poolie: I left the other one there because it was the barest minimum required
<igc> sure
<fullermd> spiv: I think vila's not seeing the weird errors with revisions disappearing that I do.  It may be py2.6 related, though I'm sure I've reproduced it on 2.5 in the past.
<fullermd> Probably be a while before I can try out the changes; I haven't gone to 2a yet, probably won't have time 'till later this week at least.
<vila> fullermd: oh, do you have the loom plugin installed ?
<fullermd> Nyet.
<vila> any othe plugin ?
<vila> any other plugin ?
<fullermd> Several, but I ran the tests with --no-plugins.
<vila> ok
<fullermd> After I do the 2a switch and catch up, I'll see if I can get a run in on both systems (amd64/8.x/py26 and i386/7.x/py25.  That should nicely isolate the root of the problem  :P)
<vila> 8.x ?
<fullermd> OS version.
<vila> Is that released ?
<fullermd> Who needs releases when you have CVS/SVN?   :p
<vila> :-)
<vila> Ok, wrong question, same player tries again,
<fullermd> It's actually branched though, so next update I'll be on 9.x.
<vila> Should I setup my slave with 8.x instead of 7.2 ?
<fullermd> Well, if 8 were out, maybe.  It's on beta...   beta4, I think?
<fullermd> I doubt it would matter for the purposes of testing bzr.
<vila> But which one is considered stable or is the most used ?
<vila> ha, sry, missed that line
<vila> so 8 is not out, ok, let me know when it is then :)
<fullermd> 7 at this point, probably.  6 is fading out, 5 and earlier are probably dead outside of special cases.
<fullermd> Last schedule update suggests ~end of the month.  It'll probably slip, like schedules always do.
<fullermd> ('course, it'll probably be announced without a Windows installer available  ;>
<vila> pff, those lazy packagers....
<bialix> good day gentlemen
 * fullermd waves at bialix.
 * vila waves
 * bialix waves back
<vila> . o O (waves lead to tsunami...)
<bialix> :-D
<fullermd> That's OK, I'm a hundred miles or so inland.
<vila> same here ;)
<bialix> what's wrong with windows installer again?
<vila> bialix: ??
<bialix> [10:00]	<fullermd>	('course, it'll probably be announced without a Windows installer available ;>
<fullermd> Excess therbligs.
<vila> bialix: Ooooh you mean the FreeBDS installers ? :-D
<vila> BSD even
<bialix> therbligs?
<bialix> oh. I see
<fullermd> Well, I was being a little facetious.
<fullermd> (but 'excess therbligs' DOES seem to be a problem with making it, so...)
<bialix> yes, you do
<igc> hi bialix
<bialix> hi igc
<bialix> igc: ru-chm content is so small for some special reason?
<igc> bialix: I alomst have the win32 installer stuff out of core btw
<bialix> igc: cool
<bialix> igc: why you want 2.6?
<igc> bialix: if I publish the project, are you able to test it at all? I'm still get c compilers installed, etc on vista
<igc> bialix: just felt I ought to ask re 2.5 vs 2.6
<bialix> I still use 2.5 because 2.6 is the whole new thing
<bialix> poolie said there is something faster with 2.6. I dunno what exactly but I think it should be measured on win32 separately
<spiv> poolie: oh, drat, it failed pqm.  There's a test that tries to create a broken repo as part of the fixture that now fails at commit_write_group time...
<bialix> igc: publish the project? I think I can try it
<spiv> poolie: fixing now
<spiv> (by skipping the test in that case)
<spiv> I guess it's extra proof that the code works..
<spiv> Hmm.
<spiv> I wonder if this last failure is actually a real bug or not...
<spiv> It sure looks like a real bug uncovered by this patch...
<igc> bialix: https://code.edge.launchpad.net/~bzr/bzr-windows-installers/trunk
<igc> bialix: some questions ...
<igc> 1. does the Makefile look ok?
<igc> 2. What inside tools/win32 needs to remain in the bzr core project?
<igc> I'm guessing most of it is redundant with this stuff pulled out?
<tonyyarusso> Say, I'm getting the following message and I'm not sure what it means:  'No handlers could be found for logger "bzr"'
<spiv> tonyyarusso: where are you seeing that?
<spiv> In a program that imports bzrlib, or from the "bzr" command-line tool itself?
<tonyyarusso> spiv: 'bzr' itself
<spiv> That's pretty weird.
<spiv> Are you using any plugins?
<tonyyarusso> Not that I'm aware of?  I just started using it.
<spiv> What command are you running?
<spiv> It's a harmless message, but you shouldn't be getting it.
<tonyyarusso> init, add, I think commit did it
<spiv> Also, what version of bzr?
<tonyyarusso> 1.3.1
<spiv> Hmm.  That's pretty old.  Possibly this is something that's fixed in a newer version.
<tonyyarusso> Wait a sec, I think I found something relevant
<tonyyarusso> Yup
<tonyyarusso> For some reason my .bzr.log was owned by root
<tonyyarusso> which apparently confuses it
<spiv> Oh, right.  I do remember something about that bug.
<spiv> I'm not sure if that got fixed since 1.3.1.
<tonyyarusso> meh, either way, as long as I know nothing's going to explode I can go to bed ;)
<bialix> igc: tools/win32/ostools.py used by main Makefile
<bialix> igc: sorry, I'm a bit busy right now, will look shortly
<igc> bialix: np
<spiv> poolie: Hah, yes, this patch did find a real bug.
<spiv> poolie: Although not really an important one.  The "push inventory-deltas to server without RPC that supports inventory-deltas" case had a subtle bug; it wasn't doing target_repo.refresh_data between stopping the RPC insert and falling back to the VFS insert.
<spiv> So the new paranoia erroneously believed a text was missing in some cases (depending on autopacking, I think).
<bialix> igc: about new Makefile: there is no docs bundled into installer?
<igc> bialix: the intention is to bundle the new chm files
<bialix> and?
<igc> bialix: possibly by pulling them from the downloads area on doc.bazaar-vcs.org
<bialix> ok, so bzr.iss should be updated
<igc> and probably the buildout.cfg file as well
 * bialix real prefer scons for complex builds
<spiv> poolie: resending now.
<bialix> igc: I think bzr.iss.cog should be retired and special python script just used to generate the bzr.iss
<bialix> but maybe post 2.0
<bialix> igc: how you expect to marry this separated project with bzr.dev at build time?
<igc> buildout.cfg grabs the bzr code from lp
<igc> bialix: ^^
<bialix> igc: ok re-phrase queston: you're using Makefile in the same position like in bzr.dev Makefile
<bialix> so they will clash
<igc> bialix: ah ok - I guess the Makefile for this project needs to delegate down to build-win32/Makefile or something like that?
<bialix> delegate down?
<Lo-lan-do> G'day all
<Lo-lan-do> I'd like to help getting dulwich/bzr-git working (with bzr-receive-pack and bzr-upload-pack).
<Lo-lan-do> I guess I'll be poking the usual suspects, aka jelmer, james_w and Jc2k (if memory serves) :-)
<bialix> igc: may be you need to start from the desired layout of components at build time?
<bialix> igc: I'd prefer to have bzr.dev and win32 tools in separate directories
<igc> bialix: I need to have dinner now and spend some time with the kids
<igc> bbl
<bialix> kk
<igc> bialix: I've emailed bzr-windows with some brief details on the new project so hopefully a few people can help me pull this together
 * igc dinner
<Lo-lan-do> jelmer: I've gotten to the point where IÂ can "git clone" a bzr branch, with a small patch in bzr-git, see http://pastebin.com/f4e3d0434
<Lo-lan-do> Can't fetch or pull or push yet, but I'm on it :-)
<jelmer__> Lo-lan-do: cool :-)
<Lo-lan-do> My test setup is "described" at http://pastebin.com/f14c3c80d
<Lo-lan-do> Stuff between the ----- lines is done as guest, the rest as myself
<Lo-lan-do> (guest being a trashable account, completely emptied from time to time)
<Lo-lan-do> jelmer: Can I also bother you with dulwich, or is that more james_w's turf?
<jelmer__> Lo-lan-do: no, dulwich is fine too
<Lo-lan-do> Okay :-)
<Lo-lan-do> Oh, by the way, I believe the patch is incomplete, there are probably other places in bzr-git where the branch location is interpreted as a transport.  I just haven't faced them yet.
<Lo-lan-do> As for dulwich, there are several places where progress() is called with informative messages.  These messages are unfortunately sent on the wire, and for some reason they don't conform to the git protocol so the client barfs on receiving them.
<jelmer__> Lo-lan-do: I think the intention was actually to use a transport there
<jelmer__> rather than a path
<Lo-lan-do> Maybe. But my short-sighted patch makes it work :-)
<Lo-lan-do> Example for dulwich: http://pastebin.com/f4adf44d1
<lifeless> jelmer__: ji
<jelmer__> lifeless: ji!
<Lo-lan-do> Ni?
<jelmer__> Lo-lan-do: hmm, is that a recent change? I'm pretty sure that progress reporting worked in the past
<Lo-lan-do> jelmer__: No idea. I've neglected this bzr-git stuff for too long.
<lifeless> jelmer__: so, subunit.
<lifeless> jelmer__: I want to release 0.0.2; your perl diff is incomplete.
<lifeless> jelmer__: ~ a week+ ago you said a few days :P
<lifeless> jelmer__: I'm here to nah
<lifeless> *nag*
<Lo-lan-do> Aehm. It appears my git client doesn't like sideband stuffâ¦
<Lo-lan-do> Or maybe it doesn't like that the server doesn't announce it.
<Lo-lan-do> Or maybe I suck, since the server does announce it.
<jelmer__> lifeless: sorry about that
<jelmer__> lifeless: I took some time to look into it two days ago but I ended up fighting with automake
<lifeless> jelmer__: I can help, but you need to point me in the right direction :)
<jelmer__> lifeless: automake doesn't have a way to install perl stuff by itself, so we have to call out to a perl makefile
<jelmer__> That Makefile can be generated by running perl/Makefile.PL
<jelmer__> but I can't figure out a way to get automake to trigger that rebuild before recursing down into the perl subdir
<lifeless> so, you need configure to run perl/Makefile.PL
<lifeless> or you need make to
<lifeless> uhm
<lifeless> put . into SUBDIRS
<lifeless> in /Makefile.am
<lifeless> SUBDIRS = . perl
<lifeless> perl/Makefile:
<lifeless>         $(PERL) $@
<lifeless> or whatever
<lifeless> in fact
<lifeless> perl/Makefile: perl/Makefile.PL
<lifeless>         $(PERL) $@
<jelmer__> lifeless: that doesn't work, it recurses before making perl/Makefile
<lifeless> no
<lifeless> thats what SUBDIRS = . perl
<lifeless> is for
<lifeless> you'll need one more target to tell it that it needs perl/Makefile to recurse
<jelmer__> lifeless: how do I tell it that?
<lifeless> add
<lifeless> $(RECURSIVE_TARGETS): perl/Makefile.PL
<jelmer__> just that?
<lifeless> yes
<lifeless> no rule
<lifeless> or you will replace the big rule for recursive targets
<jelmer__> complains about a undefined user variable
<lifeless> automake does?
<jelmer__> yes
<lifeless> add distclean-local:
<lifeless>     -rm perl/Makefile
<lifeless> while we are here
<lifeless> can you pastebin your patcfh ?
<lifeless> also, #subunit might be more appropriate at this point :O
<jelmer__> lifeless: I'm there (-:
<lifeless> not on my server ;P
<jelmer__> http://pastebin.com/m2ec94176
<lifeless> jelmer__: as in, I can't see you in #subunit
<jelmer__> hmm, that's odd
<lifeless> it had lost me
<jelmer__> lifeless: merge req submitted
<lifeless> sweet
<vila> AfC: ping
<spiv> lifeless: you'll be happy to know that the full check references patch has already found a (minor) bug
<Kinnison> a "leak" ?
<spiv> lifeless: (the fallback-to-vfs case in the hpss client for streaming inventory-deltas was missing a repo.refresh_data(), so the repo object didn't realise it had all the keys that it should have)
<spiv> Hmm, PQM still rejected it.  Oh, another test that wants to create damaged repositories.  Hmm.
<lifeless> spiv: you may enjoy ec2test and other massively parallel testing tools
<vila> spiv: ... which PQM is not :-P
<igc> night all
<spiv> lifeless, vila: :P
<AfC> vila: pong
<vila> AfC: I was searching how to take the bazaar overlay into account, I just found package.keywords...
<vila> AfC: I still have  a question though
<vila> I only added '=dev-util/bzr-1.18', but is there a way to say: 'accept all from that overlay' ?
<vila> AfC: May be the question should have been, how do *you* proceed and what bzr version are you using ?
<vila> AfC: still there ?
<AfC> vila: ... "bazaar overlay" ... what's that?
<vila> https://edge.launchpad.net/bzr-gentoo-overlay
<vila> it seems that gentoo has bzr-1.15, this overlay has 1.18 (I need >= 1.16)
<AfC> vila: if you mean someone's contrived unofficial Portage tree, then all I have to say is this: overlays are  like PPAs, but worse: broken, unsupported, and usually unmaintained.
<vila> ha :-/
<vila> So what do you use ?
<AfC> vila: (and, still on that topic:) you run into SERIOUS hell if you find yourself needing to use packages from one person's overlay & another person's overlay. They will NOT mix.
<AfC> vila: this is, frankly, just another variation of the plugin anti-pattern
<AfC> vila: but anyway; it's enough to say that I work very hard to encourage Gentoo developers to get on with getting their work into Portage where they're supposed to be working; if it's broken, that's what package.mask is for. And if it's unstable, that's what ~arch is for.
<AfC> vila: that's the way Gentoo was founded, but a lot of them lost the plot along the way.
<AfC> anyway, back to point
<vila> meh, speak slowly :) package.mask ? ~arch ?
<AfC> Gentoo currently seems to have 1.15 as stable (which is largely meaningless, it merely means some combination of "no serious bugs in > 30 days" + "some developer has gotten around to marking it arch from ~arch".
<AfC> Waiting on the latter is usually what the hold up is
<AfC> Gentoo has 1.18 in ~arch
<vila> aaah
<AfC> Gentoo did have 2.0-rc1 in ~arch, but this has been "package.masked"
<vila> And can I activate that for my host without any overlay ?
<AfC> vila: you up & running with a Gentoo system right now?
<AfC> vila: yes
<vila> yes
<AfC> vila: tip: install app-portage/eix
<vila> so first I should remove that overlay right ?
<AfC> vila: and use it's `eix-sync` to do `emerge --sync`. eix is a lovely little package search engine
<AfC> vila: yes
<AfC> vila: it is sometimes worth having your *own* private overlay at (say) /usr/local/portage but there's rarely if every payoff to using some developer's private tree.
<vila> AfC: emergeing eix
<vila> done
<AfC> vila: just this once, do `update-eix`
<vila> eix-sync in progress :-/
<AfC> ah
<AfC> well, it'll do it for you, then
<AfC> so, back to basics:
<vila> it said running eix-update
<AfC> package.mask is a file in /usr/portage/profiles which lists packages that are in the tree, but which will be blocked unless you go to some length to unblock them
<vila> err, I can't read my messages, nor any other for that matter
<vila> wow, back
<vila>  /portage/profies ! That was the needle I couldn't find, ok, so I can see bzr-2.0rc1 in package.mask there
<AfC> That file is maintained as a part of the portage tree; it allows them to introduce (say) the next GNOME stack without suddenly pushing
<AfC> it a bit at a time
<AfC> vila: second concept:
<AfC> arch and ~arch
<AfC> vila: pull up... oh, say /usr/portage/dev-util/bzr/bzr-1.15.1.ebuild in less or view or gedit or whatever.
<AfC> vila: and look half a page down at the KEYWORDS= line
<vila> oook (compared 1.15 and 1.18)
<AfC> [for all you in the audience playing along at home, looking on awestruck and shaking your heads at this craziness, that line in the 1.15.1 ebuild says:
<AfC> KEYWORDS="amd64 ~ia64 ppc sparc x86 ~x86-fbsd"
<AfC> whereas, if we look at the one in the /usr/portage/dev-util/bzr/bzr-1.18.ebuild file, we see
<vila> 1.18 says: KEYWORDS="~amd64 ~ia64 ~ppc ~sparc ~x86 ~x86-fbsd"
<AfC> what vila just said :)]
<AfC> so on both amd64 and x86,
<vila> AfC: just showing I'm following :)
<AfC> we have 1.15.1 "stable" (colloquially known as arch) whereas we have 1.18 "unstable" aka testing (known as ~arch)
<AfC> vila: now
<AfC> vila: last detail
<AfC> vila: you can tweak things individually by creating a file called
<AfC> /etc/portage/package.keywords
<AfC> and appending the line
<AfC> dev-util/bzr
<AfC> to it
<AfC> or, say
<AfC> >=dev-util/bzr-1.18
<AfC> [you used to have to say
<AfC> >=dev-util/bzr-1.18 ~x86
<AfC> or, say
<AfC> dev-util/bzr ~x86
<AfC> which actually makes a bit more sense
<AfC> but one day I noticed by accident that it worked without that. It may be a Portage 2.2 thing
<AfC> er, portage-2.2 :|
<vila> I understand '=dev-util/bzr-1.18' but the others ?
<AfC> right,
<AfC> so
<AfC> you don't need to explicitly list a version if you don't want to
<AfC> ie
<AfC> if you are willing to accept the unstable "~arch" ebuild of bzr
<AfC> (which is *entirely* appropriate for you and I since you and I participate here in upstream)
<AfC> then you can just put
<vila> I can play with 'equery list -i -p bzr' now
<AfC> dev-util/bzr
<AfC> instead of
<AfC> =dev-util/bzr-1.18
<AfC> or
<AfC> >=dev-util/bzr-1.18
<AfC> or
<AfC> =dev-util/bzr-1.18*
<AfC> or whatever
<AfC> vila: even simpler,
<AfC> type
<AfC> [hm]
<AfC> try
<AfC> # eix -e bzr
<vila> oooooh
<vila> what if I want to force a reinstall of 1.18 ?
<vila> (since it came from the overlay ?)
<AfC> I see 1.15.1 in green (stable) then (~)1.18 in yellow then 2.0_rc1 in reverse because that's what's installed
<AfC> vila
<AfC> # emerge bzr
<AfC> :)
<AfC> Ok, learning tip:
<AfC> # emerge bzr -va
<AfC> verbose ask
<vila> haaa
<AfC> which is an interactive form of
<AfC> # emerge bzr -vp
<AfC> verbose pretend
<AfC> you should see a
 * AfC tries
<vila> excellent
<AfC> [ebuild    R]
<AfC> R for rebuild
<AfC> *I* see:
<AfC> [ebuild   UD]
<AfC> because since I installed 2.0_rc1 the Gentoo dev(s) looking after this package.mask'd 2.0_rc1 and added 1.18
<AfC> [ebuild   UD] dev-util/bzr-1.18
<AfC> I should say
<vila> AfC: yeah, don't use 2.0rc1 to upgrade to 2a
<AfC> vila: oh, last point:
<vila> and yes I see [ebuild R]
<AfC> You can put USE flags per package in /etc/portage/package.use
<AfC> ie, there I have:
<AfC> dev-util/bzr curl
<AfC> which is why I see
<AfC> [ebuild     UD] dev-util/bzr-1.18 [2.0_rc1] USE="curl sftp -bash-completion -doc -emacs -test" 5,838 kB
<vila> excellent, added emacs :)
<AfC> [apparently USE=sftp is kindly inherited from somewhere in the /etc/make.profile -> /usr/portage/profiles/default/linux/amd64/2008.0/desktop
<AfC> profile chain
<AfC> vila: Gentoo is undermanned and occasionally immature, but technically it's package management is unbelievably brilliant.
<AfC> its {sigh}
<AfC> vila: (and, compare the output from emerge -va / -vp with that from eix)
<AfC> same same
 * vila looking at bzr-1.18.ebuild and seeing the huge skip_tests :-(
<AfC> yeah, well
<AfC> one thing at a time
<AfC> the most important part is making the Gentoo packager(s) who are doing the work on these ebuilds feel loved.
<vila> AfC: That is my target :-D I asked all these questions to setup one more slave in the botnet :)
<vila> that's wonderful, I have the bug numbers right there, no need to search them again and again :D
<AfC> Anyone know Christian Faulhammer [fauli] or Peter Volkov [pva]? If you see them, give them some props for their hard work.
<AfC> vila: [frankly, filing a bug to get a package "stabilized" seems warped to me, but whatever]
<vila> pva, I know the nick he reported many bugs in the test suite, but I don't remember seiing him here
<AfC> vila: anyway, welcome to continuous moving target land.
<vila> AfC: Thanks for the ride !
<AfC> vila: I recommend you run as much (ie, your entire system) as arch if this is a server.
<AfC> vila: if it's a Desktop, then it's less alluring;
<AfC> vila: I go to considerable trouble to ~arch the entire GNOME set
<vila> It's a vm and will be used only to run the test suite
<AfC> vila: but I'm back running a stable X server which is nice.
<AfC> vila: fine
<AfC> vila: (one of the things missing is the ability to say "unmask or ~keyword Â«GNOMEÂ» whereas I have something like 100 lines in /etc/portage/package.unmask to achieve that. Pain in the ass. But the entire rest of my system is stable. Nice mix)
<AfC> s/unmask/keywords/
<vila> I just read this morning that you can transform package.keywords into a directory and use the package names for the file names into that directory... but I don't know if that apply... (mentioning it just in case it was a recent addition...)
<AfC> That's a neat idea
<AfC> No, the hassle is every 6 months GNOME (or the Gentoo packagers thereof) deciding to create 13 new packages where before there were 8 different ones. PITA.
<vila> ha, ;-/
<AfC> so as you're trying to upgrade, `emerge` stops one by one saying "can't satisfy blah" and you tediously add it to /etc/portage/package.keywords
<vila> AfC: found it back, that's in man portage
<AfC> I could easily avoid this hassle if I just ran my entire system ~arch but I have no desire to do that
<AfC> vila: ah
<vila> But your explanations will help me now in that 752 lines monster :)
<lifeless> gnight
<vila> lifeless: gnight !
<AfC> vila: it's a bit dated, but the PDF at http://www.operationaldynamics.com/reference/articles/GentooUnusual/ is what I wrote some years ago about these topics.
 * vila printing
<jelmer__> heh
<jelmer__> "bzr stats" on a mercurial repo is now slightly faster than "bzr stats" on a bzr repo
<jam1> morning vila
<vila> morning jam !
<AfC> jelmer__: is it faster than mercurial status (sic) on a mercurial repo? :)
<jelmer__> AfC: I'm not aware of a stats command in mercurial
<jelmer__> AfC: fortunately "bzr status" on a native branch is a lot faster than on a mercurial branch
<AfC> oh... er, "stats" not "status". Don't seem to have that command here.
<jelmer__> it's a plugin
<jelmer__> "hg status" is several factors faster than "bzr status" on the same tree, because of the startup speed
<AfC> ah :(
 * vila rejoices ! Full test suite passing on the gentoo slave \o/
<bialix> wow
<jam> bialix: ?
<bialix> hello jam
<jam> morning bialix
<bialix> for you it's morning
<bialix> for me it's 17:40
<bialix> jam: are you asking me?
<jam> bialix: You said "wow", I was trying to figure out what about
<bialix> [16:56]	* vila	rejoices ! Full test suite passing on the gentoo slave \o/
 * bialix wonders what platform will be next? win32?
<vila> we have a winner here :)
<vila> bialix: yes, that's my next target :)
<bialix> oh! no! I can't believe!
<vila> freebsd and gentoo was for warming me up :)
<jam> vila: do you know how close we are? Or is the cygwin stuff getting in the way?
<jam> Last I checked, we closed a few hundred failures with Robert's fixes to the merge and shelve code
<vila> jam: still in the way, my next step (as opposed to target :-) is to finish setting up my local windows XP vm
<Lo-lan-do> Speaking of win32â¦ please tell me that TortoiseBZR works fine?
<LeoNerd> I ran it over a year ago.. seemed just fine then
<vila> and last I ran the test suite on windows it failed with Can't create thread, which I'm now able to reproduce on gentoo, so we're making significant progress on all fronts :-D
<Lo-lan-do> (I'm selling bzr to a client, but many of their employees use TortoiseCVS currently)
<Lo-lan-do> (yes, CVS)
<bialix> Lo-lan-do: honestly I'd recommend bzr-explorer instrad
<bialix> instead
<Lo-lan-do> Aha.
<vila> Lo-lan-do: try getting in touch with naoki which is now actively maintaining it or look at bzr-explorer
<bialix> TortoiseBzr against TortoiseCVS is the little guy who can't piss into toilet
<vila> Lo-lan-do: listen to bialix more than to me, *he* uses windows :-D
<Lo-lan-do> vila: What's naoki's timezone?
<vila> I think he's japanse
<vila> I think he's japanese
<Lo-lan-do> 'kay
<bialix> Naoki from Japan
 * Lo-lan-do looks at bzr-explorer while the Earth spins
<vila> . o 0 (He's still using Mosaic ??? )
 * vila wonders how many got the joke, fullermd maybe ? :-D
 * jelmer__ did :-)
<vila> amazing jelmer how old were you *then* ? :D
<Lo-lan-do> I may be slightly too young, I started with Navigator and Communicator.
<vila> Lo-lan-do: yup, too young, Navigator was what ? 3.0 already ?
<jelmer__> I never used it, my first browser was netscape
<vila> haaaa
<jelmer__> I must've been 7 or 8 when mosaic was released
<Lo-lan-do> Mosaic Netscape 0.9 â October 13, 1994
<Lo-lan-do> Netscape Navigator 3.0 â August 19, 1996
<Lo-lan-do> I started in September 1996, so yeah, 3.0 probably.
<Lo-lan-do> (http://en.wikipedia.org/wiki/Netscape_Navigator)
<vila> wikipedia never stops to amaze me
<vila> http://en.wikipedia.org/wiki/Mosaic_web_browser
<Lo-lan-do> The bzr-explorer site says "bound branches (also called heavyweight checkouts in Bazaar 1.x)"
 * bialix just several days ago installed TCVS to get one project from sf.net. TCVS is amazed thing!
<Lo-lan-do> So checkouts are now lightweight unless otherwise specified?
<vila> http://en.wikipedia.org/wiki/File:Mosaiclogo.png too bad it's not animated :-)
<jam> Lo-lan-do: I think there is some discussion about doing that, I don't think there has been a specific patch that landed
<jam> (note that 'bzr checkout' doesn't have a --heavyweight flag yet, etc)
<Lo-lan-do> Okay.  I'll just be careful when mentioning the feature then.
<vila> jam: so reagrding #424444 did the recipe in #425594 helps understanding the problem ?
<jam> vila: not sure, it seems that they are the same basic cause, I haven't dug any loser
<jam> closer
<jam> I'm just barely getting through the extra email from being away for 1 day ...
<vila> ... I know the feeling :-/ :-)
<DrSlony> Hey, how do I update something I downloaded using bazaar a while ago?
<jam> DrSlony: either 'bzr pull' or 'bzr update' depending on how you got it
<DrSlony> bzr branch lp:phatch
<jam> phinze: ping if you are around
<jam> DrSlony: genreally 'bzr pull' then
<phinze> jam: pong, got your email
<DrSlony> ok, thx :]
<vila> DrSlony: bzr pull -v
<vila> DrSlony: so you'll get some idea about what has changed, or 'bzr missing' first if you're unsure
<vila> about getting these changes
<DrSlony> great, thanks a lot! :)
<Naoki> Good evening, all.
<Naoki> Lo-lan-do: Currently, TBZR can init, add, delete, commit, push, pull, and some commands.
<Lo-lan-do> Naoki: Can it do checkouts, logs and remote branches?
<Lo-lan-do> (Good morning, by the wayÂ :-)
<Naoki> Yes, it can.
<Lo-lan-do> Excellent. diff?
<Naoki> But lightweight checkout is not recommanded.
<Naoki> Because "bzr st" on lightweight checkout impossible.
<Lo-lan-do> No, heavyweights will be very fine.
<Naoki> Yes. qlog, qdiff from context menu.
<Lo-lan-do> Then it seems it will fit the bill perfectly.  The targeted users are unlikely to need more than that.
<Naoki> Most basic operation can done with TBZR, except move/rename.
<Naoki> And currently, tbzr doesn't load plugin. So TBZR doesn't work with bzr-loom. etc.
<Lo-lan-do> Ah, hm.  I guess I'll tell them to run the CLI for renames then.  That shouldn't be a problem.
<Lo-lan-do> I believe the targeted users are not advanced enough to require plugins.
<Lo-lan-do> This is all excellent news.  Thanks!
<Naoki> not at all.
<Naoki> Good night.
<Naoki> s/"bzr st" on lightweight checkout impossible/"bzr st" on lightweight checkout without connection to branch impossible/
<Naoki> lightweight checkout from local works fine.
<Naoki> lightweight checkout from remote branch and offline is problem.
<Lo-lan-do> In this case, the users are a company and the server is assumed to be always reachable (although I'll discourage lightweights anyway to avoid server load).
<davidstrauss_> Is it possible to have bzr stores its repo data in a place other than .bzr at the branch root?
<Lo-lan-do> Yes, you can use shared repositories or lightweight checkouts (or both at the same time)
<Lo-lan-do> But you'll still have a .bzr dir with a few files pointing to the actual location of the data, I believe.
<davidstrauss_> Yes, OK
<Lo-lan-do> I'm not sure you can avoid that, but I'm just a bystander here so don't trust my word on that.
<jelmer__> davidstrauss_: what is it you're trying to do?
<jelmer__> davidstrauss_: if you don't have a pointer to the actual location of the data, how are you going to access the data?
<jelmer__> or perhaps, do you not care about history at this point?
<Lo-lan-do> Magic! (or an environment variable, maybe)
<davidstrauss> Lo-lan-do: I'm trying to version config on a server
<davidstrauss> Lo-lan-do: And I'd rather not keep stuff in /.bzr
<Lo-lan-do> If "stuff" is the real history data, then shared repos and/or lightweight checkouts are for you.  If you don't want a .bzr dir at allâ¦ I'm not sure there's a way currently.
<davidstrauss> Lo-lan-do: I'm thinking a symlink
<Lo-lan-do> Hm.  Interesting.  Never tried it myself, but I guess it's worth a try :-)
<theuiguy> Does anyone know whether python will use function arguments in order if you don't use named arguments?
<theuiguy> For example:  merge_cmd.run(branch=branch_base, revision=revision) . Could I call it as  merge_cmd.run(branch_base, revision)
<theuiguy> I'm hoping so, because it changed name from branch to location
<jam> theuiguy: generally named arguments can be called as positional arguments
<theuiguy> jam: thanks. Is there a better solution to this? I need to support older and new bzr with my plugin.
<jam> theuiguy: don't use cmd_merge.run...
<jam> At least, IMO, if you are using cmd_* then we probably have something wrong in our library, since it is only meant as a way to get from command line args to internal processing
<jam> (I'm not saying you have the option, but it might be pointing at something we should look at)
<theuiguy> jam: It's convenient in this case because I don't need to redo everything that happens when the command is called from the command line
<bpierre> hi
<bpierre> abentley: did you have time to look at my merge proposal for bzrtools?
<abentley> bpierre: Sorry, I went away on vacation and then forgot about it.
<abentley> bpierre: I will look at it this week.
<bpierre> ok, thanks
<lvh> hello
<kfogel> abentley: I haven't done anything "differently" in this branch in a while, but all of a sudden:
<kfogel> $ pwd
<kfogel> /home/kfogel/src/bzr/bzr.dev-trunk
<kfogel> $ bzr pull
<kfogel> Using saved parent location: http://bazaar-vcs.org/bzr/bzr.dev/
<kfogel> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<kfogel> abentley: any idea what that's about?  I'm just pulling, so not sure why any mkdir() on the server side would be needed.
<abentley> kfogel: what does 'bzr info' say about the branch?
<kfogel> abentley: http://paste.ubuntu.com/267498/
<kfogel> abentley: is this b/c of 2a upgrade of bzr trunk?
<abentley> kfogel: Your branch is a checkout.  You should run update, not pull.  You are attempting to pull into http://bazaar-vcs.org/bzr/bzr.dev/
<kfogel> abentley: wow.  I think that must be because I set it up way back when, before I'd developed other habits of setting things up.  Thanks.  I'm just going to restructure so that my bzr trunk works the same way my everything-else trunk works.
<abentley> kfogel: No problem.
<abentley> kfogel: 'bzr unbind' or 'bzr reconfigure --tree' is what you need.
<kfogel> abentley: nothing fancy here, I'm just re-branching.  Nothing Can Go Wrong.
<Lo-lan-do> (Famous last words)
<kfogel> abentley: I'm in a 2a shared repository on my local machine, with two branches in it: "trunk" (branched from lp:launchpadlib) and "apidoc-html-title-attrs" (branched from lp:~kfogel/launchpadlib/apidoc-html-title-attrs, which is *now* known as lp:~kfogel/launchpadlib/OLD-apidoc-html-title-attrs because I just now moved it as one strategy for coping with the fact that I couldn't push my changed local branch to it).  Now I'm getting this err
<kfogel> or:
<kfogel> bzr push --remember lp:~kfogel/launchpadlib/apidoc-html-title-attrs
<kfogel> Using default stacking branch /~lazr-developers/launchpadlib/trunk at lp-45207760:///~kfogel/launchpadlib
<kfogel> bzr: ERROR: Server sent an unexpected error: ('error', "KnitPackRepository('lp-45207760:///~lazr-developers/launchpadlib/trunk/.bzr/repository')\nis not compatible with\nCHKInventoryRepository('lp-45207760:///~kfogel/launchpadlib/apidoc-html-title-attrs/.bzr/repository')\ndifferent rich-root support")
<abentley> kfogel: 2a is not compatible non-rich-root formats, such as the one used by your default stacking branch, ~lazr-developers/launchpadlib/trunk
<kfogel> abentley: thank you.  But when I branched lp:launchpadlib into my local 2a repository, that worked.
<kfogel> ?
<Lo-lan-do> It works one-way
<abentley> kfogel: Right.  non-rich-root is compatible, at a model level, with rich-root.
<abentley> kfogel: We just make up the missing data.
<kfogel> Lo-lan-do, abentley: ah, okay.  So I can branch older into newer, but never newer into older because older has no way to represent some of the data in newer.
<kfogel> right?
<abentley> kfogel: Correct, but there's more.
<kfogel> abentley: ?
<abentley> kfogel: The error is because no repository format is compatible, for stacking purposes with other repository formats.
<abentley> kfogel: stacking is done at the data-representation level.
<kfogel> abentley: *nod*  And "stacking" being different from "sharing", I can share, but not stack.
<abentley> kfogel: Right.
<abentley> kfogel: Once you've branched older into newer, your branch is in the newer format, so there's only one format in the picture.
<kfogel> abentley: thanks, that was helpful.
<kfogel> I'm just going to rebranch everyone with default format.
<abentley> kfogel: np.
<kfogel> abentley: latest bzr (which I am using) does 2a by default; what's the right thing to pass to get "whatever format will work seamlessly with Launchpad, not counting the few Launchpad-hosted branches that are themselves in 2a"?
<Magilum> bzr crashes trying to import my SVN repository in version 1.13.1 (the version in Ubuntu Jaunty), but I can't upgrade bzr to 1.18 and upgrade bzr-svn via the bazaar PPA. Will the PPA's bzr-svn get a dependency bump, or is there something else I should do to see if this error is fixed?
<Lo-lan-do> I'm still amazed someone like kfogel is still involved in version control after all these years.  I've known the name from the CVS book like 12 years ago :-)
<kfogel> Lo-lan-do: well, everything else one does involves version control somehow, so... :-)
<abentley> kfogel: You don't need to pass anything in to get the source branch's format.  That is what "bzr branch" does by default.  The '2a' default applies mainly to init and init-repository.
<kfogel> abentley: I'm creating a shared repository first.
<Lo-lan-do> I hope I'll still be around and doing stuff with forges in 5 years.
<abentley> kfogel: If you create a shared repository, there can be only one format.
<kfogel> abentley: I know.  I'm asking what that format should be, for a currently typical (non-2a) Launchpad-hosted project.
<kfogel> Lo-lan-do: escape while you still can!
<kfogel> :-)
<lamont> are bzr-gtk and bzr-svn from the bzr ppa the right versions for 1.18?  (if someone knows before I go through the work of downloading them just to find out)
<abentley> kfogel: There isn't a single answer to that question.  You should use whatever format the development focus of that project uses.
<Magilum> lamont: bzr-gtk seems to be, but bzr-svn's package is wrong.
<Lo-lan-do> kfogel: Certainly not.  I found a hole where I can do what I like without needing a job to earn my living, I'm not abandoning that in a hurry.
<abentley> kfogel: if the development focus doesn't support stacking, it doesn't matter, though.
<kfogel> abentley: the trouble is that such pages (e.g., https://code.edge.launchpad.net/~lazr-developers/launchpadlib/trunk in this case) talk about formats in plain English, whereas bzr wants flags.  When I look at the output of 'bzr help init-repo', I'm unable to map what I see on the branch web page to the right flag.
<kfogel> abentley: based on the error I got earlier, the development focus clearly supports stacking :-).
<abentley> kfogel: bzr info will report the format.
<kfogel> abentley: so I should check out a branch, run 'bzr info' on it, then create a shared repository so I can fetch the branch again?
<kfogel> abentley: that came out sounding more sarcastic than I meant it, but... I do mean it a little sarcastically :-).
<abentley> kfogel: You can run any operation that doesn't access the working tree on a remote branch.  In this case, I meant you to run "bzr info sftp://bazaar.launchpad.net/~lazr-developers/launchpadlib/trunk".  I'm sorry I was unclear.
<kfogel> Ah, thank you.  No, you were clear -- I just didn't know 'bzr info' worked on remote branches (though why shouldn't it, really?).
<abentley> kfogel: So the weird bit is that the branch is in pack-0.92 format.
<abentley> kfogel: It shouldn't be trying to stack.
<kfogel> abentley: oh, running 'bzr info lp:launchpadlib' isn't enough, I guess I actually have to run the exact command you just gave, no?
<kfogel> abentley: the end goal here is a shared repository with launchpadlib trunk in it, and with my already-existing branch in it.  I'm not sure what the fastest path to that is anymore.  Do you have any ideas?
<abentley> kfogel: due to an ancient bug, bzr+ssh URLs do not provide the right information, and lp: resolves to bzr+ssh.
<kfogel> ah
<kfogel> abentley: ah
<kfogel> abentley: http://paste.ubuntu.com/267520/
<kfogel> abentley: that's what I get when I branch launchpadlib to a standalone branch and run 'bzr info -v'
<kfogel> abentley: none of the English there directly corresponds to a flag to init-repo either (?), as far as I can tell.
<abentley> kfogel: The "format: unnamed" would normally correspond to an init-repo flag.  The problem is that your working tree format is not the usual format produced by --pack-0.92
<kfogel> abentley: sorry, dropped off their b/c laptop somehow hit critical temperature (I have no idea how).
<kfogel> abentley: I probably missed some things you said.
<abentley> kfogel: No, after you said "none of the English there directly corresponds..." I saw you fall offline and waited.
<kfogel> abentley: thx
<kfogel> abentley: should I just give up on the shared repo for now?
<kfogel> abentley: I don't really need it, I just prefer to do things that way.
<abentley> kfogel: I think that if you create a --1.9 shared repository and a --2a shared repository, that will probably work.
<abentley> kfogel: But yeah, the only advantage of keeping distinct projects in the same shared repo is reducing the management cost, and you lose some of that advantage by having two shared repos.
<kfogel> abentley: ?  these aren't distinct projects.  these would all be branches of the same project
<abentley> kfogel: So none of it should be in --2a format.
<kfogel> abentley: sure, we've definitely established that
<abentley> kfogel: Okay, I don't understand why you were suggesting that giving up on shared repositories was a solution.
<kfogel> abentley: well, because we've been working on this a long time and I still don't know what command to use to create a shared repository that would actually work for these branches?
<kfogel> abentley: I've already unblocked and just made standalone branches, so it's not a bottleneck anymore.  I'm now just curious what I would have done, if I were going to go the shared repos route.
<abentley> kfogel: bzr init-repo --pack-0.92 will work.
<kfogel> abentley: thanks.
<abentley> kfogel: Because you were asking about generalities before, I couldn't answer you.
<kfogel> abentley: Er.  I thank you for all the help, but I was pretty specific.  See the log.
<kfogel> "abentley: the end goal here is a shared repository with launchpadlib trunk in it, and with my already-existing branch in it.  I'm not sure what the fastest path to that is anymore.  Do you have any ideas?"
<abentley> kfogel: I meant this one here: "I'm asking what that format should be, for a currently typical (non-2a) Launchpad-hosted project".
<kfogel> abentley: well, sure -- but the whole discussion started with a problem statement and an error message.  Seriously, look back at it :-).
<kfogel> abentley: I guess I'm not sure how I could have been clearer about what I was trying to do.
<abentley> kfogel: The error message does not describe how you are using bzr, or why you have a --2a format.  The bit where you specifically asked "what's the fastest path" came relatively late in the discussion.
<kfogel> abentley: sorry, I would have stressed that earlier if I'd realized my goals weren't immediately clear.
<abentley> kfogel: After I said "So the weird bit is that the branch is in pack-0.92 format", we had all the information we needed to solve your specific problem.
<abentley> kfogel: A lot of people like to keep a single shared repo, and I thought that was what you were doing.
<kfogel> abentley: ah.  I've never done that, though it's intriguing.
<abentley> kfogel: And then when they upgrade their shared repo because one of the branches within it needs to be rich-root, they start running into problems everywhere.
<kfogel> abentley: yeah, I'm not going to try it, b/c of precisely the problems we've seen today
<abentley> kfogel: Now, your already-existing branch: did you do commits into it when it was in 2a format?
<kfogel> abentley: nothing I can't easily replicate
<abentley> kfogel: Cool, 'cause as you'd imagine, you can't put a --2a branch in a 0.92 repository, or merge it into a pack-0.92 branch like trunk.
<kfogel> yup
<poolie> hi jam
<init> rawr
<init> does anyone know where i can find the bzr_access script?
<init> and/or somehow get equavilent functionality?
<jam> hey poolie, care to try again?
<jam> I was just bringing my son back home
<init> i can't seem to find the link on google
<jelmer__> g'day poolie, jam
<jam> init: contrib/bzr_access
<jam> hey jelmer__
<jam> init: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/contrib/bzr_access
<jam> with the direct link being
<jam> http://bazaar.launchpad.net/%7Ebzr-pqm/bzr/bzr.dev/download/head%3A/bzr_access-20071210163004-c9lb1renhra2ncg0-1/bzr_access
<init> aha
<poolie> jam, hi,
<init> thank you
<init> ugh
<init> i'm having an issue with loggerhead now
<init> http://awos-bzr.wilcox-tech.com/repos/AWOS/annotate/head%3A/src/utils/Makefile <- happens with all files
<init> ah ProgressBarStack was deprecated...
<init> not sure what to replace it with
<init> ahh managed to fix it
<init> i think
<mwhudson> jam: you still here?
<init> yep i did
#bzr 2009-09-09
<emmajane> poolie, ping?
<poolie> emmajane: hi
<poolie> nice to see you
<emmajane> poolie, and you as well. :)
<poolie> are you in the UK and up really late?
<emmajane> have you got a few minutse?
<poolie> sure
<emmajane> Indeed. It's gone midnight here.
<poolie> just give me 2m here first though.. biab
<emmajane> np
<igc> morning
<KeBugCheckEx> I need a better progress info for bzr branch
<KeBugCheckEx> Event if I need to develop a plugin or use the bzr API
<KeBugCheckEx> bzr checkout -v is not enough, it's sens stalled for long time
<KeBugCheckEx> Anyone knows if it's possible?
<poolie> spiv, hi, i have a call with francis in a bit
<poolie> KeBugCheckEx: is this as a user of the command line or from your own program (ie at the api level)
<KeBugCheckEx> poolie: I'll do it at the api level
<poolie> KeBugCheckEx: so there are two layers: events fired from the core code to the uifactory
<poolie> you can hook into that if you're eg using bzrlib in a gui or daemon
<poolie> and then if the core code is not sending enough progress events, i guess file a ubg
<poolie> try using the breaking debugger (Ctrl-\ or Ctrl-Break) to see where it's spending time and not repotring it
<poolie> for curiousity, what is the app you're doing this from, and on what platform?
<KeBugCheckEx> poolie: I downloaded Bzr Explorer for Windows, it shows the same progress the bzr command does
<KeBugCheckEx> lots of time in "Fetching revisions:Inserting stream"
<poolie> nice nick btw
<KeBugCheckEx> I'm testing on Windows XP and Ubuntu Server, bzr 1.17
<poolie> this is over the network?
<KeBugCheckEx> testing with bzr branch -v http://bazaar-vcs.org/bzr/bzr.dev bzr.dev
<poolie> KeBugCheckEx: on the command line you should get a network progress indicator?
<KeBugCheckEx> Maybe it's to early to ask questions since I didn't study the api enough, but I didn't find any tool with a decent progress report
<poolie> it may be that bzr explorer doesn't expose that
<KeBugCheckEx> It shows the progress, but looks like it doesn't know how much is left to be downloaded
<poolie> like this: http://www.ubuntu-pics.de/bild/24166/screenshot_20090909_09_37_17_rjPOI4.png
<poolie> blah
<poolie> not that
<poolie> this: [#########|          ]      2KB     0KB/s | Fetching revisions:Inserting stream
<poolie> showing the network rate
<KeBugCheckEx> bzr and bzr-explorer just show the bytes dowloaded but not how much there's left
<KeBugCheckEx> the tool I'll develop will need to show how much MBs is left
<poolie> ok
<poolie> what tool is that?
<KeBugCheckEx> I'll create a tool for non technical people based on bzr
<KeBugCheckEx> open source of course :0(
<KeBugCheckEx> :-)
<KeBugCheckEx> but the repositories will be big
<KeBugCheckEx> maybe gigas
<poolie> ok
<KeBugCheckEx> it's very important to show the user how much time is left
<poolie> our current setup is to have the server stream out data as it works through history
<poolie> so it doesn't necessarily know up front how much data it will send
<poolie> however, we could probably give at least some estimate
<poolie> of how many more revisions need to be copied
<poolie> if you look at eg 'bzr check' it does i think show how many objects will be checked
<poolie> so you get proportional overall progress
<KeBugCheckEx> let me try the checkout...
<poolie> if you hook in at that level, when the core is updated, your ui will be told
<KeBugCheckEx> bzr checkout -v --lightweight looks better
<KeBugCheckEx> Build phase:Adding file contents 533/1105
<KeBugCheckEx> I'm assuming 1105 is the number of files to download
<KeBugCheckEx> can I copy a branch from a machine to another? copy the files?
<KeBugCheckEx> creating a branch in /tmp, zipping and then sending it via http is a viable alternative for me
<poolie> KeBugCheckEx: yes, that will work
<poolie> 1105 is the number of files in the working copy
<poolie> you should get that output from any command that creates a tree
<poolie> spiv, hello?
<KeBugCheckEx> So, if I ensure nobody is changing the branch I can copy the branch files, right?
<poolie> right
<KeBugCheckEx> Event form Linux to Windows?
<poolie> yes
<KeBugCheckEx> *Even*
<KeBugCheckEx> nice!
<poolie> make sure it's a standalone branch, ie includes the repository data too
<KeBugCheckEx> If someout changes the branch after this I only need to merge
<KeBugCheckEx> someone
<KeBugCheckEx> ok, I thing I can start something with this info. Thanks!
<KeBugCheckEx> god, I better go sleep or take some typing lessons...
<spiv> poolie: good morning.
<poolie> hi spiv
<poolie> spiv, did your patch land?
<spiv> poolie: no, a surprising number of tests try to commit invalid revisions.
<spiv> I just fixed a test in per_workingtree, for example, which I wasn't expecting to be affected.
<spiv> Mainly it's been that a lot of tests that create revisions directly, without creating the texts in those revisions.
<spiv> And all 2a revisions have a root.
<spiv> Ok, looks like per_workingtree is now passing.
<spiv> Also, we have lots of tests that do: "start_write_group(); try: ...; except: abort_write_group(); else: commit_write_group()"
<poolie> :/
<spiv> But actually when commit_write_group fails we still need to do abort_write_group(), otherwise the inevitable unlock will raise an error from the cleanups and hide the real failure.
<poolie> what's the problem with that one?
<spiv> So more correct is to put the commit_write_group inside the try, I think.
<spiv> But I wonder if commit_write_group shouldn't actually be "commit_or_else_abort_write_group".
<lifeless> spiv: commit can lead to suspend, no?
<lifeless> spiv: not that I'm here today.
 * lifeless goes :)
<spiv> Because I don't think we ever try to recover if commit_write_group fails, so the current API is a bit suboptimal.
<spiv> lifeless: actually, no
<spiv> lifeless: we detect that case before trying commit
<spiv> But anyway by far the most common case is "I want to either commit, or fail", but the current API makes that tedious.
<lifeless> spiv: I'd favour a helper rather than a larger contract for commit
<spiv> Sure, I agree it's useful to have the smaller operation available.
<spiv> We're just not doing a good job of catering to the common case, atm.
<poolie> yeah, copy & pasting this seems bad
<poolie> on phone
 * igc lunch
<spiv> poolie: my patch landed.
<jam> mwhudson: I'm sort of around, though not for long
<mwhudson> jam: no worries
<mwhudson> jam: i commented on a bzr/launchpad-code bug, it would be nice if you replied at some point
<jam> mwhudson: response sent
<poolie> spiv, woo, way to go
<poolie> spiv, did you get another review? it sounded like there were nontrivial changes there
<mwhudson> jam: thanks
<mwhudson> spiv: the fix for https://bugs.edge.launchpad.net/launchpad-code/+bug/424136 should be on staging by now, want to test it?
<ubottu> Ubuntu bug 424136 in launchpad-code "Cannot upgrade stacked branches from 1.9 to 2a on Launchpad" [High,Fix committed]
<spiv> mwhudson: hmm, it should be straightforward to test I guess.
<spiv> make a 1.9 trunk branch; make a 1.9 branch stacked on trunk; upgrade trunk to 2a; upgrade stacked to 2a.
<poolie> igc, it's sphinx 0.6 you need?
<spiv> mwhudson: hmm
<spiv> mwhudson: when I try to upgrade my test trunk on staging I get bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', 'mismatched lock context and write group. None, <bzrlib.transactions.WriteTransaction object at 0x3111ed0>')
<spiv> mwhudson: oh, actually, nevermind
<mwhudson> !
<spiv> That's probably just because I'm trying to push from a 1.9 local branch to a 2a remote, but the server is too old to support that sanely.
<spiv> Oh, hmm, 1.18rc1
<spiv> Oh, right, but it doesn't support the new insert_stream verb, and yeah.
<spiv> Known issue, I think.
<spiv> mwhudson: (p.s. please upgrade lp to 2.0rc2 ;)
<mwhudson> tests fail currently
 * spiv waits for https://code.staging.launchpad.net/~spiv/+junk/test-stacked to find out if 424136 is fixed.
<spiv> mwhudson: looks good, thanks!
<mwhudson> spiv: yay
<igc> poolie: yes
<poolie> igc, that's only in karmic
<poolie> that kind of worries me
<poolie> dependencies are a pain in the butt
<poolie> despite all the work that's gone into modularity
<igc> poolie: the best result comes from sphinx 0.6
<igc> poolie: I suspect it still works on earlier versions but I'd need to test
<poolie> oh ok
<igc> poolie: it shouldn't be hard for us to support earlier sphinx versions
<igc> poolie: but we won't get the blue theming for example pre 0.6 IIUIC
<poolie> i'm just worried about adding it at all, given the kerfuffle with putting it on orcadas
<igc> poolie: well I felt our *default* docs ought to look the best they can - see http://sphinx.pocoo.org/theming.html
<igc> poolie: less pretty colours in the docs for a given distro concern me much less, of course
<igc> by default, I meant our online ones
<poolie> essentially i'm not feeling this is a good risk/reward tradeoff to land at this time
<igc> :-(
<poolie> what do you think?
<igc> well, I'm not objective it
<poolie> to me the main thing is to field it on the public site, and we can do that without putting it in the 2.0 tarball
<poolie> i don't want to frustrate you, but i also don't want packaging to be held up
<poolie> so
<igc> I've put a lot of energy into getting good pdf and chm docs ready for the win and os x installers
<poolie> hm
<poolie> they are really popular
<poolie> i guess if this doesn't go in, we won't get chm etc?
<igc> right
<poolie> or we won't get it split out by language, so it looks broken?
<poolie> or just not at all?
<igc> and searching in html will suck as well
<igc> without this patch, we have no chm at all and no/very-little pdf at all
<igc> poolie: so the blocker is dependency on sphinx 0.6
<igc> if it built with sphinx 0.4 or 0.5, that would be ok?
<poolie> how about if i try this branch on jaunty
<poolie> that will give us some data
<igc> sounds good
<poolie> so sphinx is reasonably straightforward to install on windows?
<poolie> and os x?
<igc> I'm on jaunty as well but will sphinx installed via easy-install
<igc> poolie: easy to install on Windows - I did that to build the chm's
<igc> poolie: on Windows, install python, install east_install via an installer and then use easy_install to grab sphinx
<poolie> spiv, tell me about https://code.edge.launchpad.net/~spiv/bzr/set-tags-bytes-bug-2.0/+merge/10778
<poolie> it seems like that should land to 2.0?
<poolie> did it bounce?
<spiv> poolie: hmm!
<poolie> also, do you have an opinion about changing to sphinx for documentation generation for 2.0?
<spiv> I'm also wary of making life harder for packagers just before 2.0
<spiv> But I don't really know how much of a problem sphinx would be for packagers.
<vila> hi all
 * bialix waves at vila
<spiv> poolie: I don't know any reason why that set-tags-bytes-bug-2.0 branch hasn't merged yet.
<vila> hmm, regarding docs, it sounds a lot like we want to split the docs *out* of the bzr package like we do for installers,
 * vila waves back 
<spiv> I've just merged in latest lp:bzr/2.0 to make sure the NEWS entry is in the right spot.
<spiv> Oh, perhaps that's why, the 2a transition.
 * spiv pushes to a new lp branch to workaround 424136
<vila> hmm, still regarding docs, without looking at the code, ISTM that there should a basic way to produce the html docs from the source package, then, any installer branch can add its own way of generating specially targeted docs, chm, pdf, shiny web site, etc
<vila> that way we don't add dependencies on the source package.
<vila> poolie: testing on jaunty is hardly relevant, try, say, OSX, Fedora and FreeBSD. *Then* you'll get a batter taste of the dependency issue :-D
<spiv> poolie: lp:~spiv/bzr/set-tags-bytes-bug-2.0-again is up-to-date, and not broken by the 1.9->2a transition.
<spiv> poolie: I'm happy to fire that at PQM unless you'd rather have PQM to yourself for making a release?
<vila> Did I say jaunty is hardy relevant ? I should have, that's the current LTS
<poolie> spiv, yes please, send it
<spiv> poolie: ok
<poolie> vila, you don't need to convince me, i'm the one that has doubts about it
<vila> :)
 * fullermd waits for vila to question how well the docs show up in Mosaic   :p
<poolie> vila, see pm
<rockstar> easy_install fail - error: Can't download http://launchpad.net/bzr/2.0/2.0rc1/+download/bzr-2.0rc1.tar.gz: 404 Not Found
<bialix> rockstar: 2.0rc1 had critical bug inside and was withdrawn
<igc> poolie: call?
<vila> fullermd: the interesting question, IMHO, is: can we still setup, on today's hardware, an OS where we can install Mosaic ? :-D
<Lo-lan-do> *Still* discussing Mosaic?
<vila> Lo-lan-do: welcome to VCS channel where you can have branched discussions that last forever !
<Lo-lan-do> :-)
<poolie> igc, hi
<poolie> sure, call
<spiv> poolie: the _set_tags_bytes fix landed, btw.
<poolie> yay
<spiv> First time, unlike the last patch :)
<vila> bug #424136
<ubottu> Launchpad bug 424136 in launchpad-code "Cannot upgrade stacked branches from 1.9 to 2a on Launchpad" [High,Fix committed] https://launchpad.net/bugs/424136
<vila> hmm, spiv, can you tell me more about that bug ? I successfully upgraded a couple of branches by doing: 'bzr upgrade bzr+ssh://lpnet' ignore the error, 'bzr reconfigure --stacked-on bzr+ssh://lp,net' pesting because I couldn't use lp url in the later, but otherwise, I got usable branches... I didn't check the public ones though
<spiv> vila: it's the public ones that are the problem
<spiv> vila: also, look at the branch pages for the branches you've upgraded
<spiv> vila: oh, and beware the confounding bug that if you don't change the tip revision, lp won't try update the mirror AFAICT, even if the format has changed.
<vila> right, I upgraded branch to push, so there ;)
<spiv> vila: for an example of an affected branch, see https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-chk-root
<spiv> vila: https://code.edge.launchpad.net/~vila/bzr/test-isolation appears to be a victim of the same bug, for instance
<vila> spiv: right, I think that's where the 'bzr reconfigure --stacked-on' workaround help
<vila> spiv: do you mind if I try there or do you want to keep that as evidence ?
<spiv> vila: no, go ahead.
<spiv> vila: I don't care much, as mwhudson has fixed the bug anyway (although it's only rolled out on staging so far)
<vila> spiv: ok, thanks for the feeback !
<AfC> What would I have to do to info.py in bzr-git to make it work with bzr 2.0-rc1?
<bialix> poolie: still here?
<bialix> hmmm, every new repo/branch format changed the way how locking works
<bialix> every time we have to accommodate qbzr internals
<bialix> does 2a format is radically different from 1.9 re locking?
<vila> bialix: I don't think the design changed, but the usage may raise lock errors at different places/times...
 * igc dinner
<vila> ...if not used correctly (bzr itself had bugs there)
<bialix> Bug 426688
<ubottu> Launchpad bug 426688 in qbzr "ObjectNotLocked opening diff from annotate on 2a branch." [Critical,Confirmed] https://launchpad.net/bugs/426688
<bialix> vila: ^
<vila> exactly
<poolie> bialix: it's not very different with regard to locking
<bialix> perhaps there should be some guidelines for bzrlib users
<bialix> I don't understand why it worked fine before and now blow up
<poolie> i wonder if this relates to john's fix to fix shelve or something similar
<vila> bialix: sometimes locks were taken abusively and are not anymore, that leads to bugs like above
<bialix> shelev fix is lifeless work
<poolie> my mistake
<vila> poolie, bialix: It may very well be related to lifeless fix
<bialix> bzr 1.17
<bialix> vila, poolie: ^
<bialix> it's not related
<bialix> to lifelees fix
<vila> ok, still, it certainly mean you need to take a read lock where it was taken by bzrlib before (for wrong reasons AIUI)
<poolie> i wish people would put useful reprs on
<poolie> does locking a wt implicitly lock the branch and repo?
<bialix> my question is more generic
<vila> 'why it worked fine before and now blow up' ?
<poolie> sorry, what's the question?
<vila> That's what bugs are about generally...
<vila> bugs that appear to make things work being the worse kind !
<poolie> vila :-) :-) nice mail
<vila> poolie: thanks :)
<bialix> vila: no, why it blows up every time new format is appears
<vila> bialix: same answer: new format, new bugs, now, giving the backtrace, it starts with a call to id2path() which is an important change in 2a (inventories), bugs there are not that surprising
<bialix> heh
 * bialix not planned to switch to new format because of all this stuff
<vila> it's a bit surprising that it ends up in a groupcompress index though
<poolie> mm
<poolie> i'd say this is a latent bug in either qbzr or elsewhere though
 * bialix thinks 1.18.1 is the right thing to have as latest stable pre-2a default format
<poolie> that it was getting away with it before
<vila> bialix: that's still a bug in qbzr IMHO
<bialix> vila: yes
<bialix> I'm really hope 1.18 can be a long term supported pre-2a release as poolie want for post 2a development
<bialix> there is too much dependencies between various tools
<poolie> bialix: how about if we add an option to 2.0 to set the default format
<poolie> and then support 2.0?
<bialix> maybe other people can jump right into 2a -- I can't
<vila> bialix: even for new projects ?
<bialix> so when jam wrote he don't think 1.18.1 make sense -- it hurts
<poolie> that's probably the last thing i should do today
<bialix> vila: I don't have completelly new projects at work
<vila> I don't follow your reasoning, 2a becomes the new default format, but previous formats are still supported...
<bialix> 2a is default when you start working
<vila> nobody forces you to *upgrade*
<bialix> bzr init-repo will create repo in 2a, right?
<bialix> this will be implicit upgrade
<bialix> and then I can't push to my central repo
<vila> yes, you do that frequently ?
<bialix> because of incompatible rich-roots, pfffs!
<bialix> yes, I'm do new local shared repos frequently
<bialix> for each customer we support, when new features need to be implemented
<vila> you can swallow the incompatible rich-root by upgrading to 1.9-rich-root or 1.14-rich-root
<bialix> 1.9-rich-root is slower than pack-0.92, you know?
<vila> but 1.14 should be faster no >
<vila> but 1.14 should be faster no ?
<bialix> 1.14 is base don 1.9, no?
<bialix> 1.14 is just new wt format?
<vila> AIUI it has the faster indexes
<poolie> so
<poolie> if we made it read /etc/bazaar.conf
<poolie> and there had default_format = 1.9
<poolie> then you'd get the same behaviour but from the different code base
<poolie> or rather the same codebase
<bialix> if you will allow 0.92 as well -- then great
<vila> 0.92 *is* still supported
<bialix> I mean allow in bazaar.conf
<poolie> sure
<vila> it's called --pack-0.92, ha, right,
<poolie> bialix: want to choose a name for this release? :)
<vila> Nein-Nein-Nein :)
<bialix> lol
<bialix> last from Mogikan?
<poolie> that's the name?
<poolie> it's a place?
<bialix> wait a sec
<bialix> The Last of the Mohicans
<bialix> James Fenimore Cooper
<poolie> because it's the last post 2.0?
<bialix> something like that
<poolie> i wonder if Disney will trouble us?
<bialix> it makes sense for those who read/saw the movie
<bialix> I feel the joke
<bialix> never mind me, I'm thinking in Russian
<bialix> it's famous quote in our culture
<poolie> hm
<poolie> i think there is a cultural difference
<poolie> how about if i use the way you originally spelled it?
<bialix> lol
<bialix> poolie: I realy had to shut up
<poolie> anyhow, i want to get it out tonight
<bialix> vila's variant is funny
<poolie> oh, it is too
<bialix> I hope spiv landed that patch for tags
<poolie> to 2.0 yes
<bialix> I've backported it to 1.18.1
<poolie> oh, he was going to land your backport?
<bialix> he seems to land it
<bialix> but to wrong branch
<bialix> https://code.launchpad.net/~bialix/bzr/bzr-1.18-set-tags-bytes-bug/+merge/10811
<vila> poolie: my proposal will not be fun at all if you don't release today :)
<poolie> vila: genau!
<bialix> vila: oh
<bialix> you mean 9-9-9
<vila> bialix: yup, double meaning :-)
<bialix> I've recall Hitler "nine" from recent movie
<vila> bialix: Infurious Bestards  ?
<bialix> yep
<bialix> saw the trailer
<bialix> poolie: is it possible to land https://code.launchpad.net/~bialix/bzr/bzr-1.18-set-tags-bytes-bug to 1.18.1?
<vila> Watch it undubbed (sp?), Brad Pitt accentS are hilarious !
<poolie> yes
<bialix> spiv has not landed it
<poolie> i'll merge it
<bialix> vila: ok, will wait for dvd with English sound and subtitles
<poolie> in fact i am merging it
<luks> vila: especially the italian one :)
<vila> luks: indeed !
<bialix> hi luks
<luks> hey
<luks> bialix: there is more german and french than english
<bialix> well, in Ukraine I believe our brave translators cut out german and french and leave only ukrainian
<luks> heh
<bialix> so original DVD sound is cool for listen
<bialix> yep
<poolie> bialix, was there a bug for that change?
<poolie> i think there was
<bialix> yes, it was
<bialix> Bug 418931?
<ubottu> Launchpad bug 418931 in bzr "AssertionError: _remember_remote_is_before((1, 18)) called, but _remember_remote_is_before((1, 15)) was called previously" [High,Fix committed] https://launchpad.net/bugs/418931
<bialix> yes, that bug
<bialix> poolie: ^
<poolie> lp is a bit down
<vila> poolie: slow, but not down
<poolie> ok, i'm sending 1.18.1 to pqm
<poolie> ok that's it for me
<bialix> vila: do you want long answer in e-mail about setup.py?
<bialix> I think you can look at qbzr's setup.py and its extras/
<bialix> to get some impression
<vila> oooh, so you meant, 'that' already what qbzr does' not 'we don't need that stuff' ?
<bialix> I've lost in ' signs
<vila> sorry, reading /extras/*
<vila> bialix: what qbzr did is exactly what bzr needs to do there, and igc should really look at build_docs for example, it sounds like a far easier way to make sphynx a soft dependency that trying to do that from the Makefile
<vila> bialix: now, I don't really know hoe bzr setup.py and plugins setup.py can collaborate, but I'm sure we'll find :)
<vila> s/hoe/how/
<vila> bialix: Do we agree ?
<vila> bialix: still there ?
<bialix> vila: ping, I'm back
<vila> ha ok, so ^
<bialix> [13:00]	<vila>	bialix: what qbzr did is exactly what bzr needs to do there, and igc should really look at build_docs for example, it sounds like a far easier way to make sphynx a soft dependency that trying to do that from the Makefile
<bialix> yes, I agree here
<bialix> [13:01]	<vila>	bialix: now, I don't really know hoe bzr setup.py and plugins setup.py can collaborate, but I'm sure we'll find :)
<bialix> ^ I think all setup.py should be importable
<bialix> i.e. call to setup() function should be guarded with if __name__ == '__main__' stuff
<vila> ooooh, so we can use 'from  bzrlib.plugin.qbzr import setup as qsetup' for example and collect anything we need ?
<vila> bialix: sounds like a very good plan
<vila> bialix: so may be you should point to qbzr/extras stuff in that mail discussion so that we converge
<bialix> .ÑÑ Ð¸Ð¸Ð´
 * bialix bbl
<bialix> vila: ping
<bialix> [13:19]	<vila>	ooooh, so we can use 'from bzrlib.plugin.qbzr import setup as qsetup' for example and collect anything we need ?
<bialix> ^ yes
<lvh> hello
<lvh> I'm getting AttributeError: 'module' object has no attribute 'ProgressBarStack' when inspecting a file with loggerhead
<lvh> loggerhead 1.10-1 from debian testing, bzr1.17 from the same
<CameronP> Hi Everyone
<lvh> just upgraded to 1.18, problem persists
<alex-weej> sometimes i like to commit just to save a checkpoint even if i don't intend the commit to be permanent (i.e. a mess of files left over from some aborted experiment)
<alex-weej> *e.g.!
<alex-weej> is there a way i can re-organise such commits at a later date?
<alex-weej> and what are the implications on the sequential revision numbers? i think git sidesteps the problem by using hashes
<AfC> alex-weej: the revnos are just aliases (and are unique to any branch)
<AfC> s/unique/local/
<AfC> alex-weej: speaking personally
<AfC> when I have to do what you're describing
<alex-weej> hey AfC :)
<AfC> I make a commit with a log message like "CHECKPOINT" and it's pretty obvious that the next morning I'll be uncommitting that.
<AfC> alex-weej: yo
<alex-weej> lol yeah
<spiv> lvh: hmm, sounds like your loggerhead is trying to use an old bzrlib API.
<AfC> alex-weej: others use `bzr shelve` for this sort of thing
<AfC> alex-weej: I use `bzr commit -m "CHECKPOINT"` ... and then switch away to another branch
<alex-weej> ok i got another question then, when i want to merge changes from a workmate's branch
<AfC> alex-weej: that all said,
<AfC> alex-weej: I should observe that there's a slight cultural difference 'round here
<AfC> alex-weej: in that most people would probably encourage you just to commit with a half decent attempt at some vaguely almost useful sentence as a log message,
<AfC> alex-weej: and then just carry on from there (ie, no uncommit later)
<alex-weej> hm. a lot of the time i just want a kind of undo history when i am doing some dirty development. i should probably hack better, though, really.
<AfC> alex-weej: while there is a rebase capability lying around, most of us tend not to use it. Just merge, and carry on. It's not lkml
<AfC> alex-weej: (ie, I review patches at merge time. I really do encourage people contributing to me to write good log messages so the annotation is good,
<Lo-lan-do> I do rebase, but not to change history.
<AfC> alex-weej: but on the other hand, if people are doing small to micro commits then, well, the usefulness of individual log messages starts to go down)
<Lo-lan-do> I use it to port local branches to an SVN trunk, so IÂ need to linearise.
<AfC> Lo-lan-do: perhaps, but if *anyone* else has access to your previous branch, well, then you're recreating history.
<AfC> if it's just you and not published, then {shrug}
<Lo-lan-do> They don't, that's thte point :-)
<AfC> [I don't push to subversion any more, and I publish everything including work-in-progress, so...
<AfC> I have to assume someone else might have a revision I've made]
<alex-weej> when i want to merge changes from a workmate's branch, i look at it and see that i want to merge e.g. up to revision 17, but in the time it takes me to type bzr merge -r 17 /path/to/branch, revision 17 may have been changed! i tried to use one of the revision IDs with some kind of number and a hash, but "merge" didn't accept it.
<Lo-lan-do> Well, technically the clients for whom I developed the stuff could see it, but in practice they don't even look.
<AfC> alex-weej: um
<jelmer__> moin AfC, Lo-lan-do
<AfC> alex-weej: 17 won't have changed
<AfC> ... oh
<AfC> alex-weej: so -r takes all kinds of things
<AfC> -r 17 is shorthand for -r revno:17
<AfC> from there we can consider
<spiv> alex-weej: "bzr merge -r revid:FOO" is how you use the long identifier for a revision.
<AfC> -r tag:v4.0.7
<lvh> spiv: So, update loggerhead?
<spiv> alex-weej: see also "bzr help revisionspec"
<alex-weej> ahhhh
<spiv> lvh: at a guess, yeah.
<AfC> but what you want is what spiv just saidm
<alex-weej> AfC, spiv, thanks :) will use revid
<alex-weej> i love bzr!!
<Lo-lan-do> I'd love to get away from SVN too, but I still have to contend with git users, so until bzr and git can cooperate fully we keep SVN as a pivot.
<AfC> -r revid:andrew@operationaldynamics.com-20090909023536-f0n026ookg9j64vr
<Lo-lan-do> (Which is why I'm a pain in jelmer's neck from time to time :-)
<spiv> lvh: https://launchpad.net/loggerhead mentions a 1.17 release, so my guess is 1.10 is pretty out of date.
<spiv> alex-weej: also,
<spiv> alex-weej: you could just do "bzr merge /path/to/branch", then review then changes with "bzr diff", and then either revert or commit.
<AfC> alex-weej: while revnos are specific [local] to a given (and each) branch, they are somewhat usable on (say) a published 'mainline' that everyone else is merging in from
<AfC> alex-weej: but yes, be aware that there in (say) my ~/src/java-gnome/ directory, I have many many branches
<alex-weej> spiv: yeah good point, i forgot it wasn't an automatic commit
<AfC> with revno 646 in them.
<spiv> alex-weej: then if the other branch changes since you did the merge, it doesn't matter; those changes won't affect what you commit.
<spiv> alex-weej: even if it was an automatic commit, there's always uncommit ;)
<AfC> (which could refer to different things if these various branches all forked off of mainline at, say, revno 640)
<AfC> alex-weej: what you and I call cherry picking is [still] a bit funny around here. If you find yourself fighting it, give me a shout and I'll do my best to talk you through the possibilities. I've been fighting it for 3+ years now
<alex-weej> i thought it was just merge -r 19..20 or something?
<AfC> alex-weej: yes... but revisions are tree states, not diffs
<alex-weej> hmm
<AfC> but in several permutations you can pull in a patch without pulling in / merging "revisions" which, as far as I'm concerned == loss of history. Which I continue to be very grumpy about
<alex-weej> eugh
<AfC> alex-weej: anyway, if you just merge a branch, or a branch up to a revno
<alex-weej> well, hopefully never have to do it
<AfC> then in come the revisions.
<AfC> as you'd expect.
<AfC> $ bzr status -v
<AfC> after a merge before committing it will show you all the revisions you're merging in. That's useful to keep an eye on.
<Tak> hello jelmer_*
<AfC> alex-weej: (essentially, you will either not notice this at all, or hit it all the time. All depends on your usage habits. As a maintainer & gatekeeper trying to be selective about things, I hit it a lot, but the problem goes away the more I encourage people to submit orthogonal branches)
<alex-weej> everyone else here uses it as if it was cvs
<AfC> alex-weej: at the end of the day, though, just merge branches. It'll do the right thing.
<alex-weej> but say i am working on my mainline, and my boss asks me to put a new feature that's in mainline into the deployed stable branch... i can't just merge all the way up!
<AfC> alex-weej: yeah, that's when you have to start cherry picking
<Lo-lan-do> Maybe bzr replay would work here, although it's still not recorded.
<AfC> alex-weej: probably have a read of http://blogs.operationaldynamics.com/andrew/software/version-control/bzr-orthogonal-patches.html . That might be a bit outdated now, but it's where I was a couple years ago.
<AfC> alex-weej: in the case you're describing, [even if you happen to use a -r range to get the delta you're looking for], you really are creating a new changeset and on committing a new revision [on your stable release branch]
<AfC> anyway, I'm still a bit sceptical. I but heads with the bzr hackers about this all the time
<alex-weej> so when you use -r a..b it's not really merging revisions?
<jelmer__> alex-weej: you're merging revisions but bzr can't track cherrypick merges at the moment
<jelmer__> so it won't remember what happened there and can't use that fact when you're doing merges in the future
<alex-weej> oh right, so it is likely to conflict in the future if i merge the whole branch?
<alex-weej> or is there some other issue i'm overlooking?
<alex-weej> sorry i'm still quite new to dvcs really
<AfC> alex-weej: it [probably] won't conflict if the lines of text are the same (which they will be).
<AfC> alex-weej: [that's sorta the point of the essay I linked to above]
<AfC> alex-weej: fwiw, have a read of the "Getting Started" section of http://java-gnome.sourceforge.net/4.0/HACKING.html ; it's not really that java-gnome specific
<AfC> alex-weej: Bazaar also has a thick extensive user manual, which has the drawback of explaining that there are 6 different ways to use the thing.
<alex-weej> AfC: ok, don't have time to read it now though as i'm on the clock. have bookmarked :)
<alex-weej> thanks for your help, i need to write some code though now!
<AfC> alex-weej: (admittedly that talks about the contributor side of things, not the maintainer viewpoint)
<phinze> is there a plugin that allows you to selectively commit a la shelve?
<phinze> interactive?
<vila> phinze: not that I know of, but you can use shelve and *then* commit :-)
<phinze> vila: yeah i do that a lot, looking to cut out that extra step... looks like lp:bzr-interactive might do it... checking it out
<phinze> yup, adds `bzr commit -i` ... with colored output and everything, nice!
<Lo-lan-do> That should be fasttracked to mainline, I think :-)
<phinze> Lo-lan-do: +1 here, from inital usage
<Lo-lan-do> And I said that without even initial usage :-)
<Lo-lan-do> That and interactive rebase with squashing, and git is dead.
<Lo-lan-do> (maybe)
<Lo-lan-do> Oh, and cherrypicking.  And milliseconds-fast, too.
<jelmer__> Lo-lan-do: cherrypicking is already supported
<Lo-lan-do> Shush, I'm trolling!
 * Lo-lan-do returns to trying to fix bzr-git
<jelmer__> (-:
<Lo-lan-do> How would you debug that, by the way?  My usual technique of printf-debugging ends up on the wire so it can't be done.
<jelmer__> Lo-lan-do: debug what specifically?
<Lo-lan-do> bzr-upload-pack
<Lo-lan-do> Mostly dulwich's server.py it seems
<Lo-lan-do> I'll try speaking the git protocol into stdin, the good old-fashioned way.
 * Lo-lan-do remembers speaking IRC into a telnet tube years ago
<jelmer__> Lo-lan-do: pdb is your friend :-)
<jelmer__> Lo-lan-do: and wireshark is very useful for protocol debugging
<jelmer__> although there isn't a specific git protocol dissector yet
<Lo-lan-do> Doesn't pdb eat my stdin?
<\u03b5> erm, is there a doc for whatever Branch.tags is?
<\u03b5> ah, right
<jelmer__> \u03b5: try "pydoc bzrlib.branch.Branch.tags" :-)
<\u03b5> bzrlib.tag.BasicTags
<\u03b5> no Python documentation found for 'bzrlib.branch.Branch.tags'
<\u03b5> hehe
<Lo-lan-do> jelmer: I think I found something.  In bzr-git's server.py, line 603 indirectly calls graph_walker, but it's been called already and therefore it won't return anything since the client isn't going to send the list again.
<Lo-lan-do> Shouldn't there be a cache of some sort?
<Lo-lan-do> One can't reset the iterator, either, for the same reason.
 * jelmer__ looks
<jelmer__> Lo-lan-do: I don't have a line 603
<\u03b5> what should I use to find out a branch's public URL? get_public_branch, or get_push_branch, or get_parent_branch or nothing?
<\u03b5> and get_master_branch for bound checkouts
<jelmer__> \u03b5: for the public branch, get_public_branch()
<\u03b5> or am I missing something that does the job already
<\u03b5> it's empty :x
<jelmer__> \u03b5: did you set a public branch URL explicitly?
<\u03b5> nope, and I doubt people will do so
<Lo-lan-do> jelmer: You have a *revno* 603, and I should look in the appropriate place, sorry.  Line 136.
<jelmer__> \u03b5: the public URL of a branch depends on the setup
<\u03b5> yeah, I saw
<jelmer__> \u03b5: so it may be right it's empty
<\u03b5> in one branch I have it as parent branch, in the other as push location
<jam> btw \u03b5, cute name (epsilon, right?)
<\u03b5> heh yes
<jdo> bzr: ERROR: Lock not held: LockableFiles(lock, bzr+ssh://bazaar.launchpad.net/~jdobrien/ubuntuone-servers/coucdb-web-api/.bzr/repository/)
<jdo> how can i fix that? ^^
<Lo-lan-do> jelmer__: Do you think adding a cache and a reset method to dulwich's UploadPackHandler.ProtocolGraphWalker would break things?  If not, I'll try implementing that.
<vila> hey morning jam !
<jam> morning vila
<igc> night all
<Lo-lan-do> jelmer__: I have git fetch and git pull working now!
 * Lo-lan-do dances the happy dance
<jelmer__> Lo-lan-do: w00t!
 * jelmer__ awaits the merge requests (-:
<Lo-lan-do> You bet :-)
<weigon> Lo-lan-do: you work on git-bzr ?
<Lo-lan-do> weigon: I'd love to get rid of SVN as a pivot for FusionForge, and making bzr branches accessible with the git clients would be a good way to do that.  So I'm only interested in that part.
<\u03b5> is there a way to have bzrlib.branch.Branch.revision_history() grab merged revisions too?
<Lo-lan-do> jelmer__: Can I pastebin the bundles?  This account has no email accessâ¦
<luks> \u03b5: you can get the ancestry from the repository, using branch.last_revision as the top revision
<lvh> hi
<lvh> bzr (or lp) appears to be convinced a few commits didnt come from me
<lvh> https://code.launchpad.net/~lvh/twisted/positioning
<luks> but it's been a long time since I worked with that, I guess there are some fancier graph functions now
<lvh> how can I fix that
<luks> lvh: it probably looks at the email address for account matching
<lvh> ah, right
<luks> I wouldn't care about it, personally
<luks> not sure if you can convince LP that lvh@leibniz is you
<lvh> well, im nto worried about those 3 commits
<lvh> but it'd be nice if i could fix my bzr config so it sets my email address properly
<luks> see bzr whoami
<lvh> Laurens Van Houtven <lvh@leibniz>
<lvh> Yup.
<lvh> Next step: fixing it. emacs ~/.bazaar/authentication.conf?
<luks> you can use `bzr whoami '...'` to change that configutation
<luks> I believe it's the first step of the bzr tutorial :)
<lvh> hah
<lvh> right, sorry :-)
<lvh> this is the second box I'm using bzr on -- new install.
<\u03b5> hm, there is Graph.iter_ancestry()
<\u03b5> but, if I got it right, that gives recursive tuples
<\u03b5> would I have to count them manually?
<luks> the one I was thinking about is repository.get_ancestry(rev_id)
<\u03b5> yeah
<luks> which gives you a list of all revisions in the branch
<\u03b5> wouldn't that list all revisions in the repo?
<luks> no, only revisions below rev_id
<luks> so if rev_id == branch.last_revision it will return all revisions in the branch
<\u03b5> thanks
<jam> \u03b5: dict(graph.iter_ancestry()) tends to work pretty well
<jam> but depends what you need
<lvh> What's the reccomended tool to see the tree structure of a bzr branch 20 revisions back?
<lvh> checking out that revision?
<Lo-lan-do> bzr ls
<jam> lvh: you can 'bzr revert -r -20' or do "bzr co -r -20'
<jam> or 'bzr st -r -20'
<jam> if you just want to see the changes
<Lo-lan-do> bzr ls -R -r -20
<lvh> thanks everyone, worked a charm :-)
<luks> I'd recommend 'bzr qbrowse -r -20', but not sure if that's useful to a emacs user :)
<CoffeeIV> I am taking over a project from from another developer; I am looking in his workspace at his .bzr directory, how do I find out the URL of the repository from that directory, so I can do a fresh checkout myself ?
<maxb> Try bzr info
<bac> what is wrong with doing "bzr pull :push" (other than it looks funny)?  i get the following error:  http://pastebin.ubuntu.com/268111/  in the same branch 'bzr pull :public" works
<jam> bac: your :push is configured to an "lp:" url, and ":push" doesn't expand 2x
<jam> not sure if that makes sense, but it does to me...
<jam> if :push was configured to bzr+ssh://bazaar.launchpad.net/... then it would probably work
<bac> jam: ok.  that makes sense.
<bac> jam:  yes, public is a bzr+ssh URL and it works.  just more typing!  :)
<jam> bac: I think it is an open bug
<jam> and something that *I* would like to see fix
<jam> fied
<jam> fixed
<jam> as I have some config that is set up for automatic 'lp:' paths
<bac> well, my odds are improved, then
<jam> but just one of the things on the list... :)
<bac> thanks for the answer...
<blueyed> Is it possible to show last-mod-date of files using "status" and maybe even sort by them? (without much shell-foo)
<blueyed> I think "st --verbose" should show that maybe?!
<Lo-lan-do> jelmer: Am IÂ confused or is the current bzr-git supposed to be able to store several git branches and not only one?
<Lo-lan-do> The "for oldsha, sha, ref in refs: if ref[:11] == 'refs/heads/':" loops seem to be indicating so much
<benchik> hello
<benchik> today for some reason i started to get: bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.       how do i tell bzr to override the shared version with my version?
<glyph> benchik: Did you read 'bzr help diverged-branches'? :)
<benchik> glyph: didn't tell me anything useful in my situation
<glyph> benchik: what is your situation?  (the way you asked the question, 'override the shared version', doesn't really make sense)
<Lo-lan-do> jelmer: So it is. Yay, yay, yay :-)
<Lo-lan-do> I'm still struggling with the confusion over the "transport" stuff, but IÂ feel like I'm close to getting push working, too.
<CoffeeIV> maxb: thanks !
<benchik> glyph: i want to run the shared version over, with my version
<benchik> glyph: the tips the help gave: bzr missing etc. didn't give me useful results
<glyph> benchik: why do you think you want to do that?  I suspect what you actually want to do is to merge your changes into the shared version
<glyph> if you "run the shared version over" then any other people or other repositories which have changes in them that know about the current shared version will immediately make it diverge again
<Lo-lan-do> benchik: Maybe you're looking for bzr push --overwrite (but as glyph says, it's evil)
<glyph> Lo-lan-do: I was trying to avoid saying that until he explained that he actually wanted it ;)
<benchik> glyph: because i think i got all the changes before. and today i updated the app, and it's the most recent update. also i think merging will be harder
<Lo-lan-do> glyph: Evil is not patient.
<glyph> benchik: you're wrong, you didn't get all the changes before.  otherwise it wouldn't have diverged :)
<glyph> benchik: merging is easy.
<glyph> here's how you do it:
<glyph> bzr merge
<glyph> bzr ci -m "merged from shared"
<glyph> bzr push
<glyph> and besides, even if it's harder, it give you more pretty lines in 'bzr visualize' which is totally what you want
<benchik> when i bzr merge i get: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<Lo-lan-do> Totally
<Lo-lan-do> bzr viz is just an intricate way of designing celtic knots
<benchik> glyph: how do i resolve this error?
<Lo-lan-do> I think someone's been evil before you had a chance to be.
<benchik> Lo-lan-do: so what do i do now?
<Lo-lan-do> Try to talk with your coworkers to understand where this situation comes from.
<benchik> Lo-lan-do: no way on my side to merge?
<Lo-lan-do> I have to admit I'm not enough of a guru to answer this one, and I'll leave you in some more capable hands.
<benchik> ok
<Lo-lan-do> Um. jelmer? Is is expected that a ./repository/git.tdb for a 80 MB repository eats more than 200 MB (and still growing)?
<bzr_troubling> Hello... How can I verify which SVN version bzr is using ?
<bzr_troubling> I'm getting the Svndiff too-large window, and I'm trying to verify if bzr is using my 1.6.5 version of the svn client... ( I have 1.4.4 and 1.6.5)
<Lo-lan-do> Are you using a package from a distribution?
<bzr_troubling> No.. I'm in MacOS X, Leopard
<bzr_troubling> The package from SVN I got from Collabnet
<Lo-lan-do> I think bzr-svn doesn't use the command-line svn client.
<Lo-lan-do> It uses subvertpy, which, in turn, uses the SVNÂ libraries.
<bzr_troubling> But the libraries it uses are built-in bzr or it looks for the libraries in my computer ?
<Lo-lan-do> I'm not familiar enough with MacOSX to be answer that question reliably, sorry.
<bzr_troubling> Because the Svndiff too-large window bug was reported as a svn bug.. and I should upgrade my svn version..
<bzr_troubling> Ok, but still know a way to find out which version of the libraries ou binaries of SVN bzr uses ?
<Lo-lan-do> Not really.  On Linux I'd use strace, but that's low-level and I doubt it works on other kernels.
<Lo-lan-do> You could move one version aside temporarily and see if the other still works :-)
<bzr_troubling> hum, too bad. Is there a way to convert my bzr working copy to SVN only working copy ? That way I can check what's happening..
<Lo-lan-do> Not as far as IÂ know. You could do an SVN checkout.
<Lo-lan-do> I may be wrong though, I'm just not aware of another way.
<bzr_troubling> Ok, I'm looking at the documentation.. maybe there's a tool for that.
<bzr_troubling> Thank you very much Lo-lan-do
<Magilum> I get this error trying to install bzr-svn from the ppa in Ubuntu Jaunty:   bzr-svn: Depends: bzr (< 1.18~) but 1.18-1~bazaar1~jaunty1 is to be installed
<poolie> hullo all
#bzr 2009-09-10
 * igc lunch
<spm> not quite sure how to describe this: have a branch that on codehost that is only using 216Kb of disk; yet our copy is 50Mb; bzr pack reduces the pack file to a single 44Mb monster. fwiw this is managed by config-manager if that helps at all.
<SamB_XP_> spm: I've a suggestion: fetch a new copy ;-)
<SamB_XP_> then, do the old switcheroo
<spm> good ol' rm-rf :-)
<BasicOSX> Hello, http://bazaar-vcs.org/Download click bzr-2.0rc1.tar.gz link is broken.  http://launchpad.net/bzr/2.0/2.0rc1/+download/bzr-2.0rc1.tar.gz
<spm> SamB_XP_: gah. is even bigger. 56Mb now.
<SamB_XP_> spm: pulled from the 216K one ?
<spm> aye
<spm> via config-manager
<SamB_XP_> what happens if you just "bzr fetch"?
<SamB_XP_> er. branch.
<SamB_XP_> too many damn vcses, there are
<spm> bzr branch, standalone as in. 650Kb.
<spm> :-)
<SamB_XP_> spm: what does config-manager do to it ?
<SamB_XP_> and ... 650K is still >2x as big :-(
<spm> SamB_XP_: cm, is the magic that pulls all the various sourcecode branches together that are used under, eg, Launchpad
<SamB_XP_> what does it do rather than "bzr branch" ?
<spm> i should add we *don't* get this issue - to our noticing :-) on the launchpad tree itself. So is very odd.
<spm> lifeless'd be the best to ask on that score i spect
<SamB_XP_> spm: what format did you say the branch is in ?
<spm> Branch format 7
<spm> tho.. also get Standalone tree (format: unnamed) from a straight info
<SamB_XP_> er, repository-format-wise, I mean
<spm> repository: Development repository format - rich roots, group compression and chk inventories == that one?
<SamB_XP_> spm: ah, yeah, that's even 2a ...
<spm> 'k
<spm> i woder if it's sharing or something in some weird way
<spm> Branch history: 57 reviosns -is also what I get from a bzr branch of same
<spm> yet: Repository: 10382 revisions
<spm> which seems... excessive for such a small branch
<SamB_XP_> indeed!
<spm> is there some way you can tickle bzr to show what files/whatevers it thinks it's holding a pack? am searching for any even vague clue as to wtf at this stage
<spm> in a pack, as in.
<spm> Ahh. clue: the branch up on LP codehost is stacked on another. I suspect we may be getting a copy of the entire stacked branch...
<SamB_XP_> ah. that's likely ;-)
<spm> next Q becomes "WHY!?!?!?" and then "HOW DO WE MAKE IT STOP!!!" ;-) I think at this point I'll pull all the info together and throw an email at Rob.
<spm> thanks SamB_XP_ for your time, much appreciated
<SamB_XP_> happy to be captain obvious for you ;-)
<spm> heh
<SamB_XP_> (that's another name for "help desk", I think ;-)
<spm> Teddy Bear in the Corner is another
<poolie> igc, sphinx is in review
<poolie> spm, would you mind making a new pqm branch for us this afternoon
<spm> poolie: sure, 1.19?
<poolie> no, 2.0.0
<poolie> igc, are you back?
<poolie> coming off 2.0, for the 2.0final release, so that people can land things targeted at 2.0.1
<poolie> spm, regarding your funny branch:
<BasicOSX> poolie:  seem my comment about broken download link?
<spm> poolie: sure; so is that 2.0.0 you want? or 2.0.1? Just to clarify.
<poolie> there is no ui to find out what's in a pack but it is feasible to do it through the api and we could possibly add a tool
<poolie> also, you could file a bug or support question about that branch
<poolie> BasicOSX: no
<BasicOSX> http://bazaar-vcs.org/Download click bzr-2.0rc1.tar.gz link is broken.  http://launchpad.net/bzr/2.0/2.0rc1/+download/bzr-2.0rc1.tar.gz
<spm> poolie: ok, ta. I suspect the latter is the way to go. fwiw it's not so much "A" branch, as about 2 dozen of 'em.
<poolie> spm, so actually you can do it now if you want
<poolie> that's a branch coming off 2.0 and called 2.0.0
<poolie> or later is fine, just let me know
<poolie> BasicOSX: thanks
<spm> cool, 2.0.0 it is, and doing now is fine - pizza is apparently heating in the oven as we speak! :-)
<igc> poolie: back for 15 minutes or so
<poolie> igc, so the submission bounced but i'll fix it and resubmit
<poolie> then cut a release
<poolie> thanks for your feedback on ej's draft
<igc> poolie: tests failed?
<poolie> mm, see the mp
<poolie> or actually don't, it's shallow
<poolie> you just need a copyright statement
<poolie> though that might be hiding other failures
<poolie> at any rate i'll follow up
<poolie> i might get some lunch first though
<igc> poolie: thanks. I'm able to head off for a medical appointment
<igc> s/able/about/
<spm> poolie: should be all systems go: https://code.edge.launchpad.net/~bzr-pqm/bzr/2.0.0
<poolie> great
<poolie> good luck igc
<igc> poolie: that's a generated file btw
<igc> that's why I didn't add a copyright
<poolie> we can tell it its an exception
<igc> sounds the right choice to me
 * igc off the doctor - bbl
<igc> off to the doctor, that is
<jml> poolie, the new page looks really good.
<jml> poolie, I think the serif font for "Bazaar" clashes with the rest of the page, fwiw.
<poolie> mm
<poolie> you should say so in the thread then
<jml> poolie, ok. will do.
<jml> (I was hoping to short circuit finding the right message in the thread :))
<jam> poolie: did you cut an official 1.18.1? Your patch seemed to go through pqm just fine
<jam> I noticed because I was getting kerguelen 'rebuilt' slightly with the 2a upgrade
<jam> and it seemed to build a 1.18.1 with a mbp revision
<poolie> jam, i didn't make the tarball yet
<poolie> right
<poolie> i don't have any more changes for 1.18.1
<poolie> also, spm just made a 2.0.0 branch for us
<poolie> oh, except someone snuck in to pqm in front of me :)
<jam> poolie: is this 2.0.0 or 2.0.0-rc2 ?
<poolie> it's the branch leading up to 2.0rc2 then 2.0
<poolie> so other 2.0.x suitable stuff can land on bzr/2.0
<lifeless> why not land on 2.0 directly?
<lifeless> actually, I'll ask that tomorrow; today I have a plane to catch.
<poolie> i'm drafting a mail, it will be out in a bit
<fullermd> What will you do with it when you catch it?
<SamB_XP_> for a split second I heard "crash"
<poolie> spiv, thanks for putting progress onto the ~ bug
<spiv> poolie: np
<poolie> and the kind of pre-impl note, really
<spiv> Seeing as it was already marked "In Progress" I needed some other way to make it visible that it really is in motion again :)
<poolie> replied
<poolie> yes
<jam> poolie: I went ahead and created the 1.18.1 release, since I had the installers built
<jam> you can cut the tarball when you lke
<jam> http://launchpad.net/bzr/1.18/1.18.1
<poolie> jam, i just did it
<poolie> thanks
<poolie> i was going to <https://code.edge.launchpad.net/~mbp/bzr/trivial/+merge/11501> stop making source zip files too
<poolie> i think you already agreed with that?
<jam> poolie: oddly enough, POST doesn't fail instantly when the page doesn't exist
<jam> which means I would have had to wait until the whole 15MB was uploaded before it failed...
<poolie> hm :/
<jam> I've run into that before
<poolie> what was sending the post?
<poolie> the cheesy upload script?
<jam> poolie: curl
<jam> *my* cheesy version of it
<poolie> we should probably change it to use the api
<poolie> :)
<jam> which analyzes filenames etc, so it does most of the work
<poolie> should we just announce it now, or wait for other builds?
<jam> so it is just 'upload.py *.exe'
<jam> poolie: I think you need to cut a tarball and announce that on the dev list :)
<poolie> i did, there's a tarball there
<jam> I'd like to follow our planned announcements
<jam> poolie:   bzr-1.18rc1.tar.gz
<jam> I think you packaged something slightly wrong
<jam> poolie: so, I'd like to follow the plan, but I'm noticing that having to come back 1-week later isn't working very well, either
<poolie> hm, good catch
<jam> as for 'no zips....' I'm not 100% sure, let's check the downloads
<jam> for older versions
<jam> poolie: so... foo.zip has very few downloads versus the others
<jam> setup.exe 2.5k, tar.gz 1.4k, .zip 122
<jam> about 1/10th
<jam> fairly consistently
<jam> setup.exe is 2x the tar.gz, and the tar.gz is about 10-20 times more than the .zip
<poolie> and i suspect some of them are misguided
<poolie> and now the 2.0 docs patch landed
<jam> poolie: I'm actually pretty impressed that 1.17 has 11k downloads overall
<jam> I guess it is extra long because 1.18 was a bit delayed
<jam> poolie: approve
<poolie> thanks
<jam> though I should say... you can open a .zip in plain Windows Explorer, you can't open a .tar.gz
<jam> or .tar.bz2
<poolie> true
<jam> but... I don't think people who want *source* will care
<poolie> at least in recent windows
<poolie> they can get the source from the nonadmin installer though?
<jam> >= XP I believe
<poolie> or indeed from bzr
<jam> yeah, the source is in nonadmin, I believe
<jam> anyway, good night
<poolie> good night! and thanks
<vila> eerk, hi jam !
<vila> hi all :)
<poolie> vila, hi
<vila> the never-sleeping team :-)
<fullermd> vila: Ah, just the person I wanted to see...
<fullermd> vila: I've answered your question.
<fullermd> vila: http://www.over-yonder.net/~fullermd/dl/bzrdocs.png
<vila> . o 0 (*Which* question :)
<vila> ROTFL
<fullermd> User-Agent: NCSA_Mosaic/2.7b5 (X11;FreeBSD 8.0-BETA2 amd64)  libwww/2.12 modified
<vila> wow, now I'm impressed, congrats !
<fullermd> I'll bet you serious money I'm the only one on the *PLANET* with that U-A string.
<fullermd> In fact, I may be the only person ever to compile it on amd64   :p
<vila> my god I forgotten about the default grey background, sniff, tear dropping
<fullermd> Took a bit of work.  I guess I should have been doing real work instead, but...
<fullermd> Tons of int/ptr size mismatch warnings, probably due to the I32LP64 config.  Probably not overly safe to use I guess, but it was fun   8-}
<vila> More seriously, that really kick ass ! No proprietary software can pretend such long term support...
<vila> but man, you should have tried a 32bits VM :-)
<fullermd> But it does show PNG's!  So there's a white and blue and green arrow sign in the middle of the gray for the homepage.
 * fullermd grabs
<fullermd> bzr.png in that dir
<vila> PNG ??? How comes... relying on a external library even then ?
<fullermd> Yeah, it's got libpng support.
<fullermd> Really *OLD* libpng support.  That was one of the things that took non-trivial hackery to get running right.
<vila> fullermd: but to completely ansewr the question, you need to capture a video of the revolving earth you know...
<fullermd> It's funny; I was actually wondering just last week "Dangit, how old a browser do you have to use to not understand <script>?  Why can't people stop putting these stupid comment wrappers around them?"
<fullermd> I guess now I know the answer...
<vila> aha, you had to hack it... ok
<fullermd> Well...  it doesn't revolve very long.  Maybe my connection's too fast for it.
<vila> By the way, didn't you mention the 'if it doesn't work, try again' syndrome recently ?
<vila> One place where it applies *today* is web browsing !
<fullermd> Maybe dunno.  I know I've used "If at first you don't succeed, redefine the parameters of success."
<vila> And *that* one is here to stay I fear :-/
<vila> I was referring to principle more than the wording itself.
<fullermd> igc: ^^^  New docs look wonky in Mosaic   :p
<fullermd> Anyway, I guess that fills my "do insane stuff for no good reason" quota for the week.  Back to work!
<vila> fullermd: congrats and keep nagging web site devs for compatibility :-D
<fullermd> I pulled up Google too.  The javascript took up more space than the rest of the page
 * vila wonders about starting a 'support mosaic' campaign....
<fullermd> Well, _my_ page works fine in it   :p
<vila> Aren't societies defined by how they care of their elders ?
<fullermd> (some people might even say it looks better...  not my fault they don't appreciate the genius of my palette.)
<vila> Web devs should think a bit more about Mosaic, really....
<vila> fullermd: by the way, did you get my mail about that page of yours or did it get lost ?
<fullermd> I did.  Sorta skimmed it; have it flagged to look at in detail when have($tuit)
<fullermd> But yes, the installer is pretty...   special...
<vila> fullermd: ok, np, wasn't sure I sent it
<fullermd> It's a prototype.  We're planning to replace it after 2.1.6 release ships.  Maybe after 2.2 if we slip...
<igc> fullermd: damn, that's disappointing
<vila> I guess that may be reflecting the fact that you're not actively recruiting new users ?
<fullermd> igc: Inoright!  Obvious failure in testing...
<fullermd> I think it more reflects the fact that nobody's driven a new installer through.
 * fullermd isn't joking about the releases where it was considered obsolete   :(
<fullermd> If you're doing something simple, and you've used it before, though, it's *REALLY* fast and easy.
<vila> fullermd: my point exactly.
<fullermd> Yah.  Nobody likes it, though.  Especially code-wise; it's impossible to work with.
<fullermd> It's really horrible.
<fullermd> There was a drive to integrate the bsdinstaller instead, that gets occasional perks of action.  Been meaning to look at it myself in my CFT.
<fullermd> It'd be nice to throw sysinstall into a deep hole   :|
<vila> well, as the first point of contact... it's certainly not the best way to be introduced to FreeBSD...
<fullermd> Yeah.  It's definitely something that has to be read about before being used.
<fullermd> Actually, it's probably less that the devs are used to it, than that they just don't use it.  I know setting up this box, I used an extra drive as a running system, and installed it manually via that.
<fullermd> (had to anyway, since sysinstall can't hack ZFS, but I would have anyway just 'cuz it's simpler)
<fullermd> ...   anyway, that's way OT here.
<igc> poolie: 2.0.0 has the new docs thanks
<poolie> yep
<vila> fullermd: back to my point again :) New users needs it, actual users works around it :)
<igc> poolie: were you planning to submit them to 2.0 or merge across at some point
<igc> ?
<poolie> to merge across
<poolie> probably after making 2.0rc1
<igc> you mean rc2 right :-)
<igc> vila better you too it :-)
<igc> s/better/beat/
<vila> fullermd: OT, yes, on the other hand, your help to setup the FreeBSD test slave was invaluable, so thanks again
<igc> s/too/to/
<vila> igc: ??
<vila> ha 2.0rc1 :)
<fullermd> vila: Always glad to help   :>
<poolie> gosh
<poolie> vila: really?
<vila> Is there a bug filed about two concurrent processes trying to create the same pack file at the same time ?
<poolie> vila, there might be
<poolie> do you want to make rc2?
<vila> poolie: :-D
<poolie> mm
<poolie> vila, you're doing it off 2.0.0 right?
<vila> poolie: what ?
<poolie> > igc: vila beat you too it :-)
<poolie> i thought he meant you were going to make an rc
<vila> poolie: I think igc joke was about the 2.0rc1 I *did* not about the 2.0rc2 you *will* do :)
<igc> poolie: I meant vila called beta1 rc1 accidentally some weeks ago
<poolie> but maybe you just merged back to 2.0?
<poolie> oh right
<poolie> heh
<poolie> :)
<spiv> vila: hmm, I know I fixed a bug where packing resulted in the same pack.
<spiv> vila: but I don't know of a bug report for two concurrent processes.
<vila> spiv: different beast,
<vila> my case is two processes doing 'bzr update' for two branches in the same shared repo
<vila> sometimes, they both upgrade to the same revision from roughly the same revisions and probable requires the same set of revisions which end up creating the same .pack file in upload/
<vila> it's pathological at best so there is no hurry, I was just wondering...
<vila> I should file it anyway
<vila> fullermd: my GF just saw the Mosaic screenshot and had a good laugh when I explainde :D
<fullermd> I always try to entertain on multiple continents at once.
<poolie> vila, so you're definitely ok for UDS? i told clan you were.
<poolie> vila, oh, also, in conflict resolution
<poolie> it seems like it would be nice to avoid needing an explicit 'resolve' command if i clearly edited out the conflict markers
<poolie> what do you think?
<poolie> maybe commit should see if things can be automatically considered resolved, using the same logic 'resolve' with no arguments does
<vila> poolie: definitely ok for UDS.
<vila> I think resolve is required because some cases are too tricky to get right (or were). I'm not sure I know better at that point
<vila> It's true that *I* fail to call resolve in roughly 30% of the cases though...
<poolie> me wonders, should we recombine 2.0rc* in the news into just one heading, as we had for 1.17?
<poolie> i think we should
<poolie> vila, that's great about uds
<fullermd> I'd agree.  It's useful during the RC's, but post-release it's just noise.
<poolie> i'm just wondering if being required to run 'resolve' ever saves trouble
<vila> resolve cleans up the mess (.THIS, .moved, etc) as you go along, I'd be inclined to keep it that way
<vila> I mean, conflict resolution, with tenths or hundreds of conflicts are quite stressful, *I* would not like a tool that suddenly sayd: "It's ok, I will clean up some mess, don't worry, everything will be good !"
<vila> especially if the tool generated the conflicts in the first place because he didn't know how to merge cleanly
<vila> So i'd prefer to put effort to generate less conflicts instead :D
<vila> But back to our original point, the idea of resolve --interactive is that the cleanup is more automatic, yes.
<vila> Anybody to review https://code.edge.launchpad.net/~vila/bzr/shell-like-tests/+merge/11204 ?
<vila> I have more patches coming there, so I could land that first...
<vila> I have more patches coming there, so *if* I could land that first...
<hno> Is it possible to create a lightweight repository where history starts at a given revision? But keeping sufficient information to be able to pull/push/merge of new changes?
<Lo-lan-do> What's a lightweight repository?
<fullermd> He means a shallow branch or history horizon or whatever we decide to call it.
<fullermd> Stacking is a step toward that, and may be enough.
<hno> probably yes..
<hno> from what I have read of stacking it's not exactly what I am looking for. The repository should be self-contained, just not dragging along 10 years of history.
<Lo-lan-do> Oh, yes, sorry, I read your initial question backwards.
<Lo-lan-do> I guess if you don't care about keeping existing checkouts working, you could replay all revisions from the old repo starting at some point onto an empty repo.
<Lo-lan-do> The new revisions would be unrelated to the old ones, so you couldn't move stuff back and forth between the two repos though.
<hno> Lo-lan-do: I do care about push/pull/merge being possible between this repository and the one with full history.
<Lo-lan-do> Forget replay then :-)
<vila> hno: stacking is the closest to your needs today
<hno> vila: Ok.
<vila> hno: but why do you want that ?
<Spabby> He folks, we moved our bzr repos to another server which has port forwarding from the outside world, but now when I try to checkout from that server BZR won't do it because the keys do not match, is there any way I can wipe bzr's key database on my local windows machine please?
<Lo-lan-do> Spabby: SSH keys?
<Spabby> yes
<Spabby> I use bzr+ssh
<Spabby> and told it to remember the key the first time I used this IP
<Lo-lan-do> Probably in the SSH config then.
<Lo-lan-do> Using Putty?
<Spabby> it is correct, the machine at that address does have a different key; it's a different machine
<hno> vila: The repository without old history? because in many situations dragging along the complete history just adds unwanted bloat. The specific use case is feature branches that I want to be just enought to keep the feature but at the same time self-contained not depending on another repository for a checkout,
<Spabby> tortoise bzr
<vila> hno: why don't you use a shared repository ?
<Lo-lan-do> Spabby: I'm not sure tortoise embeds an SSHÂ client.  If it does, though, try looking for a file called known_hosts or so.
<Spabby> im just using bzr+ssh to checkout a new branch, but bzr is aware of another machine on that ip and now is trying to warn me that the key has changed, which I know
<Lo-lan-do> (I don't do Windows so IÂ can't give you the exact name)
<hno> vila: I do, but these are pushed to another server.
<vila> hno: haaaa, so you want to stack on the *server*
<hno> vila: No, I do not want the complete history to be on that server. Not needed there for it's purpose.
<vila> hno not even once ?
<hno> not in that repository no.
<Spabby> Lo-lan-doI can't find any file that is similar to that name, or looks correct
<vila> hno: anyway, you should be able to stack against another server
<Spabby> where would I find it on linux?
<Spabby> please?
<hno> vila: I said I want it to be self-contained not needing access to another repository for checkout.
<Lo-lan-do> Spabby: On Linux it's in ~/.ssh/known_hosts
<Spabby> ah right it's an OS problem rather than bzr
<Lo-lan-do> Spabby: But as IÂ said, it's related to SSH more than Bzr
<Lo-lan-do> Hence my question about which SSHÂ client you're using.
<vila> hno: hmm, you're very close to being self contradictory you know :-) You can't have the ability to merge while not being able to recognize that you are merging something already merged in your old history
<Spabby> the ssh client is tortoise bzr
<Spabby> im not using an ssh client to ssh in, im just using the bzr+ssh protocol
<hno> vila: I don't see a problem with that.
<vila> that's the problem :)
<hno> development generally moves forward you know..
<Lo-lan-do> Spabby: That protocol still uses an SSH client, even if it's not visible :-) The question is: is it provided by tortoisebzr or is it external?
 * Lo-lan-do browses the tbzr website
<fullermd> tbzr probably just uses whatever bzr does.  And I think it traditionally grabs putty at least if it's available.
<fullermd> Believe it was recently changed in trunk to mostly prefer paramiko, but that's irrelevant for released versions.
 * hno read up on http://bazaar-vcs.org/HistoryHorizon and it describes very well what I am looking for.
<Spabby> it's in c:\documents and settings\<user>\Application Data\<bazaar\2.0
<Spabby> if anyone wants to know :D
<Spabby> thanks for the help Lo-lan-do
<vila> hno: I was talking about what is possible *now*, staked-on repos are accessed only when needed, the main difference with  history horizon is that you will be told: 'Sorry can't do that, need to access <URL>' where stacked repos don't ask the question,
<vila> hno: yet, stacked repos are accessed only when *needed*
<hno> vila: you can't to a checkout of a stacked branch without access to the full history, not even an lightweight one. Same for diff/log etc.
<vila> hno: It seems that either I don't understand you or you're trying to do accomplish something that really requires history horizon, or you found a bug or you don't understand how stacked branches work
<vila> you can create a stacked branch locally that will point to the same stacked-on branch than its counter-part on the server
<vila> both will have a reduced history if that's what you're interested in
<hno> vila: stacked branches works just fine for temporary feature branches in an all-online world. But is a bit too lightweight for many other purposes, mainly missing a shadow/ghost copy of the ancestor revision.
<vila> hno: let's not rehash why we need history horizon, you're preaching the choir. I thought you wanted to solve a problem today, with today's features, if that's not the case, sorry for the noise.
<hno> vila: I just objected to you saying the main difference is when the two accesses the stacked-on repository. To me that's the minor difference.
<vila> hno: no worries :)
<hno> I'll use full branches for now. And cheer happily the day history horizons become available.
<hno> Hmm... is it supposed to take ages to for 1.18 branch into a 2a repository (both locally)?  CPU been running at 100% for many minutes now... still making progress howeer, but probably another 5-10 minutes before it finishes.
<fullermd> Is it 2a on both sides, or is it converting from another format?
<hno> source repository is using the 1.9 format.
<fullermd> Yah, so that's having to convert the format, as well as rewrite all the revisions on the fly (since it's going poor->rich root).
<fullermd> Time consuming.
<hno> Ok. So all normal then.
<fullermd> Don't forget that because of the root richness, any revs you make in that 2a repo can't be applied to the 1.9 source, so you might not want to do that if there are other branches of it in 1.9 that you care about your changes being portable to.
<hno> Hmm... so you can't merge from a 2a into 1.9? Not even via bundles?
<fullermd> Into 1.9-rich-root, yes.  Into 1.9, no.
<fullermd> (and similarly, 1.9-rich-root can't be merged into 1.9; that's the watershed)
<hno> Ok. So I guess there will be some (many) years before we can officially switch to 2a then.. need to wait for main enterprise distros to pick up support.
<hno> because I guess that also means you can't pull/push into 1.9 from 2a..
<fullermd> Well, 2a is compatible with any rich root format.
<fullermd> Which goes back to rich-root-pack, which was in 1.0.
<fullermd> (and can with some manual fiddling probably interact with some formats back to 0.15, but you probably don't want to get into that)
<fullermd> Of course, moving between knitpack formats (pack/0.92 through 1.14) and 2a can be pretty slow, but that's not necessarily a deal breaker; small blocks of revs don't take near as long as the whole thing.
<fullermd> You'd just need a flag day for going rich-root.
<hno> ok, that's better. Means we can push relevant branches from the main repository into an older format contributors can access when stuck on older bzr versions...
<fullermd> If everybody's recent enough that 1.9 for the central branch is working, then just taking that to 1.9-rich-root would be simple.
<fullermd> (well, conceptually; once one branch hops over the rich root boundary, they pretty much all have to follow before they can interact again, but that's a Simple Matter of Cat-Herding  ;)
<hno> i think some are stuck on bzr 1.3 unfortunately..
<Lo-lan-do> Even Debian stable has 1.5 :-)
<Lo-lan-do> (And 1.16 in backports)
<fullermd> Well, 1.3 is new enough for rich-root-pack anyway.
<awilkins> Academic question : How would you design a DVCS for a set of data that was itself a directed acyclic graph?
<Lo-lan-do> Consider graph-friendly diff and merge algorithms?
<awilkins> Do those cover data which is both large and does not have intrinsic ordering like source?
<Lo-lan-do> And store diffs as a set of added/removed nodes and arcs?
<luks> versioning linked data is a pain
<Lo-lan-do> Your nodes don't have identifiers that could be used for ordering?
<awilkins> luks: Sure is :-)
<luks> especially if you have lots of them
<awilkins> Lo-lan-do: They do have identifiers, but we're talking 2.9M node minimum
<awilkins> That's for a single version of the core data, and there are presently 12 versions available for historical versioning
<Lo-lan-do> Are you versioning a social network?
<awilkins> Lo-lan-do: A terminology
<Lo-lan-do> Must be loads of fun.
<awilkins> Lo-lan-do: Like pulling teeth. Via your colon.
 * Lo-lan-do backs away
<awilkins> The worst bit today is that I must argue to prevent people putting requirements for permissions or ACLs on this data, or my head may explode.
<awilkins> IMHO this requirement is a Bad Idea, especially since they are moving to a distributed authoring system which (should) have a gatekeeper-style flow of data to the release branch
<hno> Oh, bzr 2.0rc2 is out?
<hno> now the tricky question,, should I push 2.0rc2 into Fedora rawhide so that Fedora 12 can ship with bzr 2.0 (hopefully not a rc by then.. F12 development freeze is 29/9), or wait until Fedora 13 with that upgrade...
<vila> hno: no changes are expected between rc2 and final
<fullermd> vila: Well, great, NOW you've done it.  The whole thing'll be rewritten now.
<Lo-lan-do> What about 1.8.1?
<Lo-lan-do> 1.18.1, sorry
<vila> fullermd: I didn't mention any release number... Just commenting out in the wild you know, don't take seriously, etc
<fullermd> Murphy ALWAYS takes things seriously!
<vila> Lo-lan-do: 1.18.1 sources and windows installers are available, OSX ones should follow shortly and THEN 1.18.1 will be announced :)
<vila> Subject: bzr 1.18.1 source and Windows installers available
<vila> To: Bazaar <bazaar@lists.canonical.com>
<vila> Date: Thu, 10 Sep 2009 15:39:36 +1000
<vila> Subject: bzr 2.0rc2 source frozen
<vila> To: Bazaar <bazaar@lists.canonical.com>
<vila> Date: Thu, 10 Sep 2009 17:19:15 +1000
<vila> There's a separate branch (see other mail) for 2.0final, which I plan
<vila> to do one week from today.
<vila> --
<vila> Martin <http://launchpad.net/~mbp/>
<Lo-lan-do> Yay :-)
<vila> so there, it wasn't me saying it, jinx conjured :)
<Lo-lan-do> I'm at a client's next week to evaluate a migration to bzr.  I'm bound to get the question of 2.0 availability.
<fullermd> Sheesh.  Why don't you just predict the power will stay on and no volcanos will erupt while you're at it?
 * vila checks eight-ball furiously
 * pygi shoots at vila 
 * vila ducks
 * pygi sends dogs after vila's ducks
<vila> ouch rib hurts
<james_w> hno: I'm planning to push 2.0 in to Ubuntu now, so it should work fine for Fedora
<fullermd> "I flipped over my magic eight-ball, and it said 'Outlook not so good'.  I said 'Sure, but Microsoft ships it anyway.'"
<vila> They said 'Use windows or better' so I used Ubuntu
<vila> james_w: \o/
<fullermd> Eep!  The Daystar is climbing into the sky!  Must be bedtime...
<SamB_XP_> last time it said that near me, I said something like "Wow! wormgas is right for once!"
<jelmer__> wow, we're already well on our way to test 30k
<Tak> jelmer__: how difficult would it be to do a ppa for md-bzr?
<jam> jelmer__: do you know if there is a bzr-svn that claims compatibility with bzr 2.0?
<jam> morning all
<jam> vila: the joke works better if you use a windows version
<jam> "Use windows xp or better"
<jam> as that would be something they actually *do* say :)
<vila> ha yes, you're right of course ! Morning jam :)
<jelmer__> Tak: hi
<jelmer__> Tak: not very difficult, but would require somebody to dedicate time to keep it up to date
<jelmer__> jam: the 1.0 branch claims 2.0 support, but hasn't had a release yet
<jam> abentley: you sent an email about releasing bzrtools 2.0.0 but I don't think you actually tagged it
<jam> maybe because there wasn't an actual change the tag didn't get uploaded?
<jam> jelmer__: k, just looking at building a 2.0.0rc2 installer, and obviously that will be important :)
<jelmer__> jam: there isn't a version change either, version.py says 1.18.0
<jelmer__> (unless I'm looking at the wrong branch)
<jam> jelmer__: in the tarball?
<jam> I wonder if he created a tarball, and didn't update trunk
<jam> jelmer__: the tarball clearly has 2.0.0 in version.py
<jam> so I'm missing something
<jam> I don't see any other possible branches on: https://code.edge.launchpad.net/bzrtools
<bialix> igc: ping
<hsn> !pastebin
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. Ubuntu pastebin is at  http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from  command line | Make sure you give us the URL for your paste - see also the channel topic
<bialix> there is also imagebin.ca
<jelmer__> ls
<hsn> how serious is this problem? http://paste.ubuntu.com/268588/ if i do bzr get and bzr check then newly created repo is ok
<balor> How do I throw away the current changes in my working directory?
<hsn> balor: bzr revert
<bialix> balor: bzr revert
<balor> much obliged
<bialix> bingo
<igc> hi bialix
<bialix> hi
<igc> rev 3 pushed now
<bialix> what is build-bzr-exe.py
<abentley> jam: I just didn't push after I tagged it.
<igc> my name for the script that the code buried in setup.py could become
<igc> bialix:^
<bialix> there is no in revno.3
<bialix> igc: I see there is Makefile changed and some buildout config
<igc> bialix: right
<igc> bialix: if you run make, it will take some time to pull everything down from the URLs but ...
<igc> it will go close to working
<bialix> igc: I think we should import bzr's setup.py and use function from there to get list of bzrlib modules
<igc> for me, it falls over bhilding the tortoise stuff because it can't import PyQt4
<igc> bialix: that sounds ok to me
<igc> bialix: for you, I'm hoping the tortoise stuff will build and then it will get to ...
<igc> the commented out setup.py py2exe line in the script
<bialix> igc: 1) I don't use buildout and don't plan to use it
<bialix> if you think I should then I need some time to install it and get familiar with this technology
<igc> bialix: there's nothing to install
<bialix> I think this is irrelevant to actual py2exe stuff
<igc> bialix: just run make
<igc> it bootstraps
<bialix> sorry, but your current Makefile require buildout
<igc> I never installed buildout
<igc> bialix: the make file basically ...
<bialix> does it will install setuptools in my Python?
<igc> 1. bootstraps buildout
<bialix> ...run bootstrap.py which trying to run setuptools
<igc> 2. uses it to pull down the right versions of the right products
<igc> 3. generates a disk image with bzr & plugins installed
<igc> 4. calls py2exe via setup.py
<igc> 5. runs inno-setup
<bialix> igc: sorry, I think I'm interesting only in steps 4 and 5
<igc> bialix: and that's where I'm up to
<igc> bialix: you have everything needed already for steps 1-3
<bialix> so if you have the documented layout how bzrlib and plugins are layed out it's all I need without buildout and setuptools
<igc> python, c compiler, pyrex
<bialix> igc: I'm explicitly prevent to install setuptools to my py2.5
<bialix> igc: gimme layout
<bialix> that's all I need
<bialix> then I can work on py2exe stuff
<igc> the layout is ...
<igc> a build_win32 directory with a bzr directory inside that
<igc> if you can take the code out of bzr.dev/setup.py that calls py2exe and move it into a script in bzr-windows-installers, I'm happy to do the rest
<bialix> igc: sorry, urgent call. can you describe layout in the some document and push it to the branch or mail me?
 * bialix bbl
<igc> sidnei ping
<bialix> igc: if you're ok using scmproj I'll create scmproj-based project for my work to avoid using buildout
<bialix> you can transform it to buildout config w/o problems
<igc> bialix: sure
<jam> igc: don't you know when to sleep?
<igc> bialix: the key thing is that py2exe code needs to run against a location where bzr isn't the current directory but some other path
<igc> jam: I'm exhausted and in pain tonight :-(
<igc> jam: after 2 3pm nights in a row, I need to go to bed
<jam> igc: I'm very sorry to hear that
<igc> jam: but I'm stuck on the Windows installer and if bialix or someone else doesn't help in the next 24 hours, then we won't have a better one for 2.0
<sidnei> igc: oi
<igc> jam: given I'm on leave next Thursday and Friday
<igc> sidnei: do you have the buildout image documented somehow so bialix can see it without using buildout?
<igc> s/somehow/somewhere/
<igc> sidnei: see above
<jam> igc: what is the sticking point?
<igc> sidnei: I'm struggling to get the new bzr-windows-installers project building an installer
<jam> as I've certainly dealt with it a bit myself
<sidnei> bialix: it will not install setuptools in your python
<igc> the current code assumes a py2exe target in setup.py
<sidnei> bialix: it will download a copy of setuptools in the 'eggs' directory and use that
<igc> and that assumes the bzr being packaged is directly under where the installer artifacts are
<igc> sidnei: if you grab the trunk of lp:bzr-windows-installers, you'll see where I'm up to
<sidnei> igc: where you said 'generates a disk image', is that something you added?
<igc> sidnei: no ...
<igc> I just meant it installs the plugins into the bzr getting packaged
<sidnei> igc: then that's incorrect?
<sidnei> igc: ah
<igc> sidnei: I'm still learning how it hangs together
 * bialix back
<igc> sidnei: btw, it's a shame that generated script is a .bat file - python would be *much* nicer!
<bialix> guys, I'm really like when things are documented. at least somehow
<bialix> at least a bit
<igc> bialix: I will document it
<igc> bialix: but I need to make it work first :-(
<bialix> igc: I can see what I can do about py2exe tonight
<bialix> igc: but promise that you go to bed now
<igc> bialix: thank-you heaps
<sidnei> igc: i discussed that with jam at some point. unfortunately doing a bunch of calls to subprocess is not something python excels at
<igc> shall do
<bialix> *now*
<bialix> check mail tomorrow
 * igc heads off to sleep
<igc> night all (and thanks guys)
<jelmer__> emmajane: hi
<jelmer__> emmajane: what is the plan wrt the maintainance of the new web site? Will it be a wiki again, plain html/python in a bazaar branch?
<emmajane> jelmer__, hey :)
<emmajane> jelmer__, unconfirmed but *very* likely flat HTML in a bazaar branch.
<emmajane> jelmer__, which is part of why I've already got it as flat HTML in a bazaar branch.
<jam> jelmer__: do you have a rough eta of a 1.0rc even?
<jam> Just to have something that will at least pretend to work with 2.0rc2
<jelmer__> jam: there's a critical bug in subvertpy I need to fix, after that I think we're ready for a RC
<jam> k
<jam> of course, you need to tell me the versions of everything
<jam> subvertpy, bzr-rewrite, bzr-svn, etc
<jam> I'm always guessing a bit when it comes to making the next release
<jelmer__> ok
<jelmer__> bialix: did you have a chance to look into bzr-git on windows again?
<bialix> jelmer__: not yet
<james_w> jam: I just created a version tracking page at http://bazaar-vcs.org/Releases/2.0.0
<bialix> I need the patch for bzr-git to allow dulwich be imported in the case of bzr.exe. I don't remember if you merged it
<james_w> we can try and get all the versions to go with 2.0.0 on there so that we all know what we are expected to package
<bialix> jelmer__: lp:bzr-git is ok to use?
<jelmer__> bialix: Yeah, that was merged
<jelmer__> bialix: yep, lp:bzr-git is the main branch
<bialix> then I'll try to run selftest shortly
<bialix> ping me later
<jelmer__> bialix: hmm, actually
<jelmer__> I think I might have merged the subvertpy one
<jelmer__> not the dulwich one
<jelmer__> this should be in __init__.py right?
<bialix> right
<bialix> I'll look
<bialix> time passed, I forget the details
<jam> can anyone here read Japanese?
<jam> I'm getting some spam on my blog, and I'm curious what it says
<Lo-lan-do> I can read a bit
<Lo-lan-do> jam: URL?
<jam> Lo-lan-do: I just deleted it, I found a Japanese - English translation online
<jam> which did a poor job
<jam> but enough to make me know that I didn't want 150,000 yen for men who like women
<Lo-lan-do> Okay :-)
<jam> Lo-lan-do: excerpt:  æ§æ¬²ã®ãã¼ã¯ãè¿ããã»ã¬ãçå¥³ãã¡ã¯ããéã§ç·æ§ãè²·ããã¨ãå¤ãããã§ãã
<jam> what was really strange is that there weren't any outbound links
<jam> which made me wonder if it was actually a legitimate conversation about my blog in japanese
<jam> but no
<jam> not at all :)
 * emmajane chuckles.
<jam> so I have 2.0.0rc2 installers built, but they don't include bzr-explorer, etc.
<jam> Should I upload them? (bialix ^^)
<james_w> renamed=[(u'README', u'README', 'readme-20090910165710-bk5k711lzk9ktzce-10', 'file', True, False),
<james_w> really now?
<eyalw> Hi, I'm trying to push the initial commit into my branch on LP, and I get :: bzr: ERROR: At lp:saturn-clock you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again.
<vila> wow, karmic boot + login in ~16 secs (excluding password typing time :-)
<james_w> so in a rich root repository a branch gets a random file-id for the tree root on creation?
 * james_w waves to vila
 * vila waves back ! 
<awilkins> vila: Is that Karmic + ext4 ?
<vila> awilkins: default install, ext4 yes (keep in mind that's a VM though)
<awilkins> So if you have lots of RAM the entire disk may be in it :-)
<vila> so that ext4 is a single file on ext3 in the host
<vila> I don't think it matter that much at boot... and anyway that's still a huge progress :)
<james_w> is it possible to specify or modify the root file-id?
<james_w> I'd like it to match another branch, even if they don't share any revision history yet
<eyalw> can anyone help with bzr please
<Tak> eyalw: try push --overwrite?
<Tak> eyalw: btw, there's a monodevelop-bzr branch now for MD 2.0 at https://code.launchpad.net/~taktaktaktaktaktaktaktaktaktak/monodevelop-bzr/2.0
<Tak> although there's also a MD 2.2 beta release now
<eyalw> Tak: same error
<eyalw> Tak: how is that gonna help
<eyalw> Tak: if bzr can't commit, how can something that use it
<Tak> it won't help in this instance, but we were talking a few weeks ago about md-bzr
<Tak> two separate threads ;-)
<eyalw> Tak: wow, nice memory : )
<Tak> if you do `bzr plugins` , it shows the launchpad plugin, correct?
 * Tak brb
<eyalw> Tak: so how do I install it
<Tak> the easiest way is to branch it, load the solution in md, build it, and drop the dll in ~/.config/MonoDevelop/addins
<eyalw> Tak: nm, I jusr recreated the branch, so it fixed the problemo
<Tak> cool
<eyalw> Tak: I get an error that the remote repository is not compatible with my local shared repository, different rich root support, you know anything about that?
 * eyalw is off to gym
<Tak> eek
<Pilky> hey all, I'm having a bit of a problem with bzrlib
<Pilky> I've got a simple branch with 3 files in, lazydog.txt, veryactivedog.txt and a .bzrignore with the rule *active*
<Pilky> I create a working tree object (wt)
<Pilky> but if I do wt.smart_add(files, save=False) it doesn't detect that veryactivedog.txt should be ignored
<Pilky> (I'm using save=False just to test)
<Tak> that's the same thing that would happen if you did `bzr add lazydog.txt veryactivedog.txt` , isn't it?
<Pilky> oh wait yeah
<Pilky> lol, forgot about that
<Pilky> Tak: but then how do you get smart_add to add everything?
<Pilky> or do I need another method for that
<Tak> give it a directory?
<Pilky> ah thanks
<Pilky> the API docs could really do with mentioning stuff like that
<Pilky> might have a go at looking at improving the documentation of bzrlib when I'm bored one night and feel like learning more about bzr's internals
<Tak> I think it's in the ui help for add
<Pilky> yeah, but if you're developing using an API it's annoying to have to jump to user documentation to find out how an API works
<Pilky> that said it's not quite as annoying as the number of undocumented or half documented methods
<Tak> the ui api is part of the api, though ;-)
<Pilky> oh wait, so it is
<Pilky> ah well
<Pilky> bad example then :P
<Pilky> good example of bad documentation = WorkingTree.commit()
<bialix-py2exe> lol
<Kobaz> when i load up emacs (22), it loads some sort of bazaar module... anyone know how to disable it?  it makes file loading take forrreeeevvveeer
<Kobaz> it only loads the module when i'm in a bzr branch
<garyvdm> Hi bialix
<bialix> hi garyvdm
<bialix> lp seems down
<garyvdm> I see :-(
<bialix> garyvdm: for you too?
<garyvdm> yes
<bialix> garyvdm: I've planned to update translations in 0.14 branch
<garyvdm> Ok
<garyvdm> bialix: I'm hoping to release 0.14.1 tonight
<bialix> but can't until lp finished maintenance work
<garyvdm> I c
<bialix> well, in this case no translations update from me
<bialix> it's not critical
<bialix> do you fixed that bug with locking as you planned?
<bialix> guys! anybody has copy of igc's branch with new windows-installer stuff?
<sidnei> bialix: i think lp:bzr-windows-installers it is
<bialix> sidnei: lp is down *right now*
<sidnei> bialix: oh, in which case you want an actual copy. i have one.
<garyvdm> bialix: I fixing that bug right now.
<bialix> sidnei: I need latest revno 3 which igc did today
<bialix> can you publish it or mail me in archive?
<sidnei> bialix: i can, i suppose. let me think about how to do it
<bialix> it should be pretty small I suppose
<sidnei> bialix: i guess you want the actual branch, not a 'bzr export'
<bialix> don't care
<sidnei> bialix: much easier then, email?
<garyvdm> sidnei: bzr senf
<garyvdm> *bzr send
 * bialix recall my ol plugin gzipped-bundle
<sidnei> garyvdm: it's asking me for a submit branch
<bialix> sidnei: am I understand correctly that buildout just lay out bzr and plugin branches based on its names?
<bialix> sidnei: export will be enough
<sidnei> bialix: yes, that sounds correct
<bialix> I'll get the actual branch later when lp will back to life
<baccenfutter> hi, are noob questions allowed?
<bialix> yes, but be careful
<garyvdm> sidnei: You can provide you current branch as the submit branch, and provide a -r
<bialix> garyvdm: this won't work
<garyvdm> baccenfutter: Sure - bialix: :-p
<sidnei> garyvdm: -rlast:3 .
<sidnei> Bundling 0 revision(s).
<bialix> exactly
<baccenfutter> I'm about to setup a repository for a collaborative project with a couple of friends - now I don't really quite get, how to go about the main structure.
<bialix> sidnei: you can use empty branch (revno.0) as submit
<baccenfutter> We want to have the trunk centralized public and a branch locally each
<baccenfutter> so do I now go about and init a trunk on the server and then a local repo and branch that into first?
<bialix> yes
<baccenfutter> oder do I build the whole thing on my box and push that?
<baccenfutter> s/oder/or/
<baccenfutter> k, so first
<bialix> this will work too
<garyvdm> baccenfutter: Either
<baccenfutter> i'd prefere first, if it would work
<bialix> np
<baccenfutter> and then how would I wanna design that? /trunk, /branch, brach/user1, branch/user2, branch/foo?
<sidnei> bialix: i think it's on its way *wink*
<bialix> lp seems back to life
<baccenfutter> or is the branch folder created on first branch?
 * bialix chase the branch until it run away
<bialix> sidnei: thanks a lot
<sidnei> bialix: np. fwiw, your server didn't accept the first message i sent, it responded that it was spam
<bialix> ah yes
<bialix> it's free emial provider
<garyvdm> baccenfutter: You need to create that structure, and you can do that how ever you like
<garyvdm> baccenfutter: We have a doc on that, let me find it quick
<bialix> I have account at gmail which is myname.myfamilyname @ gmail.com
<bialix> but I've got your mail already thanks
<bialix> sidnei: ^
<sidnei> bialix: thank you!
<bialix> sidnei: do you will be around soe time so I can ask about buildout stuff if needed
<zsquareplusc> could someone please write an easy to understand help page for bzr split? :p
<bialix> sidnei: do you will be around some time so I can ask about buildout stuff if needed?
<sidnei> bialix: i will be around for the next 2-3 hours, but ping me directly im not paying attention to irc
<garyvdm> baccenfutter: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#organizing-your-workspace
<bialix> sidnei: ping
<bialix> this way?
<sidnei> bialix: yep
<bialix> ok
<Kobaz> unkuhnown
<bialix> zsquareplusc: may be you don't need it?
<zsquareplusc> bialix: i want to have a subtree as standalone branch (splitting sub-projects from a historically grown big tree)
<bialix> you still will have entire history for entire project after split
<bialix> just less files
<bialix> is it your intent?
<zsquareplusc> no
<bialix> you can try fastimport then
 * bialix fears to run buildout
<zsquareplusc> ok, so split isn't what i need then. but i have to say that it is not intuitive at all that command. it spits out errors about not being a workingtree which i don't understand
<garyvdm> bialix: Can I do the translations import? I interested as to how to do it.
<garyvdm> ^for 0.14.1
<bialix> garyvdm: I've realized we need to upload qbzr.pot template for 0.4 seies first
<bialix> for 0.14 series first
<garyvdm> oh
<bialix> perhaps I'm just starting this too late
<bialix> I can guide you but maybe not tonight right before release, ok?
<garyvdm> OK
<bialix> garyvdm: ping me if you need my help with release
<garyvdm> ok
<bialix> I've promised to Ian to help with py2exe stuff
<garyvdm> bialix: I don't think any strings have changed from 0.14.0 to 0.14.1. I'll dbl check.
<bialix> I think so
<bialix> so I think it's not critical for 0.14.1 even if couple of them are
<garyvdm> bialix: No strings have change.
<garyvdm> So I'm going to do the release now.
<bialix> let's rock!
<bialix> garyvdm: wait
<garyvdm> ...
<bialix> can I push one small fix first?
<bialix> garyvdm: ^
<garyvdm> sure
<bialix> just a sec
<bialix> garyvdm: done
<bialix> thx
<bialix> sidnei: does buildout supposed to build svn from scratch?
 * bialix wonder why buildout put all components (install them) into the same directory where helper files/dirs resides, why not in subdir?
<bialix> jam: are you here?
<jam> bialix: yse
<jam> yes
<bialix> do you know why buildout put downloaded components in the same dir, but not in the subdir?
<jam> bialix: I don't really know why, and think it sucks, which is I why I 'fixed' the buildout script in bzr so that it creates a staging directory, copies things into there, and then does its work
<jam> I believe you can configure the directories buildout wants to work in
<bialix> and why for releases it's not used official tarballs instead of getting branches?
<jam> as I think I remember sidnei saying he usually points buildout at local directories in various places on disk
<jam> bialix: because I prefer to build from branches
<jam> we have a VCS, lets use it
<bialix> my home inet is limited :-/
<jam> tracking tarballs is sucky
<jam> bialix: if you use branches, you don't have to download a lot each time
<jam> as you probably already have it in a repo
<jam> (after the first download)
<bialix> but not so sucky to download svn sources and unzip them :-P
<bialix> I don't follow
<sidnei> the directories are configurable yes, just come up with a consensus and i can help applying it
<bialix> jam: IIUC your proposal is to have one big 2a shared repo and doing build inside it?
<jam> bialix: thats basically what I'm doing on kerguelen
<bialix> :-/
<jam> I think it started with a mix, because bzr-svn was in rich-root, but nothing else was
<jam> now that we are moving to 2a, we could simplify a bit
<bialix> I see but not quite agree
<bialix> sidnei: can I stop buildout execution, fake the big branches (like bzr one) and the resume it?
<sidnei> bialix: iirc, yes
 * bialix trying
<zsquareplusc> ok, instead of splitting up a repository i can re-export from CVS. but i'd like to combine some of the CVS modules in one bzr branch, however export is restricted to one module at a time. is it possible to merge two branches like that? can i simply use bzr merge?
<bialix> sidnei, jam: why bzr branches going into $PRODUCT/release ?
<bialix> sidnei: I see here .installed.cfg: can I edit it manually and fake some steps?
<sidnei> bialix: i believe that's what jam is referring to when he said he's creating a 'staging' directory
<sidnei> bialix: yes, though you shouldn't need to
<bialix> I'm afraid I'll wait all night until I'll pull all required branches from lp
<bialix> and my inet quota will be exhausted
<bialix> what's good for kerguelen is not good for mere mortals
<sidnei> bialix: you can branch from a local branch into the local build repo?
<sidnei> (if you have a local branch of the dependencies that is)
<bialix> lol: bzr info said I have: Unshared repository with trees (format: 2a)
<bialix> bzr reciepe should not branch. it should init + pull
<bialix> so process could be resumed
<jam> bialix: init + pull can't be resumed unless you are doing a format conversion
<jam> packs => packs fetch is an all or nothing affair
<jam> (same for 2a => 2a)
<jam> only the cross-format conversion builds things as you go
<jam> and then, I think it only does that locally now ...
<bialix> I don't have words
<bialix>  git operates in the term of hash-addressable objects it can easily support resume I think
<bialix> *if git...
 * bialix shut up
<jam> bialix: there are things we could do. we don't
<jam> We used to
<jam> lifeless felt that having atomic inserts was better than resumable copies
<jam> and it also lets us fetch things 'out of order'
<jam> and not worry about it until the stream is finished
 * bialix no more believe in ideal solution, sorry
<jam> out-of-order fetching actually made fetching quite a bit faster
<jam> especially since we can read inventories to determine text keys
<jam> and write the inventories to disk
<jam> rather than buffering them
<jam> or re-downloading them
<jam> I've oft wanted a resumable fetch
<jam> we just aren't there yet
<bialix> sidnei: what should I edit in buildout.cfg to disable fetching of bzr?
<jam> bialix: and while git does things in terms of sha1s, it still needs to know when it has the complete set of sha1s
<jam> I believe it isn't perfect about resuming fetch either
<jam> since it doesn't talk about all file shas
<jelmer> I don't think git does resumable fetch either
<jelmer> I wouldn't see how, anyway
<jelmer> you only get back one pack file from the server
<bialix> sidnei: remove bzr from "parts"?
<bialix> jam: I think this problem related to recent garyvdm post about downloading too much stuff via dumb transport
<jam> bialix: so log in to launchpad, and everything will be downloaded via the smart transfer
<jam> jelmer: for the stuff you've gotten so far, you could write it to disk and mark it as locally available
<lifeless> moin
<jam> I don't know how you would resolve the 'what do I have that you don't question'
<bialix> by "this problem" I meant "resumable pull"
<jam> which is generally done by inspecting the revision graph
<jam> lifeless: morning
<jelmer> jam: but you don't have any guarantee about the order of the pack file
<jam> jelmer: exactly. So you can't be sure when you've gotten all the content for a revision
<jam> without actually focusing on determining that
<jam> which is probably not cheap
<jelmer> right
<jam> lifeless: did I read correctly that you were catching a plane yesterday?
<bialix> jelmer: if I know which pack file I need to download from server and I see it present locally I can just omit it
<bialix> no?
<jelmer> bialix: not with the git smart server
<jelmer> bialix: as that generates a pack file on the fly for you
<lifeless> neither git nor hg do resumable branches
<jelmer> bialix: you don't actually know what it's name is until it's completely sent
<bialix> jelmer: but pack has inside objects?
<jelmer> bialix: yes, a pack file contains objects
<jam> lifeless: well I think hg sort of does, but encourages you to 'hg truncate' if the fetch fails
<jam> though they may do it for you
<eyalw1> hi, I'm getting an "different rich-root support" error when I try to branch a LP project into my local repo, why is that ? and how do I fix this
<bialix> can you recover objects from partially downloaded pack?
<jelmer> bialix: that's what jam and I were just discussing
<lifeless> jam: I used hg to get this netbeans thing
<lifeless> jam: it rolls back on failure
<jelmer> bialix: you might be able to recover some objects, but that doesn't really help you
<bialix> sorry, I'm battling with buildout and don't read carefully
<awilkins> eyalw1: One end is a rich-root format, the other isn't
<awilkins> eyalw1: Is your repo in --2a format?
<eyalw1> awilkins: what is a rich root format?
<jelmer> bialix: unless you go back and check that you happened to have gotten all of the objects required for a revision it doesn't help
<jelmer> bialix: (and the chances of that are slim)
<lifeless> jam: bialix: let me say, I'd love resumable downloads.
<awilkins> eyalw1: rich-root versions metadata about the root folder, as well as everything else. Which means you can do things like move it
<bialix> jelmer: okay okay
<lifeless> I just think they are extremely hard to do well; and none of our competitors do them.
<bialix> lifeless: but you just trying to say "but..."
<bialix> don't
<jelmer> lifeless: that's a good reason why we should do them well :-)
<lifeless> jelmer: it is
<awilkins> eyalw1: It's required for SVN interoperability, and is the default in --2a format - new formats will all be rich root. Older formats were only rich-root if you explicitly said so.
<jam> jelmer: well the 'extremely hard to do them correctly' is the main reason we don't
<lifeless> I've put my thoughts on the issues on the list before
<eyalw1> awilkins: so, do you suggest to use it by default or not
<lifeless> atomic insertion has bought us a _lot_
<awilkins> eyalw1: I tend to use it by default because I have a lot of SVN repos I interoperate with
<lifeless> we used to have lots of rpeository glitches on NFS, and we couldn't do concurrent insertions
<bialix> so, no one modern VCS has resumable pull?
<eyalw1> awilkins: but for people who don't use svn, is it recommended?
<jelmer> bialix: darcs :-)
<lifeless> jelmer: does it?
 * bialix chuckles
<awilkins> eyalw1: I would probably start using --2a for new projects
<jelmer> lifeless: I'm pretty sure it does
<awilkins> eyalw1: Which is rich-root. Existing projects are mostly not using rich-root.
<eyalw1> awilkins: why isn't bzr use it by default today
<lifeless> jelmer: it would be interesting to check :)
<awilkins> eyalw1: But if you were branching the bzr repository, that moved to --2a a while ago (see topic :) )
<bialix> it seems only svn has decent windows support. all others are suck on different tiny details. darcs too
<awilkins> eyalw1: Because it didn't historically
<jelmer> lifeless: Yeah
<jelmer> bialix: even bzr?
<awilkins> bialix: I find Bazaar to be the best of the DVCS for supporting Windows, but it has some nasties (like the OS locking thing which stopped you using the powerful shelve 2 command)
<awilkins> Certainly git and Mercurial I found to be less Windows-friendly
<bialix> awilkins: (proper) support for case-insensitive fs?
<bialix> line-endings?
<bialix> lifeless almost fixed os locks
<awilkins> bialix: I view these as less of an issue ; the only tools silly enough to require particular line-endings I use are windows-only anyway
<lifeless> bialix: is it still giving trouble?
<bialix> I dunno
<eyalw1> awilkins: ok, thanks : ) I guess ill read about it some more on google
<lifeless> jelmer: #subunit :P
<bialix> lifeless: but ya know: OSLMD
<lifeless> bialix: I agree
<awilkins> bialix: And I don't create files who's names differ only by case, so that doesn't really cause any showstoppers - if Bazaar handles the "rename a file to a different case of the same name" use case on windows, that's the only one I know about that was a problem with SVN for a long while
 * awilkins tests the "rename to different case" thing
<bialix> awilkins: I have no desire to chew all this again tonight again and again
<bialix> sorry
<awilkins> bialix: No problem ; I guess I've just adapted my habits enough that these things are irrelevant to me
<bialix> awilkins: I mostly too, but they still blow into the face of novices
<bialix> if you want sell a tool to novices you should be perfectly looking
<bialix> don't tell people: uh oh, this is known issue, so don't see at this error please
<bialix> when I have to tell this in ru_bzr I feel bad
<bialix> awilkins: one more thing! diff headers!
<bialix> they are in utf-8!
<bialix> huh?!
<bialix> I hope one day abentley will help to resolve this
<awilkins> bialix: No BOM I presume
<bialix> awilkins: you're ascii-only guy I assume
<bialix> diff for non-ascii filenames show name of the file as utf-8
<lifeless> jelmer: ping
<bialix> in the windows console
<bialix> Ð±Ð»Ð°Ð¶ÐµÐ½Ð½Ñ Ð½ÐµÐ·Ð½Ð°ÑÑÐ¸Ðµ
<awilkins> bialix: It seems to cope with the same-name-different-case-rename scenario
<bialix> awilkins: this scenario I've fixed many years ago, yes
<awilkins> bialix: Yes, British english, CP1252 console
<awilkins> Or UTF-8 / 16 powershell
<awilkins> And UTF-8 bash
<awilkins> (on linux)
<eyalw1> awilkins: bzr: ERROR: no such option: --2a
<lifeless> jam: ping
<jam> lifeless: ?
<awilkins> eyalw1: Which version are you using?
<awilkins> eyalw1: bzr version
<lifeless> jam: py memory dump
<lifeless> jam: I want to analyse this 6gb trace
<eyalw1> awilkins: 1.13.1
<bialix> awilkins: what's about powershell?
<jam> lifeless: now officially branded 'meliae' and available as "bzr branch lp:meliae" :)
<lifeless> jam: the existing tools seem to want to load the entire thing
<jam> lifeless: the general operations do, yes
<jam> which is what heapy does, too
<jam> just doesn't support 6GB dumps in the first place
<awilkins> bialix: Powershell? It's all .NET strings internally so it's UTF-16 in memory
<bialix> it's console?
<bialix> which encoding it uses?
<awilkins> bialix: Yes, next-generation Microsoft console
<lifeless> jam: so, the comments about module references and the like are a little unclear to me
<jam> lifeless: so how would you reduce what you read in?
<awilkins> bialix: Better scripting than cmd.exe
<lifeless> jam: mainly because it only seems to me that it would matter when there are global variables that are the leak?
<jam> since stripping stuff out would lead to an imprecise picture...
<awilkins> bialix: In a lot of ways I find it easier than bash
<jam> lifeless: so if you have a function it references its module
<lifeless> jam: you should delete the old py_memory_dump +junk branch, or rename it into meliae, so that folk get some sign to chance :>
<jam> which means if you have a variable pointing to a function you end up...
<bialix> awilkins: std cmd.exe uses OEM encoding, and could be switched to ANSI. But it does not support utf-8 in the way bzr can understand it
<jam> which is what 'remove_expensive_references' is somewhat about
<jam> for when you want to compute the recursive size of things
<lifeless> ok
<jam> lifeless: I'm happy to include things that would be useful to you
<awilkins> bialix: Did you get the PM?
<jam> understanding memory consumption has been pretty tricky for me
<lifeless> jam: cc1: warnings being treated as errors
<lifeless> meliae/_scanner_core.c: In function '_dump_object_info':
<lifeless> meliae/_scanner_core.c:261: error: format '%d' expects type 'int', but argument 3 has type 'Py_ssize_t'
<bialix> PM?
<lifeless> jam: you seem to have a very good handle on it. I agree that tuple keys are a poor proxy for a compact object btw
<jam> lifeless: I run on 32-bit, so don't notice some 64-bit issues. Patches/bug reports welcome
<lifeless> jam: if you change that line to use %ld, does it build?
<lifeless> jam: have you considered using the unparsed \0 separated strings as keys?
<jam> lifeless: changed to %ld
<jam> in rev 70
<lifeless> jam: theres a bunch more; I was checking ld worked for you :P
<jam> lifeless: I've considered something like that, but it doesn't work particularly well for parent lists
<jam> lifeless: I changed more than that one
<jam> I changed all the Py_ssize_t ones I've found
<lifeless> jam: did you change the tests :P
<jam> lifeless: the tests passed here
<jam> both ways
<lifeless> jam: I'll have a patch for you soon :P
<jam> there are probably some 64-bit size-of-objects bugs as well
<jam> since some things scale, and some don't
<jam> I also saw some python 2.6 differing from python2.5
<jam> like dicts getting bigger for some reason
<jam> I think the GC header actually grew from 12 bytes to 16 bytes here
<lifeless>         self.assertSizeOf(6, 'a', extra_size=1, has_gc=False)
<lifeless> what does 6 mean here
<jam> lifeless: 6 32/64-bit words
<jam> extra_size = num bytes
<lifeless> yes but why 6
<jam> lifeless: because a string has:
<jam> ob_refcnt, ob_size, ob_type
<jam> 3
<jam> hash == 1
<lifeless> so 6 means 'string overhead'
<jam> flags == 1
<jam> lifeless: right
<jam> in C
<jam> sizeof(PyString) == 6*4
<lifeless> so, 64 bit word size is still 4
<jam> or 6*8
<jam> lifeless: pointers and longs are 8 bytes in python
<jam> on 64-bit
<lifeless> jam: yes, because neither of those are words
<jam> the one that doesn't change is an int field in strings
<jam> so it is probably 5*4, extra_size=1+4
<jam> or something like that
<jam> lifeless: so call the 'basic pointer/long' size what you want
<jam> I'm focusing on multiples of those
<bialix> awilkins: https://bugs.launchpad.net/bzr/+bug/382699
<ubottu> Ubuntu bug 382699 in bzr "diff headers should contain non-ascii filenames in user_encoding, not in utf-8" [Undecided,Confirmed]
<jam> lifeless: AFAIK word is still 16 bits
<jam> given that microsofts api's use DWORD for Double Word == 32bits
<lifeless> jam: it gets worse, as pointer width is a model thing, and there are hybrid arches
<lifeless> jam: with 32 bit points, and 64 bit numbers
<jam> lifeless: I don't particularly care about getting the test suite to pass on hybrid arches, but if someone cares to put in the effort, great
<jam> there are also alignment issues, etc
<jam> And I've heard that py 2.7 is going to re-align strings
<jam> and cut out a couple of bytes of waste
<bialix> wow, buildout finished to get components
<lifeless> jam: can you confirm on win32
<lifeless>         self.assertSizeOf(4, '', extra_size=0+8, has_gc=False)
<jam> lifeless: confirmed
<lifeless> thanks
<jam> lifeless: on py2.7 I think that becomes self.assertSizeOf(4, '', extra_size=0+5, has_gc=False)
<jam> as they use offsetof(ob_sval) rather than sizeof(PyStringObject)
<jam> but as I don't have py27 to test, I'm not worried about it
<lifeless> lp:~lifeless/meliae/64-bit
<bialix> awilkins: one day (soon) I'll plan to write article with some advices how the best work with bzr in windows (from command-line and gui). I'd like to consult with you about powershell tricks which can be useful for bzr users
<awilkins> bialix: My use on Windows is entirely Powershell + qbzr ; I don't use the overarching GUIs like Olive and bzr-explorer
<bialix> awilkins: it's ok, I just need couple of advices who the best configure powershell for bzr needs
<bialix> s/who/how/
<jam> lifeless: :(, on mingw32 with %ld, I get: 271: warning: long int format, Py_ssize_t arg (arg 3)
<jam> oh, also with python2.5
<lifeless> And this is why C sucks
<lifeless> does %zd work for you?
<jam> lifeless: %zd is not understood by Visual Studio
<jam> It doesn't complain
<jam> but the test suite gives:
<jam> "size": zd
<jam> in the output
<jam> lifeless: #define time, I guess
<lifeless> #define SIZET_FORMAT "%l...
<lifeless> yes
<lifeless> so backto analysing the dump
<jam> lifeless: so I would start with 'strip_duplicates.py'
<jam> which uses a fairly lightweight Set object and doesn't store each row in memory
<lifeless> there are two issues I know of
<lifeless> these expensive references
<lifeless> and cycle breaking
<jam> it doesn't matter for analyzing with meliae, but it avoids using sort -u, etc
<lifeless> have you heard of Tarjan's method?
<jam> lifeless: not specifically
<lifeless> http://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm
<lifeless> I've implemented this in C++ for cygwin's setup.exe
<lifeless> it is/was how it breaks dependency cycles for installs
<jam> lifeless: seems somewhat similar to gdfo, only smallest distance from origin
<lifeless> it finds cycles
<lifeless> a strongly connected component is a subgraph where every element in the subgraph can reach every other element
<awilkins> Heh, I think I wrote that for VB DLLs once
<jam> lifeless: so the main reason for the remove-expensive-references is because if you hit a module, your cycle basically includes *everything*
<lifeless> jam: so I was thinking about a few things we could do for very large memory dumps
<lifeless> tarjan's method is a tool we may find useful
<bialix> jam, sidnei: components layout is simply awful, sorry for my french
<lifeless> one thing I was thinking was to shove the memory dump into a b+ tree; with long reference lists split into internal graph nodes
<lifeless> this would allow logn lookups to do graph processing on it
<sidnei> bialix: merci beaucoup
<bialix> oops
<jam> lifeless: performance might be a bit poor given the sorted requirement, shear number of keys, and probably lack of locality
<jam> but it certainly seems like a way to handle the memory issues
<bialix> sidnei: but really, all eggs are put into the same basket
<bialix> heh
<bialix> never mind
<sidnei> literally yeah
<lifeless> jam: actually locality should be pretty good
<lifeless> jam: I'm going to give it a spin anyhow
<jam> lifeless: I suppose it depends on the locality of the malloc, right?
<lifeless> right
<lifeless> what arena its in basically
<lifeless> things allocated in a tight loop of the same type will be 'close'
<jam> lifeless: anyway, tests right now are passing on py2.5 using mingw and py2.6 using VC on Windows
<bialix> it's not my call now to maintain this mess, so who am I to point on such things
<lifeless> even if they use several subtypes, we should see a cluster of related regions
<sidnei> bialix: i'd be happy to change it if you got a better proposal
<bialix> I'd like to see buildout helper dirs, source components dirs and release dirs separated by dedicated subdirectories
 * bialix wonder how jam handle all this
<sidnei> bialix: care to draw some ascii art for me?
<sidnei> like pwd/<buildout-stuff>, pwd/source, pwd/release?
<bialix> yep
<lifeless> jam: cool, let me know when you've pushed ;)
<jam> lifeless: pushed rev 71
<jam> hold on a sec
<jam> it was pushing to a personal branch rather than the official trunk
<jam> pushed now
<lifeless> jam: have you merged my branch?
<jam> lifeless: I'm happy to make you a dev if you want
<jam> I didn't know you published a branche
<lifeless> 07:13 < lifeless> lp:~lifeless/meliae/64-bit
<jam> lifeless: doing it now
<lifeless> jam: thanks
<jam> lifeless: so after merging, I still get: 271: warning: long int format, Py_ssize_t arg (arg 3) with gcc, but at least the tests pass
<jam> lifeless: test suite still passes, though the warnings suck
<lifeless> jam: I get no warnings.
<lifeless> jam: I suspect you just need to use the #ifdef in some spots you missed
<lifeless> jam: bzr diff should show you those
<GaryvdM> Please can someone copy qbzr 0.14.1 in the bzr ppa. https://edge.launchpad.net/~qbzr-dev/+archive/ppa/+copy-packages
<lifeless> GaryvdM: drop a mail to the list cc john ferlito
<jam> lifeless: is this your last commit:
<jam> 66 Robert Collins    2009-09-11
<jam>    64 bit port.
<jam> well only commit :)
<bialix> something wrong with buildout. No module named subvertpy
<jam> I don't have a #define for %ld vs %d etc
<lifeless> jam: oh, thought you did
<lifeless> so %zd is the right thing to use
<lifeless> but visual studio will fail
<jam> lifeless: except it isn't a C standard...
<lifeless> jam: I know :P
<lifeless> so we need a #define for it
<jam> what is zd?
<lifeless>        z      A following integer conversion corresponds to a size_t or ssize_t argument.
<lifeless> (man 3 printf)
<lifeless> zd == ssizet
<lifeless> zu == sizet
<bialix> jam: are you using some special additionasl settings on kerguelen for building installer? buildout from Ian's branch can't find subvertpy, while it actually downloaded
<jam> lifeless: not in my 'man 3 printf' but I'll trust you :)
<jam> The PRIuPTR macro (from <inttypes.h>) ...
<jam> http://stackoverflow.com/questions/174612/cross-platform-format-string-for-variables-of-type-sizet
<bialix> sidnei: for building bzr.exe build-installer.bat should add location of subvertpy to PYTHONPATH
<bialix> sidnei: it seems don't
<bialix> sidnei: is it intended?
<sidnei> bialix: likely not, but jam should know better
<bialix> jam: have a minute?
<bialix> sidnei: I smell bug, but I'm not sure
<lifeless> jam: uhm, thinking.
<jam> lifeless: so it seems using "#ifdef __GNU__; #define FMT "%zd"" doesn't work here
<bialix> sidnei: oh, my bad
<jam> it gives "zd" in the output.
<jam> Probably the formatting is done in the windows library
<jam> arg
<lifeless> jam: what gcc version do you have?
<bialix> sidnei: Ian has disabled it in his branch
<jam> lifeless: 3.4.4 (cygming special
<lifeless> god thats old
<jam> lifeless: newest version in cygwin
<jam> there is a 4.x version but not for mingw
 * awilkins is using the 4,1.x mingw one
 * awilkins starts his bzr-build vm
<lifeless> jam: cygwin's mingw packages are often old
<lifeless> jam: #ifdef __linux__
<lifeless> jam: will keep me happy
<GaryvdM> bialix: what version of PyQt should I have for the windows installer?
<bialix> 4.4.3 for Python 2.
<bialix> 2.5
<jam> lifeless: well, it doesn't handle 64-bit windows but hey...
<jam> (I can't use sizeof() because types are defined yet...)
<lifeless> jam: 64 bit windows will be different
<lifeless> jam: as its LLP64
<bialix> incredible
<bialix> buildout seems to build bzr-svn successfully for me
<lifeless> jam: I could be wrong; still, wait for the bug reports :P
<jam> lifeless: so I don't have a good answer for *windows* yet
<jam> because I can't just use %ld
<jam> I can set it to use %zd for you
<jam> without much problem
<jam> #ifdef _WIN32 #else
<bialix> sidnei: I've reached the point when I have to say you: you rock
<sidnei> bialix: what did i do *wink*
<bialix> sidnei: [01:00]	<bialix>	incredible
<bialix> [01:00]	<bialix>	buildout seems to build bzr-svn successfully for me
<lifeless> jam: so regarding the PRIuMAX approach;
<lifeless> jam: http://www.embedded.com/columns/technicalinsights/204700432
<sidnei> bialix: \o/!!!
<lifeless> jam: thats the referenced article, and in it he suggests (at the end) just doing a specfic typedef
<lifeless> jam: which is what I favour too
<bialix> \o/ indeed
<bialix> sidnei: jam: thanks, and sorry
<bialix> lifeless: at which time igc usually wake up?
<lifeless> another hour or two
<jam> lifeless: I don't have a problem with that, but I still can't find the #ifdef combination that will activate on 32-bit windows versus 64-bit windows...
<lifeless> he's one hour TZ behind me
<jam> lifeless: igc went to bed pretty late, though
<jam> he was up around 6 hours ago, IIRC
 * bialix going for some coffee
<lifeless> bialix: but I wake up early in my TZ :P
<lifeless> jam: #ifdef _WIN64
<bialix> it seems I have no good news for him
<bialix> igc: when you wake up -- ping me
<lifeless> jam: actually try just WIN64
<jam> lifeless: seems to work: http://paste.ubuntu.com/268811/
<lifeless> jam: have you tried WIN64 ?
<lifeless> http://mail.python.org/pipermail/patches/2000-May/000619.html
<jam> lifeless: I don't have a win64 machine to test it on
<jam> anyway, time for me to go
<lifeless> ok
<lifeless> _WIN64 is the one, I think. I find lots of refs to it
<lifeless> night
<igc> ping bialix
<awilkins> His nick says he's having coffee
<lifeless> jam: how important is using FILE* in the scanner?
<igc> ping bialix-coffee
<bialix> igc: good morning
<igc> bialix: morning
<bialix> I hope you sleep well
<igc> very
<bialix> I have 2 news
<bialix> bad and not so bad
<bialix> igc: I think we should leave bzr setup.py as is for 2.0
<bialix> and don't extract py2exe stuff right now
<bialix> good news
<bialix> after battling with buildout all night I've reached the point when bzr and all plugins compiled sucessfully, excerpt tbzr
<bialix> because tbzr require msvc 2008 which I don't have
<bialix> so basically last time inno setup installer compiler blow up on the point when there is no docs
<bialix> igc: so my proposal is just add you chm docs to existing build, add bzr-explorer and ship 2.0
<igc> bialix: sounds good to me
<bialix> igc: and persuade jam to build another rc2 installer from your sources
<bialix> bzr 2.0 is frozen, but your branch is good enough to tweak buildout stuff as needed
<bialix> igc: I should say that despite my ignorance and my skepticism -- buildout is coolthing
<igc> bialix: right, so 2.0 is frozen so we can't change what's in there
<bialix> sidnei and jam are f** geniuses
<igc> bialix: but there's plenty of room for tweaking the code in bzr-windows-installers, adding plugins, etc.
<bialix> igc: I've got successful build of bzr-svn!!!
<bialix> igc: right
<igc> bialix: hooray!
<igc> bialix: the dependency list for building the installer is crazy long still
<igc> bialix: it will be good to gradually improve that - ditch cog as you suggested, etc.
<bialix> you have igc: if you can get access to kerguelen then you can speed up the testing the whole thing I guess
<bialix> s/you have//
<igc> bialix: final builds will happen there
<igc> bialix: I just want to enhance and debug it locally first
<bialix> igc: I've battled with your build.bat until I've realized you commented out some stuff
<bialix> igc: installing things like compiler and pyrex is not hard
<igc> bialix: so can you push your changes?
<bialix> but you can't build tbzr without msvc 2008
<GaryvdM> bialix: Dose qbzr/installer/copy_libs.py get used for the bzr installer?
<bialix> GaryvdM: lemme check
<GaryvdM> bialix: and if so, can you fix Bug #427593
<ubottu> Launchpad bug 427593 in qbzr "installer\copy_libs.py should copy PyQt4\plugins\imageformats" [Undecided,New] https://launchpad.net/bugs/427593
<GaryvdM> ps the lag on my Irc is very bad, so Sorry If don't respond quick
<bialix> GaryvdM: it's wrong bug
<bialix> igc: I have not changed your code yet
<bialix> igc: I've tweaked the things in the build-win32 dir
<bialix> heh, Gary Gary
<bialix> ScoobyDoo, where are you
<bialix> igc: do you have msvc 2008?
<igc> bialix: no, just mingw32 5.1.4
<garyvdm> Hi bialix: Not sure if you got my prevs msg
<bialix> garyvdm: no, copy_libs not used anymore
<garyvdm> Hi igc
<igc> garyvdm: is bug 427586 the one?
<ubottu> Launchpad bug 427586 in qbzr "installer\copy_libs.py crashes if dir missing" [Undecided,New] https://launchpad.net/bugs/427586
<bialix> garyvdm: last message I've got is: [01:42]	<GaryvdM>	ps the lag on my Irc is very bad, so Sorry If don't respond quick
<bialix> garyvdm: I've said: the bug 427593 is wrong
<ubottu> Launchpad bug 427593 in qbzr "installer\copy_libs.py should copy PyQt4\plugins\imageformats" [Undecided,New] https://launchpad.net/bugs/427593
<garyvdm> bialix: Yes that was the last messages sent
<igc> hi garyvdm
<bialix> garyvdm: I fixed installer build stuff in trunk
<bialix> not sure it was backported for 0.14.1
<bialix> garyvdm: I can build installer myself
<bialix> anyway I'm not sleeping yet
<igc> garyvdm: thanks for the recent qbzr bug fixes - qbzr is looking pretty damn good now!
<garyvdm> bialix: I ran installer from trunk
<garyvdm> igc: thanks
<bialix> garyvdm: then look at make_release.txt document
<bialix> it explains how installer built
<garyvdm> bialix: I also used the one from trunk.
<bialix> http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/annotate/head%3A/docs/make_release.txt
<garyvdm> bialix: I have built the installer, I noticed that I does not have the image formats
<bialix> garyvdm: that's right
<bialix> garyvdm: oh!
<bialix> garyvdm: you have installed pygments as eggs???
<garyvdm> bialix: Why is bug 427593 wrong?
<ubottu> Launchpad bug 427593 in qbzr "installer\copy_libs.py should copy PyQt4\plugins\imageformats" [Undecided,New] https://launchpad.net/bugs/427593
<garyvdm> bialix: yes - with easy install
<bialix> because imageformats should be installed not in _libs
<bialix> but in C:\Program Files\Bazaar
<bialix> along bzr.exe
<bialix> garyvdm: then my copy_libs script did not copy pygments
<bialix> because it can't deal with eggs
<garyvdm> bialix: What if that install bzr from source, and qbzr from installer?
<garyvdm> *they (a user)
<bialix> our _libs required only for custom bzr.exe case
<bialix> you can freely omit them
<garyvdm> Bialix: I think it did copy the pygments egg - I'll double check.
<bialix> actually our _libs are used only with bzr.exe. only
<bialix> I can rebuild installer tomorrow if you wish
<bialix> igc: so what is consensus about bzr.exe installer now?
<bialix> igc: do you plan to extend buildout stuff with reciepes for bzr-explorer and chm docs?
<igc> bialix: yes I do
<bialix> if so then I can test it in morning
<bialix> and ensure everything excerpt tbzr are build and packaged correctly
<igc> bialix: great. I'll add the recipes for the new plugins and docs then
<igc> bialix: we can leave tbzr out initially IMO - it's going to be off by default anyhow
<bialix> igc: *my* morning will be after 8 hours
<igc> sure
<bialix> oh
<igc> bialix: my immediate focus this morning will be getting explorer 0.8 out
<bialix> and we should make it actually off by default in installer
<bialix> does it mentioned in todo?
<garyvdm> bialix: I think that my installer is ok. I'
<igc> it should if it doesn't already
<garyvdm> bailix: I'm going to upload it.
<bialix> igc: re explorer: I need update tramslations
<bialix> garyvdm: ok
<jam> lifeless: I would be plenty open to using a callback, etc. I used FILE as a way to have very minimal memory overhead so that you can dump 6GB of data without going OOM.
<igc> bialix: let's do that next week
<igc> I'll call for translations to be enhanced after my changes land
<jam> btw, I have an rc2 built from current sources
<jam> but still waiting on bzr-svn 1.0, etc.
<jam> so I'm not releasing it yet
<igc> i.e. I expect/hope translations to improve between rc2 and 2.0
#bzr 2009-09-11
<igc> bialix: I'll build and upload the latest chm files today - you'll like them
<bialix> jam: while you still here: igc has new special branch for building windows installer
<bialix> igc: maybe it worth to put them into bzr branch
<bialix> it seems I'm in black list of jam
<igc> bialix: we recently agreed on the list that windows packaging didn't belong in the bzr core
<garyvdm> jam: What version of qbzr did you use? I hope 0.14.1
<bialix> igc: I don't understand about translations
<garyvdm> bialix: http://bugs.edge.launchpad.net/qbzr/0.14/0.14.1/+download/qbzr-setup-0.14.1.exe
<igc> bialix: I need to finish and package explorer 0.8
<bialix> garyvdm: please, merge 0.14 branch into trunk
<igc> and put it in new installer
<garyvdm> bialix: I did I forgot to push :-(
<igc> bialix: then we can call for translations
<igc> bialix: then package those translations in 0.8.1 and ship that with 2.0.0
<bialix> igc: if by package you mean cut out tarball then I can do it for you after I'll update translations. or you prefer to release 0.8.1 later?
<igc> bialix: though 0.8 might be called explorer 1.0beta1
<garyvdm> bialix: Done.
<igc> and 0.8.1 might be called explorer 1.0
<bialix> igc: ok, I understand your plan now
<bialix> release 0.8, test installer, release 0.8.1 right before 2.0 final
<bialix> igc: ^ right?
<igc> bialix: my primary focus is getting explorer and chms into installer
<bialix> ok ok
<bialix> garyvdm: jam uses qbzr trunk
<igc> bialix: explorer gets a few 100 downloads each release
<igc> bialix: bzr 1.13 got 35k downloads
<bialix> garyvdm: but now igc's installer stuff will rule the world
<bialix> mwhaa mwhaa mwhaa
<garyvdm> haha
<igc> bialix: so getting explorer 'in the box' is essential
<igc> to ramping up it's adoption
<bialix> igc: ok, I've groked your idea already
<igc> "Bazaar Explorer wins hands down over RapidSVN" - latest quote received overnight
<bialix> ok ok ok
<bialix> hands down?
<garyvdm> igc: will we get a start menu short cut for explorer?
<bialix> it means easy?
<garyvdm> bialix: whats happening with bzrw.exe?
<igc> garyvdm: that's the plan
<bialix> garyvdm: oh! we definitely should create shortcut
<bialix> aaaaaaaaaaaaahhhhhhhhhh
<garyvdm> bialix: "Bazaar Explorer wins *easily* over RapidSVN"
<bialix> there's too much little thing here and there
<bialix> igc: I hope I won't forget all of them
<bialix> garyvdm: thx
<igc> bialix: well I'd be fixing many explorer little things today if I was doing the installer instead!
<bialix> igc: you should be proud
<igc> we should be proud - I'm a small part
<bialix> you wrote most of it
<bialix> ohloh said line count of explorer codebase is roughly the same as qbzr
<igc> bialix: right, but epxlorer is a small part compared to bzr core and qbzr and ...
<bialix> just numbers
<igc> it's just the bit people *see*
<bialix> don't be so shy
 * bialix waits for new quote: bzr-explorer wins hands down over TortoiseBzr
<bialix> :-#
<igc> :-)
<igc> bialix: the bigger question is, does it win over tortoise-hg?
<bialix> so, igc, 2am here, and soon I'm going to sleep.
<bialix> igc: honestly?
<igc> bialix: good night - chat in 8 hours or so
<bialix> yes, +8 hours from now
<bialix> hg beats as almost everywhere -- this is my opinion
<poolie> hello all
<bialix> garyvdm: thanks for releasing 0.14.1
<igc> hi poolie
<bialix> garyvdm: now we should ask for updating karmic?
<poolie> good night bialix
<bialix> poolie: hi and gnight
<garyvdm> bialix: Yes will do
<bialix> garyvdm: you rock
<bialix> igc: you too
<bialix> and sidnei and all all all
<bialix> gnight
<garyvdm> bialix: so do you
<sidnei> bialix: thanks!
<garyvdm> night
<garyvdm> Hi poolie
<poolie> hi
<moldy> hi
<moldy> does bzr have equivalents to submission keywords such as HEAD?
<lifeless> morning poolie
 * igc away from IRC and email for a few hours
<zsquareplusc> moldy: are you looking for this? http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#specifying-revisions
<moldy> zsquareplusc: not quite, i think
<moldy> zsquareplusc: i am looking for an easier way to say "show me the last committed change"
<moldy> zsquareplusc: something like "bzr di -c tip"
<zsquareplusc> then revno:-1 should help
<garyvdm> moldy: bzr log -l 1
<moldy> garyvdm: not quite what i am looking for
<garyvdm> what is di short for?
<moldy> diff
<garyvdm> moldy: bzr diff -c -1
<garyvdm> -1 = tip
<moldy> ok, that works
<moldy> bzr di -c last:
<moldy> works, too :) thanks
<lifeless> jam: using something with a non C-guaranteed backend would be good for testing
<lifeless> jam: e.g. 'anything with write(bytes)'
<igc> poolie: NEWS in 2.0.0 still says 2.0rc2 and 1.18.1 aren't released yet
<poolie> hi
<poolie> on phone
<poolie> in 2.0 or 2.0.0?
<igc> poolie: 2.0.0
<poolie> hm ok, i'll check
<poolie> it might have bounced from pqm
<igc> or I might be brain dead
<lifeless> 1.18.1 isn't something I'd really expect 2.0.0 to mention :)
<igc> poolie: sorry, me brain dead
<igc> lifeless: just in the NEWS file which becomes the Release Notes, of course
<igc> lifeless: chapter tile was "1.18.1 NOT RELEASED YET"
<igc> lifeless: tends to stand out :-)
<lifeless> igc: oh
<garyvdm> Night all.
<poolie> igc: in 2.0.0? i thought i fixed that
<igc> poolie: you did. I just needed to pull your change down locally
<poolie> jam, nice work on Keys()
<poolie> spiv, around?
<lifeless> poolie: call?
<poolie> 1m
<spiv> poolie: I am, although my ADSL apparently may not be :(
<zsquareplusc> is it possible to merge two independent branches into one (i.e. have 2 separate CVS modules converted, that should go together)
<spiv> zsquareplusc: "bzr merge -r0..-1 ../other-branch"
<zsquareplusc> ah, you have to use a range :-) i just tried single revisions. thanks spiv
 * Pilky collapses
<Pilky> if anyone is interested, I've just released version 0.1 of my Objective-C Bazaar API: https://launchpad.net/objective-bzr
<AfC> Endless struggle, release at 4am, die of heart attack.
<AfC> That's always a good sign. Usually good code comes from that.
<fullermd> AfC: So...   good software clogs the arteries?
<AfC> fullermd: Well, you know they gave it their all. Sacrificing for the cause.
<lifeless> so much for non zero sum
<fullermd> Either that, or they didn't want to have to deal with support...
 * igc lunch
<lifeless> jam: bzr+ssh://bazaar.launchpad.net/~lifeless/meliae/strip_duplicates/
<lifeless> poolie: those mails are on my plate, will finish this evening approx; EODing till then more or less, meeting family in town.
<poolie> k
<poolie>     435 class GlobalConfig(IniBasedConfig):
<poolie>     436     """The configuration that should be used for a specific location."""
<poolie> why?
<poolie> that seems like it's not global
<spiv> poolie: "global" in the sense that it's per-user rather than per-branch?
<spiv> I agree that it's confusing.
<poolie> it doesn't seem like it's used for a specific location?
<poolie> leaving aside it being per-user not per-machine
<poolie> or per-planet ;)
<jml> only functions on the Material Plane
<poolie> :)
<vila> hi all
<vila> Can I have some feedback on shell-like tests ? No feedback is hard to interpret...
<poolie> hi vila
<poolie> yes i'll read it today, soon
<vila> poolie: great ! The merge thought will help me in the next half-hour :-D
 * vila-dentist afk for ~1/2h
<poolie> 'mere'?
<poolie> good luck
<fullermd> I hope so.  Combining merge thoughts with dentists doesn't help *ME*...
<poolie> spiv, still around? does bug 427736 mean anything to you? i'm apparently getting xml inventories in what's meant to be a chk stream
<ubottu> Launchpad bug 427736 in bzr ""unknown object type identifier 60" in bencode " [High,In progress] https://launchpad.net/bugs/427736
<bialix> igc: hi again
<poolie> hi bialix
<bialix> poolie: I have question for you
<bialix> and hi
<poolie> hi
<bialix> poolie: I'd like to have some logo for QBzr
<poolie> i mean, sure, go ahead
<bialix> but I'm not very good in computer graphics
<bialix> recent incredible work on b-v.o site redesign makes me think it will be cool to have the help here
<igc> hi bialix
<bialix> poolie: is it possible?
<bialix> igc: so after some hours of sleep I think I should focusing on inno setup installer script improvements
<poolie> bialix: i think so
<poolie> we can probably get someone in canonical's graphic design group to help
<poolie> but they're pretty busy
<bialix> poolie: cool, I have couple of ideas for logo, but then good designer need to improve it
<bialix> heh
<spiv> poolie: it sounds like the bug that jam fixed recently that I encountered doing the inventory streaming work
<poolie> can you send a mail to me and beuno with your thoughts?
<bialix> poolie: it means you're positive but not sure
<poolie> i'm sure they would be happy to help but it might be hard to get to the front of their queue
<poolie> spiv, yes, it does, i thought we'd squashed these though
<spiv> poolie: specifically, that CHK repositories were generating XML inventories when you called some APIs
<bialix> poolie: I can draw by hands and then send my sketch to qbzr ml and cc you and beuno, yes
<spiv> Right.
<poolie> this seems to be the opposite
<poolie> or not precisely opposite
<igc> bialix: the buildout recipes for explorer and the chm files are done now
<poolie> if we can give them the concept it should be faster
<spiv> poolie: well, what are the bzr versions involved?
<igc> bialix: grab rev 7
<spiv> LP is involved, I think, which is probably still running an affected version?
<poolie> spiv, the tip of 2.0 here, and
<poolie> yeah, that may be so
<bialix> igc: so for CHM stuff I think I should add separate items for each language, so users can select what they want to have installed
<spiv> poolie: bzr ping claims lp uses 1.17
<poolie> interesting
<spiv> poolie: which is affected IIRC.
<poolie> :/
<bialix> igc: so we put chm docs in C:\Program Files\Bazaar\docs just instead of old html, right?
<spiv> poolie: yes, IIRC jam fixed this as part of the 'bzr send of 2a' bug, which NEWS says was fixed in 1.18rc1
<igc> bialix: I think so. Either there are directly in the Bazaar directory
 * spiv makes a note of that on the bug
<poolie> thanks
<bialix> igc: so my plan is following: I'm update bzr.iss script for 2.0 and will update buildout receipe to override the one in bzr sources, so installer will be built from our tweaked script
<bialix> igc: post 2.0 we can continue extract things (like py2exe) to your separate branch
<igc> bialix: excellent
<vila> poolie: lol, yeah 'mere' interesting freudian slip :)
<igc> bialix: today i've ...
<bialix> I hope to finish installer during weekend and then we need jam to build new rc installer so I can test it with TBZR
<igc> built the help, updated the TODO and added the recipes for epxlorer/xmloutput/upload and CHM files
<igc> bialix: sounds good
<igc> bialix: I'll work on getting explorer 0.8 done over the weekend - no time for that today
<bialix> igc: so I'll update translations ;-)
<igc> bialix: I've updated the buildout recipes to pull in qbzr 0.14.1 as well
<bialix> ok
<bialix> igc: we need to look at buildout improvements made by jam in bzr.dev/2.0
 * bialix found intermediate result of buildout layout awful
<bialix> last question to bzr experts: is it possible to get overall size of the branch repo (in MiB) via remote dumb/smart transport?
<bialix> this morning I'm thinking about resumable branch/pull/push
<igc> bialix: time to go - family stuff to do for next few hours
<bialix> I can write simple hack to pull in small portions
<bialix> igc: bye
<igc> bialix: thanks for your help!
<igc> poolie, spiv, vila, all: have a good weekend
<igc> night all
<poolie> igc, you too!
<vila> igc: g'night and good week-end !
<poolie> spiv, in this kind of case i'd like to teach bzr to blacklist that op on that server
<bialix> ditto from me
<poolie> on 1.17 i mean
<bialix> poolie: what is correct branch for 2.0rc2? lp:bzr/2.0 or some other?
<vila> bialix: I think you need to get the size of the packs, I don't remember an API for that (and that will still not get you the size of the indices...)
<bialix> poolie: or https://code.launchpad.net/~bzr-pqm/bzr/2.0.0?
<poolie> bzr/2.0.0
<poolie> see my mail 'branchs, bugs... 2.0'
<vila> bialix: lp:bzr-repodetails certainly contains interesting stuff in that regard
<bialix> ok
<bialix> vila: can I talk with you about my idea with plugin of resumable pull/push?
<vila> bialix: hmm, it you want to make it a plugin, then I think the effort will be better spent making the core resumable,
<vila> what accidental scenarios do you want to address ?
<bialix> pulling/pushing a very big branches is several steps automatically
<vila> can they be recognize by bzr and acted upon (ctrl-C, network connection loss sound possible to address)
<bialix> so if connection breaks or just time out user can resume it later
<bialix> s/is several steps/in several steps/
<bialix> last night there was mini discussion about resumable pull in core
<vila> bialix: I understand the approach, I'm wondering about what could be done in core to make it useless :)
<vila> Oh, I missed that then
<bialix> the short answer: bzr would like to do it but can't
<vila> oh, ok, I'm late in the game then ;)
<bialix> can't today because it's not clear how ideal solution should work
<bialix> vila: you can check irclogs from the point when we started talking about git
<bialix> jam, lifeless and jelmer talking
<vila> I will do that later eventually, or do you think I need to read it to talk about your plugin ?
<bialix> something about atomic insert prevents to have it in the core
<vila> bialix: Hmm, I can imagine it's not trivial, especially with gc
<bialix> well, basically I want to talk my idea and have someone who listen and critize
<vila> bialix: shoot then :)
<bialix> criticize
<bialix> you already started doing this ;-)
<bialix> so main idea is automatically get last_revision info from remote repo and then divide pull into smaller steps
<vila> right, but if it can't be done in core, then pulling by steps is the next best thing
<bialix> like pull by 100 revisions at once
<bialix> I'm just would like to know the size of remote repo
<bialix> not only number of mainline revisions
<vila> bialix: I would go with a simple --step parameter and leave the user in control (use 128 or 256 as default value)
<bialix> hmm, maybe
<bialix> just for fat branch of 200 revisions and overall repo size of several GiB I'd like to step in smaller delta
<vila> I think there are too much criteria to take into account to make educated guesses: repo size, bandwidth, latency, connection quality, server robustness, server load, etc
<bialix> yep
<vila> so in the end, only the user, at a given time (and even...) can roughly guess what is the "right" step
<bialix> well, I imagine such plugin can measure how long each steps and then do some prediciton?
<fullermd> It seems like with the current structure it would be hard to work in granularities other than revision.
<vila> What you can add, though. is say: if it doesn't complete in 5mins, break it and try again with a smaller --step
<bialix> vila: actually I've struggled last night with buildout and its desire to get fresh copy of bzr branch from lp
<fullermd> (though there are *BIG* advantages to being able to do so, even aside from this incremental question)
<vila> fullermd: A balance between #revisions, elapsed time, yes
<bialix> vila: so some sort of auto adjusting of step will be nice, so I can have stepped-branch command aliased to plain branch and use it automatically all the time
<fullermd> Yah.  But as long as things currently work as they do, when the bulk of the size is the 5 gig first revision, nothing will help.
<bialix> vila: to use it with tools like buildout
<vila> bialix: I encounter such problems with the botnet and had to set the timeout to 1h and use a shared repo (where possible)
<bialix> fullermd: yes
<vila> fullermd: sure
<fullermd> (luckily, that's relatively rare)
<vila> fullermd: and then the answer is: Don't do that !
<fullermd> That's too facile an answer in the DVCS world sometimes   :|
<bialix> vila: also about stepped-branch: I should branch exactly one revision from remote to get correct branch/repo format and then start stepped-pull
<vila> Frankly, who will try to use Mosiac to go to say.. Facebook ?
<fullermd> Dunno.  Why would you use ANYTHING to go to Facebook?
<bialix> fullermd: vila: lol, I never laughed so loudly from your Mosaic experiments
<vila> fullermd: I hate that answer, but sometimes that's the only reasonable one, see example above
<bialix> fullermd: while you're here: do you plan to build 1.18.1 package for bsd? I want to update bzr on my hosting
<vila> bialix: There is a very serious idea behind these experiments nevertheless ... backward compatibility
<fullermd> With 2.0 so close, and the major change being on Windows, I hadn't planned to.
<bialix> fullermd: ok, so I'm stick with 1.18
<fullermd> Wait...  there was serious reason behind it?  I was just doing it for S&G...
<vila> bialix: you use FreeBSD on your hosting ???
<fullermd> Why stuck?
<vila> S&G ?
<bialix> well, my hosting provider run freebsd
<bialix> wair a sec
<fullermd> (i.e., why wouldn't 2.0 be good 'nuff?)
<bialix> fullermd: how can I get os version?
<fullermd> uname -a
<bialix> from command-line
<vila> bialix: uname -a
<vila> :-D
<fullermd> vila: Shi...   stuff & Giggles
<bialix> FreeBSD donkey.tophost.com.ua 6.2-RELEASE-p9 FreeBSD 6.2-RELEASE-p9 #1: Thu Jan  3 17:39:10 EET 2008
<johnf1> poolie: do you want me to repush that branch or did you merge it another way?
<vila> fullermd: So, 'uname -a' tells you about the base system, but what about ports ?
<fullermd> Well, there isn't a "ports version"; there are only versions of individual ports.  So you'd have to look at the ones you care about.
 * vila frowns
<vila> fullermd: I was expecting better :-/
<bialix> vila: repodetails plugin does not work for lp:bzr
<bialix> vila: should I file a bug?
<vila> bialix: certainly
<vila> bialix: it's very surprising given it has been developed *for* bzr.dev and used mainly there
<spiv> poolie: 2.0 does blacklist that op
<vila> s/*for* bzr.dev/& first
<fullermd> Well, I guess you could import the ports tree from CVS into bzr and use the head's revno as some sort of overarching version...  not sure what information that would actually communicate though.
<bialix> AssertionError: Don't know how to process RemoteRepository(bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/)
<vila> fullermd: some sort of equivalent of the distros releases
<spiv> poolie: or rather, it will give a UnknownMethod response to that particular request because it knows the client won't be able to use the stream.
<vila> bialix: ha right, use sftp then
<fullermd> I mean, what does "ports version" matter; you care about what version Apache or Firefox or bzr is.
<vila> fullermd: a single data point is easier to grasp
<fullermd> Well, if he's got bzr 1.18, I'm confident he doesn't have a ports tree shipped with 6.2   :p
<vila> even if (of course) less precise
<vila> fullermd: sure, don't pretend you didn't understand my question ;-)
<bialix> vila: https://bugs.launchpad.net/bzr-repodetails/+bug/427751
<ubottu> Ubuntu bug 427751 in bzr-repodetails "`bzr repository-details lp:bzr` fails" [Undecided,New]
<Lo-lan-do> Someone correct me if I'm wrongâ¦ with bzr's 2a format, performances for the long operations are more CPU-bound than I/O-bound, right?
<Lo-lan-do> (Not talking start-up time here)
<bialix> vila: use sftp then is not option sometimes
<vila> Lo-lan-do: ETOOGENERAL
<fullermd> vila: I'm not sure I really _do_...   what are you looking for?  "$DATE of last time I updated my ports tree"?
<Lo-lan-do> vila: Fair enough.  Let's restrict to "bzr check", for instance.
<fullermd> Most of my long bzr operations have been CPU-bound since 0.6.2...
<vila> fullermd: somethinh like that yes, "Is it a two years old install or a recent one"
<vila> Lo-lan-do: still a bit hard to answer :-/ Let say that most of the operations are faster and the repositories smaller than with previous formats
<Lo-lan-do> I'm probably going to recommend a nightly or weekly bzr check at a client's if IÂ can get them to switch to bzr, but since they have large (CVS) repos it may take some time.
<vila> From there, we do less IO, so it doesn't always translate into more CPU
<fullermd> Yeah, I don't think of check as IO bound.  I've got repos under 20 megs that take several minutes to check; might be IO bound on a floppy, but...
<bialix> vila: and last one about stepped operations: I can save result of latest step in the branch.conf so user can use stepped-continue to continue. something like rebase doing. does it sound as more or less make sense?
<vila> bialix: as long as user can still override from command-line, yes,
<bialix> override what?
<vila> the branch.conf value
<bialix> why for?
<Lo-lan-do> Good.  Next question: when working in bound branches (or pushing to a bzr+ssh server), most of the CPU-intensive stuff is avoided on the server, right?
<vila> but are you sure you will always have a branch.conf to start with ?
<Lo-lan-do> And the shared repo on the server "only" has to repack from time to time?
<bialix> vila: I mean I've pulled 200 revs from 100. I save this counter and name of operation (pull). Then run `bzr stepped-continue` to continue
<bialix> vila: yes, for stepped-branch is most logical step is to create local branch with 1 revision inside
<bialix> vila: so basically stepped-branch op is: branch REMOTE_URL -r1; bzr stepped-pull
<vila> bialix: that sounds fine with standalone brances, but what about shared repos ?
<bialix> and what about shared repos?
<bialix> bzr working at branch level
<bialix> shared repo is behind the scene
<bialix> stepped-pull will be like this: for i in range(1, LAST_REVNO, STEP): bzr pull -r i..i+STEP
<bialix> stepped push is similar
<vila> bialix: with shared repos stepped pull makes more sense for the revisions you don't have yet
<bialix> vila: is not they will be skipped automatically?
<bialix> vila: I have good results of invoking run_bzr and run actual CLI bzr commands (in scmproj) for doing stuff
<bialix> vila: I'd prefer to not dive into bzrlib API
<bialix> then I can write such stepped plugin very quickly
<vila> bialix: they will succeed by virtue of not involving problematic operations :)
<bialix> I'm not quite understand, can you re-phrase?
<bialix> vila: ^
<vila> If I branch bzr.dev in a shared repo and bzr step-branch 2.0, almost all revisions are already in the repo
<vila> most of the steps can't fail since there is nothing to pull
 * bialix bbl, sorry
<vila> bialix: You may well ignore that
<vila> Right, google calendar unreachable for more than 2 hours, imminent death of the net ?
<Kamping_Kaiser> mine works </unhelpful>
<vila> Damn, no, same mistake than a couple of days ago: when *redirected* to an error page, *don't* hit refresh :-(
<Lo-lan-do> Only the part of the net whose users think google==net
<fullermd> Wait...  you mean Google isn't the whole Interblog?
<vila> Lo-lan-do: you mean you're not aware that Google owns most of the black fiber ?
<Lo-lan-do> I use yoghurt cans and string for my Internetz.
<fullermd> Oh, no wonder you come through all muddled.
<fullermd> You gotta stick with coffee cans, man.
<Lo-lan-do> A bzr check tells me I have 7 inconsistent parents.  Should I worry?  Could bzr reconcile fix that?
<fullermd> I'd have a little chat with Mom and the mailman, myself...
<fullermd> But yah, reconcile fixes that.
<Lo-lan-do> (I've learned that ghost revisions can be safely ignored so IÂ won't bother you about that)
<Lo-lan-do> Here goes a reconcile then.
 * fullermd still wishes the two could be combined.
<fullermd> I want a combination check/reconcile/pack/garbagecollect, so I can fire off a "bzr makemybranchallneatandtidy" before I go to bed, and wake up knowing that it's as good as it can be.
 * Lo-lan-do concurs
<Lo-lan-do> Um.  There's a garbagecollect now?
<fullermd> Well, no.  That's one reason I want it   :p
<Lo-lan-do> Ah.
<Lo-lan-do> I had started working on it at FOSDEM with one of you guys, but it never went anywhere.
<Lo-lan-do> I forget who it was, possibly Odd_Bloke.
<fullermd> Sure wasn't me.  I don't do python.  Or FOSDEM, for that matter.
<bialix> fullermd: ping
<Lo-lan-do> Blah. After a bzr reconcile, I no longer have inconsistent parents, but I still have a few sha1 mismatches.  Any way to fix that, or is my repo seriously corrupted?
<Lo-lan-do> It seems they're all on revisions coming from svn. I'll see if I can get rid of them by doing a fresh checkout.
<garyvdm> Hi vila
<vila> hey garyvdm !
<vila> garyvdm: your example in #427773 is bogus, what we care about is how we end up with a limbo dir :)
<vila> oh, right, there is a cascading bug too
<vila> but let's search the root cause anyway, this should never happen and identify a real problem
<Lo-lan-do> Is there a way to find out exactly where in the DAG ghost revisions are?
<garyvdm> vila: Please can you give me a pointer. I want t write a test for bug 427773. I want to run bzrlib.merge.Merge3Merger.do_merge with a limbo dir, and check that it unlocks.
<garyvdm> vila: I'm not sure where to put this test, and should I test other Merger classes?
<ubottu> Launchpad bug 427773 in bzr "empty limbo dirs prevents to successful execution of bzr commands and left working tree locked" [Undecided,Confirmed] https://launchpad.net/bugs/427773
<vila> garyvdm: can you read me ?
<jam> garyvdm: when I was playing with building the installer 1.14.1 didn't exist yet. I'll certainly use it for the final rc2 build
<jam> morning vila
<vila> morning jam !
<garyvdm> vila: Hi
<vila> garyvdm: can you read me ?
 * vila thinks garyvdm has net problems that makes this channel a write-only medium :-/
<garyvdm> My irc is very flaky
<garyvdm> vila: I think I know what is causing bug 427773. I'm writing a test to confirm it.
<ubottu> Launchpad bug 427773 in bzr "empty limbo dirs prevents to successful execution of bzr commands and left working tree locked" [Undecided,Confirmed] https://launchpad.net/bugs/427773
<vila> garyvdm: Good
<vila> garyvdm: I'm still interested by what *caused* the limbo dir creation
<vila> garyvdm: but no need to leave the branch locked, so your fix will be welcome anyway
<ChrisW> Does TortoiseBzr form part of the linux and macos distributions of bzr?
<vila> ChrisW: Nope, it's a windows only thing
<vila> ChrisW: bzr-explorer is considered a better alternative, and that is available (or shoudl be) for all platforms
<ChrisW> meh, I desktop integration... guess I'll look at TortoiseHg instead ;-)
<vila> haa, nothing like a good and opened discussion.... :-/
<Pilky> lol
<Pilky> vila: if he waited a few days i'd have a 0.1 of a native Mac client out
<Pilky> his loss :p
<vila> Pilky: tortoisebzr on mac ? great ! Is that a fork of the existing lp project or do you sync with naoki ?
<Pilky> heh not tortoisebzr
<Pilky> completely new client from scratch
<jam> james_w: are you looking into why the ppa builds started failing?
<Pilky> one I tried starting ages ago but gave up on
<vila> Pilky: a standalone app then ?
<Pilky> yep
<Pilky> I release 0.1 of an Objective-C framework for talking to bzr last night, I'm working on 0.1 of the app this weekend
<vila> Pilky: he said disktop integration and by this I think he meant finder-integration in mac vocabulary
<Pilky> yeah
<Pilky> probably
<garyvdm> Hi vila. Sorry - my irc is very flaky, so I am now using http://www.web-irc.org/..
<jam> igc: are you still around?
<igc> hi jam
<jam> hey igc
<jam> you know, you should really sleep... but since you are up
<garyvdm> vilia: I saw what you said here: http://irclogs.ubuntu.com/2009/09/11/%23bzr.html
<jam> the ppa builds are failing with: cp: cannot stat `debian/tmp/doc/_static/en/quick-reference/bzr-quick-reference.pdf': No such file or directory
<jam> do you know what changed there?
<igc> jam: yep :-)
<igc> name is now ...
<igc> bzr-en-quick-reference.pdf
<vila> garyvdm: I also said (later): your fix is good, we want your fix :)
<igc> jam: if you look in http://doc.bazaar-vcs.org/test/downloads/pdf-en/ say, you'll see ...
<igc> that all the pdfs use that convention so I tweaked the quikc refs to follow it too
<garyvdm> vila: Ok - did not see that - thanks
<garyvdm> vila: Are the tests ok?
<vila> garyvdm: I don't know, I've yet to see your patch, I was talking about the principle of your fix
<vila> garyvdm: we want your fix AND we want to understand why bialix encounter the problem in the first place
<vila> i.e. what is the 'mkdir limbo' in his case
<garyvdm> vila: I see.
<vila> garyvdm: pew, finally :-)
<igc> ChrisW: bzr-explorer is shipping on windows, gnome, kde and os x and working well on each
<vila> igc: He left...
<garyvdm> vila: My fix is here: https://code.edge.launchpad.net/~garyvdm/bzr/Bug427773/+merge/11601
<igc> vila: thanks
<vila> igc: and he want desktop integration aka tortoise and nothing else (that's how I understand him at least, since he didn't stay to say)
<igc> vila: ok
<jam> vila: the bug gary posted, I believe the original 'mkdir limbo' was a bzr merge that got interrupted by a power outage
<jam> at least, from his follow up post
<jam> if updating the workingtree fails badly, we leave stuff like limbo around
<jam> it doesn't happen often anymore, since we can rollback for stuff like symlinks, name collisions, etc.
<jam> but I would assume there are still possibilities
<vila> jam: really badly then because it's been a while since I encountered it for the last time
<jam> vila: it has to be an unhandled exception, yes
<jam> and we handle a lot
<vila> garyvdm: wow, that's TDD....
<garyvdm> vila: :-)
<vila> The nice thing is that I don't have to understand what you fixed and where you fixed it. The test are short and clear enough to demonstrate that you diagnosed the problem, had them failed, fix the problem, had them pass. So since PQM will catch you if you cheated, I can just approve :-D
<vila> garyvdm: Add a NEWS entry !
<jam> garyvdm: so the problem was that after the failure the WT was still locked?
<vila> jam: yup
<vila> *left* locked
<jam> garyvdm: it helps to say that in the merge proposal
<jam> though apparently vila has been following on enough to already know
<vila> garyvdm: jam is right, I knew from following the bug comments, but it helps all reviewers to summarize
<vila> garyvdm: the NEWS entry can partly address that too :)
<jam> igc: your change seems ok. I'm wondering what the packaging bug is, then.
<jam> is it something in Make that is talking about the pdf, or is it a debian/* directory issue
<vila> jam: some MANIFEST file checking file presence ?
<jam> vila: My gut feeling says it is a bug in the packaging script
<jam> which as you say, is something like MANIFEST
<Lo-lan-do> Hmmm. Since there's no after: keyword in revisionspecs, is there a way of getting a log of stuff that happened after a given revid?
<vila> revid:<revid>..
<Lo-lan-do> This includes the given revid.
<Lo-lan-do> I'd like to get stuff that happened strictly later than that.
<Lo-lan-do> (For a commit hook)
<vila> Lo-lan-do: err, why do you want to use a revspec if you're already in a commit hook ?
<vila> Lo-lan-do: What are you trying to get your hands on ?
<Lo-lan-do> I don't understand the question.
<vila> Lo-lan-do: me neither :) Let's try again
<vila> Lo-lan-do: What are you trying to get your hands on ?
<Lo-lan-do> Trying to run "bzr log -r $old..$new$ and not get $old listed
<vila> in a commit hook ???
<Lo-lan-do> In a shell script that'll be run by a commit hook, yes.
<Lo-lan-do> Think commit emails, for instance, or triggering builds, or whatever. I want to keep the genericity of just calling a $repo/.bzr/hooks/post-commit script.
<vila> right, why not stay in your commit hook in python where you can call bzrlib.log.show_branch_change for example ?
<vila> def show_branch_change(branch, output, old_revno, old_revision_id):
<vila>     """Show the changes made to a branch.
<vila>     :param branch: The branch to show changes about.
<vila>     :param output: A file-like object to write changes to.
<vila>     :param old_revno: The revno of the old tip.
<vila>     :param old_revision_id: The revision_id of the old tip.
<vila>     """
<igc> jam: fyi, reasonable progress on the new windows installer today
<Lo-lan-do> I want to keep the external shell script, because it may be used for other things than commit emails.
<jam> igc: good to hear
<igc> jam: I'm packaging explorer 0.8 this weekend and bialix is making innosetup and py2exe related fixes so everything should be good for  ...
<igc> packaging on Windows by Monday your time
<jam> igc: any chance to do it sooner? I'd like to have a full build for the guys in Canada
<jam> and I'll be flying early monday morning
<jam> if not, no prob, I'll survive
<igc> jam: ping bialix and check
<igc> jam: I lack the expertise to make all the required installer changes
<igc> jam: though the buildoutv recipes are now done and more-or-less working
<jam> igc: I'm more concerned about bzr-explorer
<garyvdm> vila: I've updated news. Please will you submit to pqm.
<igc> jam: so bialix hopefully has enough to tweak py2exe and the iss file from here
<igc> jam: ah, ok
<vila> garyvdm: you need a second vote :)
<igc> jam: I'll see how I go
<garyvdm> vila: ok - Not sure how to get launchpad to update the diff, with out loseing your review.
<igc> night all
<vila> garyvdm: you can't
<vila> jam: care to have a quick look at  https://code.edge.launchpad.net/~garyvdm/bzr/Bug427773/+merge/11601, I'll merge if you approve
<vila> garyvdm: also, naming your branches 427773-unlock-when-limbo instead of just Bug427773 helps
<jam> vila: approved
<vila> jam: thks
<vila> garyvdm: pqm'ed
<garyvdm> vila, jam: Thanks
<vila> garyvdm:  thanks to *you* :-D
<garyvdm> vila: As it's a simple bug fix, should I submit it for 2.0?
<vila> garyvdm: since it isn't  a regression, no
<garyvdm> vila: ok
<garyvdm> bbl
<jam> vila: simple bugfixes are expected for 2.0
<jam> for the 2.0.1 stuff
<jam> as long as it isn't an api change
<jam> I think it should land for 2.0.1
<jam> garyvdm: ^^
<vila> >-/
<jam> the point of the 2.0.x series is "bugfixes without features"
<jam> regardless regressions
<jam> vila: though it is a "feeling" thing
<jam> that we will have to tune with time
<jam> we can always "ask poolie" :)
<vila> my gut feeling is that we'd better keep the regression rule in place...
<vila> or we'll be back-porting everything, or am I already contradicting myself regarding spiv recent case....
<jam> vila: spiv's is a code cleanup
<jam> I'm 90% sure we aren't keeping the regression rule
<jam> regression rule is for the "what do we backport for an rc"
<jam> bugfixes get done on the stable branch
<jam> the whole point is to give people bugfixes without features, not having to do with regressions
<vila> I really need to draw myself a picture with release numbers and associated dates :-/
<jam> vila: well, 2.0.1 is likely to come out the same time as 2.1.0b1
<jam> with 2.0.1 == bugfixes only, 2.1.0b1 == bugfixes + features
<vila> and we'll merge 2.0.x in 2.1 regularly then... I still have a feeling that we shouldn't need a 2.0.0 branch....
<vila> 2.0 and 2.1 have to be enough or something escape me
<jam> vila: we need 2.0.0 branch so that I can land patches for 2.0.1 before 2.0.0-final is out
<jam> rc2 has been cut
<jam> which means 2.0.0 is imminent and bugfixes shouldn't land there
<jam> regressions can
<vila> land them to 2.0.1 then !
<vila> or wait for 2.0 to be out....
<vila> that's the part I'm  missing...
<vila> sounds like more troubles than benefits, but well, it may just be that I don't look at it from the right POV
<vila> and I'm grumpy because I can't find some notes I took a couple of weeks ago, so there !
<jam> vila: well, if it helps, there is no 2.0
<jam> it will be 2.0.0
<jam> lp:bzr/2.0 == the 2.0.x series
<jam> which *was* 2.0.0 until the 2.0.0rc2 was cut, when we started a new branch
<jam> the same as 'trunk == current series' and we create a new branch at rc time
<vila> yes, I liked that branch, do you mean that we will just use lp:bzr/2.0.x from now on ?
<vila> Then, yes, it helps
<jam> Arguably it would be clearer if the branch was explicitly called "lp:bzr/2.0.x" rather than "lp:bzr/2.0"
<jam> anyone know the magic attributes to tell gcc that a function is a "printf" style function, and it should check the % codes?
<vila> jam: http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Function-Attributes.html
<vila> extern int
<vila>           my_printf (void *my_object, const char *my_format, ...)
<vila>                 __attribute__ ((format (printf, 2, 3)));
<jam> vila: thanks
 * vila bounces to jam and google :-D
<vila> haaaaa, found them !
<jam> vila: you have some 64-bit machines at your disposal, right?
<vila> jam: yes, karmic or jaunty
<jam> can you do: "bzr co lp:meliae; cd meliae; py setup.py build_ext -i; py run_tests.py" ?
<vila> jam: Ran 101 tests in 0.027s
<vila> OK
<vila> s/py/python/ first :)
<jam> gotta love that 27ms
<jam> vila: I always alias py => python
<jam> mostly because on Windows it is
<jam> /cygdrive/c/Python26/python
<jam> which is crappy to type
<vila> :-D
<vila> how long does it take to run for you ?
<jam> 0.031s
<jam> on my laptop
<jam> vila: any compiler warnings?
<vila> __Pyx_GetItemInt and __Pyx_SetItemInt defined but not used
<vila> for _loader.c and _intset.c
<fm> is there a way to generate a patchset with bzr. i.e. i want to add a special formated comment and then export the last n revisions as patches ....
<jam> vila: you probably need a newer pyrex :)
<vila> jam: :-P
<jam> fm: you might look at 'bzr send'
<jam> bzr send -o filename
<jam> can put the data into a file
<vila> or log -p
<jam> but it generally exports all-at-once, not one patch per rev
<fm> but i'd like one patch per rev.
<vila> fm: log -p
<luks> fm: it's not supposed to be applied to a bzr branch?
<fm> vila: looks great
<jam> fm: for i in `seq A B`; bzr send -o filename.$i -r before:$i..$i; done
<vila> fm: care to explain your use case ?
<jam> fm: depends whether you want something that we can "bzr merge $YOUR_PATCH"
<jam> or whether you just want to send it to someone to look over
<fm> i am collaborating with people on a translation project. and they do not use version control systems. the patches are discussed by email. the target repository is an svn repository. but most patches are attached in pieces (my local revs) into a bug tracking system.
<fm> jam the for loop was my idea, but i thought there must be something prettier ...
<fm> in a perfect world i could modify allready committed versions ;)
<vila> fm: may be you want a branch for each of your patches instead and *then* you can use send and all its goodies :)
<fm> the translations files are huge (40.000+ lines). and i create patches by topic to be easier to review. a patch just doing simple spelling mistakes. then one correcting spaces. and others changing some "meaning"
<fm> vila: is is possible to "restack" branches as i do not know in which order the patches are applied in advance. they should not conflict ...
<fm> is it possible to "restack" branches?
<vila> fm: they do overlap ?
<fm> vila: they might
<vila> do you use bzr-svn >?
<fm> vila: no
<fm> i do not have any access to the server. i.e. i must contribute in patch form
<vila> ok
<vila> I don't have a really good answer, the problem is that you're working without connection to the svn server, at least having a mirror of that server locally (with bzr-svn) may help you find better workflows
<vila> using bzr should help you remove that " they should not conflict" constraint, if they conflict you can easily solve the conflict locally and then submit updated versions
<vila> otherwise, the short answer is 'log -p'
<fm> but log -p does not allow me to modify later if i missed a string.
<vila> short of (uncommit, shelve) dance until you get to the proper patch, no
<vila> followed by (unshelve; commit) dance, but you'll tired of dancing soon
<vila> an alternative is loom or maybe pipeline (I don't use the later)
<vila> but I'm unclear about 'log -p' will work there, you may want to add a '-n[123]' there and find the good one
 * vila EODing with a violent headache :-/
<fm> i want to have a branch changing "get" to "got" and another one changing "car" to "vehicle". now i want to be able to reorder in which order they have to be applied to the base.
<fm> as there might be a line containing get and car. or at least in the three lines before and after
<exarkun> I cannot commit to my newly created bzr branch.
<exarkun> bzr: ERROR: Permission denied: "rynyps2dbs221zpo09ag.pack": [Errno 13] Permission denied: '/data/.bzr/repository/upload/rynyps2dbs221zpo09ag.pack'
<exarkun> bzr version 1.17
<exarkun> It is certainly true that I lack write permission to /data
<exarkun> But I don't know of any good reason why write permission to that directory should be required.
<exarkun> Why does this happen?  How can I fix it?
<exarkun> Did I leave something important out that makes it difficult to answer?
<luks> is your branch somewhere under /data?
<luks> or perhaps under a directory symlinked leading to /data?
<luks> if you create a new branch, it will go up to / looking for a repository to use
<exarkun> My branch is beneath /data, yea
<exarkun> How do I stop it from going up looking for a repository?
<exarkun> And how do I undo creating the branch?  Just delete the .bzr directory which was created?
<luks> create a new repository
<luks> yes
<luks> (bzr init-repo)
<exarkun> Thanks, that worked.
<Lo-lan-do> Maybe bzr should only go up to / looking for a *usable* repository, and fall back to . if none is found?
<exarkun> I guess that figuring out what "usable" means is finicky and fiddly.
<jam> lifeless: I merged your streaming changes, though I had to make a bunch of tweaks to make sure it support python 2.5 and windows peculiarities
<jam> We should probably split up files.py a bit more and have more direct testing
<jam> otherwise if you have gzip it doesn't test the code path without it, etc.
<fm> vila: how are patchsets like the ones sent to the linux kernel mailing list created?
<garyvdm> Yhay - I finally got a decent internet connection.
<Tak> is there a bisect plugin?
<Pilky> Tak: https://launchpad.net/bzr-bisect
<Tak> nice, thanks
<Pilky> AFAIK most plugins for bzr are listed here: http://bazaar-vcs.org/BzrPlugins
<Pilky> so that's the best place to look if you want something
<jam> fm: 'bzr log -p' is not much like the kernel patchsets, which have the embedded data to recreate the git repository
<jam> 'the result of 'bzr send' does have the ability to recreate the data
<fm> jam i guess quilt is what i want
<jam> fm: the general bzr equivalent is 'bzr-loom' or 'bzr-pipeline'
<jam> which is the same idea of preparing a series of patches
<fm> just looking at the pipeline ,)
<jam> but does it without 'throwing away' as much history
<jam> Pilky, Tak: There is also: https://launchpad.net/bazaar which is the list of projects under the Bazaar banner.
<fm> http://bazaar-vcs.org/BzrPipeline sounds good
<Tak> cool, thanks
<fm> is there anything for pipeline or loom, they seem quiet similar
<jam> fm: They are roughly similar, but store things on disk a bit differently
<fm> hopefully i do not have to edit the on disk format ...
<jam> fm: Sure.
<jam> bzr-pipeline works 'with regular branches' while 'bzr-loom' works with a custom branch format
<jam> I'm not sure if that means much to you now
<jam> but it means that the individual bits that you are working on
<jam> can be more directly accessed in 'pipeline'
<jam> (they have a path on disk, for example)
<fm> which will still be maintained in two years?
<jam> fm: which ever one stays possible
<jam> from current PoV, both
<fm> are these plugins used by any "big" project?
<jam> fm: Both are used by developers hacking on Launchpad
<jam> and Bazaar
<jam> what do you consider "big"
<jam> Though from my understanding of the internals, neither should have any trouble scaling
<fm> jam big was more about the project than the files. just was interested how others decided between the two. but i guess i will look at both
<jam> fm: Well, abentley was the one who put together pipeline to work on Launchpad because he wanted 'more direct access' than loom gave him
<jam> as such, he's started getting more people in Launchpad using ti
<jam> it
<jam> 'loom' was around earlier though
<jam> so I don't know how many users of each
<jam> if *I* was choosing, I would go with pipeline probably
<jam> it is closer to how I already work today
<Pilky> is there a way to find out whether a Repository object is representing an actual repository or a standalone branch?
<Pilky> besides checking if it returns 1 branch url from find_branches() and that url is the same as the repo
<Pilky> ah found it, was looking for is_shared()
<fm> bzr: ERROR: add-pipe should be run in a lightweight checkout.  See bzr help pipeline for details.
<jam> Pilky: yep
<fm> i have a local repo created with a simple bzr init. what is the difference of a lightweight checkout?
<jam> fm: bzr init-repo --no-trees repo; bzr init repo/branch; bzr co --lightweight repo/branch working_tree; from there "add-pipe"
<fm> bzr reconfigure should do if i am reading correctly
<jam> it should
<fm> http://how-bazaar.blogspot.com/2009/07/breaking-up-work-for-reivew.html
<fm> what do i loose by going leightweight?
<fm> no local history?? that is why i use bzr instead of my svn repo ....
<jam> fm: if you have a 'bzr init-repo' you still have the data locally
<jam> just not in the working tree itself
<jam> mostly you just gain flexibility
<jam> as the working tree can point at multiple branches
<hsn> you cant pull from 2a into 1.9 repo?
<jelmer> hsn: only into a 1.9-rich-root repo
<jelmer> hi SamB
<SamB_XP> jelmer: hello
<garyvdm> Hi pygi.
<pygi> hi garyvdm
<pygi> how are you doing my friend?
<garyvdm> pygi: At uds, you were running WinXP inside you desktop environment. How do you do that?
<garyvdm> pygi: Good and you?
<pygi> garyvdm, virtualbox
<pygi> garyvdm, could be better, folks at uni are bugging them
<garyvdm> pygi: thank you. I'm maintaining a website written in .asp, and so I have to boot into windows to often :-(
<garyvdm> Hi Jelmer
<jelmer> hi Gary
<pygi> garyvdm, I understand the problem. Virtualbox seems like an adequate solution for the problem
<garyvdm> jelmer: Do you know of any plugins that implement commit_message_template hooks? (I know of bzr-builddeb)
<jelmer> garyvdm: bzr-builddeb is the only one I know of as well
<garyvdm> jelmer: Ok - Thanks
<pygi> garyvdm, any cool things you've done recently? :)
<garyvdm> pygi: No - just lots of bug fixing.
<pygi> awww
<pygi> at least you did more then me :(
<pygi> my uni is amazingly bugging me
<garyvdm> pygi: Work hard! I all ways regret that I never finished at uni.
<exarkun> Party hard.  There's plenty of time for work later.
<pygi> exarkun, hardly. I'm in a bad enough situation already.
<exarkun> pygi: Nothing that some more partying can't solve, I'm sure!
<pygi> garyvdm, yes, I will. But I also need to fix some stuff in bzr-gtk :P
 * pygi looks at vila 
<fullermd> Forget work and party.  SLEEP hard; there'll be no time for it later.
<garyvdm> pygi: Not a day goes by that I don't think about creating a gtk qbzr port (gbzr...)
<pygi> garyvdm, what's the point? :D
<pygi> I don't care about toolkits war xD
<fullermd> Well, once you've got gqbzr, you can port it to Motif, see...
<garyvdm> pygi: neither do I, but there are lots of people that won't use qbzr because its written qt.
<pygi> garyvdm, why do we even market it as such? :)
<pygi> lets call it something else, so most won't even notice :p
<pygi> fullermd, :D
<garyvdm> pygi: My idea is that gbzr would be a branch of qbzr. When new features get added to qbzr, then you merge qbzr into gbzr, and port the changes.
<garyvdm> When I have time....
<pygi> garyvdm, my opinion, which doesn't matter too much in this case, is that doing that is a waste of resources
<lifeless> jam: I agreee
<lifeless> jam: (re split ups and testing etc)
<pygi> garyvdm, limited resources, while we're at it
<garyvdm> pygi: but that would be less work that maintaining qbzr and bzr-gtk
<garyvdm> *than
<pygi> garyvdm, possibly
<garyvdm> Any way - It's just a crazy idea in my head. I think I'm destined to just think about it, but never start for ever.... :-p
<zsquareplusc> what is it in bzr-gtk that has a state? after a fresh login, it always fails with an exception when i run the 1st command and any successive run works :/
<jelmer> zsquareplusc: it's a bug in seahorse
<pygi> garyvdm, we might talk about this one day. perhaps next UDS? UI stuff for bzr is getting better every day, but such diversity is hurting us (with no real maintenance on everything)
<zsquareplusc> jelmer: ah. i had suspected bzr-notify. can i do something to fix that or just wait for 9.10 ;-)
<jelmer> zsquareplusc: you can uninstall searhose if you don't use it for anything else
<zsquareplusc> hm, no option, i use it
<jelmer> zsquareplusc: otherwise, wait for 9.10 indeed
<jelmer> pygi: is there really anything that can be done, other than having upstream gtk and qt merge?
<pygi> jelmer, surely ppa must have newer seahorse for 9.04 somewhere? :)
<jelmer> not aware of any
<pygi> jelmer, not sure, make people stop caring about toolkits? :p
<SamB_XP_> jelmer: get the pyqt package split into pieces like the qt libs are ?
<jelmer> SamB_XP_: how would that help?
<SamB_XP_> then I would probably have room to install enough to install qbzr ...
<jelmer> Ah, in that sense.
<jelmer> I don't think disk space is the problem for most people though
<SamB_XP_> okay, I don't know why they care so much
<SamB_XP_> I mean, it would be *nice* for things to look and act consistantly with eachother ...
<jelmer> yeah, that's my main reason for picking bzr-gtk over qbzr
<lifeless> jelmer: https://code.launchpad.net/~lifeless/subunit/perl-install/+merge/11498
<SamB_XP_> ... but, you know, that doesn't seem to stop many people from using gitk as their preferred git visualization tool ...
<fullermd> Actually, disk space kept me from even looking at qbzr 'till I built this new system...   but build time would have factored in too.  qt4 is _big_.
<garyvdm> Startup time is another issue
<garyvdm> jelmer: what do you think of my idea?
<garyvdm> Night all
<maxb> Is there any way to have bzr-notify poll remote branches?
#bzr 2009-09-12
<jelmer> maxb: hi
<maxb> hello
<jelmer> maxb: bzr-notify listens to dbus requests
<jelmer> maxb: it doesn't poll by itself, although there was a avahi plugin at one point that could forward commit events between avahi and dbus
<maxb> ok, is there something that will poll remote branches and send dbus requests? :-)
<jelmer> maxb: there isn't something like that yet afaik
<jelmer> the avahi plugin worked well at some point (it was a neat toy to use at sprints to see what other people around you were committing), but I think it's regressed since
<jelmer> for non-LAN branches, I don't think there's anything
<zsquareplusc> maxb: indirect solution, mirror the branches you are interested in, make a script that runs bzr pull in each, run the script manually or with cron
<zsquareplusc> alternatively use a site that sends mail on changes, e.g. launchpad can do that
<jelmer> I think it would make sense for bzr-notify to support polling
 * zsquareplusc could use that too if it would support sftp:// :-)
 * zsquareplusc has some private branches on a box with just 32MB RAM so he uses sftp because of the fear that a smart server would use to much resources
<SamB_XP_> zsquareplusc: that's *so* 1997!
<zsquareplusc> SamB_XP_: nah, it's a "modern" NSLU2, that uses less than 10W. i don't want to run old power hungry hardware 24/7...
<SamB_XP_> zsquareplusc: is that some kind of PDA?
<zsquareplusc> SamB_XP_: no, a small embedded box with 2xUSB+Ethernet. supported by Debian/Linux :-)
<SamB_XP_> debian can still run on machines that tiny ?
<zsquareplusc> yes. it has no display, so you don't have X and applets etc. that eat all the memory ;-)
<jumpkick> how would one see the rev numbers associate with individual files in a workspace?
<jumpkick> (normally I'd go on code.lp.net, but that's on the fritz)
<bob2> as in, in which rev no a given file was last modified?
<jumpkick> I think bzr log <file>
<jumpkick> ?
<jumpkick> that looks like it has the rev of the file at its last update
<fullermd> That's probably the most straightforward way of getting it, yes.
<jumpkick> thanks
<bialix> fullermd: around?
<timClicks> hi all, is there a way to automatically sync a branch with the shared repo?
<bialix> branch and shared repo is the 2 different things
<bac> good morning.  anyone here help maintain the bazaar-vcs.org site?  lots of broken links on the front page.
<bac> abentley, jam1, spiv ^^
<bialix> bac: it's a wiki
<bialix> you can edit it
<bac> bialix: ah, so it is.  had never noticed.
<bialix> scroll down
<bac> bialix: i see that now
<bialix> k
<DaffyDuck_> Let's say I do a "bzr checkout -r 10", and then fix a bug which was introduced there, how do I reset the working-tree later to "the latest revision" (such as it is now)?
<DaffyDuck_> Ah. "bzr update"
#bzr 2009-09-13
<meoblast001> just out of curiosity, is it easier to apply patches in bzr than git?
<davidstrauss> meoblast001: If you have the patch plugin installed, which you should on most platforms, it's just "bzr patch FILE-OR-URL
<meoblast001> no wonder i don't use git
<meoblast001> i just gave up on trying to patch a file
<meoblast001> apply a patch rather
<davidstrauss> meoblast001: Did bzr patch work for you?
<meoblast001> i don't have anything to patch with bzr.. i just know i'm going to have to use it in the future
<meoblast001> and wanted to make sure it wasn't as much of a PITA as it is with git
<davidstrauss> meoblast001: You may want to run "bzr help patch" just to check that you have it installed.
<meoblast001> i have Ubuntu so i'm assuming i do
<davidstrauss> meoblast001: Hmm. It's not in bzr core.
<meoblast001> yeah, i have it
<damijit> I'm having trouble pushing my branch to an SFTP server.
<damijit> I'm following the instructions here:
<damijit> http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html#publishing-your-branch-with-sftp
<damijit> When I push the branch, everyone seems to complete successfully. But when I ssh to the SFTP server to look at my branch, only the .bzr directory is there. None of my files are there.
<damijit> Does anyone have any idea why this might be?
<davidstrauss> damijit: bzr does not push a copy of the working tree
<davidstrauss> damijit: There are plugins to do so, though
<damijit> davidstrauss: Thanks, I'm looking at this: https://launchpad.net/bzr-push-and-update/. My problem is that bzr is not install on the SFTP server (it is my school's server), so "ssh [remote] bzr update [branch]" fails. Am I out of luck, or is there some way around this?
<mheld> hey y'all
<mheld> I'm helping to teach a course in comp sci and I'm trying to use svn to deal with homework handins and assignment/lab handouts
<mheld> or bzr
<mheld> basically [PUT VCS HERE]
<mheld> we have the students pair program through the year but then we have them switch partners a few times through the year
<mheld> we (ideally) want the students to see the same source when working together, but i'm not sure how we'd do that
<mheld> I guess we could have one repo for all the handouts and push to each user account then let the students deal with sharing their assignment repos
<mheld> yeah, I'll probably just make a webapp
<fullermd> vila: I just ran selftest with up-to-date bzr.dev.  Still get the errors that seem related to nonexistent revs (and I forgot --no-plugins, so I get a stack of e.g. qbzr too, but that's another matter)
<fullermd> vila: But the other stuff you fixed seems fixed here too.
<vila> fullermd: thanks for the feedback, I'd really like to understand the difference between our setups,
<vila> so of course 1) Can you re-rerun with --no-plugins (or better BZR_PLUGIN_PATH=-site ./bzr selftest... which is more precise) 2) try again with python25 or 3) teach me how to install python-2.6 while retaining python-2.5 in FreeBSD
<vila> 2 & 3 are relevant only if you can reproduce the failures, but a mail or better a bug  with the failures would be really nice
<vila> fullermd: I just upgraded the botnet to stop using '--no-plugins' which is one more step on the road to test a set of predefined plugins, but testing against several python versions may be relevant if your intuition is right there
<Lo-lan-do> Does automatic repacking run for each 10/100/1000/etc. revisions per branch, or per repository?
<jelmer> Lo-lan-do: repo
<Lo-lan-do> Great, thanks
<Lo-lan-do> Hm. Pushing a branch to a 2a repo running bzr 1.16 through bzr+ssh:// yields a "bzr: ERROR: Server sent an unexpected error: ('error', "'LocalTransport' object has no attribute 'startswith'")" errol
<Lo-lan-do> error
<Lo-lan-do> Does that ring a bell?
<Lo-lan-do> The resulting branch doesn't seem to be broken
<jelmer> Lo-lan-do: no idea, sorry
<jelmer> Lo-lan-do: seems like something is trying to use LocalTransport as a string
<Lo-lan-do> np
<Stavros> hello
<Stavros> is it possible for me to use bzr with github (and git branches in general), or does it screw things up?
<jelmer> Stavros: no, that works
<jelmer> Stavros: I'm using it for some projects
<Stavros> jelmer: oh, amazing
<Stavros> which plugin are you using it with?
<Stavros> i wanted to use github but i didn't want to switch away from bzr
<Stavros> does it discard any metadata or anything?
<Stavros> push isn't supported? what? :(
<jelmer> Stavros: I'm using bzr-git
<jelmer> Stavros: you can use dpush
<Stavros> oh, hmm, what's that?
<jelmer> Stavros: it throws away metadata that can't be stored in git
<Lo-lan-do> (He's *developing* bzr-git :-)
 * Lo-lan-do grovels
<jelmer> Lo-lan-do: so are you now >-)
<Stavros> haha
<Lo-lan-do> Nah, I'm trying to understand it currently.
<Lo-lan-do> Got your mail, btw, I'll try to fix what you mention, but I won't be at home for a week.
<Stavros> oh yay, this plugin is awesome
<Stavros> no more pulling stuff on linux and copying to windows
<Stavros> yay
<Stavros> now let's see if it works
<Stavros> ah, it doesn't :/
<Stavros> jelmer: are you trying to read a NamedTemporaryFile anywhere?
<jelmer> Stavros: We're doing something with temporary files
<Stavros> jelmer: that doesn't work under windows
<jelmer> Stavros: though I don't think we're using that specific class
<Stavros> well, it's failing for me and i'm not getting a traceback :/
<jelmer> See also https://bugs.edge.launchpad.net/bzr-git/+bug/382125
<ubottu> Launchpad bug 382125 in bzr-git "Can't branch from remote repository on Windows" [Undecided,New]
<Stavros> but if you want to do it in windows you need to make a file with mkstemp()
<jelmer> I'm not on Windows, so not entirely sure how to debug that
<Stavros> is it in dulwich or in your code?
<jelmer> dulwich is my code too :-)
<Stavros> oh
<jelmer> I suspect the code that's problematic for you is in bzr-git
<Stavros> can you check to see if you're using tempfile? i'm going to comment on that bug but i don't want to be irrelevant
<jelmer> as far as I can tell we use tempfile.mkstemp everywhere
<Stavros> hmm
<Stavros> let me grep the code then
<Stavros> that's odd, you're right
<jelmer> I'll be back later today
<Stavros> ah, okay, thanks for your help
<jelmer> it could be that we're trying to open that file twice or something
<Stavros> yeah, might be missing a close()
<Stavros> so, someone branched off my revision 62 and made various changes to various files. i changed one file they hadn't touched, committed, and then merged their changes. bzr produced conflicts in unrelated files i hadn't touched. is this normal?
<fm> i am trying to understand pipes. i have one pipe upstream where i created a file. now i switched to another pipe by bzr switch-pipe and i thought the file would be inherited, but it is not ....
<fm> vila: is there a way to reorder pipes?
<blueyed> Hi. I've shelved local changes, merged (but have forgotten to commit the merge) and unshelved. Can I separate my local changes now again?
<blueyed> I'll create a diff against the parent branch, then revert and patch. Looks like what I need.
<blueyed> this does not work as expected.. gives me a diff of change 7935 (tip) only: bzr diff --old lp:b2evolution -r7909 --new lp:b2evolution -r7934
<blueyed> how do I get the changes between 2 revisions in a remote branch?
<blueyed> oh.. I see.. r7909..7934 should do.
<blueyed> seems like when using "-r" only the latter gets used? Shouldn't it error out then?
<RobOakes> Is there any way to specify which text editor bzr uses for comments?  Right now, it looks like the default is nano.  I would prefer for it to use vi.
<LarstiQ> RobOakes: I recommend to set $EDITOR and/or $VISUAL
<LarstiQ> RobOakes: bzr respects those.
<LarstiQ> as do most tools.
<RobOakes> That's good to know.  Thanks for the tip.
<LarstiQ> RobOakes: otherwise, `bzr help configuration` mentions you can set the editor explicitly.
 * LarstiQ back to studying
<jam1> LarstiQ: btw, I'm pretty sure it was nano because that is what 'alternatives' uses as the default editory
<jam1> something like /usr/bin/editor ...
<LarstiQ> right
<LarstiQ> we fall back to vi after that iirc
<meoblast001> if a file is moved, are things logged as a deletion and creation, or a move?
<luks> as a move
<meoblast001> it seems quite inefficient to me to delete a file and create a new one if both contain the same contents
<meoblast001> luks: so it doesn't create a completely new copy of a file?
<luks> you mean in the repository, right? no, it just changes name for the file entry
<lifeless> moin moin
<lifeless> jam: hi; wondering if remove_expensive_references should discard the null node as well
<Goundy> ow
<Goundy> I just did a wrong: bzr add
<Goundy> how can I undo it plz ?
<Goundy> note: Haven't committed yet
<exarkun> bzr revert
<Goundy> ow shit
<Goundy> it fucked all up >_<
<mwhudson> bzr rm --keep the-file-you-added
<Goundy> well it re-added my files anyway
<Goundy> thanks guys
<fullermd> vila: (1) yields nothing unexpected; usual list of fails.
<igc> morning
 * fullermd waves at igc.
<igc> hi fullermd!
<poolie> good morning
<lifeless> hi poolie
<igc> hi lifeless, poolie
 * lifeless watches memory usage go past 5G
 * fullermd . o O ( `bzr memtest86` )
<lifeless> fullermd: meliae - johns py_memory_dumps' final name
<lifeless> fullermd: I'm tuning it to let me analyse a dump I got from the fast-import of netbeans, when that when up the kneebend @56K revisions
<lifeless> 28012 robertc   20   0 5352m 5.2g 1036 R  100 90.2  22:16.97 python
<lifeless> so this is a dump, of the memory graph, of a 6.4GB runaway process
<lifeless> I have 6GB of ram on this box :P
#bzr 2010-09-13
<beuno> heya poolie!
<beuno> knittl, heh, ingenious
<knittl> beuno: well, it worked fastest :>
<knittl> and so i made sure nothing is left
<lifeless> knittl: bzr clean-tree --ignored
<spiv> Good morning.
<poolie> hi there spiv, lifeless
<poolie> spiv, would you care to give a second opinion on https://code.launchpad.net/~mbp/bzr/ui-factory/+merge/34956
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: jam | bzr 2.2.0 is officially out | patches welcome: http://webapps.ubuntu.com/employment/canonical_BSE/
<spiv> poolie: sure
<lifeless> poolie: the apport one might be usable
<poolie> lifeless: apport what?
<lifeless> it has a dup detection demon
<lifeless> for detecting things with the same backtrace
<poolie> so, spiv, what do you think?
 * poolie is going to see about getting scriptrunner to test interactive ui stuff
<spiv> poolie: comment added
<poolie> thanks for the review, and i think that's a nice statement about kwargs
<poolie> i'd almost paste that into hacking
<poolie> actually i will paste that into hacking
<spiv> Ok :)
<spiv> It took me a few goes to get my thoughts on kwargs reasonably clear.
<poolie> yes, it's pretty much what i was trying to say
<grettke> Hi folks. Just insalled bzr on the olpc-xo-1. When I try running bzr, I get ""bzr does not support python -OO." What did I do wrong?
<spiv> grettke: bzr 2.2 should work with python -OO
<spiv> It seems a bit unusual that bzr would be installed to be run with python -OO by default, but I guess it's an attempt to avoid wasting space on the XO.
<spiv> grettke: how did you install bzr?  As a workaround, you can probably do "python /usr/bin/bzr", although if there are only .pyo files and no .pyc files it could be quite slow.
<grettke> I did a yum install bzr.
<spiv> Sounds like a bug in the rpm package, then :/
<grettke> oh ok, good to know, thank you
<spiv> But it wouldn't matter with the current release of bzr, which should work fine in those conditions.
<spiv> (And thus also allow the space saving that -OO provides)
<spiv> (And memory saving as well.)
<spiv> On most systems I'd say those wouldn't matter, but they probably do help on the XO :)
<poolie> is it just me or does lp-propose fail if there's already a proposal for the branch?
<poolie> spiv, where was your testdoc branch?
<spiv> poolie: it's in trunk now
<poolie> oh, just lp:testdoc?
<spiv> poolie: (also, jml made me the maintainer)
<poolie> i like the idea of using it to review what i changed
<poolie> tag :)
<poolie> wow, very nice
<spiv> Hooray :)
 * poolie resolves to make his docstring slightly better 
<spiv> vila tells me it's unreadable with a light-background terminal ;)
<poolie> :/
<poolie> that's such a mess
<poolie> i mean it's probably true but it's a shame unix lets you say "yellow" when you want "a bold contrasting color"
<spiv> Yeah.
<poolie> i guess he could write a formatter that either uses just bold/underline/etc, or that uses emacs to rewrite stuff into its own face markup
<poolie> actually you could write the whole thing inside emacs quite well
<poolie> i'm kind of surprised jml didn't
<spiv> Yes, for interactive use the editor is in a way a better home for it.
<spiv> I think perhaps jml wasn't thinking of using it interactively initially (given that the original output format was Moin markup).
<spiv> Also I can imagine writing elisp to invoke Python to do fiddly introspection might trip some "that's too gross" thresholds...
<poolie> i probably wouldn't use real python introspection, just regexps to find the methods and docstrings
<poolie> but i'm glad it's standalone, since i no longer use emacs
<poolie> much
<spiv> I think ideally it wouldn't use introspection, but it certainly makes it easier to write.
<vila> hi all !
<vila> woohoo, connected to pratchett (.freenode.net) The day will be fun :)
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | bzr 2.2.0 is officially out | patches welcome: http://webapps.ubuntu.com/employment/canonical_BSE/
<bialix> hi
<vila> hmm, is it me or is lp using a new font in same places ? (the mp links at https://code.edge.launchpad.net/bzr/+activereviews for example)
<vila> bialix: _o/
<lifeless> vila: the ubuntu font?
<bialix> vila: \o_
<vila> lifeless: hehe, looks like so to me, the funny thing is that I just installed it myself ;)
<lifeless> vila: thats why you just noticed.
<vila> lifeless: haaa, you mean the font change is older ? When did it occur ?
<lifeless> 2 weeks I think
<vila> lifeless: wow
<vila> lifeless: haa, right, I see the font *because* I installed it...
<mgz> morning all.
<mgz> see from planet debian Robert's done an interesting post on what he's been up to
<lifeless> I meant to edit it more, but it escaped due to wordpresss
<poolie> > Bazaar is a tool anyone can install locally
<poolie> > Launchpad, by contrast
<poolie> is a tool no one can install :)
<lifeless> hah
<poolie> jk
<poolie> vila, are you up?
<poolie> is there some trick about matching blank lines in test scripts?
<vila> poolie: yup !
 * bialix waves at poolie
<vila> poolie: hmm, ring a bell...
<poolie> hi there bialix
<bialix> new qbzr release hits the street
<vila> I vaguely remember that initially blank lines were ignored when there was no '$' prefix for commands... Not sure we fixed that now that the expected output lines don't have a prefix
<vila> poolie: what do you observe ?
<vila> poolie: An expected output blank line not respected or detected or... ?
<poolie> there's a blank line in the output
<poolie> it seems to be a bug: by the time we run the checker, it's not in the 'expected' variable
<bialix> poolie: check http://stackoverflow.com/tags/bazaar/info ; is it ok for you?
<poolie> looks good
<poolie> did you just set that up? thanks
<bialix> actually, yesterday
<bialix> I've got enough bazaar karma for this
<bialix> ddaa asked me to do so...
<vila> poolie: right, so I think my bell was right, want me to look at it ?
<poolie> no it's ok, i think i see it
<vila> poolie: bzrlib.script.py line 87
<poolie> yeah :)
<poolie> just working out what level to test that at
<vila> poolie: right, and line 112 smells like an additional test would be good
<poolie> i put up a branch ~mbp/bzr/script, that tests user interaction
<vila> poolie: like... test_empty_line_is_ignored ? :-D
<poolie> exactly
<poolie> i think in some contexts it should be ignored
<poolie> i guess only at the start of the document
<vila> poolie: but I think this one should be kept... yeah, you got it
<vila> i.e. output can exist if a command as been seen, otherwise, just ignore
<poolie> so as simple as just saying, we'll ignore one initial blank, but no more?
<poolie> at the _script_to_commands level?
<vila> poolie: lp:~mbp/bzr/doc approved if you remove the 'I think' occurrences, I don't think we ever say 'I' in these docs ;-p
<mgz> "I don't think we ever say 'I' in these docs" <- maybe you should add that to the docs
<lifeless> -lol-
<vila> mgz: my man ! Can you have a look at your mps ? There are some tweaks, but otherwise you have several you can land
<mgz> yeah, I'm short news again aren't I?
<vila> hehe
<lifeless> probably
<mgz> I'll add what's lacking and push.
<vila> mgz: s/I don't think// applies to your remark :)
<mgz> when you next poke babune vila, lifeless has released a new pyjunitxml version.
<vila> mgz: already done, but thanks for the heads-up and thanks to lifeless for the upgrade ;)
<mgz> ...you're always ahead of me
<vila> I try to avoid running private branches for babune or I lose... track ? my mind ? my sanity ?
<vila> mgz: not at all, just following closely instead :-p
<vila> mgz: ... which may mean I'm ahead when you stop :D
<mgz> pqm has news merge on right? otherwise I'm going to conflict horribly here.
<poolie> vila: proposal updated
<poolie> vila :)
<poolie> well, it was kind of quoted
<poolie> but not very clearly
<vila> poolie: sure, but lp doesn't show any changes yet, you've pushed right ?
<vila> wow, I'm already in love with the new Ubuntu font :)
<poolie> oh i meaont the scripts one
<poolie> did it change again?
<vila> ha
<vila> poolie: ok, wasn't there yet
<poolie> do you think that's a reasonable position about string interpolation?
<vila> "args are split in to words" ? into ?
<vila> poolie: hmm, I really dislike the idea of removing the first and final line
<vila> """\ works great for the first one
<poolie> vila, and you can do the same for the last one
<poolie> it just seems unfortunate to make every caller type that
<poolie> especially because it's meant to be an easy way to get good tests, and because i don't think tracking them will ever be useful
<vila> they shouldn't need that if we ignore the first one (but take care of it if we need error reporting with correct line numbers)
<vila> your note about the comment handling is right though...
<poolie> oh, so you're saying you don't mind ignoring them, but you don't like the implementation of trimming the list
<poolie> because it will change the line numbers?
<vila> well, it will always be impossible to distinguish a comment *preceding* a command, from a comment in the expected output of the *previous* command
<vila> yes, I think it's fine to ignore the first line if it's empty (while keeping track of line numbers) knowing that anal script writers can use """\
<vila> but I think we shouldn't ignore the last one until someone encounter problems with it (which hadn't occur yet right ?)
<poolie> it does happen
<vila> and for the comments, well, the only robust solution I can think of is to allow \# when you want to use it literally
<poolie> now that i don't ignore all blank lines, a bunch of tests fail
<poolie> """
<poolie> $ echo foo
<poolie> foo
<poolie> """
<poolie> fails
<poolie> because '\n'.split(that) has a '' at the end, after the last newline
<vila> rhaa, bogus split
<spiv> Trim leading and trailing blank lines?
<poolie> a bit surprising hey
<poolie> that's what i'm doing
<spiv> Or use """\ ;)
<poolie> yes, but i'd rather write the trim once, not \ a hundred times
<poolie> especially because the message is confusing if you miss it
<vila> poolie: you have 'if line == '': continue' indented, is that intended
<vila> wow, look mom, no typo !
<vila> poolie: and the tweak in _check_output looks suspicious too
<poolie> the indenting is actually intentional
<poolie> it's a somewhat misleading diff
<poolie> we want to skip lines that are blank only because they contain a whole-line comment
<poolie> why suspicious?
<vila> poolie: yup, I'm digging
<poolie> that's the change i was originally trying to make :)
<poolie> so the interaction test works
<poolie> test_confirm_action
<poolie> needs it
<vila> is that because test_confirm_action doesn't require that the user type <enter> ?
<poolie> no, it's because bzr doesn't write out a \n at the end of the prompt
<poolie> it leaves the cursor there and the user presses enter for us
<vila> ouch, that's "expected output does not end with \n', ok
<vila> right, that's what you say in the comment :)
<vila> almost
<poolie> isn't that nice? :)
<poolie> then i can pop back one fram
<vila> poolie: right, it's not clean but 100% DWIM
<poolie> so my goals, which i suppose are yours too
<poolie> are that it's easy to use
<vila> poolie: what about http://paste.ubuntu.com/492989/ ?
<poolie> when it fails, gives a decent message
<poolie> and as much as possible lets you  be precise if you want to
<vila> poolie: totally, the alternative would be to allow specifying an expected output *without* a final new line which means rewriting _script_to_commands for a little benefit
<poolie> vila so it seems like the only actual difference in behaviour there is that you tolerate multiple leading blank lines
<vila> poolie: overkill
<poolie> which does not seem useful to me
<vila> try putting a several lines long comment at the start
<poolie> ok, let's add a test for that
<poolie> that works
<vila> and an empty line after the opening comment ?
<vila> http://paste.ubuntu.com/492991/
<poolie> vila i'm not convinced that should pass
<poolie> istm letting people have a leading """ with no \ is useful
<poolie> but letting them have arbitrary blanks is not actually helpful
<poolie> and may get in the way of precision
<vila> poolie: no, failing because they forgot to be precise before their first command is just annoying them for no good reason IMHO
<vila> in _script_to_commands, the split is the bulk of the scanner while the loop is the parser, the comments are scanned in the loop to finish the scanning, and the parser should really kick in when the first command starts, but well, that's not so important, it just feels cleaner
<vila> but the comment I deleted is obsolete and misleading now
<vila> well cleaner and respecting newlines which del doesn't...
<vila> anyway, don't spend time on it, this will matter more if/when we implement error reporting with linenos at which point whoever does it can fix it
<lifeless> jml: so, testtools MP, I gave feedback, you seem undecided?
<vila> lifeless, jml: As a data point, I came across 'a' and 'n' *this* wee-end and... found it akward
<vila> week-end I don't even know what wee-end could mean...
<lifeless> vila: EPARSE
<vila> good :)
<lifeless> I don't know what 'a' and 'n' you mean
<vila> yeah 'b' :)
<vila> at least this typo reveals my lack of understanding, I don't know what it's about so I can't type it properly :)
<lifeless> vila: I'm still lost
<vila> lifeless: I encountered 'a' and 'b' in assertEqualDiff and thought: "Wth ? Why not 'expected' and 'actual' ?"
<lifeless> oh right
<lifeless> yes
<jml> lifeless, yes.
<jml> lifeless, I'm otp atm.
<poolie> hello jml!
<lifeless> jml: yes
<jml> poolie, hi
<poolie> welcome back (if you are)
<lifeless> jml: we can talk about it tonight/tomorrow if you want
<poolie> vila i'd kind of like to just merge this
<jml> lifeless, that'd be good.
<poolie> that particular problem might be confusing but it hasn't bit me yet, anyhow
<poolie> bug 636930 sounds familiar
<ubot5> Launchpad bug 636930 in Bazaar "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/636930
<poolie> ah bug 513432
<ubot5> Launchpad bug 513432 in Launchpad Bazaar Integration "AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 13, heat: 23)" [Critical,Fix released] https://launchpad.net/bugs/513432
<poolie> spiv, if any, it looks like that has regressed in 2.2?
<mgz> 633915 is the same bug and also new.
<mgz> and 635874.
<mgz> all of them involve launchpad, so the regression might be that side rather than in 2.2
<vila> poolie: as in: "Thanks for review, but still" ? :-D
<vila> grr, %2Bbranch still ?
<poolie> yes, "but still" :)
<poolie> i feel like that's enough of that particular yak for today
<vila> poolie: ok, I've shelved my patch and I can trivially break your test, that's good enough :)
<vila> poolie: moreover I get a "SyntaxError: No command for line ''" which is a perfect case to implement better error reporting with line numbers :-D
<poolie> yeah that would be higher up my list
<poolie> also there's something strange happening with ellipsis
<lifeless> I triggered the elusive bzr: ERROR: Tree transform is malformed [('missing parent', 'new-1')]
<vila> lifeless: hmm, with bzr itself or builddeb ?
<lifeless> with bzr
<lifeless> 2.2b3
<lifeless> rev 5340
<lifeless> I had added a directory and files in the dir, and I did shelve --all
<vila> that's a bug then (all MalformedTransform are :-/)
<vila> oh, shelve...
<vila> or... did you have .pyc files there ?
<lifeless> ignored files yes
<lifeless> foo~ - editor backups
<poolie> oh, wow
<lifeless> sounds like you have an idea about whats going on; perhaps you could file the bug ?
<vila> lifeless: can you try again with lp:~vila/bzr/323111-orphan-non-versioned-files ?
<poolie> an actual bug, not a test suite bug
<poolie> but not a very big one
<lifeless> vila: i will tomorrow
<vila> lifeless: ok, waiting for your feedback then
<lifeless> vila: you could try it yourself :P
<lifeless> vila: trunk, and then your branch
<vila> lifeless: yeah right :) I'm busy fixing my branch.conf files with lp spitting bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr/ urls everytime I create a new bzr branch :-/
<lifeless> vila: you might like to file a bug on that
<lifeless> its good that private branches are supported, but its a bit annoying
<vila> lifeless: there isn't already one ??? I thought you mention tim related to that when I mentioned it... friday ?
<lifeless> I did
<lifeless> have you communicated with him about it though?
<vila> no, I thought you and I were already discussing it, rats, it's a bad bug
<vila> lifeless: should I file against lp or lp-code ?
<poolie> ok, and now i get to fix the n-1th yak
<vila> lifeless: oooooh, but the urls work...
<vila> no need to fix my branch.conf files (I get fooled in a particular setup)
<vila> hmm, fooled twice even, if they work today, the problem I encountered friday was either transient or fixed since
<vila> lifeless: so bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr/ will now always point to the dev focus right ?
<lifeless> I don't know.
<lifeless> I guess.
<mwhudson_> vila: yes
<lifeless> and anothe bug
<lifeless> :!bzr shelve --all debian/python-fixtures.install
<lifeless> Selected changes:
<lifeless> -D  debian/
<lifeless> -D  debian/python-fixtures.install
<lifeless> bzr: ERROR: Tree transform is malformed [('unversioned parent', 'new-2'), ('missing parent', 'new-2')]
<lifeless> (filed)
<vila> mwhudson_: thx
<bialix> poolie: still here?
<poolie> hi, yes, though not for long
<bialix> https://bugs.launchpad.net/bzr-website/+bug/636961
<ubot5> Launchpad bug 636961 in bzr-website "www.bazaar.canonical.com URL does not work (affected: 1, heat: 6)" [Undecided,New]
<poolie> really
<poolie> it should
<poolie> thanks
<poolie> i can't fix it but i'll ask
<bialix> so far I'll use URL without www.
<poolie> good idea
<poolie> ok good night all
<spiv> poolie: yes, bug 636930 did sound familiar, thanks for finding the bug it may be a regression of
<ubot5> Launchpad bug 636930 in Bazaar "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 3, heat: 26)" [Critical,Confirmed] https://launchpad.net/bugs/636930
<spiv> I'll look into it tomorrow if no-one fixes before then.
<jml> poolie, good night. we should have a chat some time.
<nlisgo> 'bzr remove --keep file.php' keeps the file locally but removes it from repository. Is there a way to have it removed from repository but it when the repo is pull within a branch the file file.php is not removed within the branch
<nlisgo> I know it also needs adding to the .bzrignore file
<rubbs> I'm looking for a way to create a shared repo system that allows for devs to have their own branches in the shared repo, but not have write access to a specific branch, for example, the trunk. what's the best way to go about doing this?
<rubbs> I basically want the space saving abilities of the shared repo (or similar) but need a gate keeping sort of system. I'm the only one who should have commit access to the trunk. Is this possible? or do I need the trunk to be in a separate repo?
<maxb> You'll need everyone to have write access to the repository. You could enforce some application-level constraint on people who can change a branch tip
<rocky> what's the quickest way to see what repo a branch comes from? (ie where all the rev info is stored)
<Meths> bzr info ?
<rocky> bzr info on a branch does not tell me where it's repo is located
<ddaa> rubbs: maybe have a look at stacked branches
<ddaa> they were designed for this kind of use case:
<ddaa> space saving of shared repo, without giving everyone write access to everything
<ddaa> http://doc.bazaar.canonical.com/latest/en/user-guide/stacked.html
<rubbs> maxb: ddaa thanks. I'll take a look at stacked.
<ScottK> Feedback from a satisfied customer on a proprietary project I'm working on that uses bzr: "`bzr merge --uncommitted --force --interactive`s. Neat." <-- the commenter is generally a die hard svn/centralized VCS traditionalist.
<ddaa> separatists of the world, unite!
<Kinnison> splitter!
<rubbs> Hmm... seems like binding to a stacked branch could cause some problems.
<ddaa> generally, it's better to enforce this kind of constraint by policy, or to deal with the additional disk usage of having multiple independent repos
<rubbs> ddaa: yeah I htink I'm going to do that later. We would have the policy and I do trust the devs here, but I want that safety net if possible.
<rubbs> I think I'm going to have a dev repo and a release repo
<rubbs> disk space is cheap ;)
<ddaa> stacked branches were designed for launchpad, which has a relatively unique set of constraints and level of control.
<ddaa> hi Kinnison. Do you really, really hate the Romans?
 * ddaa goes out to look at the bright side of life
<maxb> rocky: Yes, it does, unless the repository is implicitly located within the branch bzrdir itself
<dobey> can anyone help me figure out http://pastebin.ubuntu.com/493200/ ? the tarmac branch tests are all failing with this error in the PPA package builds. and rockstar and others seem to get the errors when running the tests, however, i am unable to get the errors to occur on my system.
 * rockstar bets jam can help.
<rockstar> He is smart.
<jam> rockstar, dobey: starting with bzr 2.2 we require a configured username to commit, because we had a lot of problems with people forgetting to enter it, and then getting committers they didn't want
<jam> for test suitse
<jam> the bzr TestCase sets BZR_EMAIL as part of setUp()
<rockstar> dobey, we should be using the bzr TestCase in those examples.
<dobey> ah
<dobey> hmm
<dobey> TestCaseWithMemoryTransport?
<dobey> also, i'd still like to know wtf i'm not getting the issue while everyone else is
<jam> dobey: do you have the env variable set already?
<Logomachist> Are we any closer to a bzr book getting released?
<jam> again bzr's base TestCase clears out the environment variable while running
<jam> I just double checked the code
<jam> bzr's TestCase has a "_cleanEnviroment" function, called from TestCase.setUp()
<jam> which sets BZR_EMAIL = None, and EMAIL=jrandom@example.com
<jam> if you are inheriting from a bzrlib TestCase you should get that for free
<dobey> jam: no
<jam> if you are just inheriting from unittest.TestCase then you won't
<jam> and you'll want to do something similar
<dobey> jam: if i run 'bzr whoami' in os.system() in the test, it prints the message that it's unset
<jam> dobey: right, but that is because there are multiple ways of setting it
<jam> what does "set" give?
<jam> we will accept, EMAIL, BZR_EMAIL, or 'bzr whoami "foo bar <foo@bar.com>"
<dobey> none of those are in my env
<dobey> and the tests are setting BZR_HOME to an empty dir
<jam> dobey: IIRC, 'bzr whoami' only looks at the information you gave it
<jam> (it doesn't look at the env vars)
<jam> dobey: would you have an older version of bzrlib?
<jam> like 2.1 ?
<dobey> well it looks at the config too. and since it's printing the no value message, it is not reading it from my config
<dobey> no, i'm on maverick and have bzr 2.2
<dobey> this broke when the 2.2 release went into maverick, and i did some work on the tarmac tests to make the error go away
<dobey> but it seems to have cropped back up somehow, though i can't make it happen on my machine
<jam> dobey: sorry, I got disconnected for a second, last thing i see:
<jam> 11:49:11 AM) dobey: but it seems to have cropped back up somehow, though i can't make it happen on my machine
<jam> (11:50:00 AM) jam: dobey: this is for the tarmac test suite itself, right?
<dobey> yeah, a subset of the tests in tarmac
<dobey> i'm happy to switch it to using the appropriate bzrlib testcase, but want to understand why i seem to be the only person not seeing the issue :)
<rubbs> quick question, is there a way to make a branch on the remote server without having to make commands via ssh. I'm basically saying can I from computerA do this: rubbs@computerA$ bzr branch bzr+ssh://computerB/branch1 bzr+ssh://computerB/branch2?
<jelmer> rubbs, you should be able to, yes
<jelmer> it would probably be slower than ssh'ing out to computerB or computerC though
<rubbs> jelmer: thanks, that worked. I know it may be slightly slower, but at this point it's easier to explain it to newbies. Long story short, I want all their branches to be on the server so I can back up their work. They will use bzr to create their branch on the server, then branch+bind to their local machine from the new server branch. If I can get them to do it all with bzr commands, it will make more sense to them.
<rubbs> after they are more comfortable I'll make sure they know they can do it faster
<rubbs> I'm also toying with the idea of giving them sftp access only to our repo server
<jelmer> rubbs: well, s/slightly/a lot/
<jelmer> rubbs: rather than using local paths it would fetch all data locally to computerA only to send it off to computerB again
<rubbs> jelmer: ah, I'll try to find another way around it.
<servilio> hi all! is there a [stable|reliable] way to have composite/nested trees?
<lifeless> servilio: the externals plugin seems popular
<servilio> lifeless: will take a look, thanks
<servilio> lifeless: just found the lp:~jelmer/bzr/foreign branch, but doesn't have any linked blueprints or bug report, so no info on when to expect it to be merged in core bzr
<jelmer> servilio: What do you expect that branch do be?
<servilio> jelmer: it is a hosting environment, I have one repo for the environment skeleton, and another for the different hosting buildouts
<jelmer> servilio: I mean ~jelmer/bzr/foreign, what are you expecting it to do?
<jelmer> servilio: it's just the branch where I keep changes to improve foreign branch support that haven't landed yet.
<servilio> so, are there any options in the stock bzr to be able to create nested branches?
<servilio> like "bzr co repo:hosting . && bzr co repo:buildouts/b1 b1"
<servilio> and then being able to do bzr pull independently in b1 and its parent to pull updates
<servilio> is that possible right now?
<jelmer> servilio: no, see bug 402814
<ubot5> Launchpad bug 402814 in Launchpad Bazaar Integration "Importing revisions with submodules is not supported (affected: 8, heat: 56)" [Wishlist,Triaged] https://launchpad.net/bugs/402814
<servilio> jelmer: just read the bug report
<servilio> jelmer: but I don't have anything clear yet
<servilio> jelmer: I mean, of current support and if it is possible to use it
<jelmer> servilio: there is no support in bzr core for by-reference nested trees. There are some plugins that provide alternatives.
<servilio> jelmer: and what's the prospect for its support in the core?
<servilio> jelmer: any plugin that has some kind of forward compatibility with the approach that core will head to?
<jelmer> servilio: it's a much requested feature and I believe the core team has plans to work on it in the near future.
<jelmer> servilio: there is no plugin that uses the same approach as core will use.
<servilio> jelmer: do you know of one that at least won't cause problems when migrating to the way core will support this?
<jelmer> servilio: I don't think any of them will cause problems.
<servilio> jelmer: any specific suggestion? or links?
<jelmer> servilio: personally I would suggest bzr-externals
<servilio> jelmer: thanks a lot
<jelmer> it's the simplest but also the most straightforward
<servilio> great
<TresEquis> jelmer: that plugin is stable / recommendable at this point?
<TresEquis> I think the last time I looked it was still not-quite-there, but that was a while ago
<jelmer> TresEquis: it's stable as far as I know
<servilio> TresEquis: just looked at the page, and right now looks to be at a useful and usable state
<jelmer> TresEquis: I'd still consider it a stopgap fix until proper nested tree support lands though.
<TresEquis> maybe that's the caveat I was remembering
<TresEquis> I have a bunch of SVN-backed checkouts which use svn:externals, would be nice to be able to track those in bzr-svn
<servilio> jelmer: anything that could be done to get proper support into the core faster?
<chx> hi. i am trying diff one file in a checkout against its HEAD counterpart.
<chx> nevermind :)
<jelmer> servilio: I think it's already high on the list of things to work on of the Bazaar core developers, for more details the mailing list or that bugreport are probably the right places to ask.
<servilio> jelmer: ok, thanks
<ali> hi bzr masters, what does this error mean? bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('ShortReadvError', 'b22a569ce92096b22330c933808dc3b1.tix', '0', '772', '60')
<ali> seems my repository is corrupted ("bzr check" reports the same thing, "bzr reconcile" failed with   File "/usr/lib/python2.5/site-packages/bzrlib/index.py", line 1074, in _parse_lines
<ali>     raise AssertionError("%s %s" % (self._size, pos)) AssertionError: 772 59)
<maxb> ali: Yes, that doesn't sound good. The first thing you could do is to try running "md5sum .bzr/repository/packs/*.pack" to check the status of some other files in your repository - for pack files, their name should be identical to their md5sum value
<lifeless> maxb: hi
<maxb> hello
<lifeless> maxb: I've got your mail about packages on my to-read
<lifeless> I've updated a couple of packages
<lifeless> in sid
<maxb> hmm, which ones?
<lifeless> python-junitxml
<lifeless> testrepository I think, or was it testtools
 * lifeless checks archive mails
<maxb> Ah yes, I have tracked them down in debian-devel-changes@ now
<lifeless> yes, those two
<lifeless> I need to do a testtools one
<lifeless> May wait a few days, get a small improvement in cleanups into it first
<maxb> Ok, once that appears, I'll do the PPA uploads for it, and re-propose promotion of testtools/subunit from the beta ppa
<maxb> That reminds me, bzr-svn is also languishing in the beta ppa, I should do something about that
<ali> ni, maxd, i just ran "md5sum .bzr/repository/packs/*.pack", all files' md5 matches file name
<maxb> Well, that's a start. You might want to read through https://answers.launchpad.net/bzr/+question/96346 next - I don't know any more than what's there, but others here can possibly help
<ali> thx, maxb
<RomanMoz> Hello! How to launch bzr-gtk or bzr-explorer on Windows systems? Ten years I used Linux and forgot many things in windows
<RomanMoz> Please...
<ali> maxb, "bzr dump-btree" is even failing on my other good repositories, any ideas?
<ali> build@dev-001:/bzr/server/.bzr/repository/indices$ bzr dump-btree b8e9c1d28ae7c837d4f1472535a58a03.iix
<ali> bzr: ERROR: b8e9c1d28ae7c837d4f1472535a58a03.iix is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
<maxb> ali: hmm. odd. what format repository is that?
<maxb> also, you could try dump-btree --raw
<maxb> also, is the broken repository private data, or public?
<ali> it is private. tried with "--raw", none of the indices are recorgnized
<ali> i tried .six, tix, rix, iix files. bzr version 2.0.4 on 64-bit ubuntu, weird
<lifeless> ali: what does 'bzr info -v' show - you can elide the paths, but we need the format data
<ali> ali@dev-001:/bzr/server/.bzr/repository/indices$ bzr info -v
<ali> Shared repository (format: pack-0.92)
<ali> Location:
<ali>   shared repository: /glass/sfw/bzr/repo/server
<ali> Format:
<ali>        control: Meta directory format 1
<ali>     repository: Packs containing knits without subtree support
<ali> Repository:
<ali>       7522 revisions
<lifeless> ok, so this is not a btree based format
<lifeless> the indices are linear arrays with bisection used, instead of a btree.
<ali> i see, the repository was created two years ago with old bzr version, i guess
<ali> anyway i can migrate to the new btree repository? (if i can fix this one first)
<maxb> upgrading's easy. fixing this, however, may be rather hard
<ali> i reserved the crime scene, and just rolled back to this morning's backup. :-) If you need me to report a bug or something let me know
<lifeless> ali: it looks like you had a write to an index get truncated by your filesystem
<lifeless> ali: without notification to bzr
<lifeless> the code in question is:
<lifeless>         for line in lines:
<lifeless>             if line == '':
<lifeless>                 # must be at the end
<lifeless>                 if self._size:
<lifeless>                     if not (self._size == pos + 1):
<lifeless>                         raise AssertionError("%s %s" % (self._size, pos))
<lifeless> so we got:
<lifeless>  - an empty line (EOF shows as this)
<lifeless>  - we know the size of index we -wrote-
<lifeless>  - must be at the end of the index, but its not
<lifeless> 772 is the file size expected
<lifeless> 59 is the file size found
<ali> hmm, any reason why filesystem truncate the file? the file size is too big?
<lifeless> not in this case, 772 bytes is very small :)
<lifeless> 59 bytes is an odd amount to truncate too
<lifeless> the other possibility is that there is garbage in the index (again, almost certainly a fs bug, we've not seen bzr write nonsense stuff out in the index as a bug)
<poolie> hi
<poolie> we have seen a few people complaining their fs truncated the files to 0 bytes
<poolie> 59 is indeed odd
<ali> i can send you the idx files if you want to take a look
<ali> btw, the server was stable and running for the last 4 months, nothing weird today either
<poolie> ali, if you record a bug and attach those files that would help
<poolie> hi jam?
#bzr 2010-09-14
<ali> bug reported, thanks. https://bugs.launchpad.net/bzr/+bug/637644
<ubot5> Launchpad bug 637644 in Bazaar "Repository corruption, index file truncated by OS file system (affected: 1, heat: 6)" [Undecided,New]
<ovnicraft> hi folks, i branch a repo from lp in my VPS now i want to get it to my laptop i get this error: bzr: ERROR: Unable to connect to 173.230.141.58; [Errno 111] Connection refused
<ovnicraft> trying: bzr clone ftp://XXX.XXX.XXX.XXX/home/myuser/openerp/stable/addons
<ddaa> ah people...
<ddaa> like free online support has to be instant
<poolie> hello ddaa
<ddaa> hello poolie, wassup?
<poolie> mm i was going to answer but he just left
<poolie> ah, things are pretty good here
<ddaa> so, my bet was "missing username from URL" :-)
<poolie> just going to close all my other windows in a bit and look at this Inter2And2Helper bug
<poolie> i was going to guess firewalls around the vps
<ddaa> oh right, missing username would be a different error
<spiv> Good morning.
<ddaa> gotta say, ropemacs is da bomb!
<ddaa> when inlining a method that calls a function from another module, it adds the needed imports in the modules of the callsites
<mwhudson> ah, i never managed to get it to work
<ddaa> Mh... I did need some non-trivial .emacs hacking here.
<ddaa> Here's what I did: http://pastebin.com/eiEVBJDJ
<ddaa> the python-ropemacs-hook is personal preference
<ddaa> I'm not sure why did this thing for on-startup loading, maybe on-demand loading was broken for me...
<mwhudson> doesn't seem too bad
<mwhudson> will have to try again at some point
<spiv> poolie: huh, that Inter1And2Helper bug looks shallow, but also a bit depressing:
<spiv>             # XXX: not covered by tests, should have a flag to always run
<spiv>             # this. -- mbp 20100129
<spiv> s/source_repo/source/ looks like the obvious fix.
<spiv> Also, in a probably unrelated issue, _get_rich_root_heads_graph looks suspiciously useless.
<poolie> hm, thanks spiv
<poolie> so how should a --no-confirmations flag get down to the ui
<spiv> poolie: via the context? ;)
<poolie> hm, maybe :)
<spiv> I've put up a patch for https://bugs.edge.launchpad.net/bzr/+bug/636930 btw, including test coverage.
<ubot5> Launchpad bug 636930 in Bazaar "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 4, heat: 34)" [Critical,In progress]
<poolie> should this be remembered in the uifactory, or in the context, or should it perhaps be somewhere else
<poolie> extreme factoring would suggest there's a separate "user interaction policy" thing that is separate from the implementation of how to interact with the user
<poolie> (legend)
<poolie> and then that policy object would know whether to ask or not
<spiv> Yes, I think that sounds about right.
<spiv> I'd want to keep the policy object as simple as possible until more things use it.
<spiv> But otherwise I think that sounds like a nice approach.
<spiv> Hmm, maybe I should to fix http://bugs.python.org/issue9729 so that the test suite can pass on maverick.
<poolie> could be good
<poolie> there's another bug very slightly similar to that
<poolie> just in bzr
<poolie> which is something to do with socket.error being a bit odd
<poolie> so not caught properly
<poolie> perhaps because it's not a subclass of IOError or OSError
<poolie> spiv, teddy bear?
<poolie> i'm trying to decide if the user interaction policy layer should be a decorator layer on the uifactory
<poolie> in some ways that's an easy way to intervene around all actions
 * spiv listens
 * spiv sits with arms sticking outwards a little bit, in his best imitation of a teddy bear ;)
<poolie> :)
<poolie> but it feels a bit wrong
<spiv> Yeah, my initial reaction to that is it feels a bit weird.
<poolie> if we do it, we could add a GenericDecorator that uses getattr to feed through to the underlying one
<poolie> for instance you might like to look at the current state, or reset the state
<spiv> So the decorator could intercept e.g. confirm_action and decide to ignore the decorated object and just return True if that was the policy?
<spiv> So this is to save the individual uifactories from having to all implement the same "first, check the policy" logic?
<poolie> right
<rryan> how do you jump back a revision on a checkout?
<poolie> and to make it easier to vary the policy
<rryan> i can't believe i dont know how to do this
<poolie> rryan 'bzr update -r -2'
<poolie> for instance to have --confirmation=yes  or --force options
<poolie> https://bugs.edge.launchpad.net/bzr/+bug/397315
<ubot5> Launchpad bug 397315 in Bazaar "break-lock should have a --yes, --force or --unconditional option (affected: 1, heat: 6)" [Medium,In progress]
<rryan> facepalm, thanks!
<spiv> So here's another use case that may or may not help to think about:
<spiv> add the ability to selectively set a policy for just a specific question, e.g. "break_lock=yes/no/confirm"
<spiv> I suppose the decorator would have to inspect the args passed to confirm_action (or whatever) to see if it matches the specific question.
<spiv> (Hmm, I suppose a different variation is per-location or per-branch UI policy... I guess that's equally messy with the decorator or with every factory explicitly delegating to policy)
<poolie> right, so we're going to want it somehow hooked up to the context, from which it can get the config object
<poolie> i guess assigning a new object to ui.ui_factory feels like a very heavyweight action
<poolie> to set the policy here
<spiv> Yeah.
<spiv> The decorator approach does sound like less code, which is a big plus.
<lucidfox> What's the best way to maintain a changelog file with bzr?
<poolie> lucidfox: well, there are two ways
<poolie> you can do bzr log --format=gnuchangelog
<poolie> or, you can manually commit to it and record those changes
<lucidfox> Well, problem is
<lucidfox> because of my "commit early, commit often" work style, automated log generation commits spams the log with one-line entries like "fix typo" or "add comments"
<lucidfox> and the ChangeLog file is supposed to list *functional" changes, right?
<poolie> right, so in that case i'd suggest probably maintaining it by hand, rather than automatically
<spiv> Ok, patch submitted to http://bugs.python.org/issue9729.  If upstream likes it I'll propose it for backporting to Python 2.6 in maverick, which will make our test suite a tiny bit happier.
<spiv> It's a bit disconcerting fixing bugs in the Python standard library... the test suite doesn't seem anywhere near as comprehensive as I'm used to with bzrlib.
<poolie> heh
<poolie> feedreader was fun
<mneptok> "When the light of life has gone, no change for the meter. Then the king of spivs will come, selling blood by the litre."
<poolie> they have a ton of tests but they're all sample data matched against the parsed form
<poolie> indeed
<poolie> so what do you think for a name? --yes? --jfdi? --no-confirmation?
<mneptok> --make-it-so
<mneptok> can't go wrong with Picard references
<poolie> for bug 397315
<ubot5> Launchpad bug 397315 in Bazaar "break-lock should have a --yes, --force or --unconditional option (affected: 1, heat: 6)" [Medium,In progress] https://launchpad.net/bugs/397315
<poolie> --thats-an-order
<mneptok> --crowbar
<mneptok> (lock breaking and all)
<spiv> --yes sounds ok to me, it reminds me of fsck -y
<vila> hi all
<mneptok> :( i like --crowbar
<vila> poolie: why not a config var to define the ui itself ?
<poolie> vila, how do you mean?
<poolie> vila, istr that null output from script commands matches anything?
<poolie> is that true?
<poolie> it's just been confusing me
<vila> poolie: a yes_ui
<vila> null output matches anything... hmm, doesn't ring a bell, that would be quite a bug
<poolie> mm it seems to be true though
<poolie> vila, i agree, i think -O'ui=YesUI' should work
<vila> oh, wait, if *no* output is specified, then, yes, I think it's defined as meaning: "I don't care about the output", but that's not the same as specifying an output and getting none
<poolie> that needs just a little more buildup and it's a somewhat longwinded way to get it
<poolie> yes, that's consistent with what i'm seeing, but i think it's a bug
<poolie> i recall discussing it
<poolie> i think if you don't care, you should say '...'
<vila> poolie: but then you have to do it always, yeah may be we discussed that already
<poolie> i should say i'm generally really super happy with scripts
<vila> I don't know if we have already enough data for that (nor if can define >/dev/null)
<poolie> that's why i'm hitting bugs
<poolie> :)
<vila> hehe
<poolie> i think robert has a point they could create a pressure towards excessive blackbox testing
<vila> I fully agreed and still agree with that. I consider them a first rough shot to reproduce a bug
<vila> from there you drill down and write more precise tests
<poolie> i think if you're going to write a blackbox test, you might as well write it this way
<poolie> it's clearer and probably no slower
<poolie> and when the bugs are shaken out, it should be no less precise
<poolie> there's still the question of how we could test the command ui other than by full-stack tests
<poolie> (how or whether)
<poolie> https://bugs.edge.launchpad.net/bzr/+bug/637830
<ubot5> Launchpad bug 637830 in Bazaar "null output from test script matches anything (affected: 1, heat: 6)" [Medium,Confirmed]
<vila> oh, for blackbox tests yeah, I was thinking more generally
<poolie> no point making it _hard_ to write bb tests as a way to make people write unit tests
<vila> lol, no, that's not my point :)
<poolie> vila, i think https://code.edge.launchpad.net/~mbp/bzr/ui-factory/+merge/34956 is now all ready to land
<vila> poolie: didn't I approved it ??? ... looks like it... weird
<vila> poolie: done
<vila> hmm, that's cleanup day :) I like it, go submitters, go !
<vila> poolie: Why bzrlib.ui.testsupport instead of bzrlib.tests.ui (or something, but under tests) ?
<bialix> heya GaryvdM
<GaryvdM> Hi bialix.
<bialix> Gary, I've pushed small fix to lp:bzr-windows-installers branch, please, next time you'll build the installer use it
<bialix> GaryvdM: btw, how's your own build host going?
<GaryvdM> bialix: I installed a 32 host, so I was not able to build the tbzr 64bit shell ext. So I'm gonig to have to start from scratch
<poolie> vila, i actually did originally put it somewhere like that but i think python was getting confused by multiple things called ui
<poolie> or at leoast i was :)
<poolie> cleanup day?
<bialix> GaryvdM: oops :-(
<poolie> hi bialix, garyvdm
<bialix> heya poolie
<GaryvdM> Hi poolie
<vila> ueah, I thought about that :) So how about bzrlib.tests.ui_utils ?
<GaryvdM> Hi vila
<poolie> sure
<vila> hey GaryvdM, bialix !
<bialix> GaryvdM: which reminds me: why we still provides 32-bit bython version for 64-bit Windows?
<bialix> vila: bonjour \o_
<poolie> i wouldn't mind having a rule that code outside .tests shouldn't call things inside it
<poolie> aside of course from cmd_selftest etc
<poolie> and this would advance that
<vila> poolie: yup, hence my remark about branchbuilder on the review comment
<GaryvdM> I'll probably build the 2.2.1 installer on the ec2 instance, and then have another go after that is done. I'll have to ask jam to revert the pyqt version.
<bialix> GaryvdM: how hard it would be to have both 32 and 64 bits hosts?
<GaryvdM> bialix: Re 64bit python, -
<vila> bialix: at least twice as hard ? :-P
<bialix> vila: exactly!
<GaryvdM> bialix: Re 64bit python, - I don't really know, I have not really looked at it
<bialix> I have plans to get new computer soon, it should be 64-bit
<GaryvdM> bialix: My knowledge of the installer build is still small. I'm just following the docs....
<bialix> the only one question which bother me is: where to get the compiler for python extensions
<vila> bialix: good timing, 10.10 is nearly out :-P
<bialix> vila: yep, I'd like to have dual boot machne
<bialix> GaryvdM: which compiler are you using?
<GaryvdM> bialix: I was using VS C++ express, which is free beer, but not free speech.
<vila> bialix: even better: install 10.10 and use vms... way to go... ;) You will need a bit more RAM, but then you'll have both 32bits and 64bits windows available...
<bialix> vila: I already have 32-bit Windows XP and pretty happy with it
<vila> bialix: you mean you'll get an *additional* computer ?
<bialix> yes, new one
<vila> nice, have a look at synergy then, 2 computers is a nice setup, 2 mice, 2 keyboards... less nice
 * vila looks around and see 5 mice 3 keyboards <cough>
<bialix> hehehe
<bialix> who's talking
<GaryvdM> I use synergy.
<vila> well, I use 1 kbd 1 mouse 99% of the time though
<vila> but there are cases were one PC needs a keyboard (boot, nasty problems) and 3 mices should just go in the attic :)
<vila> mice
<poolie> vila i just got a magic touchpad today
<poolie> it's pretty sexy
<vila> what's a magic touchpad ?
<vila> Oh, the apple one ?
<poolie> yes
<bialix> Can it call spells of 80 level?
<poolie> :)
<poolie> it can scroll both downwards _and upwards_ which my worn out old mouse couldn't do :)
<vila> poolie: yeah, I have a magic mouse (2 in fact :-p) it's a pity I had trouble configuring it properly for osx/vbox/lucid/synergys though :-/
<vila> poolie: it works under maverick right /
<poolie> spiv do you want to send your approved branches?
<poolie> actually it's only on os x for now
<vila> poolie: ha.
<poolie> i might try it on maverick later but my desktop pc has no bt adapter
<poolie> oh nm, you did
<poolie> vila i moved the uifactory stuff to tests.testui and it seems happy there
<vila> hehe, I thought about that too but didn't want you to say: oh, testui and test_ui are too close ;-p Please land !
<poolie> urk
<poolie> they kind of are, but i think it's ok
<fargiolas> sorry if it is a faq, probably I'm searching wrong keywords and cannot find the answer, how do I checkout a specific revision with bzr?
<GaryvdM> fargiolas: There are many ways to skin that cat
<GaryvdM> fargiolas: If you don't allready have a branch: bzr branch -r x
<GaryvdM> If you allready have a branch: bzr pull . -r x --overwrite
<GaryvdM> or
<GaryvdM> bzr revert -r x
<GaryvdM> or bzr update -r x
<fargiolas> don't know if I have a branch, I ran brz branch lp:project-name
<fargiolas> I still have to better understand bzr lexicon
<GaryvdM> I'm not sure what you want to do exactly. If you can tell me more, I can advise you better
<poolie> you do
<poolie> fargiolas: you want a copy of the tree as at a particular revision?
<fargiolas> GaryvdM: I want to look at a project history looking at each commit changes
<GaryvdM> fargiolas: You do have a branch. do cd project-name; ls
<fargiolas> if you're familiar with git, I'd like something like git log -p
<poolie> 'bzr log -p' :-)
<fargiolas> really, cool :D
<fargiolas> as I said I'm pretty new to bzr, sorry :-)
<GaryvdM> fargiolas: no problem.
<vila> fargiolas: if you prefer fancy GUI, try 'bzr qlog' you need the qbzr plugin for that but it's worth it
<fargiolas> vila: I'll try it, thanks
<poolie> vila did you see spiv's neat "testdoc"? in lp:testdoc
<poolie> prints a summary of the contents of a test module
<poolie> i like '-f shiny'
<vila> poolie: yup, I need to use a dark backgrounf though or most of it is unreadble :)
<vila> ga <- fix typos
<spiv> poolie: yeah, I'll submit them.  I wanted to make sure the Inter1and2Helper fix got in because 2.2.1 is due quite soon.
<RomanMoz> How to launch bzr-gtk or bzr-explorer on Windows systems?
<GaryvdM> RomanMoz: If you installed with the windows installer, you should see a short cut in the start menu, and optionally on the desktop
<GaryvdM> RomanMoz: How did you install?
<GaryvdM> RomanMoz: From the console, you can run "bzr explorer"
<hrw> hi
<hrw> does someone here used bzr-git plugin?
<maxb> hrw: sometimes
<hrw> so far all my attempts ends with backtrace or other erros
<hrw> bzr: ERROR: Invalid http response for https://github.com/hrw/linaro-armel-cross-toolchain.git/info/refs: Bad status line received
<hrw> ok, found bug for it
<hrw> bug 581933
<ubot5> Launchpad bug 581933 in Launchpad Bazaar Integration "Imports from http://github.com fail, while ones from git://github.com work (affected: 1, heat: 6)" [High,Triaged] https://launchpad.net/bugs/581933
<jelmer> hrw: Hi
<jelmer> hrw: "smart" http repositories aren't supported yet, but git:// should work for github repositories
<hrw> 11:15 hrw@home:bzr-import$ bzr git-import git://github.com/hrw/linaro-armel-cross-toolchain.git
<hrw> bzr: ERROR: exceptions.AttributeError: 'InterRemoteGitNonGitRepository' object has no attribute 'fetch_refs'
<hrw> I prefer to create bzr branch with full git history but doing it by "git format-patch" + playing with bzr version of "git am" is what I do not want to play with
<jelmer> hrw: What version of bzr-git is that? Trunk should work.
<hrw>  *** 0.5.2-1 0
<hrw>         650 http://pl.archive.ubuntu.com/ubuntu/ maverick/universe amd64 Packages
<jelmer> hrw: Alternatively, you can have Launchpad do the import for you.
<hrw> jelmer: where it is in LP?
<jelmer> hrw: The "Import a branch" link on the Code page of a project.
<jelmer> hrw: Or if you mean bzr-git itself, lp:bzr-git
<hrw> ok, so time to create projects first
<poolie> vila wow we're really going to need to see about giving better errors on failure
<poolie> the assertionerror is not always super helpful
<jelmer> 'morning poolie, vila
<poolie> hi there jelmer
<vila> poolie: ECONTEXT
<vila> jelmer: hey !
<mgz> morning all.
<vila> mgz: _o/
<poolie> vila there's not much explanation of which bit of the script it's unhappy about
<poolie> but i just improved it slightly
<mgz> I see pqm doesn't have news merge.
<vila> poolie: ha, will lineno help ?
<poolie> it looks like only a few tweaks are needed to make '' not be a wildcard
<poolie> mm, or just giving the command line
<spiv> mgz: hmm yeah, I should probably file an RT to get it turned on.  It only helps a bit, but that's still worth something.
<poolie> that's not quite unambiguous
<poolie> spiv you should
<spiv> ok :)
<mgz> spiv fixed bug 625574 during the night?
<ubot5> Launchpad bug 625574 in Bazaar "testtools details should not be shared between parameterised tests (affected: 1, heat: 9)" [Medium,Confirmed] https://launchpad.net/bugs/625574
<vila> mgz: ha, thanks, I mentioned you to spiv but couldn't find back the mp... :)
<vila> spiv, mgz : I let you discuss it :-)
<poolie> actually spiv i thought there was one already?
<poolie> is this a known bug i sometimes get EBADF inside paramiko running parallel=fork?
<mgz> adding a copy method was what Robert mentioned as well, just hadn't got as far as digging into what would need fixing where myself
<poolie> probably thread leaks of some kind
<hrw> thx
<vila> poolie: I dunno it a bug ws filed for it, but yes, it's more apparent now that the leaks have been fixed but it's an old one
<vila> poolie: the root cause is that when a client and server communicate via socket the events related to the socket being EOLed do not always occur in the same order
<vila> poolie: we catch EBADF on both the client side and the server side, but paramiko use its own private thread, where EBADF, sometimes, occurs
<vila> poolie: IIRC it doesn't make the test fail thoug, it's just annoying to have it in the output at all :-/
<poolie> ah ok
<poolie> vila ah i see the naughty test_conflicts blackbox tests, but not in that directory :)
<vila> <shudder>
<poolie> hm
<poolie> so they are nice and readable
<poolie> they are kind of using the command line to do setup, which will tend to be slow
<vila> poolie: yeah, I should rewrite them into more precise tests as hinted earlier :)
<poolie> and i think was lifeless's objection to adding this facility
<poolie> just thinking out loud, not trying to give you a hard time
<vila> no no, np
<vila> I was in exploratory mode when I wrote them so they fitted the bill: how to create such and such conflicts
<poolie> some other things it's teaching me
<vila> AFAIK there are the most complex setups we have and spiv and I weren't fully happy about the parametrization either
<poolie> we're a bit inconsistent about stdout vs stderr (not totally news)
<poolie> and also, a universally respected -q would be good for these tests
<poolie> also apparently -1 doesn't work with --parallel
<vila> no, at best it could stop one thread (well process)
<vila> these tests are a good example of why I didn't care about command output... until the very end, so adding '...' for every line will make them *far* less readable
<poolie> actually -q is pretty good
<vila> on the other hand, they are not here to stay...
<vila> adding it to every bzr invocation in the script ? wfm
<poolie> to the ones you don't care about
<vila> an alternative would be to add an option to the run_script method to keep the actual behavior
<Glenjamin> hi guys, i'm trying to write a plugin to add credentials into gnome keyring in the format that bzr-gtk expects
<Glenjamin> but i'm getting lost in the code somewhat - can anyone point me to how to get the credentials stuff from a URL?
<vila> Glenjamin: look into bzrlib/transport/__init__.py split_url and unsplit_url
<vila> Glenjamin: be aware that the credential stores doesn't provide any facility for storing new credentials
<vila> Glenjamin: the rationale is that keyring, ssh-agents are best fitted for that
<Glenjamin> the gnome-keyring bit in bzr-gtk uses a hash of attributes to store
<Glenjamin> the gnome seahorse program doesn't let you set them
<Glenjamin> so i can't see a way to non-programatically set the password
<vila> I see, but still :)
 * vila searches
<poolie> so the good news is that -q does consistently suppress most stuff
<poolie> i suspect there are still some where it's not correct
<vila> Glenjamin: meh, seahorse let you create passwords or keyrings or ssh keys or pgp keys, what are you trying to create ?
<Glenjamin> http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/annotate/head%3A/keyring.py#L60
<Glenjamin> you can create a named password, but you cant set the attrs dictionary from seahorse - although it will display it for existing passwords
<vila> Glenjamin: did you look at oython-gnomekeyring ?
<Glenjamin> yes, it has bindings to let me store a password
<Glenjamin> i managed it manually
<Glenjamin> but now i want to be able to do "bzr gpass some://url" and have it prompt me for username/password, and store it
<Glenjamin> i'm struggling to convert the URL argument into the relevant bits however
<vila> Glenjamin: haaa, ok, so you don't try to store them in authentication.conf ?
<Glenjamin> as ideally i'd like to be able to plug in the same url that any other command would take - in this case it's a custom directory service which maps to bzr+https
<Glenjamin> vila: nope, if the password is in the keyring it seems to pick it up
<vila> Glenjamin: then look at bzrlib/transport/__init_.py
<poolie> that would be a nice feature
<Glenjamin> i'm intrigued as to how jelmer manages to get the passwords into keying - as he's the author of this bit of bzr-gtk
<vila> Glenjamin: that's the trick, it doesn't, he just uses the ones that are there
<vila> s/it/he/ sorry jelmer  :-/
<Glenjamin> but they'd have to get there somehow, no?
<jelmer> Glenjamin: other apps can add them
<poolie> yay, done, and not too tedious to change
<poolie> vila https://code.edge.launchpad.net/~mbp/bzr/scripts/+merge/35386 - no rush
<vila> Glenjamin: circa line 1354 there is one example
<poolie> thanks for the reviews!
<vila> poolie: ok
<vila> lunch time here, bbl
<Glenjamin> annoyingly, parsing the url just gives me bzr+https. which isn't much use. Since this is only for one repo i'm just going to make a more specific command. :(
<Glenjamin> i've run into a weird error. I've got an https smart server running, and http redirecting to https. if i try and do a command to bzr+https, i get an error about 401 being an invalid response. If i do bzr+http it redirects to https and prompts me for my password. :s
<Glenjamin_> and it only happens with pycurl
<knittl> hmm. how do i check if a revision is valid from a revision_dwim object?
<vila> Glenjamin: what do you mean by 'only bzr+https' ? Care to paste some code demonstrating that ?
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<vila> knittl: hmm, I don't think you can, the dwin processing is about trying various kind of revisions until one succeeds, see bzrlib.revisionspec circa line 325
<knittl> vila: well, i want to test if it's 0
<knittl> so -r0
<knittl> and print revision outputs <revision_dwim 0>
<vila> knittl: what's wrong with -rnull: ?
<knittl> vila: it crashes
<knittl> * <revisionspec_dwim 0>
<vila> knittl: what crashes ?
<knittl> bzr
<vila> ok, doing what ?
<knittl> inventory -r0
<knittl> inventory -r0 . works (giving filelist)
<vila> but it should output nothing right ?
<knittl> yes
<vila> file a bug, probably pretty shallow
<knittl> or a warning 'r0 does not have an inventory' or something like that
<knittl> vila: i try to fix it myself
<vila> knittl: good, thanks !
<knittl> that's why i asked how to check the revision ;)
<vila> knittl: but once the bug is filed you can assign to yourself and everybody will know it's a know one if they encounter it
<knittl> nobody is as stupid as i am and will try to show the inventory of r0 ^^
<knittl> yada yada
<vila> I'm surprised it didn't show up in other contexts... and that we don't have a test for that
<knittl> if type(dir_ie) is type(None): return;
<knittl> in inventory.py entries(self).descend(dir_ie, dir_path)
<knittl> seems to fix it
<vila> in descend ? yeah, I wsa there too (note that we use the 'if dir_ie is None' idiom instead
<knittl> that did not work
<knittl> but it was 4am when i tried last
<knittl> :D
<knittl> oh ok, works too :)
<knittl> should this go inside descend or should i check self.root before calling descend?
<knittl> checking root.self will be called only once instead of each subdirectory
<vila> knittl: I think it's an old code path, http://paste.ubuntu.com/493618/ works
<knittl> lol, ok
<vila> knittl: well, you did the hard work :) Please send a merge proposal !
<knittl> although entries(self) says "this may be faster than iter_entries"
<vila> no, it's bogus, it breaks the test suite
<knittl> ok, iter_entries works too
<vila> knittl: no it's not, it breaks the test suite :)
<knittl> what? entries()?
<knittl> hu
<knittl> what now? :D
<vila> hmm, may be the test suite is wrong and you uncovered more than you thought :)
<vila> knittl: told you :) File a bug, there are weird things there
<knittl> meh, i wanted to patch!!
<knittl> !bugs
<ubot5> If you find a bug in Ubuntu or any of its derivatives, please file a bug using the command Â« ubuntu-bug <package> Â» - See https://help.ubuntu.com/community/ReportingBugs for other ways to report bugs - Bugs in/wishes for the IRC bots (not Ubuntu) can be filed at http://bugs.launchpad.net/ubuntu-bots
<knittl> !bugs bzr
<knittl> stupid bot xD
<vila> knittl: Please keep working on the patch ! :) You can then do a merge proposal and with that and the bug, we are sure to track the issue until it's fixed
<knittl> well for me both iter_entries() and entries().descend() with the if dir is none works
<knittl> i haven't run the testsuite though
<vila> knittl: I did run it in a dirty bzr, cleaned now, re-running
<vila> knittl: you could run of subset with 'bzr selftest -s bt.test_inventory
<knittl> bzr: ERROR: No module named testtools?
<vila> knittl: argh, yes, OS/version ?
<knittl> maverick
<vila> knittl: cool, so just apt-get or synaptic will do
 * GaryvdM really really really would like to have shallow branches...
<knittl> GaryvdM: hm?
<vila> GaryvdM: even if your mirror updated your repo at night ?
<knittl> thought bzr would already allow such a thing
<knittl> vila: what's the package name?
<vila> GaryvdM: or say, every hour (which should be fast enough)
<knittl> python-testtools?
<vila> knittl: let me check, but if this one exists, sure
<vila> yes
<vila> knittl: it's a bit old, (0.9.6 has been released) but it shouldn't matter (/me crosses fingers)
<GaryvdM> vila: I'm branching a piece of code I don't normally work on
<GaryvdM> lp:ubuntu/ubiquity
<knittl> vila: http://paste2.org/p/987536
<GaryvdM> and my internet line is being very slow, I'm only doing 2kB/s
<vila> knittl: ok, now try: 'bzr selftest -s bt.test_inv -s bb.test_inv -s bb.test_non_ascii'
<knittl> ok, running
<maxb> testtools 0.9.4' is in ~bzr/proposed, ftr, though Martin gz said it may be more buggy than 0.9.2 in some areas
<Lor> How does one copy an entire colo workspace and its branches? colo-sync-* requires that there already exists a mirror workspace.
<Lor> Is one supposed to do a bzr colo-init followed immediately by a colo-sync-from?
<knittl> vila: "ran 729 tests in 164.478s OK"
<vila> knittl: sounds good, what's your patch ?
<knittl> if self.root is not None: descend(self.root, u'')
<Glenjamin> vila: http://paste.ubuntu.com/493632/
<vila> knittl: hmm, there are valid cases where self.root is None while the inventory is not, this sounds like bad test coverage :-/
<vila> Glenjamin: well, in that case user and password are None indeed
<knittl> vila: mehâ¦
<knittl> vila: but no
<knittl> self.root cannot be none in entries
<Glenjamin> this is the bit where i'm trying to get the attributes of the URL to store against the keyring
<knittl> because if it is None the .children call will fail
<Glenjamin> which would be protocol = https, server = bzr.genesys-solutions.co.uk; I know i can just chop bzr+ off the front - but that kinda feels like cheating
<vila> knittl: typed too fast, checking something (in this code path you're right, but the Inventory __init__ allows it to be None)
<knittl> i'm only checking in descend
<Glenjamin> ideally i want to try and access the url, and then where it would normally go hit the credential stores, just grab those attributes and prompt for a user/password that then gets saved.
<Glenjamin> but i dont think the stack is really set up for that.
<knittl> how can i set name and email locally for a branch?
<knittl> and how can i amend the last commit? (override author information)
<knittl> and what's the equivalent of git's format-patch?
<vila> Glenjamin: indeed the stack is not setup for that yet (well, only in a rudimentary form which doesn't interact with credential stores IIRC)
<vila> knittl: bzr whoami
<vila> knittl: bzr uncommit; bzr whomai; bzr commit
<knittl> vila: no, whoami is globally
<knittl> uncommit will clear my message?
<Glenjamin> in my particular case the repository is always the same, so i added a command which can store credentials for that repo. But my plan of making a generic "gpass" command is pretty much kaput
<vila> knittl: bzr push lp:~knittl/bzr/bug#-fix-inv-r0 ; bzr lp-open
<Glenjamin> whoami accepts a --branch option
<GaryvdM> knittl: If you use qcommit, it will uncommit will remember it for you
<vila> thanks for the support guys :-D
<GaryvdM> knittl: I think to set whoami for a branch, you have to edit .bzr/branch/branch.conf  . I'm not sure if there is a ui for that.
<GaryvdM> knittl: Not you can also do bzr commit --author
<knittl> GaryvdM: whoami --branch works
<GaryvdM> s/Not/Note
<GaryvdM> knittl: Oh - learn something everyday :-)
<Glenjamin> bzr help whoami revealed its secrets :)
<knittl> ok, so i need to push to launchpad?
<vila> knittl: that's where you will be able to create a merge proposal and where we will review it
<knittl> bzr-pqm is correct 'parent'?
<knittl> ugh, now for the reporting part
<GaryvdM> knittl: Yes
<knittl> https://bugs.edge.launchpad.net/bzr/+bug/379740
<vila> knittl: yes, bzr-pqm is our automated gate keeper that ensures that all commits on the mainline pass the whole test suite
<ubot5> Launchpad bug 379740 in Bazaar ""bzr inventory -r 123" requires a working tree (affected: 1, heat: 0)" [Medium,Confirmed]
<knittl> looks like the bug?
<vila> knittl: nope, some command but different bug
<vila> same ...
<knittl> vila: but -r0 will also have no working tree?
<vila> knittl: no, it can have an empty working tree
<vila> knittl: this bug is about using 'inventory' on treeless branches
<knittl> whatever. report a bug *click*
<knittl> vila: ah ok. understood!
<knittl> done: https://bugs.edge.launchpad.net/bzr/+bug/638034
<ubot5> Launchpad bug 638034 in Bazaar "`bzr inventory -r0` crashes because self.root is None (affected: 1, heat: 6)" [Undecided,New]
<knittl> what can i do with a file_id? is there a way to `bzr cat` it?
<dobey> i'm trying to fix up the test suite in tarmac to use bzr's TestCaseInTempDir, and super() instead of direct calls up to the parent, but now i'm getting a weird error: http://pastebin.ubuntu.com/493658/
<dobey> can anyone help me figure it out?
<james_w> dobey: it's still going through TestCaseWithMemoryTransport, I didn't think TestCaseInTempDir was a subclass of that
<dobey> james_w: nothing in my tarmac tre eis using TestCaseWithMemoryTransport though
<jelmer> knittl: it's used internally in bazaar, not really exposed at the UI level. why would you want to ?
<knittl> jelmer: showing an inventory -> displaying file contents
<dobey> james_w: i guess super() just really hates multiple inheritence :(
<mgz> class TestCaseInTempDir(TestCaseWithMemoryTransport):
<jelmer> knittl: is there a particular reason for not doing that by file path though?
<mgz> inheritance doesn't look wrong to me.
<knittl> jelmer: file paths may change?
<jelmer> knittl: Not in a particular inventory.
<knittl> but between revisions
<jelmer> knittl: But you just mentioned you wanted to lookup paths in an inventory
<jelmer> s/paths/files?
<jelmer> s/paths/files/
<knittl> what's wrong with using file_ids?
<mgz> dobey: a minimal test case that gets you that stack would be helpful
<knittl> (god i hate bazaar)
<knittl> when i want to know how to display contents of file ids i want to do that, i don't want to show contents of a normal file or use its filename â¦
<knittl> (sorry, pet peeve)
<jelmer> knittl: What are you trying to do exactly?
<jelmer> knittl: You seem to be mixing storage-specific things with UI concepts.
<knittl> i'm not interested in UI
<knittl> but i'd prefer having a command in bzr which does what i want
<Glenjamin> then that would be UI, no?
<jelmer> knittl: can you give us some more context?
<knittl> i'm analysing storage/object models of different dvcss
<knittl> and bzr documentation is really awful
<knittl> i'm reading pydoc of inventory classes
<knittl> so bzr inventory -v --show-ids will give me names and their id
<knittl> i guess bazaar tracks history per file (not easy to find either)
<knittl> and a file_id identifies a specific file
<knittl> so i should be able to show its content by using the file_id
<jelmer> you would need both the file id and the revision id
<knittl> ok, i don't care if i need revid as well
<knittl> how can i display it? you can also link me to a page which describes the command (or tell me the command name)
<jelmer> knittl: bzr cat
<jelmer> knittl: though you specify the path and the revision
<knittl> i don't want to use the path
<knittl> i'm specfically asking for file_id
<jelmer> knittl: Why not? the path is unambiguous if you also specify the revision
<knittl> is there a *single* identifier of a file in a revision?
<jelmer> knittl: yes, the path.
<knittl> that's path+rev
<knittl> that's two things, not a single one
<jelmer> knittl: right
<Glenjamin> you said "in a revision"
<knittl> "of a certain revision of a file" <- better?
<jelmer> knittl: a tuple of a revision and a path, or a tuple of a revision and a file id
<roryy> i'm trying to find an easy bug to fix; 521452 looks doable, but I can't reproduce it with 2.1.0rc1 (where it was reported) or the tip.  Any hints?  I've tried on Ubuntu 9.10 and using Wine on the same system, but no luck
<knittl> bzr cat -r5410 bzrignore-20050311232317-81f7b71efa2db11a
<mgz> roryy: it may have been incidentally fixed by poolie
<knittl> not working â¦
<jelmer> knittl: Why would you prefer that to "bzr cat -r5410 .bzrignore" ?
<mgz> rorry: do you want suggestions for starter bugs?
<roryy> mgz: please
<knittl> jelmer: because i say so -.-
<jelmer> knittl: Anyway, the short answer is that there's no way to cat by file id from the UI.
<mgz> rorry: first, if you'd like to test my theory on that you could try checking out a rev before poolie's change, and if the bug exists there but not now, closing that bug as fixed
<knittl> jelmer: that sucks â¦
<mgz> rorry: appears to have been merged in r5371, so try r5370
<roryy> mgz: cool, thanks.  I'll try that
<knittl> jelmer: hg has `hg debugdata` and `hg debugindex`
<mgz> rorry: for bugs to work on, see https://bugs.launchpad.net/bzr/+bugs?field.tag=easy - but again some of these may have already been fixed, and some may not actually be easy at all, so feel free to ask questions
<roryy> mgz: will do.  and some tagged "easy" definitely don't look that easy :-)
<mgz> any luck repoing your first bug on an earlier bzr?
<roryy> mgz: no.  still checking that i haven't made a mistake, tho
<mgz> it might help to go back even earlier, to a rev from the same time when Gary filed the bug
<roryy> i tried that by checking out tag 2.1.0rc1
<roryy> sorry, that's for 515569, for which the other is marked as a dupe
<mgz> was just about to ask that.
<Glenjamin> https://bugs.launchpad.net/bzr/+bug/202374 looks like a nice first bug
<ubot5> Launchpad bug 202374 in Bazaar "pull and update should accept --show-base (affected: 0, heat: 0)" [Medium,Confirmed]
<mgz> or how about bug 417922
<ubot5> Launchpad bug 417922 in Bazaar "treat MemoryError as a special/environmental error (affected: 1, heat: 0)" [Medium,Confirmed] https://launchpad.net/bugs/417922
<mgz> I know that code so can help you write a test and everything.
<roryy> I probably need to be able to reproduce this simple bug before i try anything more ambitious
<mgz> ...I'll try and repo here, it may well be you're doing nothing wrong
<mgz> ...quick thought though, you are using ./bzr in the directory of the checkout right?
<roryy> yeah
<mgz> okay, I can't repo with either of those old revs either.
<dobey> mgz: http://pastebin.ubuntu.com/493724/
<knittl> can i use a hash instead of a revno?
<knittl> and how do i find the hash of a revision
<dobey> mgz: testing that with trial gives the same error
<Glenjamin> knittl: bzr help revisionspec
<knittl> ok. and how do i get the revid?
<mgz> dobey: okay, yeah, that's you getting screwed by multiple inheritance
<Glenjamin> bzr log -v -r<n> i guess
<knittl> no, cannot see it
<vila> --show-ids
<dobey> mgz: so what can i do?
<Glenjamin> ^^
<Glenjamin> i think bzr qlog shows it
<knittl> -v often does nothing
<mgz> not create the tempdir in BaseTestCase I'd suggest
<knittl> inventory -v: same as inventory
<knittl> vila: thax
<knittl> * thanks
<vila> inventory is an hidden command, it get far less love than the exposed ones :)
<knittl> it got a patch from me today â¦
<vila> -v is not used coherently
<knittl> that means a lot
<knittl> but it's displayed in the help of inventory
<Glenjamin> "bzr rocks -v" is the same too
<vila> knittl: revids and file-ids are *internal* ids, if you want to manipulate them, you'd better use bzrlib (the library, developer oriented) not bzr (the command-line user-oriented tool)
<knittl> i don't want to manipulate them
<knittl> just use them
<vila> s/manipulate/address|get your hands on/ same thing
<knittl> no, quite different
<dobey> mgz: and why does the first test pass, but all subsequent tests fail?
<vila> bzr do not accept them anywhere from the command-line, except for the revid but it's not the recommanded way
<Glenjamin> first passing others failing sounds like not resetting state to me
<mgz> because you remove the attribute tempdir, which the bzr class uses for a non-test-specific tempdir
<mgz> and you removed it.
<vila> Glenjamin: yeah, in this specific case, it's even: blowing up the state ;D
<mgz> dobey: just don't do this: tempfile.tempdir = os.getcwd()
<mgz> but ideally, if you want to be using TestCaseInTempDir, don't do any of that stuff in the other base test case
<dobey> we have to do stuff in the other base test case, because we have to create other files
<dobey> if i just make the base test case use TestCaseInTempDir instead, then all the tarmac tests fail
<vila> dobey: and inheriting from TestCaseInTempDir ?
<dobey> vila: hmm?
<vila> dobey: make your base class inherit from TestCaseInTempDir
<dobey> i did that
<dobey> and everything else failed.
<vila> single inheritance
<vila> class BaseTestCase(TestCaseInTempDir)
<knittl> bzr revision-history is nice
<mgz> vila, I think ideally he'd do that, but he's trying to update an existing suite and that means lots of changes
<vila> right
<dobey> well ideally i wouldn't be here having this discussion, because the code i wrote to change this over, would just work
<dobey> it works fine if i don't do super(), and instead just call up directly
<mgz> life is never that simple :D
<vila> dobey: you can also calls both setUp and tearDown explicitely, but that won't address stepping on other toes^W attributes
<mgz> anyway, just don't assign to global state in the tempfile module
<mgz> it's dodgy and unneeded
<mgz> does that change then get your real tests passing?
<mgz> (there's no reason to change to using super for the cases it actually breaks)
<dobey> they appear to pass with that change, but i suspect there will be other problems
<dobey> and if changing it breaks the bzr test case, then the bzr test case is probably doing it wrong
<knittl> why does bzr revision-history not take a revision as its argument?
<vila> knittl: because hidden commands are generally written for a specific need and then forgotten
<mgz> dobey, no, do you want me to walk you through why that's bust?
<knittl> vila: it would make a lot of sense
<knittl> like git's rev-list
<mgz> the point of TestCaseInTempDir is it creates a tempdir and chdirs into it
<knittl> so bzr revision-history -r1000
<mgz> super call like that means it gets called first
<knittl> show history from r1000 to 0
<vila> knittl: seen the see also for revision-history ? That's what 'bzr log' does
<mgz> you then set the global tempfile default creation to the cwd, which, remember, is going to get deleted in teardown
<knittl> vila: hm?
<knittl> 'seen the see'?
<knittl> also bzr log shows a lot more
<mgz> so the next tempdir that is going to get created is put in a dir that was deleted at the end of the last test, hence error
<vila> knittl: bzr help revision-history | grep 'See also'
<knittl> i don't understand
<vila> knittl: why add -r to revision-history when it's already implemented for log whose job is to display the history of the branch
<knittl> vila: log shows a lot more info than revision-history
<vila> knittl: indeed, listing the revids only doesn't make a lot of sense that's why the command never get more love
<knittl> *sigh*
<knittl> vila: listing only revids makes a lot of sense when analysing low level architecture of different systems
<rubbs> knittl: the point is, that it wouldn't be a command commonly used. most people wouldn't care about it.
<knittl> bzr is not doing well so far: little documentation, everything is hidden and locked away from the user, nobody can properly explain object/history model and different types of objects, etc.
<vila> knittl: I understand that and I think we've already had this discussion.
<mgz> trying to analyse low level architecture from the command line doesn't make any sense at all. why don't you use a Python repl like any sane person would?
<knittl> vila: yes, i say that a lot after i've been asking for something in #bzr :D
<knittl> mgz: because the command line tools are (generally) there already
<vila> i don't understand
<mgz> so, they aren't, and you'd just spent a couple of hours complaining about that.
<knittl> mgz: yes.
<mgz> why not drop that particular hammer and pick up a more suitable tool?
<rubbs> also, I'm interested in why you think documentation isn't there. We specifically picked bzr here for a few reasons: Better windows support, and good end user documentation. The things that 90% of people use are documented and documented well. Are there holes, yes, but no more so than other projects.
<roryy> mgz: i've more-or-less given up on bug 515569 after trying it on several revisions: 4933, 4934, 4967, 5019, 5365, 5310, which seem to be when bzrlib/ui/text.py had relevant changes.  I think generating a test case might be harder than it appears.
<ubot5> Launchpad bug 515569 in Bazaar "progress bar is not removed when bzr exits (affected: 3, heat: 12)" [Medium,Confirmed] https://launchpad.net/bugs/515569
<knittl> rubbs: end user documentation might be good, but i don't read end user documentation
<knittl> it also lacks a lot when it comes to history/object model
<mgz> rorry, I fear you're probably right there. leave it for the moment, and maybe bug garyvdm or bialix about how they hit it if you see them in the chat
<knittl> i have yet to find good architectural documentation
<rubbs> knittl: ah, thank you for that clarification.
<roryy> mgz: on bug 417922, i see martin pool did do something in 4634.26.1 -- did you have something else in mind?
<ubot5> Launchpad bug 417922 in Bazaar "treat MemoryError as a special/environmental error (affected: 1, heat: 0)" [Medium,Confirmed] https://launchpad.net/bugs/417922
<knittl> rubbs: with 'i don't read end user docs' i mean, that end user documentation is irrelevant here for me. it does not contain the information i need
<rubbs> knittl: i understand, I just didn't understand when you said bzr had little documentation. I've found that teaching it to my devs here was much easier because they had a lot of good documentation, but I have no experience with dev documentation, only user documentation.
<rubbs> so I can not comment one way or the other on it.
<knittl> maybe i've just been missing it the last month
<knittl> but nobody could point me to good docs
<knittl> also the wiki has links to interesting articles
<knittl> just to find those articles are empty
<mgz> rorry, ha, another bug poolie fixed?
<knittl> or have a single line of content
<roryy> mgz: i think so.  i must go now; i'll have a look at the bug Glenjamin suggested.
<mgz> okay, sorry for the bumpy start they rorry.
<mgz> *there
<knittl> how do i go about adding a testcase for bzr inventory -r0?
<jam> knittl: I just replied to your email
<jam> I don't think we really care up at the 'bzr inventory' level, but it is good to have it at the Inventory level
<knittl> jam: ok
<knittl> that way it was easiest to explain here
<jam> knittl: sure
<jam> I'm just saying that you *could* explicitly test 'bzr inventory -r0' in a blackbox test, but I think testing closer to the change is better
<knittl> i'm not interested in `bzr inventory` either, it's just the command where i found it to fail
<knittl> how can i run only that test?
<knittl> because i updated to the previous revision and the tests pass
<knittl> `bzr selftest -s bt.test_inv -s bb.test_inv`
<jam> knittl: roughly that, you have to make sure to not just create "Inventory()" since the default creates a root
<knittl> so overwrite root after that?
<knittl> no, root_id is None
<knittl> self.assertEqual(true, false) should always fail, right?
<knittl> the test is not called :(
<knittl> afk for 30 min â¦
<danto> Hi, how could I capture an error status of a bzr update in a bash script?
<danto> Hi, how can I capture an error status of a bzr update in a bash script?
<GaryvdM> danto: you could check the return code ($?), and/or pipe the stdout to a file.
<GaryvdM> danto: Or put the stdout in a var
<GaryvdM> var = $(bzr update)
<GaryvdM> Oh -  that does no work, not sure why. Sorry
<danto> thanks GaryvdM, I'm already trying to pipe the stdout and doing grep -i error but doesn't work; bzr's error seems to broke any pipe
<GaryvdM> danto: Oh - let me try it myself.
<danto> GaryvdM, sure
<GaryvdM> danto: That's odd. bzr update | more does not work, but bzr update | less does.
<GaryvdM> danto
<danto> GaryvdM, I'm here
<GaryvdM> danto: I'm not sure. Maybe someone else may be able to help
<GaryvdM> danto: Sorry, I misspress enter after typing your name. :-)
<danto> thank you GaryvdM :)
<jam> danto: have you checked stderr vs stdout?
<jam> bzr update 2>&1 | less
<danto> jam not yet, I will try and let you know, thank you :)
<sender> I
<sender> I'm running python 2.5, but can't compile the extensions runnin 'make' b/c of missing python pyrex. Aptitude install python-pyrex gives me python 2.4.
<sender> Should I downgrade python? :S
<mgz> try cython instead.
<mgz> I'm guessing you're on lenny or an older ubuntu.
<sender> mgz: thanks, that's right, lenny
<sender> mgz: will cython give me pyrex?
<mgz> it's an alternative, yes.
<sender> mgz: i installed it, do i need to take extra steps?
<sender> mgz:  the make command still fails :/
<mgz> you may need to purge pyrex as well.
<mgz> seems we try for pyrex first in the setup script for some reason.
<sender> mgz: No Pyrex, trying Cython...
<sender> mgz: bzrlib/_annotator_pyx.c:4:20: error: Python.h: No such file or directory
<sender> mgz:   Cannot build extension "bzrlib._annotator_pyx".
<mgz> ah, you need the build deps as well.
<sender> mgz: any clues?
<sender> mgz: build-essential is installed
<chx> I just installed bzr 2.2 from PPA to be able to run bzr resolve --take-other and i got bzr: ERROR: Tree transform is malformed [('duplicate', None, 'new-1', None)]
<GaryvdM> sender: sudo apt-get build-dep bzr ?
<GaryvdM> Hi mgz
<mgz> thanks gary, couldn't remember the incantation.
<mgz> chx: bug 430129 look like it?
<ubot5> Launchpad bug 430129 in Bazaar "merge aborts with Tree transform is malformed [('unversioned executability', 'new-1')] (affected: 1, heat: 2)" [Medium,Confirmed] https://launchpad.net/bugs/430129
<mgz> or bug 611739 instead?
<knittl> how can i run a specific test?
<ubot5> Launchpad bug 611739 in Bazaar "shelve problem on shelving directory with ignored file inside (affected: 1, heat: 4)" [Medium,Confirmed] https://launchpad.net/bugs/611739
<chx> mgz: i dunno. the merge finished.
<sender> GaryvdM: thanks
<chx> mgz: it's not shelve either.
<mgz> file a new bug then.
<chx> so this is a bug.
<chx> any way to get somethin gmore detailed  to help you guys with?
<mgz> yeah, look in bzr log for the traceback and extact command you ran
<mgz> and paste that into the bug
<knittl> need help with bzr tests please â¦
<mgz> `bzr help selftest`
<knittl> â¦
<knittl> how can i run tests for inventory?
<knittl> bzr selftest inventory does not work
<chx> oh good lord, bzr logs everything?
<mgz> it's alright, we don't tell your mom.
<mgz> `bzr selftest -s bt.test_inventory`
<knittl> mgz: it does not run a test
<knittl> self.assertEqual(true, false)
<knittl> oh, wait
<knittl> no, still. it should fail, but does not
<mgz> paste the full diff of your change to the file I might be able to help you write a working test.
<mgz> true and false should raise NameError if nothing else, this isn't cpp
<knittl> asserting true and false should fail â¦
<mgz> seriously, pastebin, bzr diff.
<chx> mgz: https://bugs.launchpad.net/bzr/+bug/638451 enough? need more?
<ubot5> Launchpad bug 638451 in Bazaar " bzr resolve --take-other bzr: ERROR: Tree transform is malformed [('duplicate', None, 'new-1', None)] (affected: 1, heat: 6)" [Undecided,New]
<mgz> looks pretty good chx, did you notice anything else odd?
<chx> yes. bzr 2.2 is even more awesome than usual :p
<knittl> http://paste2.org/p/988130 @mgz
<mgz> what did the merge consist of, how did you work around etc.
<chx> uuuuuuhuuu
<mgz> just ideas, generally the more you can braindump now the less you might have to remember later
<mgz> knittl: that's in test_inv
<knittl> so?
<mgz> so, I guessed the name of the file wrong when I said -s bt.test_inv....ENTORY
<chx> mgz: I have a branch (alas, private project on lauchpad) stacked on top of a two months old lp:drupal. There are changes. I took a new lp:drupal , applied those changes, resolving the conflicts etc and then wanted to merge this back
<chx> mgz: so it's a bit complicated.
<knittl> it's in the inventory.py file
<knittl> no, test_inv
<mgz> the test is on the path bzrlib.tests.test_inv....
<maxb> jelmer: Are there any neat tricks for causing bzr-svn to redo a find_tags_between, after the initial attempt after a 'bzr branch' threw an exception?
<mgz> which is what -s wants
<mgz> chx: that sounds relevent I'm afraid, so if you could try and explain it in the bug I'm sure it'd help
<knittl> selftest -s bzrlib.tests.test_inv?
<chx> mgz: can you guys reach private LP repos?
<mgz> yeah, or the bt. shortening
<mgz> chx: I can't personally, but canonical support people probably can.
<knittl> ok, it fails now
<knittl> good :)
<GaryvdM> knittl: You can check if your test is included in your regex/-s by running bzr selftest xxx --list
<mgz> or just -v, yeah.
<GaryvdM> ah
<knittl> included in my regex?
<knittl> ok, test failed. test runs without errors. WIN!
<mgz> or your -s - selftest has a few different ways of selecting tests
<mgz> a winner is very nearly you.
<chx> mgz: okay i included the examiner trunk uri then
<knittl> no, it failed and after applying my patch it succeeds
<mgz> chx: fantastic, thanks.
<GaryvdM> Is there some where (like a faq) that explains why bzr-svn often ends up with ghost revs?
<mgz> knittl: right, you've nearly got your fix landed.
<mgz> fix done, test done.
<mgz> you want to deal with all the annoyance in one day? then...
<GaryvdM> I would like to link to such a thing in bug 638422
<ubot5> Launchpad bug 638422 in QBzr "qlog: Delta loading crashes on GhostRevisionError (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/638422
<mgz> knittl: have you signed the canonical contributor agreement?
<knittl> no
<mgz> have fun: http://www.canonical.com/contributors
<knittl> do i have to?
<mgz> yup, but it's reasonably non-onerous
<mgz> then you'll have nearly seen your fix through from >_< to :D and it'll just want approval and landing
<mgz> garyvdm: might be a question for the mailing list.
<mgz> some kind of ghost writeup is needed if it doesn't already exist.
<GaryvdM> mgz: Ok
<sender> Getting: bzr: out of memory on a simple branch from 1 server to an other
<danto> <jam> danto: have you checked stderr vs stdout? + <jam> bzr update 2>&1 | less <-- yes, it works thanks again :)
<sender> source branch is 40K (as outputted by du -h)
<danto> sender, see du -h .bzr
<danto> I have 137M of videos in a branch but .bzr is about 1.4G  :S
<sender> danto: ok, well it seems that the repo is fine, i just get an out of mem on a branch
<lifeless> sender: what bzr versions are you using on the client and server?
<sender> lifeless: thanks for the reply
<sender> lifeless: Bazaar (bzr) 2.2.0 on the client (target)
<sender> lifeless: Bazaar (bzr) 1.13.1 on the server (source)
<mgz> sender: try nosmart+ for the server url.
<sender> mgz: thanks, running now
<sender> mgz: lifeless: i do get "Doing on-the-fly conversion from RepositoryFormatKnitPack1() to RepositoryFormat2a()." Problematic?
<mgz> can be, yeah.
<lifeless> thats a very memory intensive operation
<sender> mgz: lifeless: must admit I kinda got lost with repo formats during updates of bzr over the last 2 years or so
<sender> mgz: lifeless: mem 100% and process seems halted
<GaryvdM> sender: bzr has tried to reduce the format churn. 2a has been arround for more than a year, and there is a strong commitment to stick with it as the default for a lot longer.
<poolie> yup
<mgz> okay, sender, in which case
<poolie> hi gary, lifeless
<mgz> you'll want to branch to a fresh repo, so no format conversion
<mgz> then upgrade
<sender> GaryvdM: great
<GaryvdM> Hi poolie
<sender> mgz: ok, can I do that with that old version of bzr, or first install 2.2?
<mgz> you can do that as is.
<mgz> and later push the upgraded version back to the server if you put a newer version of bzr on there
<mgz> so, branch to a new dir not inside a shared repo is step one.
<lifeless> hi poolie
<sender> mgz: ok, new repo is Standalone tree (format: pack-0.92). I run bzr upgrade?
<mgz> yup, which may again run out of memory, but hopefully won't.
<mgz> if it does, just stick with the old format locally for the moment.
<sender> mgz: out of mem on the upgrade :(
<sender> mgz: would it be smart to do a (lightweight) checkout instead of a branch and later unbind? to split up operations..
<mgz> well, there's no reason you shouldn't use the old format for the moment locally
<lifeless> spiv: does bzr have any double-parameterised tests?
<lifeless> spiv: I mean foo(Bar)(Quux)
<lifeless> spiv: if so, the __copy__ hack will silently break them.
<lifeless> spiv: (including in plugins or launchpad or other subclassers.
#bzr 2010-09-15
<sender> mgz: i have to go, thanks for the help, i'll try again tomorrow
<spiv> lifeless: hmm, yes.  Drat.
<lifeless> spiv: can I suggest:
<lifeless>  - fix it well in testtools
<lifeless>  - depend on that
<lifeless>  - revert the bzr change
<spiv> Well, it certainly has scenarios with (x,y), but I *think* it may have (x)(y) too.
<spiv> I wouldn't expect the breakage to be silent, though, because the attributes would tend to be missing or None.
<lifeless> spiv: would depend on the test code I guess
<spiv> Yeah.
<poolie> hi there spiv
<spiv> Hi poolie
<spiv> My fix for ssl.py got accepted into Python 2.7 upstream and python2.6 in Ubuntu.
<lifeless> \o/
<lifeless> although, now yu don't know if 2.6 works everywhere :P
<spiv> Well, the test failure it causes is intermittent IIRC (hooray threads :/)
<poolie> good for you
<poolie> i think i saw that bug a couple of times yesterday running my own tests
<spiv> I guess I should nag about getting my paramiko IPv6 fix in upstream and maverick too.
<poolie> could be good
<poolie> i got a few pqm failures and review comments yesterday so i'm going to do them first
<poolie> then push on detecting stale locks
<poolie> also post "what do you do"
<poolie> you should do that too spiv, if you didn't already
<poolie> i'm happy to read it
<maxb> Why does bzr selftest say ERROR when a test raises TestSkipped?
<maxb> It's most unhelpful :-/
<lifeless> maxb: python 2.7?
<maxb> 2.6
<lifeless> hmm
<maxb> A fairly ordinary lucid installation, in fact
<poolie> maxb i've never seen that
<maxb> how bizarre. I wonder why my system is broken :-(
<poolie> you can dig in to it...
<maxb> I'm already digging into something that occurred whilst digging into something, my stack is overflowing :-)
<poolie> maxb, np, then i'm inclined to write it off
<poolie> if something weird occurs let me know
<poolie> maybe you're using the wrong bzr?
<poolie> i mean the wrong bzrlib
<abadger1999> Okay -- stupidity question time
<abadger1999> I just rm -rf 'd a branch that I had.
<abadger1999> But the branch was in a shared repository.
<abadger1999> Is there any way to recover my last commits?
<abadger1999> I figure I have in the neighborhood of five commits since my last push
<fullermd> You can use heads to suss it out.
<abadger1999> k
 * abadger1999 reads the man page on bzr heads
<fullermd> Then just something like `bzr init foo ; cd foo ; bzr pull -rwhatever .` to pull it up.
<abadger1999> <nod>
<abadger1999> fullermd: Thanks!
<spiv> lifeless: https://code.edge.launchpad.net/~spiv/bzr/traceback-accumulation-2.2/+merge/35494
<abadger1999> fullermd: Thanks, that seems to have worked.
<poolie> lifeless: have you still got a traceback for bug 636946?
<ubot5> Launchpad bug 636946 in Bazaar "shelve NEWDIR/NEWFILE tries to shelve NEWDIR (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/636946
<poolie> i realize it's probably obvious where it's raised, but just in case
<lifeless> no, rebooted since sorry
<poolie> not in .bzr.log?
<spiv> poolie: rt 41382 filed for news_merge on PQM
<poolie> thanks
<vila> hi all
<poolie> hi vila, bialix
 * poolie was just going to see about fixing bug 220463
<ubot5> Launchpad bug 220463 in libvirt (Ubuntu) "unable to boot linux vm's that are not Debian derived. (affected: 1, heat: 3)" [Undecided,Fix released] https://launchpad.net/bugs/220463
<poolie> bug 220464 actually
<ubot5> Launchpad bug 220464 in Bazaar "Bazaar doesn't detect its own stale locks (affected: 0, heat: 2)" [High,In progress] https://launchpad.net/bugs/220464
<bialix> hi poolie, vila and all-all-all
<vila> poolie: oh, on that subject, how are would it be to make bzr-2.[01] accept (and ignored) more data in the lock info files ?
<vila> s/how are/how *hard*/
<poolie> probably easy
<poolie> they may already do it?
<vila> poolie: that would allow bzr >= 2.3 to put more data there
<spiv> vila: well, the fix to #619872 should have done that, if it wasn't already the case.
<poolie> however if it does need a code change, it may be hard to make sure that everyone using those versions actually gets the code change
<spiv> vila: (well, to be clear, the fix for 619872 should prevent bzr from blowing up if it can't parse the lock info file, I'm not sure whether new fields would affect the parsing or not)
<vila> poolie: rats, right, but that would matter only for projects where people use a mix of < 2.0 and >= 2.0
<vila> spiv: that's where I started thinking about that, I think you made it more resistant to empty or null-filled info files but I'm not sure about additional fields
<poolie> vila i'm pretty sure it will ignore extra fields
<vila> ok (one off my head :)
<spiv> vila: well, the intent was to cope gracefully with any error from reading and parsing the info file.
<poolie> vila iow if you want to add data, just do it, and then check it with old code
<vila> spiv: sure, not throwing stones, I didn't think about it before it landed anyway
<poolie> but i'm pretty sure it will work
<poolie> what did you want to add?
<vila> <cough> can't remember at the moment :) I didn't forget the constraint though...
<vila> I'll tell you when I remember :)
<vila> The only thing that comes to mind right now is adding the command at the highest level but I'm pretty sure it was something else
<poolie> if we know a lockdir holder is a dead process from the same machine, will it be ok to automatically break it?
<vila> poolie: with a warning, yes
<poolie> meaning we just print a message then do it?
<vila> poolie: yup, if you want to be anal you can make it depend on config var for paranoids to set
<poolie> good idea
<poolie> vila, that's kind of a case where we could say "there is a ui confirmation, but it's turned off by default"
<vila> poolie: yes, but a bit different than deny_action() or confirm_action(default=False) still
<vila> break_lock=yes/no/sometimes/always/ask :)
<vila> 5-values boolean ftw !
<vila> no. seriously.
<vila> failing because a lock has been created by a process we're sure is dead is silly,
<vila> "I can't lock, someone else did", "someone else is dead, break the lock manually" "are you sure you want to break the lock ?"
<spiv> mutt has the concept of a "quadoption", which can be yes, no, ask-yes or ask-no.
<vila> vs "I can't lock, someone else did ; it's dead, let's break the lock"
<spiv> (ask-yes causes a prompt with a default answer of yes)
<vila> the warning is there to help people tracking the root cause if it happens too often
<poolie> so maybe yagni and i'll just give a warning
<vila> poolie: yup
<spiv> Fewer options is a good thing, when possible.
<vila> Don't ask if you're going to accept a single answer too ;)
<poolie> well, the answers are really "sure/wtf"
<spiv> (a)bort/(r)etry/(w)tf?
<vila> (W) to indicate the default
<poolie> so i can think of cases where people have multiple machines all called 'ubuntu'
<poolie> and the same account on each, all getting at the same branch
<poolie> but, probably most of the time it's not wortwhile
<spiv> poolie: in principle you could try some heuristics like "is the UUID of / the same?"
<spiv> Or hardware addresses of network interfaces.
<poolie> mm
<spiv> http://docs.python.org/library/uuid.html#uuid.getnode looks almost-but-not-quite helpful
<poolie> my ui-factory branch seems to be failing in test_delta
<poolie> that's strange
<poolie> ah i wonder if this could be somehow due to the test multiplication bug?
<spiv> test_delta doesn't seem to use test multiplication, though?
<poolie> test_diff is failing and that does ad-hoc multiplication by subclassing
<poolie> i'm not sure how we would have broken that but i don't see how i would have broken it eithr
<poolie> the symptom in all failures seems to be run_bzr(...retcode=1) fails because it seems to observe a return code of 0
<poolie> i don't know if that's every case but it's many of them
<poolie> hm i wonder if it's trying to read a confirmation in a place it wasn't before, and therefore exiting early
<spiv> Hmm, the test multiplication changes seem pretty unrelated to that.
<spiv> If it's an unexpected confirmation prompt, then hopefully the test log will show that?
<poolie> the failure i was getting in test_delta was
<poolie>   File "/home/pqm/bzr-pqm-workdir/home/+trunk/bzrlib/tests/test_delta.py", line 69, in assertReportLines
<poolie>     self.assertEqualDiff(expected_lines[i], result[i])
<poolie> and that's possibly because of unexpectedoutput
<vila> poolie: teddy-bear for orphan config var ?
<vila> jam (and I agree with him) wants a hook there, there may be a way to reconcile both but nothing really simple comes to mind, would you be ok to postpone that a bit ?
<vila> your request seems tied to junk files which I'd prefer to address by refactoring ignores so we can reuse them for properly implementing junk
<spiv> vila: what's the difficulty in making a hook?  Does the orphaning happen at a fairly generic point in the treetransform code?
<vila> spiv: well, there is TreeTransform and TransformPreview that both implement new_orphan
<vila> the hook should be for new_orphan and TransformPreview should never be concerned (in theory)
<vila> but poolie would like an easy way to preserver the old behavior and a hook is not "easy" to configure
<vila> we can't put a callable there :) So this means a registry in addition to the hook. Not trivial.
<spiv> I don't quite follow the last bit there...
<vila> spiv: https://code.edge.launchpad.net/~vila/bzr/323111-orphan-non-versioned-files/+merge/35110
<spiv> Making a hook point and how configuration works are pretty unrelated concerns
<vila> orphans unversioned files now
<poolie> spiv so on at least some of these tests i see multiple tracebacks
<poolie> but perhaps that's not really the reason for failures
<spiv> poolie: the traceback fix is currently only on 2.2
<vila> spiv: how do you configure a hook ?
<spiv> vila: e.g. see merge_file_content hook
<spiv> vila: it was created to allow features like news_merge
<poolie> it seems like many tests that expect a non-0 return code are failing
<spiv> vila: but regular merge logic uses it too
<poolie> perhaps i'll just bisect back to find it
<poolie> vila, i guess it's just that if people really do have precious files
<poolie> having them dumped in a bzr-orphans directory
<spiv> vila: i.e. regular merge registers a hook function for that hook point too
<poolie> is not really helpful
<poolie> at least they're not totally lost but they'll need to manually move them back or whatever
<poolie> which might be annoying
<poolie> if we were sure there were no such people we could just delete the files
<vila> poolie: less annoying than resolving a conflict that shouldn't occur otherwise ?
<vila> poolie: handling junk files (not precious files) will mean bzr-orphans contains only precious files
<vila> poolie: and they will be put there only when the user ask bzr to proceed with an action that render such precious files orphans
<spiv> vila: I guess the thing I don't get is why you are asking "how do you configure a hook ?" at all.  Providing config options for users anad providing hook points in the API (for plugins and/or internal code) are different issues without any real overlap.
<vila> spiv: the overlap is poolie asking for a config option when we want to add a hook for which specifying which files are concerned is tricky
<spiv> vila: I mean, perhaps core bzr code might look at a config variable and use that to influence what it registers with a hook
<spiv> But that's just an implementation detail.
<poolie> vila, the thing is
<poolie> if people only have junk, they want it just deleted
<spiv> (e.g. lock debugging)
<poolie> if they have precious files, i guess they want them left where they are and a conflict
<poolie> moving them to bzr-orphans is a bit of a compromise position
<vila> "them left where they are and a conflict" or "moved out of the way and decide *at that point* how they want to make them versioned"
<poolie> ie i don't know how many people actually want that
<poolie> well in the second case you have to move them back
<poolie> by hand, which seems annoying
<vila> shudder, so I just reject the mp ?
<vila> poolie: now, not back, this occur when the parent directory is *deleted*
<vila> you have to decide *where* you want it to live then
<vila> the directory hasn't been renamed
<spiv> vila: so, hypothetically, you could provide a config var like "orphaned_files = move_to_bzr_orphans" or "orphaned_files = conflict_parent_dir".
<vila> there is a hole there I think between people wanting to have precious files, don't want to version them, yet, ask bzr to move them around
<spiv> vila: and then provide a way for a plugin to register other policies
<vila> spiv: exactly, hook + registry + config var
<spiv> vila: e.g. a plugin that provides "orphaned_files = delete"
<vila> spiv: and a bzr core implementation with at least two policies to start with
<spiv> But there's nothing in that that I would describe as "configuring a hook"
<vila> hence my teddy-bearing about: "Isn't handling junk files right more important ?"
<spiv> (Or at least, not in the usual ways that I think we use those terms :)
<vila> poolie: "i don't know how many people actually want that" I agree, I have no idea on who want what. Only that the actual behavior is a pain.
<poolie> yes, what spiv said
<poolie> i guess also, i think the handling here ought to be modularised enough that adding the config should not be too hard
<poolie> because we know people will want to vary it in the future
<vila> yeah, right, whatever, in terms of implementations, it's still hook + registry + config var
<spiv> Yes, that sounds like a good implementation to me.
<spiv> Well, I'm not sure that it is actually literally a HookPoint
<spiv> But registry-of-policies + config var, yes.
<poolie> right
<poolie> i agree if you also have a hook plus a registry the interactions seem complex
<poolie> do people want a hook in particular, or just a chance to run their own code?
<spiv> (ObComplexityIsFun: there's no reason why a specific policy couldn't provide hook points...)
<vila> poolie: right, I don't say we shouldn't do that, I'm complaining about doing it as a tweak :)
<spiv> (aside from reasons of taste ;)
<vila> poolie: especially one whose scope could be quite different if junk files were out of the equation (since the most obvious hook otherwise will be a quick-and-dirty let's-just-delete-junk :)
<vila> or said in yet another way: isn't it better to have ophans *now* as a good workaround for junk files coming in the way during pull/merges/ etc ?
<vila> and knowing we have better solutions in the pipe
<spiv> Well, I've joined late in the discussion...
<vila> spiv: most of what you miss is in the mp comments
<spiv> but I think poolie (or someone?) was asking how hard it would be to a) provide a config option that can provide the old behaviour for users that want that
<spiv> and b) do so in a modular enough way that could allow other policies to be provided too
<vila> and the answer is: perfectly doable with hook + registry + config but as a tweak ?
<vila> b) answer is: all is defined in new_orphan so far
<poolie> again i agree with spiv
<vila> I know of one case that will require a bit more work by adding a cleanup
<poolie> generally i really don't like asking people to do extra work as patr of a merge
<poolie> but i'm concerned that this may seem like a step backwards for some people
<poolie> so i want there to be an escape route, at least
<poolie> it's hard to count on immediately going on to the fix you want to do next
<poolie> interrupts tend to come up
<spiv> vila: I'm not sure what you mean by "hook" in hook + registry + config.  Do you mean something involving bzrlib.hooks?
<poolie> basically what i'm suggesting is: put this policy behind some kind of object interface
<vila> spiv: yes, a way to redefine new_orphan, and yes in the same spirit as your merge hook
<poolie> register it plus the old one
<poolie> make the new one the default
<vila> poolie: oh, I perfectly understand :)
<poolie> :)
<spiv> As a strawman, why wouldn't it simply be registry-of-new_orphan implementations, and a config var that can be set to a key in that registry.
<spiv> There's no "hook" in the bzrlib.hooks sense in that.
<vila> spiv: haaaaaa, thanks, I knew it should be simpler :)
<spiv> vila: well, I'm a bit baffled about where you thought the hook should have been ;)
<poolie> indeed (maybe later) the concept of: 'config var chooses from the registry' should be generalizable
<spiv> But I'm happy to remain ignorant on that point :)
<spiv> poolie: +1
<spiv> poolie: (we already do a pretty good job of that for command line options)
<spiv> poolie: (and I miss it when not writing bzrlib code :)
<spiv> Speaking of not writing bzrlib code... it's time to log off for the night!
<vila> spiv: well, you can imagine different policies applying to different files while the config route means a single policy for all files, but it's a matter of better defining what new_ophan can do (it's not allowed to *refuse* to orphan yet even if I made some comments about that in the tests), so I wasn't clear about it. Better now
<poolie> vila, apparently you're the RM, according to the topic :)
<poolie> good night spiv
<vila> poolie: errr, who did that ?
<poolie> :) not me i promise
<poolie> you can still wriggle out of it
<poolie> but if you wanted to do it thursday/friday, that might be nice
<bialix> as football fans shouting: vila! vila! vila!
<vila> meh, my topic line is fubared right now :-/
<vila> bbiab
<vila> I don't think changing the RM randomly will help here especially when the said RM just learn it almost by accident.... :-/
<poolie> it actually wasn't me
<poolie> perhaps it should go back to being john or me
<poolie> i thought you must have signed up for it?
<poolie> ah, i think i worked out what my problem with diff is
<poolie> one of the plugins, maybe bzr-pager, masks the error codes
<vila> I mean, I'd be happy to be RM (man, I should have been long ago and have helped on almost everything except building the installers), but I asked to be hand held on several occasions...
<vila> poolie: No, I didn't, if it has been asked I may have though
<vila> poolie: I'll keep it this way, expect some road bumps :)
<poolie> we could do it together on my friday evening?
<vila> poolie: perfect
<vila> bialix: thanks for the support :) Here, take my shirt !
<bialix> :-)
<fullermd> Ack, no!  Put that back on!
 * vila frowns, and thought the tattoo was fun...
<fullermd> That's a tattoo?  I figured you were just mauled by a bear or something...
<bialix> vila: at uds I've tried to to present the idea of multiple push/pull locations. you even listened to me then. I was not sure about the idea, and in many cases bookmarks plugin is already cover many use case. but I have one more.
<vila> fullermd: Complaining about my tattooer ?
<vila> bialix: shoot
<vila> fullermd: he *is* a bear, so what ?
 * poolie is going to merge up 2.0 -> 2.1 -> 2.2
<bialix> my use case: automatically remember on push/pull non-defaul location. it could be some temporary location used say for quick testing, or something. usually I don't care enough to create bookmarks entry for it. but it will be nice to have it remembered behind the scene
<bialix> vila: so I've been trying to present at uds the idea of :push:1 :pull:2 in addition to :push and :pull aliases
<bialix> only one question is: user will need the way to get the list of those locations
<Glenjamin> info -v perhaps
<vila> bialix: the later is easy: 'bzr config'
<bialix> maybe put them into `bzr info` output
<bialix> bzr config meant to list the options as well?
<bialix> makes sense
<vila> bialix: yes, showing option origin (bazaar, locations, branch, whatever)
<bialix> re bzr info: do we have a hhoks for it? ;-)
<bialix> re bzr info: do we have hooks for it? ;-)
<vila> dunno about that, but a 'see bzr config for more details' when 'bzr config' exists may be appropriate (or not)
<bialix> vila: I wonder is it possible to extend/override :push aliases logic from plugin
<vila> bialix: otherwise enhancing bookmarks so we can define aliases at branch level and then be able to say 'bzr pull :bm:test' sounds better than defining ':push:n'
<bialix> vila: bookmarks can be defined at branch level
<vila> bialix: this way they could be used for bind/pull/push/merge/ whatever
<bialix> or do you mean adding post_push|pull hooks there>
<bialix> or do you mean adding post_push|pull hooks there?
<vila> no, just using the aliases from the command line
<bialix> I don't follow
<bialix> do you mean adding auto-bookmarks a-la bm:push:1
<vila> no, I mean defining them manually and then using them everywhere
<vila> '1' doesn't mean anything to me
<bialix> my point is that I'm very lazy person to define them manually
<bialix> I'd like to get them recorded in post_push hook
<Glenjamin> the idea was for :push:1 to be the last non-remembered push location?
<luks> bzr push URL --remember=foo
<bialix> '1' is just a number
<luks> bzr push bm:foo
<luks> ?
<vila> bzr push URL --bookmark=foo
<bialix> hey luks
<luks> hi
<vila> bzr push URL --bookmark=foo ?
<luks> well, --remember is already there
<luks> I think it would make sense to reuse it
<vila> bzr push URL --remember=bm:foo ?
<bialix> no, guys, I don't really know when I need to re-use that URL
<vila> luks: yeah, thinking out loud
<bialix> and will I reuse it
<bialix> just auto-record in case of
<bialix> my situation: I have testing machine
<bialix> so I'm just pushing to it from time to time
<bialix> it's easier for me
<vila> bialix: but why only push ? submit and parent and master can be good candidates
<vila> too
<bialix> but the remembered push URL is URL to my central server
<bialix> vila: right, but push is just the starting point for discussion
<bialix> I've mentioned :pull:N too
<bialix> :submit have no sense for me, I dislike it very much
<vila> how to know what N means
<bialix> you need to look
<vila> bialix: that's where you merge from generally
<bialix> vila: not in my workflow
<vila> bialix: hehe, that's where I wanted to go :)
<bialix> so, again idea behind :push:N
<vila> bialix: what if you wanted to pull from the server instead ?
<bialix> I push to non-default location, this location remembered as push:1
<bialix> next time I push to another non-default location, this location remembered as push:2
<vila> bialix: or rather, what is your workflow ? pushing then going to the server to do something else ?
<bialix> say I have only 3-4 slots for this auto locations
<bialix> I push to the another computer where I have hardware programmer and debug tools
<bialix> vila: ^
<vila> do you make commits there ?
<Glenjamin> but that computer doesn't move i assume, what's wrong with a bookmark?
<bialix> almost, no
<vila> Glenjamin: many branches
<vila> bialix: so why not *pull* from this server instead ?
<bialix> Glenjamin: because I have many branches
<vila> (side note) I often use bzr push URL_prefix`bzr nick` as a good trick to
<vila> avoid having to came with new names every time
<bialix> vila: it's just a matter of habit, I guess. to pull from the server I need to launch the browser, figure out URL and then pull. With push I need one time navigate in FAR to desired location and use it for push
<vila> bialix: on the serve you should only have to issue 'bzr pull URL' once and then 'bzr pull'
<bialix> vila: believe me: I have *many* branches and *many* different devices I'm working from time to time
<bialix> it's not just one project and one trunk
<vila> bialix: I'm asking all of this because I'm working on a plugin that should help automate a lot of these workflows and I realized that we have different kind of branches, all of them needing to behave a little bit different
<bialix> ok, if you think my use case is weird, I'm okj
<bialix> I will look into hacking bookmarks, it's indeed good place to put my code in
<vila> a mirror only needs to be pulled, no commits, no push, a bug fix needs to be pushed, ends up merged, may require merging from parent, etc
<bialix> vila: I'm coding on one machine and testing on another; sometimes I made minor changes
<vila> bialix: not weird at all, I'm trying to find whether you need such auto-recorded bookmarks when there is no automatic way to use them
<vila> bialix: right, so the target branch is a mirror of your working on one
<bialix> yep
<vila> so you can either pull from it or bind it
<bialix> no, I can't
<vila> can't bind ?
<vila> already bound ?
<bialix> I'm usually don't push unfinished code to the central servewr
<bialix> can't bind because of network configuration
<vila> bind to test server while working, bind to central server when finished ?
<bialix> can't pull either, only push
<vila> aw
<bialix> there is no test servr
<vila> gee, poor bialix :(
<bialix> I don't feel so
<bialix> I'm pretty happy with push
<vila> err, I thought the discussion was about a missing feature :)
<vila> bialix: and a push template where the branch nick can be automatically inserted ? (Or using append_path may be)
<bialix> no, there is no push templates
<vila> bialix: I know, I'm proposing one :)
<bialix> I've pushed to central server: this location is already remembered, that's right
<vila> so you can say: bzr push bm:test_server and the url will caontains your `bzr nick`
<bialix> I've pushed to test machine, the URL could be pretty arbitrary, sometimes even from one working branch I'm pushing to 2 or more locations to test different things
<Glenjamin> can you get access to the branch object in a directory service lookup?
<bialix> so that non-defautl URLs I want to be remembered somehow, hust in case I will need them later
<bialix> s/hust/just/
<bialix> Glenjamin: I can open a branch in current directory if needed
<Glenjamin> ah yes, thats how the AliasDirectory does it
<vila> looking briefly at bookmarks, it seems to allow bazaar.conf and locations.conf but not branch.conf
<vila> that would be a useful addition in all cases
<bialix> vila: your proposals rely on the upfront action, that's what I want to avoid
<bialix> vila: re bookmarks, config = self.branch.get_config()
<bialix> I think the latter get the branch.conf first
<vila> bialix: sure, but you won't avoid N nor looking at its meaning before using 'bzr push bm:push:1'
<bialix> luks may know better
<bialix> vila: so what? running the command `bzr bookmarks` before push:N is not so hard
<bialix> and should be fast
<vila> bialix: it's an upfront action
<bialix> at least it will be faster than navigate to browser or FAR
<bialix> vila: can't agree here, it's just info request, by action I mean: configure your bookmarks/push templates somehow before you can use them
<bialix> in my proposal they will be recorded without any config
<bialix> if you never know will you re-use them or not
<Glenjamin> how about a plugin that records all recent URLs which aren't already remembered normally. and then accessed via recent:N and "bzr recents" lists them
<bialix> something like that will work too
<vila> cool man, we're just discussing and I'm proposing alternatives. I'm not saying your proposal is useless or bad or anything :)
<bialix> vila: ack
<vila> yeah, I like Glenjamin idea
 * bialix have been trying to explain the same thing
<vila> see ? That's why discussing is good :) I can be very dense :)
<vila> and 'bzr recents' can be 'bzr config recent*'
<bialix> see, that's good
<vila> or something
<Glenjamin> is bzr config new?
<vila> Glenjamin: so new it doesn't exist yet :)
<Glenjamin> aha
<bialix> it's imaginary atm
<poolie> this is kind of weird, now i've sorted out my bzr-pager thing
<bialix> btw, vila, will `bzr config` make the `bzr alias` command useless?
<vila> there are several related bugs floating around that can be addressed by a 'bzr config' command that can display/filter/modify config files
<vila> bialix: probably
<poolie> i still get a strange scriptrunner failure
<vila> bialix: note that 'bzr alias' handles deleting a config var...
<poolie> where ... doesn't seem to match
<poolie> and it doesn't happen locally
<bialix> I've tought `config` should do it to
<vila> bialix: indeed
<vila> poolie: doctest changes since 2.4 ?
 * bialix shakes vila's hand
 * vila feels warm
<bialix> Glenjamin: do you think recent:N should be global for all branches, or local for every branch?
<Glenjamin> hrm
<vila> bialix: local
<vila> bialix: but you raise an interesting point as it means we can't have both. If you use a config var with a list value, it can't be an aggregation of branch.conf + bazaar.conf
<bialix> hm hm
<bialix> unless they have different names?
<vila> and you will populate all of them ?
<vila> the global one will soon become a mess unless you set a maximum size..
<bialix> if I'll put them in bazaar.conf in the dedicated section then they will be different from branch.conf
<poolie> vila, that's my next guess
<bialix> maximum size is mandatory
<vila> bialix: locations.conf, but yes
<vila> bialix: that's sounds like experimentation is needed but this could fly very well...
<bialix> that's why I'd like to hack quick plugin to test the idea
<bialix> and recent: prefix is really cool idea
<vila> poolie: ellipsis handling being a recent addition ? ISTR that the flag is or'ed with others so if it's not implemented it will fail silently
<poolie> i can't believe ellipsis is recent but maybe the behaviour changed
<bialix> what's difference between branch format 6 and 7?
<bialix> ah, stacked support
<maxb> lifeless: Do you anticipate being able to do testtools 0.9.6 -> sid soon? If not, I might make the proposed PPA jump ahead of sid, so that testtools and subunit can be considered for proposed PPA promotion at the same time as 2.2.1
<lifeless> maxb: are you a dd ?
<maxb> I am not
<lifeless> ah
<lifeless> should be able to do it tomorrow
<maxb> Nor an Ubuntu anything, actually. I did read about the MOTU process but never quite got around to producing uploads for sponsorship at a sufficient rate to start on that process
<jml> poolie, hello
<poolie> hello jml
<jml> poolie, we should talk some time!
<poolie> mm
<poolie> now could be good, i was just going to warp up
<poolie> *wrap
<mgz> <poolie> now could be good, i was just going to warp up <- poolie lives is a spaceship!
<mgz> *in
<mgz> karma... can't enjoy other people's tyops without making your own
<bialix> mgz: haha
<kpettit> What is a good text editor or ide that has bzr support built in?
<kpettit> Normally I use gedit, eric or similar linux ones.
<jelmer> I think there is (some) support for gedit.
<kpettit> ah, didn't see it before.  I'll check...
<kpettit> I'm new with bzr and really like it.  So I'm trying to use it more and see if there are any native editor things to help
<Glenjamin> komodo ide claims to have bzr support, haven't tried it though
<servilio> hi all! when having B and C as branches of A, will there be a problem when I merge back changes into A if I had cherrypicked changes between either of the branches (from B to C or the other way)?
<Glenjamin> servilio: mostly no, but you can sometimes get spurious conflicts
<Glenjamin> using remerge --weave or remerge --lca can help
<vila> servilio: no, you may encounter warning about criss-cross merges.. whatever Glenjamin is saying :)
<vila> jml: bzr branch lp:bzr-gardener , feedback highly welcome :)
<jml> vila, thanks!
<jml> vila, I can't wait to try it.
<vila> jml: very basic feature-wise so far but the design should scale
<Glenjamin> very zen function naming
<vila> Glenjamin: pfew, thanks, that was the hardest part, took me... months. Coding was far easier from there ;)
<jml> vila, neat.
<Glenjamin> you know you call grd.status regardless of the value of cmd?
<vila> Glenjamin: good catch ! Doesn't matter yet, but thanks !
<vila> Glenjamin: fix pushed
<Glenjamin> oh i see, it doesn't just call bzr status - it tells you the working tree status
<Glenjamin> seems pretty tidy
<vila> Glenjamin: yup, see in action during the fix above: http://paste.ubuntu.com/494278/
<Glenjamin> will pullable be true if a checkout is out of sync with its bound location?
<vila> Glenjamin: hehe, tricky question already ?
<vila> I already encounter case where not all branch kinds want to behave the same,
<Glenjamin> i almost exclusively work with checkouts, central repo at work :)
<vila> Glenjamin: light or heavy ones ?
<Glenjamin> heavy
<vila> anyway, they will be supported but they will require more states
<Glenjamin> i'd imagine the pullable check on bound_url would be correct?
<Glenjamin> although there's more states if local commits are involved
<Glenjamin> which we try and avoid :)
<vila> and probably also require a type concept so different checks and different actions will apply to mirrors or feature branches
<Glenjamin> it might be useful to mention the other_url in the output from "merged" as well
<vila> Glenjamin: 'merged' for example doesn't make a lot of sense for a mirror
<vila> Glenjamin: could be, with -v, don't hesitate to file bugs
<vila> Glenjamin: or even better send patches ;)
<Glenjamin> i may branch and have a play about :)
<vila> Glenjamin: enjoy !
<vila> jml: I started with 'status' so that scripts can use it for... whatever
<jml> vila, good plan.
<Glenjamin> update would be pretty cool, not sure what else though
<jml> vila, I've already got a stack of ideas
<vila> jml: but ideally I'd like to do: 'bzr gardener --pull --filter mirror ~/.bazaar/plugins' to update all my plugins with respect to their respective trunk
<vila> jml: 'mirror' in that case would be somehow defined in a config file
<jml> vila, *nod*
<Glenjamin> why not make your plugins checkouts?
<vila> jml: and would exclude bug fixes or feature branches
<Glenjamin> lightweight ones even
<jml> vila, yeah. I'm thinking now that I want my Launchpad devel, stable etc branches ignored when I do status
<jml> or treated differently at least
<vila> jml: you got the idea
<Glenjamin> then the action is just "update all the checkouts", and your dev ones wouldn't be bound
<vila> jml: I don't think the branch type can be infered from the branch.conf urls, so I plan to rely on an explicit typing (which can be based on path: bzr/experimental, bzr/bugs, bzr/releases, etc)
<vila> Glenjamin: yup, that could work
<vila> Glenjamin: but I tend to use either plain branches or bound branches or looms
<jml> vila, yeah. either types or something more capability-based
<vila> jml: I haven't thought about looms yet
<jml> vila, e.g. "for devel, *do* check pullability, *don't* check merging" etc.
<Glenjamin> i don't think i've ever used looms
<vila> jml: yeah
<vila> jml: type and actions are the ones I want to put in config
<Glenjamin> can you "tag" a branch in some way, then filter by those tags? (not revision tags)
<vila> Glenjamin: via configuration, that's the plan
<vila> Glenjamin: so most of the time you could use 'bzr gardener' when working from a root (a root in a garden, it all makes sense !!!!111@@) or specify action when needed : 'bzr gardener --update this-branch'
<Glenjamin> bzr gardener --update this-branch is equivalent to cd this-branch && bzr update ?
<vila> jml: oh, I tried to use transports everywhere so branches could be scanned remotely too, but I don't know if there is a simple way to scan for lp:~vila/bzr
<vila> Glenjamin: yeah, silly example
<Glenjamin> the filter stuff seems like a good approach
<bfrog> why is launchpad so slow to clone from?
<bfrog> it never fails to be like 5kbps
<lifeless> bfrog: there is a bug open I think; we were looking at firewall issues
<lifeless> elmo: has that firewall you suspected of being LFP-sensitive been upgraded to lucid yet?
<maxb> LFP?
<lifeless> long fat pipes
<marienz> huh, I could've sworn there was a command that printed the path to your plugin dir, so you don't have to look it up in the documentation
<james_w> it's in bzr version output isn't it?
<lifeless> bzr --verison
<marienz> so it is! thanks
<james_w> ok, not exactly, but close enough
<marienz> I forgot the "2.0"
 * marienz is not normally on windows, and it shows
<maxb> Where might I discover whether InventoryLink.symlink_target is a bytestring or unicode string, other than by setting up a testcase to investigate?
<mgz> jam: it appears launchpad still doesn't like you
<jam> mgz: yeah.... no love on the emails
<jam> I don't know why, vincent looked at my emails and they work on his end
<mgz> they seems fine to me too, might just need to file a bug against launchpad
<jelmer> maxb: just checking - if you're working on that bzr-svn bug, please assign the bug to yourself
<maxb> jelmer: I was doing preliminary investigation.... which has turned into being about to propose a merge :-)
<maxb> Is it really a sensible thing to do, to repack every 1000 revisions during a single 'bzr branch' (from svn) operation?
<jelmer> maxb: it's what happens when you commit a write group
<maxb> yes, but is it *sensible*
<lifeless> maxb: yes
<lifeless> maxb: each pack adds linear probing
<lifeless> maxb: within a pack is log(200) or so
<jelmer> maxb: any luck?
<jam> vila: if you are still around, is PQM basically deadlocked without your fix? I've been trying to land some patches and I'm getting failures
<mgz> the random failure jam? if you keep trying you may have luck, but it's certainly been easier to hit recently.
<jam> mgz: Well, it takes a long time  for t-bird to successfully finish reading the 7MB email, and then to pipe it through subprocess, etc
<jam> faster to chat here :)
<jam> but I'll check
<mgz> ...I really think that's what needs fixing. PQM should be sending a nice, short, summary, not a machine readable dump.
<mgz> Is that something I can poke, or is the code somewhere obscure?
<jam> mgz: well if my patch is extended to also strip the logs from successful runs, I think we'll have it
<mgz> did you see my last comment/
<mgz> it looks like there's a line that tries to do that already, but in a different way to yours.
<jam> mgz: I saw a comment, I'm pretty sure that line doesn't work :)
<jam> It may be a 'race' thing.
<mgz> I can well believe it, the log code has been seriously changed several times.
<jam> oh, and the failing test was something else. The submitter used "\t" in his code, rather than just " "
<mgz> gah! :)
<mgz> ...I hope it wasn't me.
<jam> mgz: no, knittl probably just had his editor configured to use tabs when possible
<mgz> phew. I juggle my editor, and don't always have the right project style either.
<knittl> uh
<knittl> maybe a tab slipped in when writing the test
<knittl> i even made vim highlight mixed spaces and tabs
<mgz> knittl: you can also use `./bzr selftest -s bt.test_source`
<maxb> jelmer: Yes, I've convinced myself I do need to convert unicode to bytestring, and pushed a followup
<knittl> mgz: ok, i know the next time
<jelmer> maxb: That still can't be right though, you need a "link " prefix
<jelmer> maxb: argh, nevermind
<maxb> yes, it's in there
<maxb> I gloried in the fact that it wants an iterable :-)
<jelmer> maxb: hehe
<jelmer> maxb: could I persuade you to add a test that shows this fixes the bug?
 * maxb goes hunting for suitable test fixtures to crib from
<jelmer> there should be some in tests/test_fetch.py
<mgz> ...I've been looking at bzrlib.tests for too long, can't keep in mind which bits need explaining
<maxb> jelmer: Now I'm confused. test_fetch_special_unbecomes_symlink ought to cover this case :-/
<jam> knittl: :set et<enter> :retab<enter>
<jam> et == expandtab
<jelmer> maxb: nope, it doesn't remove the svn:special bit
<knittl> jam: for future commits?
<jelmer> maxb: although that shouldn't really matter in this case I guess
<jam> knittl: that is just the easy way to clean up your current file. ":set et" is a good way to configure vim to always expand tabs into spaces
<jam> This is my default setting, in ~/.vimrc:
<jam> set tw=79 sw=4 sts=4 ts=4 et ai si
<jelmer> maxb: it's probably the text cache that's saving us there
<knittl> jam: well, i usually prefer using tabs
<jam> defaults to wrapping at 79 chars, soft stops at 4 chars, but using spaces rather than tabs
<jam> ts=8 is probably better
<jam> knittl: sure. I think you can also put something in ~/.vim/filetype.vim
<maxb> jelmer: hmmm. right. I shall attempt to figure out how to defeat the cache, then
<jam> which uses a regex to match things under "*/bzr*
<jam> i know I have this there:
<jam> au BufNewFile,BufRead *.py match Error /\s\+$/
<jam> to watch out for trailing whitespace
<knittl> jam: i also match trailing space. and space before tabs.
<knittl> which doesn't match tabs only and vim used tabs when copying those two lines (the pydoc string uses spaces â¦)
<jam> knittl: sure, so you see *mixed* content, but not one-or-the-other
<jam> I thought there was a python 'mode' that checked if you used mixed-within-the-file
<jam> The problem I had with the "mixed-within-a-line" was wrapped lines
<jam> since I might indent them to a non-tab-multiple
<jam> Though I've since switched to all spaces
<maxb> jelmer: It is acceptable to just copypaste test_fetch_special_unbecomes_symlink, and replace the single call to self.copy_content(source, target) with two, the first with an additional revision id parameter to only copy the first revision?
<knittl> jam: can i amend the old revision?
<knittl> i've only seen the mail now
<jam> knittl: you can, 'bzr uncommit; fix; bzr commit"
<knittl> and then push without problems?
<jam> but you might as well just do a new commit, and then push
<jam> knittl: you would have to 'bzr push --overwrite'
<knittl> can i reuse the commmit message?
<knittl> jam: what is the recommended approach here?
<jam> knittl: *I* would just create a new revision with "fixup whitespace issues" and push that
<jam> some people like to collapse history, I'm not really one of those
<jam> (collapsing happens by having a 'mainline' where the tests always pass, etc. Individual branches don't have to be clean)
<knittl> ok, it's pushed
<jelmer> maxb: sure
<jam> knittl: submitted again
<knittl> k, thanks
<jelmer> maxb: These tests need some more rigurous refactoring at some point. Right now they're all basically blackbox tests (they set up some svn situation and run fetch). I'd like to do more testing of the individual classes.
<maxb> pushed
<jelmer> maxb: I don't see anything...
<maxb> jelmer: erm, yes, that would be my fault. I also pushed 82000 revisions of kdebase and have cause "some" delay in branch scanning
<jelmer> hehe
<jelmer> Those revisions should already be in the revision table on launchpad though
<jelmer> ah, kdebase.. sorry
<maxb> Question for you, though - why do various layout methods take an optional project parameter - and why is it sometimes defaulted to None and sometimes to "" ?
<jelmer> maxb: Depends on the methods implementation.
<maxb> As in, it's None if someone was prepared to assert the parameter was genuinely unused?
<maxb> btw, is https://code.launchpad.net/~maxb/bzr-svn/unused/+merge/32822 on your radar to look at at some point (it's just unused code removal) ?
<jelmer> maxb: Sorry, I saw it earlier and had a brief look but not enough time to look at it in more detail.
<jelmer> maxb: IIRC it removes get_rhs_ancestors(), which I'd like to keep around because I'd like to use it for optimization in the future.
<maxb> ah, ok. I killed it because it was unused, and only had a fileprops-based implementation
<jelmer> maxb: wrt project in the layout methods; some methods don't actually care about what project is specified for example, or their project value is a prefix
<jelmer> maxb: it really should only have a fileprops-based implementation, but would allow us to see what revisions are present in a svn branch.
<maxb> ok, I'll rewrite history of that branch to keep get_rhs_ancestors
<poolie> hi jam, maxb, jelmer
<maxb> hello
<jelmer> 'morning poolie
<dlee> If I check out with Bzr from one svn branch, then check out separately from another svn branch of the same project, assuming the two svn branches share a lot of common revisions, will I profit by putting my two Bzr checkouts in a shared repo, or will Bzr connect the common svn revisions that way?
<dlee> I read a lot about this problem a long time ago, but I'm not sure of current behavior.
<maxb> Yes you will save time and diskspace by doing both within a shared repository
<dlee> Cool!  I wasn't sure if the bzr revids would map repeatably to the same svn revisions.
#bzr 2010-09-16
<jam> hi poolie
<jam> turns out the EINTR bug was very shallow
<poolie> hi jam, i saw your mail, and i'm happy to hear that
<poolie> did you talk to aaron at all?
<jelmer> maxb: merged, thanks.
<jam> poolie: I haven't yet. For some reason I got hives last night, and couldn't sleep for the itchiness, so I ended up starting a bit late
<jam> I think it was an allergic reaction to something, but I have no idea what
<jam> I didn't eat anything different, etc
<jam> I did write up most of the decisions I've taken
<jam> so I'm pretty close to getting feedback time
<mgz> poolie: have you seen <http://babune.ladeuil.net:24842/job/selftest-freebsd/183/> ?
<mgz> it may well not be anything to do with your change,
<mgz> I've seen that sort of failure on a bunch of different cases when poking things
<mgz> right, bed for me.
<eydaimon> If I do bzr revert -r -11  is there some easy way to get what revno I've reverted to? I tried bzr revno --tree but didn't work
<fullermd> No, revert doesn't change the revno of anything, it just edits files.  It's not really any different from `bzr diff -r-11 | patch -R`.
<poolie> jam that's great
<poolie> mgz no i hadn't, thanks for pointing it out
<poolie> mgz, that's interesting it didn't fail on ubuntu
<poolie> the scope replacer thing ought to be platform-independent
<jam> poolie: would it be a python 2.7 thing?
<poolie> maybe
<jam> I believe mgz is known for random python versions :)
<poolie> hi spivvo
<spiv> Hi poolie
<poolie> hey there, how are you?
<spiv> Pretty good.  Mary's got a new laptop, new enough to be giving her mild grief with video driver issues :/
<poolie> oh, what kidn?
<spiv> A 13" Dell Vostro
<poolie> spiv, actually, would you mind investigating the scopereplacer?
<poolie> it may have been my landing that broke it but i don't think it's especially related to anything i know
<poolie> http://babune.ladeuil.net:24842/job/selftest-freebsd/183/testReport/junit/bzrlib.tests.blackbox.test_branch/TestBranchStacked/test_branch_stacked_from_smart_server/
<poolie> actually nm
<spiv> Heh.
<poolie> >> Greetings To You,
<poolie> On behalf of the OBAMA'S FOUNDATION and UNITED NATIONS,
<poolie> we wish to notify you as a beneficiary of $900,000.00 USD in compensation of
<poolie> scam victims.
<poolie> mm i bet
<lifeless> rotfl
<mtaylor> hey all - I know fuckall about fedora - is there a "more sensible" way to get recent bzr on fedora12?
<lifeless> 'debtakeover'
<mtaylor> hehe
<lifeless> there's a fedora maintainer
<lifeless> why do you ask?
<mtaylor> lifeless: and if I remember correctly, this is a known bug that's fixed in 2.2, right: http://hudson.drizzle.org/view/Drizzle-build/job/drizzle-build-drizzleslap/593/console?
<mtaylor> lifeless: well, because I've got a fedora box with 2.0.5 on it, and I believe I'm suffering from a bug fixed by upgrading...
<lifeless> mtaylor: that looks like a fs fail to me
<mtaylor> lifeless: there's 112G available on the box...
<lifeless> what fs
<mtaylor> ext4
<lifeless> when did it last crash/power down unexpectedly
<mtaylor> oh! recently apparently
<mtaylor> poo
<mtaylor> lifeless: so my solution here is kill repo and re-pull, yes? or can I just kill that file?
<lifeless> uhm
 * lifeless hands you over to a bzr person
<lifeless> spiv: ^
<mtaylor> lifeless: I think you qualifiy still as a bzr person even if that's not your job title ;)
<lifeless> its more that
<lifeless>  - the answer is complex
<lifeless>  - you need to dig a bit to get the actual answer on a case by case basis
<lifeless>  - we should make that more automated
<spiv> Sorry, my net connection dropped out, so I missed the start of the conversation.  Which file is damaged?
<spiv> (Then, apparently unrelated, my wireless router needed to be restarted too...)
<lifeless> 13:38 < mtaylor> lifeless: and if I remember correctly, this is a known bug that's fixed in 2.2, right: http://hudson.drizzle.org/view/Drizzle-build/job/drizzle-build-drizzleslap/593/console?
<spiv> mtaylor: just deleting the file won't help; bzr will still expect that file to exist.  Simplest fix is to delete and recreate that repo, yes.
<glyph> so, I am running this command here
<glyph> $ bzr dpush
<glyph> Using saved location: svn+ssh://svn.twistedmatrix.com/svn/Twisted/branches/strports-endpoints-4473
<glyph>   8817kB    38kB/s | pushing revisions:generating file id map 0/1
<glyph> why have I dpushed almost 10M of data for a couple of tiny diffs?  (you can see them at twistedmatrix.com/trac/timeline, they are not big)
<lifeless> the 10M includes local disk IO rewriting your history.
<jbowtie> Is there an easy way to query for all the documentation bugs in Launchpad?  I can't remember how to do that.
<poolie> jbowtie, all the bzr doc bugs, or all altogether?
<poolie> the easiest way is to click 'doc' in the tag cloud
<poolie> jbowtie: which will take you to https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=doc
<jbowtie> I meant the bzr doc bugs, those are the ones I want to work on.
<poolie> that would be excellent
<jbowtie> poolie: Thanks for that, will hopefully send through a bunch of patches the next few days.
<jbowtie> poolie: Just remember that when I apply for Ubuntu Developer status.
<jbowtie> :)
<jbowtie> It's a shame that all the Canonical positions require you to be in the American or European timezones, I'd apply for job so I could work on Bazaar/Launchpad full time.
<spiv> jbowtie: http://webapps.ubuntu.com/employment/canonical_BSE/ (in /topic) doesn't require those timezones AFAIK
<wgrant> Lots of positions don't.
<jbowtie> spiv: You're right, I hadn't seen that one!  Looks like I will be applying when I get home tonight.
<jbowtie> wgrant: I suppose so, but every time I see one it has the timezone requirement attached.
<poolie> jbowtie: definitely apply
<jbowtie> poolie: Oh, I will. Though I suspect you just want to make sure I actually write those documentation patches.  :P
<poolie> it will help :)
<poolie> i'm reading cvs now as it happens but i don't expect the gate will close for another week or so
<vila> poolie: just passing around, don't bang your head too much on the scopereplacer thing, I've seen it a few times, it has always been transient
<poolie> oh, hi
<poolie> how strange
<vila> poolie: often triggered for smart server test so it may be related to some thread ordering differences in turn triggering different import ordering
<vila> not worth the effort until it happens too often
<poolie> :/
<poolie> ok, thanks
<vila> poolie: last occurrence was http://babune.ladeuil.net:24842/job/selftest-freebsd/98/testReport/junit/bzrlib.tests.blackbox.test_branch/TestBranchStacked/test_branch_stacked_from_smart_server/
<vila> jun 14
<vila> run #184 just succeeded, transient again
 * vila back to bed
<glyph> lifeless: I guess I can rebase first, then dpush?
<glyph> Hmm.
<glyph> Is there a way to construct bzr+ssh URLs to be $HOME-relative?
<glyph> like, I can 'scp foo bar:' and it'll just drop 'foo' into my home directory on bar
<spiv> glyph: yes
<spiv> glyph: bzr+ssh://host/~/foo
<spiv> (requires bzr 2.1 or newer on the server)
<poolie> maybe we should just add $host:
<spiv> And make trailing slashes significant? ;)
<poolie> oh like rsync? :)
<mwhudson> hnnnnnnnnngh
<glyph> spiv: hey good idea!
<glyph> whoops typo
<glyph> what I meant was
<glyph> "spiv: die in a fire"
<mwhudson> the only way i ever get rsync command lines right is if they're in my shell history
<glyph> Thanks a lot though!  I will be using "~" a lot now! :)
<poolie> :)
<glyph> mwhudson: how do you get the rsync command lines you typoed out of your shell history
<mwhudson> glyph: it's a mystery
<mwhudson> well, actually trial and error i guess
<poolie> it is actually a bit logical
<poolie> "a" means "the thing a", and "a/" is "everything inside a"
<poolie> that's what ayn rand was talking about
<poolie> 'a is a and a/ is not a'
<mwhudson> haha
<glyph> poolie: as a source it makes sense to me.  the problem is when you put it on the destination
<glyph> 'sync a with remote:a' and 'sync everything in a with remote:a'
<glyph> like... what does that mean?
<poolie> it makes no difference to the destination
<poolie> rsync a remote:b
<poolie> and you will end up with remote:b/a/...
<poolie> rsync a/ remote:b and you'll end up with remote:b/... containing what was in a
<poolie> the fact that it looks like it might do something does make it confusing of course
<lifeless> glyph: it will still do the same work
<lifeless> glyph: the point is that the 8M doesn't represent 'network IO'
<lifeless> it represents 'IO'
<spiv> lifeless: I didn't think we included local IO in the transport activity reporting
<spiv> lifeless: a quick grep suggests I'm right...
<lifeless> I was moderately sure we did
<lifeless> if we don't its arguably a bug (NFS etc)
<poolie> we don't include localtransport io
<poolie> i don't know what bzr-svn may be doing for its own io
<poolie> lifeless: the reasoning is that for the common base case of branching from lp to localhost, it would naively double the data transferred and the rate
<poolie> obviously you can account for stuff to make that even out but maybe yagni
<glyph> https://bugs.launchpad.net/bzr-mac-installers/+bug/621446
<ubot5> Launchpad bug 621446 in Bazaar Mac Installers "AttributeError: paths when trying to svn-import (affected: 2, heat: 15)" [Undecided,New]
<glyph> Can somebody poke the responsible parties there?  the 2.2.0 mac installer on bazaar.canonical.com still has 1.0.4dev.
<poolie> glyph: can you send a mail? i don't see them online atm
<glyph> Send a mail to whom?  Do you mean put a comment on the bug?
<poolie> hm, so i thought that 1.0.4dev would have this fixed
 * poolie looks
<poolie> but there is now a 1.0.4 final
<glyph> Mmmm... it may have been due to the old buggy repository.  Let me try again.
<glyph> Nope, reconfirmed outside of the shared repo.  Very, very definitely affects the 1.0.4dev in the current bzr mac installer.
<glyph> poolie: thanks
<poolie> and 1.0.4 works?
<poolie> does 'bzr plugins -v' confirm you're using the plugin from the installer?
<zaas[1]> i have a question about branches and git and it's differences, who could possibly help me?
<fullermd> Probably a number of people, but only after you ask the question   :>
<zaas[1]> ok :) I am trying to decide between Git and Bzr and i favor git a little bit because of it's branch support. However, i work with 2 windows developers and have avarage repositories < 30Mb of php & images
<zaas[1]> i find bazaar far more clearly
<zaas[1]> but i fear that local branching might be a breaking drawback
<zaas[1]> am i right to think this or is this not something that will likely bother me? Git and bzr both seem to do their basics well
<zaas[1]> but git evangelists love their index, cheap branching and the tree-eating monster
<zaas[1]> and i am confused what to pick
<zaas[1]> (not to much text i hope?) :)
<fullermd> Well...   those are pretty broad points.  Hard to give a specific answer, since there's no real specific question...
<fullermd> Certainly the branch representations are rather different, so they have different advantages and drawbacks.
<fullermd> And one drawback of the bzr way is that some minor setup is required to share history among local branches, and rather more setup and ongoing care to share a single working tree among them git-style.
<zaas[1]> ah, can you name a bazaar advantages? I know git's: 1 tree and easy push
<fullermd> Contrarily, an advantage is that it's way easier and less hackish to have working trees of multiple branches at once with shared history.
<fullermd> And it's also somewhat easier and more obvious to push only a particular branch around.
<zaas[1]> in my case branches will normally be about bugfixes or small features that need to be merges later on
<fullermd> Me, I find that multiple WT's on the different branches make a lot of things a lot easier.  It sounds like you're doing web stuff, and it's handy to be able to have a browser tab on one branch, and another on another branch, at the same time, rather than having to switch back and forth one at a time.
<fullermd> I don't think there's always a clearcut winner on which method is better, even in some specific cases; certainly in general it's all over the place.
<fullermd> I would lay good odds that bzr grows a native and robust variant of git-style before git grows a native and robust variant of bzr-style.
<fullermd> Though AFAIK neither is right around the corner, so that's more of a longer-term thing.
<zaas[1]> this is very true. bzr to git is much better then the other way around. also i am fearing the windows developers (2) will not like the git-hassle
<zaas> oops
<zaas> @fullermd but you love bzr over git i assume?
<fullermd> Oh, yes.  That's why I'm here   :)
<zaas> i guess for simple vcs is does not really matter and bzr seems the safer choice
<zaas> why did you go for bzr?
<fullermd> Oh, mostly for dumb and superficial reasons.  But I stayed because I found better reasons.
<fullermd> There are things git has that I wish bzr did (and that multiple-branches-in-one-tree thing is a big one).
<fullermd> But, I think bzr can grow those capabilities without changing or compromising any of the advantages of the way it currently does things.
<fullermd> And I don't think git can do the complement; it would be a much bigger change in their model of things to support side-by-side branches and WT's with shared history.
<fullermd> I also particularly like bzr's exploitation of merge asymmetry.  I've seen git-using projects go to a lot of trouble to try and avoid situations that that makes a non-issue.
<vila> hi all !
<zaas> haha, my initial choice for git was it's hardcore status and the tree-eating monster on their homepage... but i find it hard to justify my choices now with bzr having API support and git does indeed seem to remain git
<zaas> it was made for large speed-needing many devvers projects like linux
<zaas> hi vila
<fullermd> Sure, I expect there will always be performance/resource-usage advantages you can point at for git.  How much they matter in a relative or absolute sense, probably less clear.  And certainly for small projects, I don't think it matters what you pick at this point perf-wise.
<bialix> ~~~
<vila> bialix: hi ! You're on the beach looking at waves ~~~ ?
<bialix> bonjour vila!
<bialix> not on the beach unfortunately
<poolie> hello vila, bialix
<poolie> won't be here for long
<vila> poolie: yeah, *you* are on your way to the beach ;)
<vila> oh my, already 13:30, time for lunch
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | bzr 2.2.0 is officially out | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<bialix> vila: ping
<vila> bialix: pong
<bialix> do you by any chance know what's the difference between wt format 5 and 6?
<bialix> 1.14 format creates wt5 and 2a creates wt6
<vila> bialix: let me check, in the meant time, why do you care ?
<bialix> I have format1 plugin to avoid 2a as default; wanna update it to 1.14
<vila> bialix: from the docstrings, wt6 supprot views
<bialix> ah
<bialix> ok, thank you
<vila> wt5 support content filtering
<bialix> ok
<vila> bialix: by the way, you still need this plugin ? poolie didn't add a config option for it ?
<bialix> I dunno. I have several machines with bzr 1.18 .. 2.1.2 on them, so I'd better safe than sorry
<bialix> still can't upgrade to 2.2 because of problems with bzr.exe and bundled pyqt
<bialix> waiting for 2.2.1
<vila> right, so I'm supposed to release that tomorrow ;)
<jml> I'm using workingtree.list_files to go through files in a checkout
<bialix> vi-la! vi-la! vi-la!
<jml> I'd like to inspect the contents of these files
<jml> should I just use normal Python facilities to open the file or is there some more efficient bzr-like way?
<bialix> there is method to get the content regardless of workingtree/revisiontree
<bialix> also this method supposedly should normalize the file if content filters defined, I guess
<vila> jml: there is get_file_text that you can use with the file_id IIRC + what bialix said
<vila> jml: so it won't be especially more efficient, but easier for you to code I presume
<james_w> using the bzr APIs makes it easier to support things like acting against the tip revision of a remote branch, if that would ever be useful to you
<bialix> vila: as I understand you will pair with poolie on release tomorrow morning your time? I will hope to see that tomorrow, as fan
<vila> bialix: yeah, that's the plan, I will now go prepare my branches and notes to be ready ;)
<jml> thanks guys :)
<mgz> I have a vision of vila bearing bundles of sticks.
<mgz> And possibly marching on a castle.
<vila> ...with a big black tower ?
<bialix> ... while poolie sneaks with the ring?
<mgz> ehhehe.
<vila> my preciouuuus ! That's where it was !
<bialix> :-D
<knittl> am i understanding a testament correctly? it only signs the current tree (or of any given revision) but not its history?
<mgz> I believe so, you can find more from jam I think on the mailing list.
<jam> knittl: correct
<knittl> ok, thanks
<mgz> yup, under the topic "security", dated 2009-11-05
<knittl> can you paste a link? :)
<mgz> I'm using gmail search, google is a bit crap about indexing the https list archives
<mgz> so.. one sec
<mgz> https://lists.ubuntu.com/archives/bazaar/2009q4/064053.html
<knittl> great, thanks a lot
<GaryvdM> Hi all
<mgz> hey gary.
<bialix> Heya GaryvdM !
<GaryvdM> Hi bialix
<bialix> GaryvdM: have you asked jam about PyQt
<bialix> ?
<bialix> PyQt downgrade for 2.2.1
<GaryvdM> No - Thanks for the reminder
<mgz> also, for 2.2.1, should look at the manifest thing
<mgz> probably just want to put the dll in a subfolder and add magic xml.
<GaryvdM> jam: We would revert to an older version of pyqt. Please could you install it on the ec2 machine.
 * GaryvdM goes to find the bug an download url.
<mgz> I've got several old versions locally, which do you want?
<bialix> GaryvdM: http://bialix.com/python/PyQt-Py2.6-gpl-4.5.2-1.exe + http://bialix.com/python/PyQt-Py2.6-gpl-4.5.2-1.exe.asc
<bialix> mgz: right, manifest
<GaryvdM> Ah - thats it :-)
<bialix> I haven't tested it locally yet for simple application. should test tonight
<GaryvdM> and bug 632501
<ubot5> Launchpad bug 632501 in QBzr "[win32] Subwindows only paint after a keyboard/mouse event. (affected: 1, heat: 10)" [Critical,Confirmed] https://launchpad.net/bugs/632501
<mgz> http://www.no-ack.org/2010/09/complete-guide-to-py2exe-for-pygtk.html <- perhaps a little interesting
<bialix> btw, Gary, I'm a bit worried about this one: https://bugs.launchpad.net/bugs/640082
<ubot5> Launchpad bug 640082 in QBzr "bzr command output is not shown in qbzr output window (affected: 1, heat: 6)" [Undecided,New]
<GaryvdM> bialix: Are you able to reproduce that. I wonder if bzrw.exe is causing that?
<mgz> that sounds like a good theory gary.
<bialix> Gary, no, I did not try
<bialix> why?
<bialix> mgz, GaryvdM : ^
<mgz> the standard streams don't point anywhere with WinMain rather than main
<bialix> it seems like the bug from Gordon is not involved bzrw.exe
<bialix> mgz: I'm sure we should invoke the subprocesses as bzr.exe
 * bialix is checking
<mgz> yeah, could be something else.
<bialix> mgz: yep, we're forcing bzr.exe even if initial GUI invoked with bzrw.exe
<bialix> I did it long ago when I first time started to play with bzrw.exe idea
<GaryvdM> bialix: I just tested. The bug happens with bzrw qpull, but not bzr qpull
<bialix> bam
<bialix> bad
<GaryvdM> I have an idea to fix this.
<bialix> yes?
<GaryvdM> Let me try do a installer build without tbzr (thats where I got stuck...)
<bialix> this is just silly: http://lists.sourcegear.com/pipermail/veracity-users/2010-September/000033.html
<GaryvdM> Rather than blackhole the std(out/err), just leave them
<bialix> GaryvdM: I don't follow
<Glenjamin> bialix: what's veracity?
<bialix> Glenjamin: new DVCS
<Glenjamin> ah yes, thats what the world needs.
<bialix> is it sarcasm?
<Glenjamin> yes
<Glenjamin> also their google-fu sucks
<bialix> ok
<mgz> didn't they have a non-d vcs already?
<bialix> my point not about veracity, but about claim that fast 'hg verify' is what user want to run often
<mgz> and yeah, that post is silly, but says something about the different projects
<bialix> mgz: yes, replacement for some silly vcs by m$
<GaryvdM> mgz: Yes - it was called Vault. I used it for a while
<Glenjamin> i think it was more that the poster cares about the results, and if his users wont ever run it then that VCS is ruled out as an option
 * bialix is trying to read the article mgz gave about py2exe, black page background kills his eyes
<MTecknology> Any idea what's up with this?  Unable to copy ownership from '/home/S6B5B28EB.s' to '/home/S6B5B28EB.s/.bazaar': IOError: [Errno 1] Operation not permitted: '/home/S6B5B28EB.s/.bazaar'.
<mgz> turn off author style then bialix :)
<bialix> mgz: how
<GaryvdM> bialix: In Firefox: View > Page Style > No Style
<mgz> ...depends on your browser?
<MTecknology> hrm.. I just clobbered permissions and it's working now ;)
<bialix> mgz: chrome
<bialix> copy-pasting to OOo may help...
<mgz> er... chrome doesn't seem to make it easy.
<mgz> bialix, the last section talks a bit about manifests, doesn't sound completely correct to me, but might be a starting point.
<bialix> ack
<GaryvdM> Hmm veracity is free (Apache License).
<bialix> mgz: IIRC manifest should be in the same directory as exe
<bialix> crazy
<mgz> it's changed at least twice since the last time I needed to actually ship any compiled code, so I really have no idea
<Glenjamin> So there's only two things veracity does that current tools dont it seems, cross platform C and repo user accounts
<bialix> ,gz: http://py2exe.org/index.cgi/Tutorial section 5.2.1
<bialix> mgz: http://py2exe.org/index.cgi/Tutorial section 5.2.1
<maxb> Python is written in cross platform C.... :-)
<Glenjamin> their words: "We love Python too, but C is a lowest common denominator that can be ported or integrated everywhere we need to go."
<bialix> mgz: or we should add to installer redistributable installer
<Glenjamin> i don't quite see how that doesn't apply to python - the only actual argument is speed i'd have thought. but meh
<mgz> no, we want the bundled + manifest way
<Glenjamin> does bzr use pyrex/pysco at all?
<jam> Glenjamin: we do use pyrex, we don't use psyco
<bialix> mgz: then we have to make sure ec2 build host has proprely licensed msvc 2008?
<bialix> and then copy required dll as part of py2exe run, oh my...
<mgz> I think it did? jam at least had full versions of the compilers I think.
<jam> ec2 has the full versions of the compilers
<bialix> jam: can I have access to ec2 when GaryvdM will build an installer?
<Glenjamin> i'd imagine throwing pscyo at long running operations might speed them up a bit
<bialix> at least read-only?
<jam> bialix: fine with me, I'll need your ip address
<jam> Glenjamin: we rarely have a long running bzr process
<jam> at least from the command line point of view
<jam> and IIRC, psyco doesn't save state between runs
<bialix> jam: my ip address... I don;t have dedicated one
<Glenjamin> bzr check springs to mind
<bialix> it depends on the i-net provider
<jam> bialix: I could potentially use a range, but I can always just set the one you have right now
<jam> I'll also need a username/pass for you, but I can generate that
<bialix> I see
<bialix> I need to get in sync with Gary
<bialix> bye for today
<Glenjamin> can anyone suggest a good letter to abbreviate the --no-backup option to revert?
<mgz> Î©
<Glenjamin> UnicodeEncodeError: 'ascii' codec can't encode character u'\u03a9' in position 17: ordinal not in range(128)
<Glenjamin> :(
<Glenjamin> optparse wigs out on unicode it seems
<GaryvdM> Hi roryy. I see you are from South Africa. Where are you base?
<GaryvdM> I'm in Randburg.
<roryy> hi GaryvdM.  In Centurion
<GaryvdM> Oh cool.
<roryy> not too far :)
<mgz> roryy is the one who fixed two bugs in bzr the other day without changing any code at all
<roryy> yers.  look out for my new book, "zen coding"
<GaryvdM> roryy: Are you coming to sfd?
<roryy> i don't know what sfd is
<GaryvdM> Software Freedom day  - I'll find a link with the details .
<roryy> ah-ha
<roryy> google suggests softwarefreedomday.org
<GaryvdM> http://wiki.softwarefreedomday.org/2010/Africa/South%20Africa/Pretoria
<roryy> hrm, this w/e
<GaryvdM> Yes
<roryy> ah - you're doing a python talk
<roryy> you work at csir?
<GaryvdM> No - I work for lsd.co.za
<roryy> an ex-colleague now at csir thinks numpy is awesome
<knittl> hm. it says in the source code of testament.py 'indented-text form similar to log; human readable'
<knittl> what text?
<vila> ping LOSA
<mbarnett> hello vila
<vila> mbarnett: 2.3b1 will be released tomorrow, sorry for the late query :-(
<vila> mbarnett: I need a pqm branch and the corresponding instance
<vila> mvo: I just filed a RT ticket for it
<vila> mvo: sry, bad Xchat :-/
<vila> mbarnett: I just filed a RT ticket for it
<mbarnett> what is the RT #?
 * vila checks mail
<vila> mbarnett: #41434
<mbarnett> vila: hmm, this is a non trivial change and I am neck deep in another problem.  Let me see if I another losa might have time to work on this.
<mthaddon> vila: what time tomorrow will it be released?
<vila> mthaddon: hopefully before 16:00 UTC
<mthaddon> vila: ok, in that case I can do it tomorrow before then
<mbarnett> yay!
<vila> mthaddon: great ! ping me if you need more info
<vila> mbarnett: thanks for the chase !
<mbarnett> np
<vila> mthaddon: one thing I failed to mention is: which branch should you start with
<mthaddon> vila: ok, please add that to the RT
<vila> mthaddon: I have a question first: can you push this branch later (once) so we start with the "right" revision ?
<mthaddon> vila: I'm not sure I understand the question - can you frame it another way for me?
<vila> mthaddon:
<vila> mthaddon: AIUI, you need to install a pqm instance (handwaving, I've no idea what it requires) including a branch of bzr itself, *and* push this branch to lp
<vila> mthaddon: from there we send requests to the pqm instances to merge new revisions
<mthaddon> vila: let's back up a bit - I was asking about what you mean by "can you push this branch later (once) so we start with the "right" revision" - I understand how to setup a new branch in PQM
<vila> mthaddon: my question is: can you run a 'bzr pull --overwrite' and a 'bzr push lp:2.3' on this branch ?
<mthaddon> vila: this is a new branch, so what am I pull --overwriting?
<vila> mthaddon: a new branch, yes, but with a content
<mthaddon> vila: I'm not sure what  that means...
<vila> mthaddon: What I want to avoid is to have to revert some revisions or add fake merges
<vila> mthaddon: what will be the revno of lp:bzr/2.3 once you create it ?
<mthaddon> vila: so which branch and revision number do you want lp:~bzr-pqm/bzr/2.3 created from
<vila> mthaddon: I don't know yet, maybe the current bzr.dev tip, maybe before, maybe after
<mthaddon> vila: well I can't really do anything until you tell me that
<vila> mthaddon: if you can modify the branch *before* we start using it, the precise revno doesn't matter that much and I can tell you later to modify it
<vila> mthaddon: you can duplicate the bzr.dev instance to start with
<mthaddon> but I have to create the branch somehow...
<mthaddon> ok
<vila> mthaddon: that's why I want to know if we can modify it ! So I can tell you either: start with bzr.dev@5430 *or* start with bzr.dev@5420 and we'll fix it later
<mthaddon> vila: you can always modify it - it's just a bzr branch
<vila> mthaddon: *I* don't have access to this branch :-)
<mthaddon> vila: ok, when I say "you" I mean "someone"
<mthaddon> i.e. a losa
<vila> mthaddon: ok, we are in violent agreement then, I'll update the ticket
<lifeless> vila: whats up?
<roryy> is there any reason that "aptitude install python-testtools" doesn't give me the package from the bzr PPA?  The package doesn't seem to be listed in http://ppa.launchpad.net/bzr/ppa/ubuntu/dists/karmic/main/binary-i386/Packages (don't know if it should be?)
<vila> lifeless: receiving support from losa to create the 2.3 pqm instance :)
<lifeless> vila: what do you mean 'instnace'
<lifeless> vila: do you mean 'please make a new branch for 2.3' ?
<mthaddon> lifeless: he means a PQM managed bzr branch for the 2.3 series
<vila> lifeless: whatever setup needed to get a lp:bzr/2.3 branch
<lifeless> vila: not an instance, new branch, documented in losa procedures.
<lifeless> mthaddon: I was scared for a second :)
<mthaddon> heh
<vila> lifeless: oh thanks, let me read that, oh wait :)
<lifeless> mthaddon: its just branch, push & update the config.
<lifeless> vila: you can I believe.
<lifeless> IMBW
<mthaddon> lifeless: yep
<lifeless> mthaddon: great, you may resume sucking eggs at any time ;)
<vila> mthaddon, lifeless : sorry guys, RM noob here ;)
<mthaddon> :)
<mthaddon> vila: have set it up branched off lp:bzr
<vila> mthaddon: wow, you rock :)
<vila> mthaddon: excellent, I see it on lp
<vila> mthaddon: some people than bzr.dev can send their requests there right ? Or should I read those procedures before asking yet another silly question but in that case where ? :)
<vila> s/some/same/ of course, the typo
<mthaddon> vila: yep, set up with the same group as all other PQM-managed bzr branches
<mthaddon> vila: well, it's the bazaar_releasemgr vs. the bzr group: https://pastebin.canonical.com/37310/
<vila> mthaddon: great !
<GaryvdM> jam: I'm struggling with a problem trying to build the win32 installer on my own host. I seem to remember getting the same error on the ec2 host, and you helped me fix it, but I can't remember how.
<GaryvdM> Here is the error: http://pastebin.ubuntu.com/494940z
<GaryvdM> sorry: should be http://pastebin.ubuntu.com/494940/
<GaryvdM> That file is located here: (sorry - copy paste broken, but I know were the file is on the disk)
<jam> GaryvdM: I don't remember fixing that off-hand
<jam> did we document it?
<jam> we *do* want to bundle that file, right?
<jam> we may need to adjust PATH to include it?
<GaryvdM> jam: I believe so, let me check if it was in the prev installers
<GaryvdM> jam: In the 2.2.0 installer, we have MSVCR90.dll (apposed to MSVCP90.dll
<jam> GaryvdM: from what I can tell, MSVCP90.dll is the C++ runtime, which I didn't think we use anywhere
<jam> ah, maybe qt needs it?
<GaryvdM> jam: Yes - if I py2exe without qbzr, it works - so I think it is a qt dependency.
<GaryvdM> I'm going to try copy it to C:\Python26\DLLs
<jam> GaryvdM: I would say look for wherever MSVCR90.dll is found
<jam> you may also need stuff like MSVCPRT.dll, etc.
<NightDog> Hi. From what I can read from bug 109114 bzr kind of has some problems with big(ish) binary files. Is there any way to increase some parameters to keep it from crashing due to out of memory? I got 16Gig RAM on this maching. Ubuntu 10.04, bzr version 2.2.0. Thanks
<ubot5> Launchpad bug 109114 in Bazaar "[master] bzr holds whole files in memory; raises MemoryError on large files (affected: 27, heat: 216)" [Medium,Confirmed] https://launchpad.net/bugs/109114
<mgz> I don't see it linked in the process when I run a qbzr command with 2.2 though
<mgz> isn't our qt built using mingw?
<GaryvdM> Ah - that worked.
<GaryvdM> I don't think it gets copied into the installer, just py2exe wants to see it.
 * GaryvdM trys a full install build.
<vila> GaryvdM: I'm marginally more happy than if you said: "Ha - that failed", but not knowing what 'that' is I refrain myself :)
<GaryvdM> vila: that = "I'm going to try copy it to C:\Python26\DLLs"
 * GaryvdM puts that in the build host doc
<vila> Oh, I missed that one :)
<mgz> can you try blacklisting them? I really think you only need the c runtime.
<vila> I'm off, tomorrow is release day and I'll start early, good nitght all
<mgz> night vila.
<GaryvdM> mgz: I don't think it ends up in the installer, but I'm going to dbl check..
<GaryvdM> night vila.
<GaryvdM> mgz: Do you know what bialix wanted to do re the manifest file?
<mgz> yeah, see: http://py2exe.org/index.cgi/Tutorial#Step52
<jam> mgz: only 52 steps in? not bad :)
<jam> wait
<zsquareplusc> i'm going to ask something silly ;-) is it possible to clean up the history, e.g. would it be possible to say it should throw away all logs before a date?
<zsquareplusc> i know i can do it with fast export/import at the expense of loosing the ability to compare the old and new tree. but some easier to use frontend/plugin in bzr itself would be practical.
<zsquareplusc> maybe something like a "rebase" that merges all changes before a date to create a new base version.
<zsquareplusc> i'm aware that such operations do not work well when different versions of the branch are published.
<GaryvdM> mgz: We are excluding MSVCP90.dll in setup.py
<GaryvdM> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/setup.py#L691
<GaryvdM> But py2exe needs to be able to find it else it errors :-(
#bzr 2010-09-17
<GaryvdM> Night
<knittl> how are bzr revision ids calculated/generated? i'm also happy with the file name (and line number/function name)
<nsh22> hey... is there a plugin for use with Qt Creator?
<jbowtie> knittl: I assume you're asking about native revids? Because the plugins that talk to other VCS code can generate their own revids. (meaning bzr-svn, bzr-tfs, etc...)
<knittl> jbowtie: yes i was. but i think i found it. email-timestamp-random
<knittl> although i don't understand why random and not some kind of hash
<jbowtie> knittl: Probably no reasonable criteria for what to hash.
<jbowtie> knittl: Don't forget that revids can originate in other places. For example bzr-tfs uses path:changeset for its revids.
<knittl> so in bzr there is no way to verify a revid is actually the revid of that particular revision?
<lifeless> revids themselves are not signatures
<lifeless> signature are signatures
<knittl> also creating the exact same revision twice will generate a different revid?
<jbowtie> knittl: If I understand the question, yes, you'll get two different revids; though I suspect they would merge cleanly in that case.
<knittl> ok
<poolie> hi all
<poolie> i'm having some hardware problems, will be offline a bit
<poolie> some web pages indicate it may be just the cable, which would be nice
<spiv> poolie: almost more aggravating if it just a cable, though :)
<poolie> :)
<lifeless> poolie_: the pad.lv root page doesn't list OOPS
<poolie> thanks
<lifeless> just a small thing :)
<poolie> can you give me an example id?
<poolie> fixed
<vila> ding ding ding, release day, hello all !
<lifeless> poolie: I mean that the root page doesn't explain showing OOPS's
<vila> poolie: got that cable plugged now ? :-p
<lifeless> poolie: actually showing a specific oops works :P
<poolie> lifeless: i understand; i've fixed it now
<lifeless> \o/
<poolie> i was just going to use a specific example
<lifeless> ah
<poolie> but i guess since most people can't click them it's of limited use
<poolie> and maybe they expire anyhow?
<poolie> hi vila
<lifeless> eventually yes
<poolie> i was hoping to get stale lock detection in for the beta, but i guess i won't now
<poolie> and i believe in resisting the temptation to slip or rush
<vila> poolie: you're right, I was hoping for orphans myself :)
<poolie> so, let's just do it
<poolie> can release another later
<poolie> vila, i'm just running gardener
<poolie> which is nice
<poolie> but it told me something was merged even though it has uncommitted changes
<poolie> is that intended?
<vila> poolie: glad you like it
<vila> poolie: it's very rough so far, so it just spew out whatever if finds without dependencies
<poolie> so that seems like a bug? do you want a report somewhere?
<poolie> or for me to just tell you here
<vila> the rules can be refined, but I'm not clear yet about all edge cases, after all, you may modify a tree after it has been merged, you can forget to commit, etc, so upfront, I can't say if your case is valid
<vila> poolie: bug please
<vila> poolie: that's why I released early :)
<poolie> vila, so today shall we do 2.2.1 and 2.3b1?
<vila> poolie: no 2.1.2 ? Anyway, I think the most important is 2.2.1 so we can then merge up
<poolie> and also that
<poolie> i sent a merge up of 2.1 to 2.2 the other day
<poolie> would be worth checking it succeeded
<vila> I think I saw it
<vila> poolie: Can you just remind me the intended audience for 2.1.3 and 2.2.1 (2.3b1 is for everyone willing to try, but not stable yet)
<vila> 2.2.1 will go into maverick right ? Somewhere else ?
<poolie> 2.2.1 should go in to maverick updates
<poolie> they've just today announced the final freeze
<poolie> i don't know if it's possible to do an SRU before the thing even officially releases
<poolie> we should check
<vila> ok, added to TODO
<vila> hmm, we don't have a place where we track which distro carry which bzr version right ?
 * fullermd will be updating ports...
<fullermd> We did have a page on the wiki once.  It was very useful for seeing when anybody bothered updating it   ;p
<vila> Didn't have such a page to track the installer builds ? Or was it done just by mail ?
<vila> That will be very helpful for me and my alzheimer... what's the name ?
<poolie> also, we may want to get a specific clarification that the SRU policy and our policy agree
<poolie> to avoid future confusion
<vila> I think we got such confirmation... or did I just dreamed it ?
<poolie> https://bugs.edge.launchpad.net/bzr-gardener/+bug/641043 - your very first!
<ubot5> Launchpad bug 641043 in bzr-gardener "says 'merged' about trees with uncommitted changes (affected: 1, heat: 6)" [Undecided,New]
<vila> poolie: anyway, yesterday mthaddon was kind enough to create a pqm 2.3 branch so I think everything is in place for whatever release we want to do
<vila> poolie: we may as well start with 2.1.3
<poolie> yes, lets
<poolie> *let's
<poolie> how about if you do it and i'll copilot?
<spiv> vila, poolie: for some reason my __copy__ hack is failing on lp:bzr but not lp:bzr/2.2.  I've thought of a shorter, more conservative workaround for traceback duplication to use to replace the __copy__ hack, it might be good to land that to 2.2 before we make a release of 2.2.1?
<spiv> (I was trying to merge 2.2 to lp:bzr so I could close off a couple of In Progress bugs)
<poolie> just in case it is subtly broken in 2.2?
<poolie> that makes sense to me, put it up for review?
<spiv> Right, and the minimise the delta between 2.2 and trunk.
<spiv> Will do.
<poolie> on the whole that was perhaps not critical enough to put in 2.2
<poolie> otoh it should only affect selftest
<vila> spiv: if you're >90% sure about it , go, otherwise, revert please ;)
<vila> oh, only selftest ? make that >80% then :)
<vila> spiv: thanks for the heads-up anyway
<vila> poolie: also, for 2.3, do we allow only backports from now on or will 2.3b2 be just a pull of bzr.dev ?
<poolie> backports?
<poolie> meaning merges from trunk to 2.3?
<vila> poolie: I mean, what will be the policy for merging changes to 2.3. The same as 2.2 as of today, or everything from bzr.dev at 2.3b2 release time ?
<spiv> IIRC the process was that 2.3 is released from trunk until the first rc... am I misremembering?
<poolie> there was some discussion that having a branch makes the actual release process easier
<vila> spiv: yeah, that
<poolie> in case any small fixes are needed
<spiv> vila, poolie: https://code.edge.launchpad.net/~spiv/bzr/traceback-accumulation-2.2/+merge/35778
<poolie> thanks, +1
<vila> poolie: wow, hold on, what about 2.0.6 ?
<vila> https://edge.launchpad.net/bzr/2.0 says: Released in September 2009; supported until at least September 2010.
<spiv> There are several worthwhile fixes that would be in 2.0.6, especially #522637
<vila> spiv: shameless plug :)
<spiv> :)
<poolie> let's do it
<poolie> hm, what should i do now? still fix stale locks?
<poolie> maybe add a note about requesting SRUs to the release guide, then go back to that
<vila> poolie: whatever you want as long as I can interrupt you :) But if you want to summarize our policies regarding 2.0, 2.1, 2.2, 2.3, that would be good too :)
<poolie> i'll be here for at least 2-3 hours
<vila> meh, now what's new for 2.0, no wonder I couldn't find it :)
<vila> bzr lp-propose -m 'Release 2.0.6' --approve lp:bzr/2.0
<vila> bzr: ERROR: bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr/2.0/ is not registered on Launchpad
<vila> ring any bell ?
<poolie> it sounds a lot like what thumper just changed
<vila> grr, firefox can't start, close any existing window (none, double checked) or *restart your system*. WTF ?
<vila> ok, found the ghost, jinxed it
<vila> poolie: https://code.edge.launchpad.net/~vila/bzr/prepare-2.0.6/+merge/35779 sanity check please,  while pqm is busy
<vila> poolie: ping
 * vila plugs poolie's cable
<poolie> poolie: hi
<poolie> i mean, vila
<vila> :)
<poolie> sure
<poolie> vila re the branch for bug 32669
<ubot5> Launchpad bug 32669 in Bazaar "Adding a symlink to another branch fails (affected: 3, heat: 17)" [Medium,Fix released] https://launchpad.net/bugs/32669
<poolie> hm
<poolie> i have a comment https://bugs.edge.launchpad.net/bzr/+bug/32669/comments/14 saying "fixed in trunk after 2.2" but i don't see it in trunk's news file
<ubot5> Launchpad bug 32669 in Bazaar "Adding a symlink to another branch fails (affected: 3, heat: 17)" [Medium,Fix released]
<poolie> at any rate i wouldn't block 2.0.6 on it
<vila> poolie: me neither :) Just a heads-up for 2.0.7
<vila> poolie: Given http://paste.ubuntu.com/495121/, I'll create a 2.0.7 milestone with a 2011-03-10 targeted date (in six months, a thursday)
<poolie> hm
<poolie> that makes sense
<vila> done
<poolie> its host distribution may EOL before then?
<vila> you mean hardy ?
<poolie> i guess so
<poolie> actually no, isn't 2.0 in karmic?
<vila> anyway, that's why I asked for a policy for 2.0, 2.1, 2.2, 2.3. The milestone is there, we can always says: and this is the last 2.0 release
<poolie> works for me
<vila> poolie: ok, sanity check on https://code.edge.launchpad.net/~vila/bzr/prepare-2.0.6/+merge/35779 ?
<poolie> yes, it's fine
<poolie> karmic is supported until april next year
<poolie> so, it's probably not worth doing a 2.0.7 in march
<poolie> but we can see how we go closer to the time
<vila> pff, two feed-pqm from two different setups, both errored out but both send the request :-/
<poolie> istm we want to get on to this page: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<vila> poolie: istm you're deadly right
<poolie> i'll mail the board
<vila> poolie: great ! thanks !
<vila> spiv:   http://babune.ladeuil.net:24842/job/selftest-hardy/lastFailedBuild/testReport/junit/bzrlib.tests.test_sftp_transport/SSHVendorBadConnection/test_bad_connection_ssh/ :-( how about http://paste.ubuntu.com/495128/
<bialix> heya vila, spiv
<spiv> vila: hmm, I don't think I like that.
<vila> spiv: e.errno and e.args seem to be a mess that we don't handle consistently in other parts (see also bzrlib.smart.medium line 930 )
<spiv> Yeah :(
<vila> spiv: hehe, I don't like it much either, but I want a stop-gap fix
<vila> spiv: I hate to discover that *now* too
<vila> spiv: and the comment in bs.medium is even more worrying because many other places don't even take it into account (grep socket.error)
<poolie> does anyone know off hand if selftest runs during packaging?
<poolie> i think it does not.
<spiv> poolie: my guess is no, but I don't know either.
<vila> dunno, but it runs at each commit and at source release time
<poolie> i know :)
<vila> releasing source is not part of packaging ?
<vila> hmm
<spiv> poolie: IIRC pitti has said that our mandatory tests-run-before-landing might be considered as good
<spiv> But I guess it's probably not too hard to make the packaging do a selftest run.
 * bialix waves at poolie
<vila> bialix: hey !
<poolie> hi there spiv, bialix
<spiv> vila: I'm actually trying to figure out why EPIPE is being treated specially there in the first place :)
<vila> spiv: do you have a better idea for http://paste.ubuntu.com/495128/  that could be landed soon ? Will a huge red blinking FIXME be enough to wait for a better fix ?
<spiv> vila: as a stopgap, socket.error isn't going to be EPIPE is it?  So it could be handled in a separate except block.
<vila> spiv: ha cool, I'd like to have this fixed asap and preferably before cutting 2.3b1
<vila> spiv: let me double check, I think it was
<vila> spiv: http://babune.ladeuil.net:24842/job/selftest-hardy/195/testReport/junit/bzrlib.tests.test_sftp_transport/SSHVendorBadConnection/test_bad_connection_ssh/
<spiv> Blah.
<vila> spiv: and I'm pretty sure the analysis was that it was a socket.error...
<spiv> Yeah.
<vila> an alternative would be a more complex test with isinstance(socket) and e.args[0] or e.errno... but without tests... :-/
<vila> s/complex test/complex if expression/
<vila> spiv: thks for the merge 2.2 -> dev
<spiv> vila: you're welcome, I already had it ready to go :)
<poolie> ok sent
<spiv> vila: I wonder if maybe http://paste.ubuntu.com/495134/ would do?
<vila> spiv: rationale ?
<spiv> vila: I don't really understand why that code is treating errno==EPIPE and EOFError as a connection error, but anything else that occurs during connection as not a connection error...
<spiv> (despite the comment and the fact that annotate blames me :)
<spiv> vila: so I'm thinking "why not treat all of those as a regular connection error?", basically
<vila> spiv: and we have evidence that not handling a socket.error.EPIPE make the test fail... how does this relate ?
<vila> now we will raise a connection error in this case and ?
<vila> it will be handled above and... what ?
<spiv> EPIPE there has always caused some sort of exception there
<spiv> So if the test needs the connection to somehow succeed in that case, we're barking up the wrong tree with tweaking which exception it raises.
<vila> Given that the comment is referring to some untested condition, I'm glad enough to get rid of it, worth a try at least
<spiv> Well, it's not going to solve the intermittent failure.
<spiv> It'll give a more appropriate error, we hope.
<poolie> i need to reply to vila's config thing...
<vila> spiv: ok, let's try that
<spiv> Hmm, I guess the test is about failure to connect, so a more appropriate error may be the fix...
<vila> poolie: the orphan related one ?
<vila> spiv: I understand
<poolie> yeah
<vila> spiv: well, I *think* I understand :)
<vila> poolie: amanica raised a good point about ignoring bzr-orphans
 * spiv experiments now
<spiv> vila: manually hacking that try block to raise various socket.errors, just unconditionally doing self._raise... works.
<spiv> vila: I'll put up a patch
<vila> spiv: thanks
<spiv> vila: I'd love to know what the different treatment of EPIPE was intended to achieve, though :/
<vila> spiv: yeah, me too, let's ask the praised one for this comment :)
<vila> spiv: just joking, trying to ease your pain for not remembering, I so know the feeling ;)
<vila> aw... 2.0 the [ascii] tests, double pain
<vila> plus the fact that I should add that back to babune some way or another ;-/
<vila> spiv: by the way, IIUC you have a patch for python addressing http://babune.ladeuil.net:24842/job/selftest-jaunty/lastFailedBuild/testReport/junit/bzrlib.tests.per_transport/TransportTests/test_readv_with_adjust_for_latency_HttpTransport_urllib_HTTPSServer_urllib_/ ?
<spiv> vila: https://code.edge.launchpad.net/~spiv/bzr/ssh-connect-socket-error/+merge/35784
<spiv> vila: yes, fixed in the upstream 2.7 branch, patch backported already to python2.6 in maverick
<spiv> vila: it's triggered by trying to things with SSLSocket objects that aren't connected
<spiv> vila: (http://bugs.python.org/issue9729 is the relevant report)
<vila> spiv: I know the root cause, ha cool
<spiv> vila: so if we want to avoid it in unfixed python perhaps we can find a way to avoid trying to use SSL sockets there before they are actually connected?
<vila> spiv: it occurs only *before* the first connection ?
<vila> hmm, given the traceback... that's an idea worth checking...
<spiv> vila: if the SSLSocket._sslobj is not set, then various methods (including send and recv) just try to delegate to the back socket object implementation, presumably so that you'll get appropriate socket.errors
<spiv> vila: except those code paths were untested and in some cases broken in two separate ways :)
<vila> spiv: so we get correct socket errors (EBADF especially) if we try to use a close socket right ?
<vila> closed
<vila> spiv: yeah, tell me about untested code ;-/
<spiv> http://svn.python.org/view?view=rev&revision=84806 is the patch that was committed.
<spiv> vila: I know it's triggered by never-been-connected sockets wrapped with the SSLSocket class
<spiv> vila: I haven't checked if was-connected-but-now-now-closed sockets would do the same thing
<vila> spiv: ok, good enough for me, I'm pretty sure the later is covered by tests
<vila> spiv: well, obviously the former is too ;)
<vila> spiv: but randomly :-D
<spiv> I was a bit depressed by the test_socket and test_ssl tests in Python.
<spiv> I'm used to nicer test infrastructure, and more comprehensive coverage.
<vila> spiv: right, I think I have rough idea on how to reproduce it in a test, but not now ;(
<vila> ;) I meant
<vila> spiv: so this patch will find its way upstream in the next 2.6 or only 2.7 ?
<spiv> vila: only 2.7
<spiv> vila: IIRC upstream considers 2.6 to be security-fixes-only now
<vila> spiv: right, ssl is all about security isn't it ? :D
<spiv> Hah.
<spiv> vila: I'm about to log off for the night, anything else you need from me urgently?
<vila> spiv: I don't think so, unless your current pqm submission fails in which case, I'll came personally talk to you on the beach
<spiv> Ok :)
<vila> spiv: I'll land the fix for the EPIPE thing when needed
<spiv> I'll try to keep an eye on it and if it fails put the failure somewhere visible.
<vila> spiv: ok, great, enjoy your week-end !
<spiv> vila: thanks, you too, when you get the chance :)
<vila> grr, bzr-2.0 knows nothing about BZR_PLUGIN_PATH damn alzheimer
 * vila whistles while sudo mv <censored>/plugins <censored>/pluginsx , because... he can
<poolie> vila, https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/35785 describes sru stuff
<poolie> there may be more to add
<poolie> i don't want to duplicate the wiki too much though
<poolie> but please ask  questions
 * poolie trying to get the scripts branch through pqm
<poolie> did we merge the patch to omit details from skipped tests?
<vila> poolie: I don't know, but my understanding is that jam and mgz are shaving this yak differently so they should agree on the better way (I've ping them both)
<spiv> At least the workaround for duplicated tracebacks will help keep the details of skipped tests to something reasonable.
<vila> spiv: +1
<vila> spiv: you did land this one right ?
<spiv> On 2.2 (which is being merged to bzr.dev as we speak)
 * vila drools about spiv wifi access from the beach 8-)
<poolie> have fun spiv :)
<vila> poolie: appropriate Ubuntu release for 2.0 -> >= karmic ?
<poolie> for 2.0 it would be karmci
<poolie> 2.1 lucid
<poolie> 2.2 mavericj
<vila> poolie: ok, and for ppas, I'll follow ppa.txt, but I'm not there yet
<vila> for those following from home: make check-dist-tarball for 2.0.6 : Ran 23384 tests in 1049.609s
<vila> OK (known_failures=39)
<vila> 2014 tests skipped
<vila> bzrlib.tests.blackbox.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server is leaking threads among 2523 leaking tests.
<vila> now running with no locale
<fullermd> Spooky.
<vila> pass with no locale:   [ascii] Ran 23384 tests in 994.671s
<vila>   [ascii] OK (known_failures=39)
<vila>   [ascii] 2260 tests skipped
<vila>   [ascii] bzrlib.tests.blackbox.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server is leaking threads among 2476 leaking tests.
<vila> Finally, I've got some reference point about the number of leaks
<spiv> vila: which reminds me: https://bugs.edge.launchpad.net/subunit/+bug/637674
<ubot5> Launchpad bug 637674 in subunit "RemotedTestCase.addCleanup exists but fails under Python 2.7 (affected: 1, heat: 6)" [Undecided,New]
<vila> spiv: hmm, should ping mgz about it
<spiv> Oh, I see the 2.2->dev branch landed.  Good.
<awilkins> Is there any software I can exploit to rapidly illustrate branch revision graphs?
<bialix> qlog
<awilkins> Esp. something that produces "management grade" graphics?
<awilkins> Hmmph.
<Glenjamin> bzr-gtk adds a graph command iirc
<fullermd> bzrtools has something that uses graphviz.
<Glenjamin> ^^ thats the one i mean
<bialix> it does not work well on big graphs
<awilkins> Heh, I was kinda hoping for something that does hypothetical ones, but I suppose that's just as much work :-)
<Glenjamin> graph-ancestry
<fullermd> Oh, well, for hypothetical ones you use ASCII-art   8-}
<bialix> jam is very good on that
<Glenjamin> oh i see
<awilkins> fullermd, I'm talking about _management grade_ visualization :-)
<bialix> you can search the examples in his mails
<fullermd> 4-color glossy ASCII art, then   :p
<vila> I heard Gary wasn't bad at generating them too ;-)
<awilkins> Heheheheh :-)
<fullermd> You could bang up fake stuff to feed into dot just like graph-ancestry does.
<Glenjamin> visio / omingraffle / dia i guess
<fullermd> I'd probably fiddle with xfig if I had to do it.
<bialix> inkscape
<bialix> we'll I
<fullermd> (I love xfig.  The UI is so bizarre by modern standards that it always makes me crosseyed for the first 10 minutes I use it, but then it snaps right into focus)
<bialix> well I'd just draw by hand and scan it later
<awilkins> Yeah, I've been using Inkscape up till now
<bialix> awilkins: what is "management grade"?
<lifeless> bialix: simple :)
<fullermd> I presume it defines the revenue contribution of each revision.
<bialix> rotfl
<fullermd> Also there need to be little clipart cartoon men pointing at them and smiling.
<fullermd> (for bonus points, they all spontaneously burst out singing _It's A Small World_ partway through the presentation.  Come to think of it, I'd kinda dig seeing that myself.)
<Glenjamin> do it in ascii, then apply a 3D filter to it so its at an angle
<bialix> awilkins: look http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html
<bialix> there is a lot of sexy pictures
<awilkins> bialix, Yes, I always liked those
<awilkins> What are those, inkscape?
<bialix> no, some MacOS tool
<awilkins> Bah.
<bialix> I know
<awilkins> Ought to write something that takes ASCII-art graphs and transforms them into SVG
<awilkins> Which you can then stylesheet and export to PNG
<fullermd> The people who can do things like that are too busy writing converters that go the other way, making ASCII movies   :p
<Glenjamin> I always find whenever i try and use a diagramming tool
<Glenjamin> that i wish i'd just used paper
<awilkins> A tool that generated Hollywood movies from ASCII art would be much more impressive
<fullermd> Isn't that what Avatar did?
<Glenjamin> its not something you generally do often enough to be able to do something that looks good quickly
<fullermd> xfig works well for me once I jerk back into the mental mode to handle the UI.
<Glenjamin> it has a horrible website
<fullermd> I didn't even know it had a website, actually...
<awilkins> Woo, the recursive SVG file on the SVG page for Wikipedia is really impressive
<Glenjamin> whenever i see a site like this i instantly imagine it hasn't been maintained for a decade
<fullermd> I don't think it's had a release in something like that, no.  But it still works fine.
<fullermd> Heck, xv hasn't had a release in, what, almost 2 decades?  But I still use it every day.
 * fullermd wonders when the last time xbiff was touched was...
<Glenjamin> awilkins: where's the recursive one?
<awilkins> Glenjamin, I figured that the one that shows an SVG file overlaid with the SVG logo was actually describing itself
 * awilkins opens the file
<awilkins> Ok, it's a MITE more complex inside :-(
<Glenjamin> oh, i thought there was an SVG which included itself and rendered an infinite picture
<awilkins> That would be cool ; on a related note I have a hankering to produce an XSLT stylesheet that renders an annotated schema as a specification document, which includes a pretty-printed copy of the schema within it as an appendix
<fullermd> Ideally also prettyprinting the XSLT   :p
<awilkins> Heh, just have one XML file that is the schema but has the XSLT inline so you can open it in a browser to get a "management grade" spec but also use it for implementation :-)
<fullermd> Better, XSL could fall into a hole somewhere for a while 'till people get around to finishing jade...    I mean, not that I'm bitter or annoyed or anything...
<Glenjamin> jade?
<fullermd> DSSSL processor.
<vila> fullermd: Digital Super Slow Subscriber Line ?
<vila> fullermd: A ZX80 should do no ?
<fullermd> Pbbt   :p
<vila> Poor BroadBand Type ?
<awilkins> I believe he meant "pttthpt"
<vila> awilkins: no no http not thpt
 * fullermd hires Bill The Cat to do his IRC'ing for him.
<knittl> hm. i still don't fully understand a testament
<knittl> it stores timestamp, parent revs, some text (it says indented, human-readable; but i have no idea what it is used for), and file paths in canonical form
<knittl> so where do file contents come into play?
<knittl> because obviously, having the same pathnames does not mean it's the exact same file contents
<Glenjamin> http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/
<Glenjamin> this says that "bzr testament --long" includes hashes of file contents
<knittl> ok. difficult to find bzr docs on gnome sites
<Glenjamin> i googled "bzr testament"
<Glenjamin> its the top result.
<knittl> still, it's a third party observation
<knittl> http://wiki.bazaar.canonical.com/Testament
<knittl> i expect the bazaar wiki to contain a little more information
<vila> there are a lot of third parties involved in the bzr community, that's the point of a community me thinks...
<vila> knittl: it's a wiki ! Your contributions will be gladly welcome
<fullermd> Well, that's a near-standing page from a glossary jblack was working up way back in the mists of history.
<fullermd> (near-standin that is)
<knittl> vila: my contributions? i really don't grokk bazaar
<knittl> and i don't want to confuse others
<awilkins> Even asking questions is a contribution ; gives people an idea of what's important for people
<fullermd> But, why ask about testaments in the first place?  They're pretty specific use items.
<knittl> because they come after files, ineventories and revisions
<fullermd> Last time I heard or thought about them was when I was looking through the command list and said "hey, what's 'testament'?"  ;p
<fullermd> (I think that wiki page is incorrect too; a testament isn't a type of revision)
<Glenjamin> only if you write a list "files, inventories, revisions, testaments"
<knittl> fullermd: well, that does not help _me_ in any way
<knittl> Glenjamin: i am
<awilkins> Well, it's like a crypto signature
<awilkins> Sort of
<awilkins> Ish
<fullermd> Yes, but why?  A testament is basically just a representation of a revision.
<Glenjamin> seems an odd list of evaluation criteria
<knittl> awilkins: i know what they *basically* are, but that's nearly not enough information
<awilkins> So you can say things like "this software was compiled from this revision" and know that you are talking about an exactly particular state, I suppose
<knittl> it's like saying 'a revision is a specific version of the project'
<jelmer> knittl: as I understand it a testament is a format-independent mechanism for verifying the contents of a revision
<knittl> great, that's 1 thing a revision is made of
<Glenjamin> does that mean you can lookup a revision using a testament's checksum
<awilkins> git just has this property because of the way it works - you can just say "revisions <blah>" where blah is the SHA-1 value and be almost totally certain that you are talking about the same thing
<knittl> awilkins: git uses annotated tags to sign revisions
<jelmer> Glenjamin: in theory, sure. I'm not sure what the use of that would be though
<awilkins> knittl, because of the way git processes data, the signature is only required to certify the SOURCE of a revision
<knittl> on an unrelated topic: how does bzr map from revids to revisions? using an index/dictionary file?
<knittl> awilkins: ehm. i know. i think i really know git well
<awilkins> knittl, The SHA-1 hash identifies any revision + it's history + it's content with certitude.
<knittl> hashes dependent on all contents and ancestor content
<awilkins> Apologies if I'm teaching you to suck eggs
<Glenjamin> what happens when you have 2^40+1 commits?
<fullermd> Linus comes to your house and beats you up.
<knittl> why 40? sha1 is 160 bits
<jbowtie> I see some of my documentation patches have been merged, but the bug status is still "Confirmed" (example: lp:401605)
<Glenjamin> hrm, dunno why i had 40 in my head
<Glenjamin> oh, its 40 chars in hex
<jbowtie> What needs to happen before those get bumped to "Fix Committed" status?
<awilkins> One hex char is a nibble
<knittl> 40 could be relevant to collision attacks, but 40 sounds like an awfull small number
<fullermd> Well, all you REALLY need for a collision is two.  Finding them is the trick...
<Glenjamin> 2^51 is the collision attack number for sha1 according to wikipedia
<knittl> my wikipedia tells me 2â¶Â³
<fullermd> Of course, most VCS exploits you'd want to do call for preimage attacks rather than just collisions...
<awilkins> And you'd have to find collisions that were both valid git trees also
<knittl> yes. but why are we having a conversation about collision attacks on sha1?
<fullermd> It's more fun than discussing snails.
<vila> jbowtie: where did they land ?
<knittl> i'm looking forward to sha3
<knittl> grÃ¸stl ftw
<knittl> :]
<vila> jbowtie: I'm releasing today and I'm reviewing all of them, but if they landed recently you can mark them 'Fix Released' with a 2.3b1 milestone
<jbowtie> vila: 401605 was merged into lp:bzr, revision 5202 back in May.
<vila> jbowtie: we don't use 'Fix Committed' anymore
<jbowtie> vila: Well that would explain it.
<vila> jbowtie: Are they mentioned in NEWS ? If yes, the milestone where they appear applies
<spiv> jbowtie: http://doc.bazaar.canonical.com/latest/developers/bug-handling.html
<Glenjamin> oh, while people are around
<Glenjamin> can anyone suggest a single letter shortcut for revert --no-backup
<bialix> bzr alias "myrevert"="revert --no-backup"
<bialix> bzr myrevert
<bialix> sorry, it's 2 leters
<Glenjamin> good point
<bialix> make up your own!
<spiv> bialix: I'd use 'bzr alias rnb="revert --no-backup"'  ;)
<bialix> cool! I like what spiv said
<fullermd> Rig up a foot petal!
<Glenjamin> yeah, i have aliases for most things - dunno why that didn't occur to me
<vila> Glenjamin: nope, that's the only case where bzr can lose your data, you have to type it, I will even prefer --no-backup-I-know-it-will-kill-my-cat :D
<bialix> hehe
<Glenjamin> i do a lot of "merge --uncommitted" followed by revert on the merge source
<jbowtie> OK, so I've basically been ignoring bugs once a merge proposal is accepted. But they're still sitting there as open - so what do I do about it?
<jbowtie> Because otherwise my bug queue is not going to get shorter.
<spiv> jbowtie: mark it as Fix Released, targetted to the milestone of the next release (the one that will include your fix)
<spiv> jbowtie: although I think if the merge proposal includes a NEWS entry with a bug number then around the time release is made the RM will probably notice if the bug status is out of date.
<jbowtie> spiv: So I should be touching NEWS when I fix bugs; did not realise that.
<spiv> jbowtie: we often ask for NEWS entries when reviewing patches, but we also often just add them for you if that's all that's missing.
<spiv> (And sometimes we don't have them at all, for sufficiently minor changes or due to forgetfulness)
<jbowtie> spiv: Hmm, I can't seem to set milestone field. #401605 needs to be updated to target the milestone.
<jbowtie> vila: Sorry - that should be for you - Launchpad is not letting me set the milestone field.
<vila> jbowtie: that's weird... not in the right team, but which team ?
<vila> ha, bzr-qa
<jbowtie> vila: You will forgive me if I have no clue...
<spiv> jbowtie: which milestone?
<spiv> (we can add you to the relevant team as soon as we figure out which one that is, but in the meantime I can set this one for you)
<jbowtie> spiv: Based on the revision number I would assume whatever's being released next
<vila> jbowtie: adde you to bzr-qa, try with another bug
<vila> added
<spiv> jbowtie: ok, set to 2.3b1
<jbowtie> vila: That seems to have worked, will review my merged bugs and try to figure out which ones made 2.2 and/or 2.3b1
<vila> jbowtie: don't forget to assign the bug to yourself so we can blame you in the future :)
<vila> jbowtie: thanks for that ! Let me know when you're done or if you need help
<jbowtie> vila: No worries; will tell you bug numbers when I finish so you can check my work.
<vila> jbowtie: I'll get mail for that, don't worry
<jbowtie> vila: Done, wasn't as many as I thought. Only odd one was #146780 since it was fixed on wiki rather than in codebase.
<vila> jbowtie: great. So yeas, wiki is instant-fix-released ;)
<knittl> how can i get a list of stored testaments for a repository/branch?
<jbowtie> Great, only 53 documentation bugs left to fix!
<knittl> i thought revnos do not change inside a branch?
<Glenjamin> they don't
<Glenjamin> but they can be different for the same revision in a different branch
<knittl> then why are my commits now 5410.1.x instead of 5411-5413?
<knittl> i did bzr pull
<bialix> revnos can be changed with pull/push --overwrite
<knittl> i did not use overwrite
<bialix> you pulled from the branch where is your local branch was merged
<knittl> WHAT?
<bialix> so pull makes your local branch the identical to the remote one
<Glenjamin> pull doesn't just update your branch, it makes your branch a mirror of the remote one
<bialix> knittl: perhaps you want to look at append_revisions_only settings for branch; it prevented to mainline revno changes
<knittl> so you tell me revnos do not change in a branch? and then you tell me they do?
<Glenjamin> no, your branch changed
<bialix> yes
<knittl> what nowâ½!
<bialix> it depends on what you need
<Glenjamin> bzr help pull
<Glenjamin> Purpose: Turn this branch into a mirror of another branch.
<knittl> i have my branch. i do a pull (which should not succeed, because i have different revisions)
<Glenjamin> you have different revision numbers, or different revisions?
<knittl> i made 3 revisions in my branch
<knittl> they got merged
<bialix> either you have alias for pull or your local branch was fully merged into another branch
<Glenjamin> so it has all the revisions
<bialix> ok, the latter
<knittl> it was. but then, why do my revnos change?
<bialix> because you branch was merged
<Glenjamin> therefore no data is lost, and your branch is no longer your branch, its a fresh version of the pull location
<bialix> your branch
<knittl> i understand that nothing was lost
 * bialix shut up for a while
<Glenjamin> if you want revnos to stay the same in your local branch, use merge - not pull
<knittl> Glenjamin: it cannot just change my branch to something different? â even if all revisions are there
<bialix> why not?
<Glenjamin> it can, it does, it even says it will
<Glenjamin> because that is what pull does
<knittl> what happens if i merged? conflicts because revs are in both branches?
<bialix> no
<knittl> all revisions from upstream collapsed into a single merge commit?
<Glenjamin> the latter
<Glenjamin> but its expandable in the log
<Glenjamin> and even looks pretty in bzr qlog
<knittl> unknown command qlog
<knittl> still, this behavior is â in my eyes â stupid
<knittl> s/stupid/unintuitive/
<Glenjamin> install bzr-qt for qlog
<bialix> it's not bzr-qt
<knittl> no, i don't need another qt app
<bialix> it is QBzr
<Glenjamin> ah yes, it seemed wrong as i was typing it but couldn't remember what it was called
<Glenjamin> its only unintuitive because you used git first, and its pull command means something different
<Glenjamin> in git, pull just means fetch then merge
<bialix> in bzr pull means fast-forward merge
<knittl> it's unintuitive in every imaginable way
<knittl> fast-forward does not change revnos
<Glenjamin> your confusing unintuitive with "different from this other tool"
<bialix> git does not have revnos
<Glenjamin> you wanna talk about unintuitive, try git checkout == svn revert
<knittl> they both do what you'd expect neven if ythey are named differently)
<knittl> and i'm not even complaining that bzr is different from git
<Glenjamin> anyway, revnos are not as important as you'd think
<knittl> but i expect my revnos to stay the same
<Glenjamin> then don't use pull
<knittl> so i can see: bzr log -rXXX # my revision
<jbowtie> knittl: The revids are stable in bzr - however the revnos are just a friendly representation.
<knittl> even after i do git pull
<Glenjamin> basically, "bzr pull" takes the remote branch, and puts it at your local location
<knittl> so it's bzr clone?
<Glenjamin> and in this case the remote branch's history differed from yours
<knittl> bzr clone --resume
<Glenjamin> yeah, i guess so
<knittl> bzr clone --update-and-overwrite-local-branch
<Glenjamin> well, only if the actual revisions are not going to be lost
<fullermd> bzr update-my-out-of-date-mirror-of-that-branch
<Glenjamin> what's do these two branches you have represent?
<knittl> grml. i have to accept it. still find it unintuitive
<Glenjamin> ie. which is the mainine, which is a feature branch
<knittl> what's do WHAT?
<Glenjamin> you merged your local branch into your remote branch, so that implies that the remote one is the mainline
<knittl> i didn't merge anything. upstream merged
<Glenjamin> well somehow the revisions you made in local got into remote
<knittl> yes, upstream merged them
<Glenjamin> right, so then upstream has the mainline list of revision numbers
<Glenjamin> which as far as the world-at-large is concerned, is the right revnos
<bialix> knittl: set append_revisions_only = True in your branch.conf
<bialix> mgz: ping
<mgz> boing.
<Glenjamin> bialix: that would have just stopped him from pulling, no?
<bialix> just discovered: python -c "print None <= 0" prints True; is it good?
<bialix> Glenjamin: yes, stopped from pulling and compalining maybe
<fullermd> bialix: I imagine you expect that from any duck typing language...
<bialix> qwa
<mgz> that's going away in Python 3.
<Glenjamin> >>> None == 0 #> False
<knittl> ok, no sense talking against you, for me it stays unintuitive. period.
<Glenjamin> >>> None >= 0 #> False
<bialix> heh
<Glenjamin> >>> None <= 0 #> True
<Glenjamin> thats odd.
<mgz> Python 3: TypeError: unorderable types: NoneType() <= int()
<mgz> it's the way it is in Python 2 so you can have a list of arbitrary objects and sort it without fuss
<bialix> hmm
<bialix> ok, I see
<knittl> how can i display the saved testament of a revision?
<spiv> knittl: there's been some discussion of making append_revisions_only = True the default
<fullermd> Testaments aren't saved.  They're generated.
<knittl> so where is the signature stored?
<fullermd> A testament isn't a thing, it's just a way of displaying a revision, not immorally unequivalent to 'log'.
<knittl> which can be signed
<fullermd> Well, any text can be signed.  Testaments are just what bzr created as "use this text to sign".
<fullermd> Signatures were a separate file in knits, AIR.  I imagine they're just another data record in packs.
<knittl> ok
<spiv> I'm not sure if there's an easy way to see the signature via the command line; I can give you the Python incantation if you like.
<knittl> i'm afk now. need to smash something :D
<knittl> spiv: no way via commandline? oh myâ¦
<Glenjamin> if it makes you feel any better, i found git really unintuitive cos i was used to bzr/svn semantics for the commands
<spiv> There just hasn't been much demand to work on UI around signatures, basically.  Relatively few people care about them.
<knittl> nobody cares about integrity?
<bialix> what is integrity?
<fullermd> A line of servers from HP, I think.
<spiv> Apparently not, from the questions I've seen users ask.
<spiv> At least, not in that form.
<knittl> nobody cares about verifying history of a revision?
<Glenjamin> not really, i just care that the code in that revision works
<spiv> Well, obviously the bzr team cares, because we implemented the feature to have signatures :)
<Glenjamin> how it got there is bonus information for me
<knittl> spiv: but it cannot be verified from the command line?
<Glenjamin> on the matter of integrity, i do have some missing revisions with cause some history operations to fail on a bzr repo that used to be an svn repo (and spent a year or so being an svn repo accessed by bzr clients)
<spiv> I vaguely recall a plugin that did that.
<fullermd> Shoot.  Almost nobody even cares enough to run ECC memory; cryptographic signatures are so many steps beyond that...
<fullermd> Yeah, jam wrote a plugin AIR.
<Glenjamin> bottom of this page http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/
<vila> fullermd: not mentioning running systems without RAID...
<knittl> what if i wanted to display a signature for a revsion(testament)
<fullermd> vila: Well, then you get into systems with (or without) RAID, but without a FS with hierarchial checksums too...   but I stray.
<vila> fullermd: hierachical file systems !!! Who needs that ???
<fullermd> vila: Well, nobody cares about hierarchial namespaces anyway.  I mean, look at DNS.
<vila> fullermd: pff IP addresses, real men use MACs ;)
<knittl> you're confusing two transport layers here
<bialix> knittl: `bzr testament` -- is not it what you're looking for?
<fullermd> Macs?  I thought you were using Ubuntu   ;p
<knittl> bialix: that does not display the signature, only the text form of a testament
<fullermd> bialix: Testament doesn't display any signatures.  It just gens a testament for the rev.
<Glenjamin> knittl: there's some code halfway down that page i linked that shows how to display a signature
<Glenjamin> which could be trivially wrapped in a command
<bialix> are you talking about gpg-signatures?
<bialix> because I don't know what else exists in bzf
<knittl> Glenjamin: i find it a pity there's no command for that
<vila> fullermd: you're mixing hardware and software now ;-P
<knittl> i think i'll write a patch for that â¦
<knittl> so i can again complain about rev 5432 being 5431.1.1 after pull
<fullermd> vila: Heck, just wait'll I get warmed up!
<bialix> knittl: `bzr pull -r5431.1.x . --overwrite`  will restore your previous history
<knittl> bialix: but will kill upstream revs?
<bialix> what it means "kill"?
<knittl> they are gone, aren't they?
<bialix> you want your precious revisions back -- you'll get them
<Glenjamin> if you do that, then merge from upstream
<bialix> then merge from upstream, yes
<knittl> Glenjamin: so, after pull --overwrite upstream revisions are gone and i have to merge (download) them again
<bialix> knittl: no
<knittl> that topic was closed btw
<Glenjamin> they're probably cached in the repo
<bialix> you don't need to download them
<bialix> they're in the repo
<spiv> knittl: the repository won't forget the revisions
<bialix> run `bzr heads --dead` after pull
<spiv> knittl: the bzr pull with simply change which revision the branch considers to be its tip
<knittl> whatever. got work to do now
<spiv> If you do another operation later that needs those revisions, they won't be refetched.
<mgz> looking at the diff of one of spiv's changes, I see I mispelt my own name in the NEWS file
 * maxb puzzles at getting "Repository with UUID 283d02a7-25f6-0310-bc7c-ecb5cbfe19da at svn://anonsvn.kde.org/home/kde contains fewer revisions than cache." from bzr-svn
<maxb> (non-reproducible)
<maxb> lifeless: Is there a debian packaging branch for testtools in sid?
<knittl> raise errors.NoSuchRevision(self, revision_id)
<knittl> bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///home/knittl/bzr/bzr/.bzr/repository/') has no revision pqm@pqm.ubuntu.com-20100917091211-1e9h9nf6bsdjr6bd
<knittl> $ bzr log -rrevid:pqm@pqm.ubuntu.com-20100917091211-1e9h9nf6bsdjr6bd
<knittl> ------------------------------------------------------------
<knittl> revno: 5431 [merge]
<knittl> so, what's wrong?
<Glenjamin> knittl: are you trying to output the signature?
<Glenjamin> i wrote a quick command to do that, and got the same nosuchrevision error
<Glenjamin> if there's no signature, thats the exception that gets thrown
<knittl> Glenjamin: yes
<Glenjamin> knittl: https://code.launchpad.net/~glenjamin/+junk/bzr-signature is as far as i got
<Glenjamin> but i have no repos with signed revisions
<dobey> if i sprout() a branch from an existing bzr branch, and commit to the new branch, why would basis_branch().get_revision_id() on the new branch, return the last revision committed to the new branch, rather than the last revision of the basis branch?
<GaryvdM> dobey: Maybe you need to unlock, and relock
<GaryvdM> dobey: Oh sorry - I miss read the question. Please ignore my answer.
<dobey> hmm
<GaryvdM> Hi vila. How is it going?
<vila> GaryvdM: at pqm pace...
<GaryvdM> vila: Ah
<vila> GaryvdM: 2.0 requests are twice as slow and I didn't order them as I should have
<Glenjamin> is anyone familiar with the inner workings of QBzr? I was trying to see how to add --diff-options into qdiff the other day and couldn't for the life of me see how it worked
<GaryvdM> Glenjamin: I can help you in a sec.
<Glenjamin> my actual goal is just to be able to say "ignore whitespace"
<GaryvdM> Glenjamin: so it would be cool if you could specify that from both the command line, and the ui. We are planing to make the qdiff ui simillar to new qannotate ui.
<GaryvdM> then we can have all the view options in a menu.
<Glenjamin> i see
<GaryvdM> Glenjamin: but to start from the command line would be easier.
<Glenjamin> is there a way to change the qannotate colours?
<GaryvdM> Glenjamin: The colours are chosen from a hash of the committers name.
<Glenjamin> heh, my boss gets hot pink
<GaryvdM> Glenjamin: you would need to change the code to do this.
<Glenjamin> clever approach to colour selection though
<GaryvdM> Glenjamin: As the commit gets older, it changes towards white.
<Glenjamin> is that pretty new? I'm sure i've used qannotate before and its been pastel colours like qdiff
<GaryvdM> Glenjamin: Those must have been older commits.
<GaryvdM> Glenjamin: so to add a commandline option to qdiff, you need to start in lib/commands.py
<Glenjamin> that bit I can do, but i couldn't see how diffwindow gets its content
<Glenjamin> or can i just assume it does, and pass the flag through to _get_ext_diff_args
<GaryvdM> get_ext_diff_args is used when launching a external diff program. You need to change get_diff_window_args.
<Glenjamin> does the external diff button only appear if its configured then?
<GaryvdM> Yes
<GaryvdM> Glenjamin: but you will need to change every get_diff_window_args, as you will need to change what is expected from that method.
<GaryvdM> Glenjamin: there are 2 in commands.py, and 3 in diff_args.py
<knittl> wouldn't it make more sense to default to the current revision instead of the last one?
<Glenjamin> would it make sense to have it return a dict instead of a tuple?
<Glenjamin> knittl: the current revision is the last one, i assumed
<knittl> e.g. in cmd_testament -> if revision is None: revision = b.last_revision()
<knittl> Glenjamin: not if you do bzr update -r old_revision
<knittl> but i'm not really knowledgeable of bzr internals, so i could be mistaken
<Glenjamin> i didn't dig into the branch/revision API, i just used an example that worked
<Glenjamin> if you want to extend it so -r actually works, please do :)
<GaryvdM> Glenjamin: Yes, a dict makes more sense.
<knittl> unhashable type list. i think i'm getting closer
<knittl> hm. that's not my code that's crashing :-/
<knittl> woohoo
<Glenjamin> GaryvdM: so once i've sorted out the arguments, where abouts can i plug in and tell the diff bit to ignore whitespace?
<GaryvdM> Glenjamin: I'm not sure what is the best way to implement this. One way is to modify the text that you pass to the diff, so that all white space is removed. You will need to keep track of what white space you removed, so that you can translate the ranges of the hunks returned for positions with out whitespace to positions with whitespace.
<Glenjamin> i wonder if it almost makes sense to allow the internal diff algorithm to ignore whitespace
<Glenjamin> i was kind of hoping qdiff was a thinner wrapper around diff than it actually is
<GaryvdM> Glenjamin: It does this at line 377 of diffwindow.py
<GaryvdM> Glenjamin: yhea - sorry about that. The only thing we use is a SequenceMatcher.
<Glenjamin> oh i see, this is the actual differencing
<GaryvdM> Yes
<Glenjamin> ok, i follow your suggestion now
<Glenjamin> sounds fiddly, but doable
<Glenjamin> i might give it a shot this weekend
<GaryvdM> Goodluck
<nprasath002> hi i,m just starting to use bazaar. how can a get gui interface for bazaar. what plugin will do that?
<dash> nprasath002: 'bzr explore' should do it in most recent versions
<dash> how did you install it?
<nprasath002> i use via synaptic package manager
<dash> ok, then that should work.
<nprasath002> thanks
<knittl> where should i put show-signature and how can i inform bzr of the new command? i thought @display_command would be enough
<dobey> anybody can help with my previous question?
<dobey> if i sprout() a branch from an existing bzr branch, and commit to the new branch, why would basis_branch().get_revision_id() on the new branch, return the last revision committed to the new branch, rather than the last revision of the basis branch?
<GaryvdM> dobey: on what object are you calling basis_branch()? I grep bzr.dev for that method, and could not find it.
<knittl> why aren't there utility functions like 'openBranch' or 'getRevisionId'?
<knittl> seems like if rev is None: rev_id = b.last_revision() else: rev_id = revision[0].as_revision_id(b) is used quite a lot
<knittl> as is if branch == '.': b = Branch.open_containing(â¦)â¦
<GaryvdM> knittl: are you writing a plugin? if so, put this in the plugins __init__.py:
<ddaa> knittl: they are static methods, like Branch.open
<GaryvdM> from bzrlib.commands import plugin_cmds
<GaryvdM> plugin_cmds.register_lazy(name, aliases, module)
<knittl> GaryvdM: i don't know if it's a plugin
<knittl> show-signature
<knittl> ddaa: so? what prevents utility methods? even better suited for calling static methods?
<GaryvdM> knittl: Are you going to have this command live in bzrlib, or a plugin?
<ddaa> Because: python -c 'import this' | grep Namespaces
<knittl> GaryvdM: right now it is in bzrlib
<ddaa> also, it makes it obvious what these functions return
<ddaa> Branch.open returns a Branch...
<GaryvdM> knittl: Look at bzrlib/builtins.py
<knittl> ddaa: i don't understand? if rev is None: "default" else: "get id" is used a lot
<knittl> GaryvdM: i've put it there already
<dobey> GaryvdM: a bzr Branch
<ddaa> knittl: because: python -c 'import this' | grep ambiguity
<dobey> GaryvdM: sorry, typo. basis_tree(), not basis_branch()
<knittl> In the face of ambiguity, refuse the temptation to guess.
<knittl> what does that tell me? :-/
<ddaa> maybe I don't understand your problem
<knittl> i think so
<knittl> my question is: the code Â»if branch == '.': b = branch.open_containing(branch)[0] else: b = Branch.open(branch)Â« is used over and over
<knittl> why isn't there a single function which returns the correct Â»bÂ«?
<knittl> same goes for Â»if revision is None: rev_id = b.last_revision() else: rev_id = revision[0].as_revision_id(b)Â«
<GaryvdM> dobey: The basis_tree for a working tree is the tree which the wt is based on. It will be the parent of the revision for the next tree.
<knittl> GaryvdM: my command class is in builtin.py
<knittl> how do i register it for autocompletion?
<GaryvdM> dobey: It has no relation to the parents branch tip, or common ancestor.
<knittl> i cannot find register_something for the other classes in that file
<dobey> GaryvdM: how do i get the last revision from the parent tree that a branch is based on, then?
<dobey> i need the revision id or revno of the last revision from the parent tree
<knittl> and should i use sys.stdout.write or self.outf.write?
<knittl> different (existing) commands use one or the other form
<GaryvdM> dobey: I'm not sure exactly offhand, but you are looking for how to get the common ancestor
<knittl> cmd_testament uses sys.â¦ and cmd_plugins uses self.â¦
<GaryvdM> dobey: From the command line, you could do bzr diff -r ancestor:../trunk/
<dobey> GaryvdM: but how do i do that with bzrlib? i don't want a diff, i just want a reference, so i can iter over the revisions since that revision
<dobey> GaryvdM: ie, i need to get all authors for all revisions, after the branch from the ancestor
<GaryvdM> dobey: ok - take a look at the code for bzr missing --mine-only. that will do what you need
<knittl> should i use self.outf.write or sys.stdout.write?
<knittl> and how do i register the command for autocompletion?
<dobey> GaryvdM: do you know where that code is? i'm having trouble finding it. if it's find_missing() in bzrlib.missing, then i can't really go that route :(
<pickscrape> Is anyone aware of a workaround for bug 389674?
<ubot5> Launchpad bug 389674 in Bazaar "NotImplementedError(_PreviewTree.inventory) when unshelving must create the parent directory (affected: 3, heat: 3)" [Medium,Confirmed] https://launchpad.net/bugs/389674
<GaryvdM> dobey: why not? If you look in find_missing, you will see that it opens the revision dags of both branches, and finds the revision unique to each branch, but you only need to get the revisions unique to one of the branches.
<dobey> GaryvdM: because how do i point at the remote branch if i've only got the local one to look at?
<GaryvdM> dobey: if you don't have access to the remote branch, you will need to record what it's tip was when you branch it. Bzr does not currently store this.
<dobey> fail :(
<GaryvdM> dobey: What are you trying to do?
<dobey> GaryvdM: get all the authors of all revisions in a branch, since it was branched from its ancestor
<ovnicraft> hi folks i want to configure bzr with my user for pull/push but my laptop user is different from my lp user?
<GaryvdM> dobey: And it has to work with no connection to the ancestor?
<ovnicraft> how i can do this?
<GaryvdM> ovnicraft: You can create a ~/.bazaar/authentication.conf
<dobey> GaryvdM: preferably, yes. i might be able to hack it to pass in the other branch, but that makes things amazingly complex, since it might have changes since the child branch was made
<GaryvdM> knittl: It seem that commands.py scans the builtins module for classes whos names start with "cmd_". Is your command named accordingly?
<ovnicraft> GaryvdM, can i add th user here: parent_location= bzr+ssh://myuser@bazaar.launchpad.net/%7Eopenerp/openobject-server/trunk/ ?
<ovnicraft> and get it done
<GaryvdM> ovnicraft: Yes
<GaryvdM> Night all.
<knittl> hm, gary is offline
<knittl> yes, my command is named cmd_show_signature
<knittl> https://code.launchpad.net/~knittl/bzr/show-signature who wants to test?
<dobey> abently, jam: ^^ is that true? do i need both branches to be able to determine the revno/revid of the ancestor from which a branch was created?
<jam> dobey: I'm not sure what you are ^^ at, but if you want to run "ancestor:" you need a branch
<jam> note that you can pretty trivially create a branch with "bzr branch --no-tree -r x.y.z . ../ancestor-branch", etc.
<jam> with --no-tree and a shared repo, it is rather lightweight.
<jam> Certaintly the bzrlib internals support more
<jam> just hasn't been needed from the commandline
<dobey> jam: previous converation with garyvdm. can i do it with just the child, or do i need both branches? i'm doing it from bzrlib, inside tarmac
<jam> dobey: how do you know what the "ancestor" is?
<jam> without having its branch
<jam> if you mean "I need the tip pointer of the branch I branched from", no bzr does not store that
<jam> also, it is not accurate once you have merged from the ancestor branch
<dobey> that's what i'm trying to figure out
<jam> if I do "bzr branch foo bar; bzr commit -m "foo" foo ; "bzr commit -m "bar" bar; cd bar; bzr merge ../foo; bzr commit -m "both"
<jam> then what is the actual answer?
<jam> what happens if foo merges bar 1 time, etc, etc
<jam> you really want something like "Graph.find_unique_ancestors()" but you need to have the current tip of the branch you are comparing against
<jam> IMO
<jam> dobey: I said that pretty fast, but I can spell it out if you would prefer
<dobey> well, if i could get the info from the merge proposal in launchpad, i'd be just as happy.
<dobey> since launchpad seems to understand all this just fine, in terms of the merge proposal, though it doesn't seem to exactly expose all the information in the API
<jam> dobey: well, there are probably 2 things to consider
<jam> 1 the branch you are merging into
<jam> 2 any prerequisite branches
<jam> I don't know what lpapi exposes
<dobey> well let's ignore the prerequisite branches issue for now, as i don't think tarmac handles them currently, anyway
<jam> dobey: https://code.edge.launchpad.net/~abentley/bzr/annotate-revspec/+merge/34681
<jam> It has a "Merge into: <BRANCH_URL>"
<jam> and a "Prerequisite: <BRANCH_URL>"
<pickscrape> Anyone know if it's possible to so something like convert a shelf-* file into a diff so I can apply it by hand?
<jam> if you grab that branch_url, you can open the branch and use "Branch.last_revision()" to get its tip
<knittl> jam: how can i make a command default to the current checked out revision?
<knittl> using last as default is unintuitive
<dobey> jam: right, but that assumes that it hasn't changed since the branch proposed for merger
<jam> knittl: WT.last_revision()
<jam> vs Branch.last_revision(0
<jam> dobey: "Hasn't changed" ?
<jam> what hasn't changed
<jam> the branch? Isn't the point that you should handle if it *does* change?
<jam> certainly the Merge Proposal page uses the current tips for those things.
<dobey> jam: relying on that has to assume that there are no revisiions in the target branch, that aren't in the source branch
<jam> dobey: MPs don't assume that
<jam> why are you?
<jam> If I have put up a branch for review with 10 changes, and I land 5 of them, what do you want the system to do?
<jam> Still report all 10?
<dobey> i'm not, but i can't get the last revision of the target and then use that as a reference in the source, if that revision isn't in the source
<jam> dobey: graph = Repository.get_graph(other_repository)
<jam> will use "other_repository" as a fall back for revisions it doesn't know about
<dobey> what i would like is for proposal.preview_diff.prerequisite_revision_id to actually give me a value other than 'None' but it doesn't seem to do that
<jam> dobey: abentley or maybe rockstar are more knowledgeable about the Launchpad side of things (even thumper if he's around)
<rockstar> dobey, don't use Launchpad at all.  Do it all in bzr.
<dobey> rockstar: it doesn't seem possible.
<rockstar> jam, dobey needs to get the LCA between two branches, and then get all the revisions from that LCA to tip in one of the branches.
<lifeless> maxb: yes
<abentley> dobey, is this for a merge proposal that has a prerequisite branch?
<maxb> where? :-)
<jam> rockstar: certainly. But he wants to get the information about what revisions, etc *from launchpad*
<jam> (what branch, and what revision in the branch, etc)
<dobey> abentley: no, not other than the target
<jam> pickscrape: I'll poke at it for a second, but offhand I don't know of a way to do it
<dobey> jam: well i'd like to get the information from bzr, but from what you're all are saying, it isn't stored in bzr
<jam> the old shelves stored actually patches, but the new one does not
<dobey> for what it's worth, i don't care about what tip is at all
<dobey> what i want is the revision id at the point when the child branch was created from the parent.
<dobey> that is the only piece of information i want/need
<pickscrape> jam: thanks!
<dash> yeah the new shelve is nice when it works, and it works more often now
<dobey> or perhaps i am oversimplyfing things at the moment, because this seems like it is getting overly complex very easily
<dash> but when it breaks it's really broken. :)
<abentley> dobey, the prerequisite revision_id is the revision_id of the prerequisite branch that was used to generate the diff.  If there was no prerequisite branch, it cannot have a revision_id.
<jam> pickscrape: if you can use python apis, you can look into bzrlib.shelf.Unshelver.from_tree_and_shelf(), or even Unshelver.from_args()
<dobey> abentley: by that definition, if there is no prerequisite branch, it cannot have a merge proposal
<jam> sorry, that would be bzrlib.shelf_ui.Unshelver.from_args
<abentley> dobey, False.  All that is needed for a merge proposal is a source branch and a target branch.  Prerequisite branches are optional.
<dobey> abentley: then the documentation is wrong.
<jam> dobey: I think you are using "prerequisite" when you don't want it
<jam> you want the revision of the merge proposal
<abentley> dobey, which documentation?
<jam> abentley: is that exposed from the api?
<jam> it may just be the Branch, which you then open for Branch.last_revision()?
<dobey> abentley: the launchpad api docs
<abentley> jam, I don't know what you mean by "revision of the merge proposal".
<jam> abentley: the revision that is being proposed to be merged into another branch
<dobey> hrmm
<abentley> jam, we don't propose revisions, we propose branches.
<jam> abentley: well there is a specific revision that is being shown
<knittl> who wants to test: https://code.launchpad.net/~knittl/bzr/show-signature ?
<abentley> jam, yes, the source branch last_revision.  It will be updated (for active proposals) if you push the source branch.
<jam> abentley: dobey basically wants to know what revisions are being proposed to be merged, and it sounds like he needs to open the source and target branches, and then use Graph.find_unique_ancestors(source.last_revision(), [target.last_revision()])
<jam> pickscrape: that will let you open up the shelf, and as long as you don't call .run() it won't try to apply it, and I think you can then query it for the data you want to pull out manually
<abentley> jam, (well, if you just want to know which are proposed to be merged, you don't need an LCA)
<pickscrape> jam: thanks, I'm having a play with that now.
<jam> abentley: he wants all the authors that have contributed to the current code
<jam> how would you determine that ?
<abentley> jam, I'd do a set difference of the two tips.
<jam> abentley: that is what find_unique_ancestors does, only without having to get the full ancestry
<jam> and to do so, you ... have to walk back to the LCAs :)
<abentley> jam, yes, I know.
<jam> anyway, I don't think I've stated a strict need for an LCA, just to get the tips and use find_unique_ancestors()
<jam> which I think is also what you are saying
<jam> dobey: does that make sense?
<dobey> maybe
<dobey> my brain hurts :)
<dobey> i guess i just need to have both branches, and do find_unmerged()
<abentley> jam, when you said "what revisions are being merged", I thought you meant which tip revisions are being merged, not the ancestry of those tips.
<jam> dobey: http://paste.ubuntu.com/495461/
<jam> some basic overview of what I would do
<abentley> If you meant "which revisions will become part of the ancestry", not "which two revisions are participating in the merge", I get it now.
<pickscrape> jam: any idea what type the "merger" parameter passed to either write_diff() or show_changes() need to be?
<jam> abentley: correct
<jam> pickscrape: I would look at the shelf_ui.Unshelver.run() method
<abentley> dobey, the API documentation doesn't say that the prerequisite branch is non-optional.  In fact, it says there are circumstances where it should be left blank.
<jam> merger = self.manager.get_unshelver(self.shelf_id).make_merger(None)
<jam> pickscrape: what about "bzr unshelve --preview" ?
<jam> that should show the diff for you, right?
<jam> does that also fail?
<pickscrape> jam: --preview results in the same execption unfortunately
<dobey> abentley: yes. but it implies that if left blank, the target is considered the prerequisite, and i would therefore expect the prerequisite_revision_id to be from the target
<dobey> which doesn't seem to be the case
<abentley> dobey, I didn't mean to imply that the target was the prerequisite in that case.
<jam> dobey: and if you take my example slightly further, it can handle prerequisite branches by just passing more revision_ids to the find_unique_ancestors() method.
<dobey> abentley: perhaps clarify that prerequisite_revision_id will NEVER point to a revid of the target, and is only there if there is a prerequisite other than the target
<abentley> dobey, the prerequisite is a branch that should be merged into target before you merge the source branch.
<jam> (I don't think find_unmerged supports that)
<pickscrape> jam: write_diff and show_changes also result in the same exception being thrown.
<abentley> dobey, for example if you have two branches, A and B, and you branched B from A.
<jam> pickscrape: so the specific failure is that PreviewTree is not a 100% reproduction of a real tree. But I don't really know what it is trying to do that is failing
<jam> (I haven't looked closely at the bug)
<abentley> dobey, You want A's changes to be considered separately from B's changes, so you set A as a prerequisite branch when you propose B for merging.
<pickscrape> jam: I posted a small reproduction recipe on the bug a while back which could be handy for you.
<dobey> abentley: i know what the prerequisite branch feature means. i'm just stating that the api documentation i just looked at, is somewhat unclear and implied there was more of a connection between what target and prerequisite are, in the backend, than there apparently is in actuality
<abentley> dobey, this is text that was written for the web interface, so it's written with Launchpad users as a target audience rather than API client devs.
<dobey> abentley: even if not your intent, the wording tends to denote the possibility that the target can be a prerequisite, and while that field should be left blank in such a case, it does not state that all the other related fields will also be blank
<pickscrape> jam: I just realised that I've been trying to unshelve while my lightweight checkout was pointing at a different branch to the shelf's original source.
<pickscrape> So in this instance I was actually being silly. However, the last time this happened it was a bit more subtle than that.
<jam> pickscrape: well, shelved content has a required revision_id that it is based upon. It sounds like we don't give a clear error when that revision is not available
<jam> that would be a separate bug from the sound of it
<knittl> anybody wants to test printing signatures?
<knittl> https://code.edge.launchpad.net/~knittl/bzr/show-signature
<pickscrape> jam: wouldn't attempting to unshelve to a branch with that revision_id not present be roughly similar to merge --uncommitted?
<jam> knittl: I'll give it a look
<jam> pickscrape: if we can't find the revision *at all* is different than if it just isn't in the ancestry
<jam> (if your branches have separate repositories)
<jam> otherwise yes, it should be 'merge --uncommitted'
<knittl> jam: great, thanks
<pickscrape> jam: ah, well in this case the revision in question will definitely have been in the shared repository.
<jam> pickscrape: then that makes less sense, and my guess is just a bug in an edge case handling
<pickscrape> jam: should I raise that as a separate bug then, and attempt to write something remotely sensible? :)
<pickscrape> (as a description)
<jam> pickscrape: if the revision is available, then it is probably the same bug
<jam> but you're welcome  to update the description and summary if you can make it clear what is going on
<pickscrape> jam: OK, I'll leave it then
<dobey> jam: ok, with your pastebin, i think i finally got something that works, using the graph.
<dobey> jam: it seems to work! thanks! :)
<jam> dobey: happy to hep
<jam> help
<jam> (not that I don't like hepping, though :)
<dobey> heh
<nekohayo> hey there, bzr is quite slow for branching from launchpad (time bzr branch lp:arista = 20 seconds). Is there any way to make it go faster, by using bzr:// or something?
<nekohayo> when I want to "sell" launchpad to someone, I obviously get the git comparison (5 seconds to git clone http://github.com/danielgtaylor/arista.git)
<nekohayo> I would really prefer my project to use bzr
<knittl> nekohayo: do you know if there is a hg clone as well?
<nekohayo> knittl, ?
<nekohayo> a mercurial repo of arista?
<knittl> nekohayo: nothing to do with your problem, i'm simply interested
<knittl> yes
<nekohayo> not that I know of
<knittl> so bzr and git?
<nekohayo> yeah, the bzr one is a mirror of the git repo
<knittl> i see. thank you :)
<nekohayo> so, anyhow, I've never seen bzr branch faster than 20 seconds from launchpad
<knittl> don't ask me, i don't use bzr :>
<glyph> nekohayo: 'bzr lp-login'
<glyph> that might not make it go faster, but things will certainly be different!
<nekohayo> I'm alreaddy logged in
<nekohayo> (or is that command supposed to do something else than just return my login username?)
<glyph> nekohayo: oh, nevermind then.
<glyph> nekohayo: without being logged in, it's http://, if you are logged in, it's bzr+ssh
<glyph> FWIW, it takes 15 seconds for me to get the branch.
 * nekohayo is scared to imagine the performance without being logged it, must be about 30-40 secs
<glyph> maybe it's better!  who knows.
<nekohayo> from my tests here, over HTTP = 20 secs, over bzr+ssh = 9 secs
<nekohayo> so I'm wondering why LP is still slow
<nekohayo> hmm, lifeless might know something
<hallyn> i did a 'bzr branch lp:qa-regression-testing', made a chance, committed it, and now want to push it to lp:~serge-hallyn/qa-regression-testing/foo.  It's a huge tree, so i want it to just base lp:~serge-hallyn/qa-regression-testing on the main one and upload only the one diff.  Is that possible?
<knittl> afaik bzr/lb does that automatically
<knittl> * lp
<knittl> but don't take my word for it
<hallyn> knittl: doesn't appear to :)  i gave up after 30 mins of very heavy net traffic
<jam> hallyn: just pushing to a branch should auto base on the old one, as long as a development focus is set
<hallyn> how do i set a development focus?
<jam> knittl: bzr show-signature works for me. 'bzr show-signature -r 4011.1.1 | gpg --verify' works
<jam> (in your brancH)
<jam> though I'm guessing you don't actually validate the testament sha1, which may be a next step
<knittl> jam: awesome :D
<knittl> no, it's only called 'show-â¦'
<jam> knittl: you may want to call it "cat-signature"
<jam> I think we have cat-revision, etc
<knittl> i think cat is a bad name for that
<jam> which does a similar "dump the text that is stored in the repo"
<knittl> because it's for concat, not for output
<jam> knittl: while true, we don't use "show-text" or "show-revision"
<knittl> yes, i understand that
<GaryvdM> hallyn: Ihttps://help.launchpad.net/Code/QuickStart#line-61  but if lp:project works, it suggests that the dev focus is set.
<GaryvdM> hallyn: When you push a new branch, it should tell you that it stacked the branch against the dev focus.
<knittl> but only after pushing
<GaryvdM> yes
<niemeyer> Hi there!
<niemeyer> We're getting a connection timeout issue when trying to checkout a bazaar branch out of Launchpad in an EC2 cloud-init script
<niemeyer> Would anyone have any vague guesses on what could possibly be going on?
<niemeyer> We're a bit puzzled at the moment because sshing into the machine and run it, it works
<niemeyer> s/run/running
<niemeyer> apt-get is running right before the bzr switch command, so it's not an actual network error
<knittl> jam: best name would probably be print-signature
<knittl> also for all the other cat-*-commands
<jam> niemeyer: do you have the traceback?
<jam> if you are checking out an "lp:" thing
<jam> sometimes that fails because of the xmlrpc request
<jam> especially if proxies are involved
<niemeyer> jam: Yes, we're using lp:
<jam> niemeyer: some versions of bzr did not handle xmlrpc requests and http proxies (because python itself does not trivially handle it)
<niemeyer> hazmat has the error message
<hazmat> bzr: ERROR: Connection error: failed to connect to bazaar.launchpad.net:4155: Connection timed out
<jam> hazmat: that is trying to connect directly to a "bzr://" url
<jam> you need to connect to a "bzr+ssh://" url
<niemeyer> jam: We're not behing an http proxy though.. it's an EC2 instance
<jam> 4155 is the bzr port
<niemeyer> Uh
<hazmat> jam, hmm. thanks i'll double check that now
<niemeyer> hazmat: Aren't we using lp:?
<niemeyer> jam: Does lp: resolve to bzr: in some cases?
<hazmat> niemeyer, we are using lp:
<knittl> jam: why should the testament hash verified? that's not the job of a signature
<hazmat> probably since we're not authenticated to bzr (no keys) on the ec2 instance
<knittl> if it's wrong, well, you signed a faulty testament :P
<jam> niemeyer: lp: should never resolved to bzr:// because Launchpad doesn't expose bzr://
<jam> if it does, that is a bug in launchpad-code (aka thumper)
<niemeyer> What the heck then :)
<niemeyer> jam: Yeah, no "bzr:" in our code base, at least
<niemeyer> If that's a bug in Launchpad, though, should be easy to fix by using http: explicitly
<jam> I don't really know why it would be trying to connect directly.
<jam> I do know that thumper recently landed code to allow "lp:" urls to be resolved inside of ssh
<jam> so that it can handle private projects, etc
<jam> so "lp:foo" actually resolves to "bzr+ssh://bazaar.launchpad.net/+branch/foo"
<jam> rather than ~/foo-group/foo/trunk, etc
<niemeyer> Hmm
<jam> I don't know if it broke something of yours
<niemeyer> Ok.. we'll try with http:.. let's see
<hallyn> GaryvdM: it did say it was trying stacked, but i don't remember against what, and it certainly wasn't pushing only the diff.
<hallyn> alas, that has to wait, more urgent question:
<hallyn> what is the recommended bzr equivalent to 'git rebase -i'?
<hallyn> in other words, remote developer makes 5 commits while offline, meanwhile upstream advances by 10 commits,
<knittl> why not use git in the first place? :>
<hallyn> now remote developer wants to squash his patches 2-4, and rebase those 3 on top of the upstream branch?
 * hallyn facepalms
<knittl> that was no sarcasm, that was a real question :)
<knittl> but i'd be also interested in the answer to rebasing in bzr
<hallyn> "we can't", basically
<nDuff> there's a 3rd-party rebase plugin
<nDuff> but using it is not necessarily a good practice
<knittl> amending a revision is so uncomfortable right now
<niemeyer> jam: Yes, http: solved the problem
<niemeyer> jam: So it looks like some kind of resolution problem with lp: indeed
<jam> niemeyer: I don't *know* that it is resolving lp:foo => bzr://bazaar.launchpad.net/foo" but it certainly looks like something like that happened
<hazmat> jam, what's odd is that when we logged into the instance by hand and used bzr switch lp: it did the right thing.. but somehow it didn't do the right thing eraly on
<hallyn> nDuff: so what is good practice?
<jam> maybe thumper changed something and forgot to have the +ssh
<niemeyer> jam: Yeah, I have no idea either
<niemeyer> Glad it's now working, though :-)
<hazmat> indeed
<niemeyer> jam: Thanks!
<jam> hazmat: if you were logged in, maybe it was using different credentials?
<hazmat> +1
<niemeyer> It was indeed
<hallyn> nDuff: i would guess: do a local branch into different working dir, work there, and do bzr merge revision-by-revision into the other after a fresh pull?
<hazmat> jam, its all anonymous work
<niemeyer> hazmat: I don't think so
<niemeyer> hazmat: cloud-init must execute as root
<niemeyer> hazmat: and we executed with sudo
<hazmat> niemeyer, but that has no bzr/launchpad credentials
<niemeyer> hazmat: Yeah, just saying it's a different env
<niemeyer> jkakar: Hi!
<hazmat> true
<nDuff> hallyn, ...to use a workflow that avoids _needing_ rebase-like functionality?
<hazmat> niemeyer,  hmm.. actually executing by hand i was using sudo.. because of file perms
<nDuff> hallyn, ...if you're not coming from git, that's not so hard :)
<hallyn> nDuff: well really i'm trying to figure out how to tell someone else, not employed by my employer, how they should proceed with their workflow...
<hallyn> (in a bzr tree shared with us)
<hallyn> nDuff: so the most basic question:  if he has made 2 commits, and now wants to push, but there are conflicting changes in the upstream, how can he stash his changes away, pull, and then (gotta use the word) rebase his revisions?
<nDuff> why do that at all?
<hallyn> nDuff: alternative?
<nDuff> why not just merge upstream and fix the conflicts?
<hallyn> well, i think tha'ts what h'es doing now.  it removes the previous commits from upstream and replaces it with one called 'merge'
<hallyn> if i didn't want meaningful revision history, i wouldn't need this at all
<nDuff> they're still there
<hallyn> how do i see them?
 * nDuff looks at help for bzr log
<nDuff> ahh, --levels / -n
<hallyn> jinkeys
<nDuff> so -- you're actually getting _more_ history this way
<hallyn> but, if the 'merge' wasn't conflicting anyway, why bother 'hiding' this way instead of just picking an order?
<nDuff> rather than throwing away the info about the context something was originally written in (and disguising bugs introduced during the rebase/merge process), you're keeping it all
<nDuff> it's a win
<hallyn> hm
<hallyn> nDuff: it definately solves my problem, thanks a bunch
<nDuff> there's textual conflicts, and there's logical conflicts
<nDuff> only the former can be detected automatically
<nDuff> so doing an automatic flatten on merge is dangerous
<nDuff> well
<nDuff> that's not quite true -- the cases where git does an automatic fast-forward are safe
<nDuff> but they lose history about when things were actually merged
<knittl> why? history is still the same
<knittl> and dummy-merge commits only clutter history
<nDuff> not from the perspective of "what did the shared tree look like at this point in time/"
 * hallyn quietly sneaks away from the ensuing battle
<knittl> then use git pull --no-ff
<knittl> or merge --no-ff
<nDuff> knittl, yes, I'm not saying there aren't workarounds -- it's just something that I've been historically a little wary of as a default behavior.
<nDuff> knittl, ...I use git for my day job, far more than I use bzr, but that doesn't mean I like every single design choice and default Linus made.
<thumper> jam: the resolve_lp_path xmlprc call that bzrlib calls to resolve lp: branches ONLY returns http or bzr+ssh, no bare bzr to be found there
<knittl> i still think --no-ff is (most of the times) unnecessery
<thumper> no idea what was causing the problem
<knittl> * â¦ary
<nDuff> knittl, I don't think you're wrong -- but I do think throwing away information just because it's unnecessary 99% of the time is something to be wary of in the context of a tool whose principal and primary purpose is storing and tracking mission-critical content. At least, I do when I'm playing devil's advocate. :)
<jam> thumper: I would have assumed so, but something weird is going on, and I new you had touched it a bit recently
<thumper> jam: yeah :)
<knittl> nDuff: if nothing changed in my version of the DAG why should i introduce i new node? that's my point of view ^^
<jam> knittl: if you look at bzr log --short bzr.dev, that is an example of where --no-ff works very well
<jam> which is: features are developed on non-mainline commits, and committed and summarized at merge time
<knittl> i don't care
<jam> so instead of seeing 100 revisions every time you implemented a feautre
<jam> you see a single summary rev
<jam> with logical step
<jam> stepts
<jam> somewhat akin to rebasing to clean up your history
<knittl> no, it only hides the turd
<jam> anyway, we do support "bzr merge --pull" which you can alias to be the default
<jam> (bzr merge --pull = ff if you can)
<knittl> whatever, i'm not interested in ff vs. non-ff merges
<knittl> jam: why should verification of testament hash happen in cat-signature?
<knittl> cat-signature should only print the signature (so, print-signature â¦)
<jam> knittl: it certainly doesn't have to, but if you actually want to verify that the revision is correct and signed, then I would recommend closing the loop (potentially only as a flag)
<knittl> if the testament hash is wrong there's another thing wrong
<jam> certainly it is "separate but related"
<knittl> should happen on testament level
<knittl> does an inventory store the executable bit?
<knittl> i guess so, but then why isn't it printed when using bzr inventory -v?
<kirkland> what's the bzr command do bind your local checkout to the network one, so that you don't get out of sync?
<dash> 'bzr bind <url>'
 * kirkland just butchered the vocabulary, he's sure
<dash> apparently not ;)
<kirkland> dash: hmm, man and bzr help don't seem to know about "bind"
 * kirkland did at least look for it
<dash> 'bzr help bind'
<dash> also listed under 'bzr help commands'
#bzr 2010-09-18
<vila> ping losa
<vila> losa: nvm
<knittl> if i do cat-revision which format is that? serialized?
<fullermd> Well, of course it's serialized.  That doesn't really say anything; it's like saying "it's bytes"   ;p
<fullermd> Looks like an arbitrary length-specified k:v serialization to me.  But I don't know any more than you would by looking at it.
<knittl> fullermd: i'm not a python expert, so i can't say what this format is
<fullermd> Well, I'm not a python anything.  I can still read and guess, though.
<knittl> that's why i asked, to seek help, not to get flamed
<knittl> i can do guessing too
<knittl> but guessing does not help
<fullermd> 'course it does.
<fullermd> inventory-sha140:ddc195c05e78e0713a61f2b046a5a27d4f8b8b87el7
<knittl> el7?
<fullermd> Now, it could be that that's actually a unique spelling of Estruscan.  Or, the most obvious interpretation could hold, and since a SHA1 is 40 chars, somebody along the line would have to be pretty dumb for that to mean anything but "field 'inventory-sha1' is 40 chars, the content of which is 'ddc19...'"
<knittl> fullermd: i got so far
<knittl> but i'm stuck with el7
<knittl> and #bzr is really the worst place to seek help
<fullermd> Well, every value looks liek it ends with el<somenum>, and that somenum looks like the length of the following key.
<knittl> there is el eel ll ee â¦
<knittl> or d
<spiv> knittl: you're probably seeing bencode
<spiv> knittl: but cat-revision is really just a debugging tool
<spiv> knittl: the format of the output depends on the format of the repo
<knittl> spiv: bittorrent encode?
<spiv> knittl: e.g. on earlier formats you'd get XML
<spiv> knittl: right
<knittl> ok, so it's not even serialized it's really the revision as stored byte for byte?
<spiv> It's the text of the record in the 'revision' store
<knittl> ok great. thanks :)
<spiv> What a user calls a 'revision' has a bit more in it than that :)
<spiv> You can say that it's some sort of serialization of a Revision object.
<knittl> ok. bencode helps a lot already
<spiv> Out of interest, why are you looking at cat-revision?  Just poking around?
<knittl> more or less poking around
<spiv> Good :)  So I won't feel obliged to stress how much cat-revision is not an interface to be building on top of ;)
<knittl> spiv: no, i'm not using it to write scripts
<knittl> i'm really only interested in the data and the format
<spiv> At a moderately high level, the data model is that there are revisions (which have a unique ID).  Revisions have an inventory (which often, but not always, shares that ID), and inventories describe what's in the tree and refer to the exact file texts.
<spiv> The four stores, or "versionedfiles" as the code tends to call them, are 'revisions', 'inventories', 'texts' and 'signatures'.
<knittl> i think i already figured that out
<spiv> (A revision's signature will have the same ID as the revision, but obviously will be found in the signatures store, rather than the revisions store.  Also, a revision does not need to have a signature, it's optional.)
<knittl> also testament being a stripped version of a revision
<spiv> Well, the testament is a serialization of a revision suitable for signing.
<knittl> yes
<spiv> i.e. even if the repository format changes, the testament won't.
<knittl> actually there are already 3 different testament versions ;P
<spiv> Well, ok, yes :)
<spiv> The actual details of how these high-level things are stored as bytes and files on disk in .bzr/ is somewhat complex.
<spiv> \\\
<fullermd> I have vague memories that one of the testament formats was actually just made for some bundle format or other.
<knittl> so to verify a signature the text of the testament has to be parsed
<spiv> To see if it matches the data you have in your repo, right.
<knittl> i have a patch lying around
<fullermd> I don't think that happens by parsing the testament, though.  Rather, from just using the data bits the testament was generated from.
<knittl> but it's not parsing yet
<knittl> only looking if the testament text is contained in the signature
<knittl> fullermd: i'm talking about printing the signature and verifying the testament which is signed by it
<knittl> it only stores the text of the testament
<knittl> so the signed message has to be parsed
<spiv> The signed message is very simple, though.  It's basically "I am testament for revision-id blah, the SHA-1 of the long testament is blah", IIRC.
<knittl> yes
<knittl> but still needs to be parsed (textwise)
<fullermd> I would assume that the stored signature doesn't actually include the testament text, that the validation process actually goes "Generate a testament for the given rev from the information I have, then check if the signature matches it"
<lifeless> the signature is of the hash of the testament
<lifeless> you don't need to parse that
<lifeless> you just generate a new testament and hash that
 * spiv -> dinner
<knittl> signature is: begin signed message------hash sha1 "testament text"----begin signature----end signed message
<knittl> https://code.launchpad.net/~knittl/bzr/show-signature
<knittl> https://code.launchpad.net/~knittl/bzr/cat-signature (new name)
<knittl> but i don't have time for that now though
<knittl> spiv: when you are back from dinner: where can i find the code for 'text' objects?
<fullermd> You could try tracing down from the 'cat' command, since that winds up giving you the text for a particular file at a particular rev.  Would be my first thought of how to find it.
<knittl> my first thought is to search for a file called text*.py
<knittl> but i guess there are multiple files
<knittl> weave, knitpack, etc.
<spiv> knittl: versionedfiles.py, groupcompress.py
<knittl> spiv: thanks a lot :)
<spiv> knittl: you could perhaps try drilling down from bzrlib/repofmt/groupcompress.py
<spiv> Which implements the current repo format.
<spiv> But it'll be a tough dig, there are many layers of abstraction...
<knittl> like everywhere in bzr? ^^
 * fullermd carefully remains mute   :)
<spiv> At a high level the API is essentially just "these are the bytes of (file-id, rev-id)", "please give me the bytes of (file-id, rev-id)".
<knittl> i'll look into versionedfile first
<knittl> i guess there are properties which are common between different formats?
<spiv> But obviously the storage has various smarts about compression and deltas.
<spiv> Yeah, it's mostly been evolution not revolution with formats.
<spiv> Some evolutionary steps are bigger than others, of course ;)
<knittl> ok, afk now â dinner
<knittl> spiv: helps a lot already, spiv
<spiv> And, even in that high-level view, you ought to be aware that just because rev X contains a file of id F that doesn't imply that (F, X) exists in the texts store.
<spiv> Because if that file hasn't changed in that revision it won't get a new texts record.
<spiv> So to find the contents of a file in a particular revision, you need to ask the revision for its inventory, ask the inventory for the (file-id, rev-id) to use, and then ask the texts store to extract that for you.
<spiv> (or use a high-enough level API that does all that for you ;)
<spiv> At some point I'd love to make a document describing all the most important abstractions, and their gotchas and subtleties...
<spiv> The really low level bits are fairly well described in various places already, if you already understand where they fit into the big picture.
<fullermd> And writing that should take only slightly less time than it takes to obsolete it   8-}
<spiv> There's also the "but I could be spending this time fixing bugs" problem.
<astraljava> Hi there, anyone know why `bzr lp-login user' fails with http://paste.ubuntu.com/495833/, while `ssh -v user@bazaar.launchpad.net' says login succeeded.
<fullermd> That's an error from curl about verifying the SSL cert on launchpad.
<spiv> astraljava: lp-login first fetches something via HTTPS, but your system's libcurl doesn't have whatever certificate authority cert is needed to validate SSL.
<spiv> Er, SSL to launchpad.net, that is.
<astraljava> spiv: Okay, thanks. How can I get past this?
<spiv> A workaround would be to uninstall python-pycurl
<spiv> (on debian/ubuntu)
<astraljava> Right, ubuntu it is. Thanks, I'll give it a go!
<spiv> Then bzr will fallback to Python's builtin HTTPS stuff, which doesn't try that validation.
<spiv> Or, install more ca-certs ;)
 * spiv -> zzz
<astraljava> spiv: Thanks, that worked. I'll look into installing LP's cert though, that's somehow better in my view. :) G'night!
<vila> astraljava: yup, Ubuntu not carrying lp cert is a bug, which version ?
<vila> astraljava: bzr not allowing you to disable cert verification is another ;-) More or less related to bug #82086 which you can subscribe too or just mention you're affected by
<ubot5`> Launchpad bug 82086 in Bazaar "pycurl transport causes tracebacks if the server's SSL cert cannot be verified. (affected: 3, heat: 46)" [Medium,Confirmed] https://launchpad.net/bugs/82086
<vila> ping losa
<Glenjamin> i've got a branch that adds --ignore-whitespace to qdiff, could anyone point me to how i'd go about getting that into trunk?
<Glenjamin> Should i file a bug and attach a patch, or do something with merge requests?
<astraljava> vila: Gotcha, thanks!
<vila> Glenjamin: merge request is the way to go, it's best when there is an existing bug though
<vila> Glenjamin: bialix and GaryVDM are the best to answer about qbzr and bzr-explorer
<Glenjamin> bah, i've found another pending merge request that doesn't have a bug which does roughly the same thing
<Glenjamin> although that branch does a bunch of other stuff too
<Glenjamin> presumably there's bugmail for these things, and I shouldn't be poking people?
<vila> Glenjamin: I can't speak for qbzr, I don't propose a lot of mps there :-/ But surely they'll receive mails when you create a new one or add a comment there
<vila> Glenjamin: and, generally, smaller proposals are easier to review/test/land
<RainCT> Hi
<RainCT> Is there some way so that if I have lp:foo Launchpad won't allow merging lp:foo into another branch and pushing that branch to lp:foo (but instead require the other branch be merged into lp:foo)?
<RainCT> Or more useful, is there some way to uncommit the last changes to recover a revision which is now X.Y.Z?
<fullermd> If you could get append_revisions_only set on the branch, it would refuse changes that change the existing revnos.  Not sure there's a clean way to do that to a branch on LP though.
<fullermd> You could use push --overwrite to move the branch head back to whatever rev you wanted.
<RainCT> fullermd: The later question is about doing it in local when I don't have the original branch. (The problem I have is I want to fork out the code of a stable release to work on a bugfix-only release, but it's got lost in the middle of a big merge).
<fullermd> Well, you can make a new branch starting from any rev you want; it doesn't have to be the current head, or on the mainline.
<fullermd> You can `bzr branch -rX.Y.Z trunk bugfix-release-branch` and go from there.
<RainCT> fullermd: Oh, that even works. Thanks!
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | bzr 2.2.0 is officially out| bzr-2.0.6, 2.1.3 and 2.2.1 need installers, atdhvaannkcse !  | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<maxb> RainCT: If you want to enable append_revisions_only on a Launchpad branch, you can do it via the bzrlib API, or you can edit the branch.conf over sftp
<maxb> atdhvaannkcse ?!
<dash> concurrency bug
<RainCT> maxb: Thanks. What's the URI for sftp?
<maxb> RainCT: Usually I use sshfs to mount the branch via fuse (because I've yet to find a sftp client that provides a better experience)
<maxb> So, 'sshfs bazaar.launchpad.net:~foo/bar/baz /tmp/mountpoint'
<maxb> And then write 'append_revisions_only = True' in .bzr/branch/branch.conf
<vila> maxb: thanks in advance with, as dash said, some concurrency bug ;-)
<vila> maxb: wow, you really don't care about bandwith nor latency do you ? bzr+ssh should be better than sftp for lp
<vila> maxb: Ha, no, only for accessing branch.conf, sry, missed the beginning
 * vila off
<lucidfox> Can I mark multiple LP bugs fixed by the same commit?
<lifeless> yes
<lucidfox> how?
<lucidfox> Also, how do I clear pending merge tips?
<maxb> specify --fixes multiple times, iirc
<maxb> bzr revert --forget-merges
<maxb> assuming you only want to clear the merge metadata, not also revert the tree
<lifeless> mkanat: around? questions about lp comments in the mozilla buzilla in #launchpad-dev if you are
#bzr 2010-09-19
<_habnabit> Is there a way to have a directory in a bzr repo link to another repo, like svn can?
<nprasath002> where can i download a netbeans plugin for bazaar??
<nprasath002> does netbeans have a bzr plugin?
<SuperBrain> Hello
<SuperBrain> I have just installed Bazaar on Windows (7) ad I have a question.
<SuperBrain> The "Configuration" button on the "Setup and personalize Bazaar" part of the Bazaar Explorer application is not working at all.
<SuperBrain> Has anyone had the same problem and can anyone tell me what to do to "activate" this option?
<SuperBrain> To be more exact, nothing is happening when I press the mentioned button.
<GaryvdM> SuperBrain: Yes - That is a known bug with bzr 2.2
<GaryvdM> SuperBrain: well to be exact, an incompatibilty with qbzr and bzr.
<SuperBrain> Is there a solution or a workaround?
<GaryvdM> SuperBrain: Fix 1: from console run bzr whoami "Name <email>"
<GaryvdM> SuperBrain: Fix 2: Install qbzr 0.19.1
<GaryvdM> SuperBrain: http://launchpad.net/qbzr/0.19/0.19.1/+download/qbzr-setup-0.19.1.exe
<SuperBrain> Ok. Thanks a lot. I will try that.
<SuperBrain> Fix 1 solved the problem :)
<GaryvdM> SuperBrain: It's Bug 622336 if you are interested.
<ubot5`> Launchpad bug 622336 in QBzr 0.19 "qconfig: Can't open if whoami not set with bzr 2.2 (affected: 2, heat: 13)" [Critical,Fix released] https://launchpad.net/bugs/622336
<SuperBrain> I have another question which may sound a bit strange.
<SuperBrain> I would like to set up a Bazaar "server" on the Windows Server machine which will hold the central repositories.
<SuperBrain> Can someone point me to a site where it is explained how to do something like this?
<GaryvdM> SuperBrain: Bazaar is very flexable as to how one can share branches. You can just create a file share.
<GaryvdM> SuperBrain: As to how to create a smart server, I'm not exactly sure.
<GaryvdM> SuperBrain: I've never done this, so YMMV - set up openssh server and then use bzr+ssh url.
<rubbs> SuperBrain: I have used Bzr's offical docs to set up our server, but I'm using Linux, I'm not sure the best way to do it with Windows.
<SuperBrain> Is it possible to set it up using Apache for example (WEBDAV or something)?
<SuperBrain> I would like to be able to access my repositories over the internet using http or https urls, not by using shared folders.
<GaryvdM> SuperBrain: Yes - http (read only) or bzr+http (smart server) or webdav
<GaryvdM> I think webdav needs a plugin
<SuperBrain> Is smart server a separate component of Bazaar or is it integrated?
<rubbs> integrated basically
<GaryvdM> I would recommend trying to setup the smart server
<rubbs> http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/index.html
<rubbs> This link shows how to set up various bzr servers
<rubbs> most are for Linux, but somewill work with windows too IIRC
<GaryvdM> SuperBrain: http://doc.bazaar.canonical.com/latest/en/user-guide/http_smart_server.html
<JoshBrown> <JoshBrown> maxb: I think this is a qbzr issue since everything works fine using plain bzr
<JoshBrown> <maxb> that seems rather odd. Possible, but odd
<JoshBrown> <JoshBrown> maxb: Yeah, maybe it's something to do with canonicalization of links or something like that. Anyway I'm off for now, I'll check the differences between the commands I'm running and the ones qbzr is running tomorrow. Bye, and thanks for the help!
<JoshBrown> maxb: Turns out my Bash shell is expanding `~` to `/home/josh`, whereas qbzr doesn't. Is this a bug?
<GaryvdM> JoshBrown: Yes - I would call that a bug. Where in qbzr is this?
 * jelmer waves
<jelmer> GaryvdM: happy birthday :-)
<GaryvdM> Thanks jelmer.
<GaryvdM> Any TDD experts here? How should one test that a piece of code dose something that is important for the performance of the code, but does not affect the output.
<GaryvdM> e.g. qlog tries to load data from the local repos before it tries to load data from remote repos.
<GaryvdM> Should the tests check that it is doing this?
<jelmer> GaryvdM: ideally, yes
<jelmer> GaryvdM: I guess you could create a wrapper repository object that recalls when it is accessed and then use that to check which one was accessed first?
<GaryvdM> Ok  - or tells you which revisions were loaded
<lifeless> moin
<lifeless> jelmer's approach is what I'd do
<lifeless> something like:
<lifeless> LoggingRepository(output_list)
<lifeless> sorry
<lifeless> LoggingRepository(wrapped_repo, output_list)
<lifeless> if you output tuples (wrapped_repo, method, params) -> output_list
<lifeless> you'll have a sequence of both repositories calls in a timeline and can see whats what
<lifeless> alternatively, as you're working with a stable API, you could use a stub/mock instead for a lighter test, but I wouldn't actually both here
<GaryvdM> lifeless: Thank
<lifeless> s/both/bother/
<vila> lifeless: and how would you use a matcher to check the results ? (say one where you could say things like this repo before this repo or this revision from this repo)
<lifeless> so a mastch is 'repo A is requested rev X before repo B', or thereabouts.
<lifeless> I think we're going to need 'getter' adapters for matchers to make them -really-really-reusable.
<lifeless> anyhow, 'repo A requested rev X if (pos_repo_A_revX_request > -1 and pos_repo_A_revX_request < pos_repo_B_revX_request) or (pos_repo_B_revX_request == -1)
<GaryvdM> I'm having a good time writing tests for qlog. I've written all this in the last while: http://bazaar.launchpad.net/~garyvdm/qbzr/log_refactor/annotate/head:/lib/tests/test_loggraphprovider.py
<lifeless> so you could build a composite with LessThan and so on, but I'd just write a specific matcher
<GaryvdM> only 18 test so far, but for a wide variety of graph shapes :-)
<lifeless> one that takes repo A, repo B and the api call to look for
<vila> lifeless: I see
<GaryvdM> lifeless: for this, I think it would be good enough to check that rev-x was not load from remote-repo.
<vila> GaryvdM: /me drooling on the test names and their easy-to-grasp associated graph representation
<GaryvdM> :-)
<vila> GaryvdM: but you're still specifying too much IMHO :-P
<vila> Ideally the input of your assert should be the drawing you have in comment, with a revno/revid (whatever) for each line where a circle appears
<GaryvdM> vila: Ye-
<GaryvdM> vila: yes - but to parse that would be difficult.
<GaryvdM> btw - most of the numbers you see there are not revnos but column indexes
<vila> GaryvdM: you're kidding right ?
<vila> GaryvdM: and the column indexes defines where the dash and the circles are as well of their shape ?
<GaryvdM> vila: An - no - no kidding
<GaryvdM> vila: Yes
<GaryvdM> s/An/Ah/
<GaryvdM> An some of the numbers indicate the color
<GaryvdM> s/an/and/
<vila> GaryvdM: well, I see no color in your comments :-D :-P
<lifeless> GaryvdM: sure, for that then Not(Contains(<repo B asked for X>)
<GaryvdM> vila: Yes - I'm still working on that one...
<lifeless> so I'd write a single new matcher 'Repo asked for rev'
<lifeless> Not(Contains(AskedForRevision(B, X)))
<vila> GaryvdM: is print_lines purpose is to print the comment from the assertComputed input ?
<lifeless> and if you want you can wrap that up in a factory object
<GaryvdM> vila: Yes
<GaryvdM> vila: Oh - no - format_graph_lines is what assertComputed uses
<GaryvdM> print_lines is just a debuging helper. It can come out...
<vila> GaryvdM: oh, right, the unicode parameter
<vila> lifeless: great example, thanks
<knittl> hm. did i read this right? bzr stores versions per line which are groupd together into a file?
<GaryvdM> vila: I still need to code it to figure out if it is safe to output unicode.
<GaryvdM> knittl: Not sure I understand your question correctly. Does it relate to the recent channel topic?
<vila> GaryvdM: yeah, right, that function is far too long to survive without associated tests ;)
<knittl> GaryvdM: no, to my research ^^
<knittl> i wasn't reading along, sorry if i interrupt
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | bzr 2.2.0 is officially out| bzr-2.0.6, 2.1.3 and 2.2.1 need installers, aTdHvAaNnKcSe !  | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<lifeless> knittl: some context would be needed to answer that, I think.
<GaryvdM> knittl: np
<lifeless> knittl: if you are referring to the weave serialisation format, thats obsolete, kept for compat
<knittl> lifeless: i'm reading groupcompress (spiv told me yesterday)
<lifeless> groupcompress isn't lined based
<knittl> it reads like, because of all the add_lines methods
<lifeless> the python implementation uses lines rather than bytes for performance reasons, but the C implementation (pyx) matches on bytes
<knittl> pyx is c?
<lifeless> knittl: thats the VersionedFile contract, you probably want to read it first
<lifeless> knittl: pyx is pyrex, which compiles to C and then to a .so
<knittl> lifeless: i've read versionedfile, but i wasn't getting any smarter ^^
<vila> GaryvdM: can you add a comment in your source describing which is which in that input list ?
<vila> GaryvdM: or is there one I missed ?
<GaryvdM> vila: Ok - I'll do that.
<knittl> any thoughts on http://bazaar.launchpad.net/~knittl/bzr/cat-signature/revision/5434?
<GaryvdM> vila: The computed_to_list will give you a hint
<vila> knittl: given the current discussion, the most obvious one is: where are the tests ?
<knittl> vila: i thought a day about tests (still haven't read the current discussion), but a test would just do the same thing?
<knittl> i.e. get the signature
<vila> knittl: no, it will call the code that will get the signature and verify that the correct signature is indeed obtained
<knittl> so the test stores the signature as plaintext and then compares it?
<vila> knittl: and will catch any regression if this code or the code it used is modified
<vila> knittl: yes, that's the point
<knittl> ok, i can do that
<vila> knittl: other tests will verify the behaviour with different arguments (aka branch, format, etc)
<knittl> how do i create a branch from the secondlast commit in bzr?
<vila> knittl: alos, if you make a merge proposal it will make it easier to view the overall patch you're proposing
<vila> bzr branch -r-2 ../new_branch
<knittl> but that will copy the whole directory :-/
<vila> bzr branch -r-2 ../new_branch --no-tree
<knittl> i simply want to ignore the last commit and work starting at the second last
 * GaryvdM discovers ghosts in the very early history of bzr.dev, e.g parent 897 -  john@arbash-meinel.com-20050709180338-33e3b5a778df9104
<vila> ha, that would be: bzr uncommit ; bzr revert
<vila> GaryvdM: hehe, preciously kept as real-life test data ;-)
<GaryvdM> ha ha - And the next ghost is a fix for ghosts in log
<knittl> not a branch: ~/bzr/new-branch
<knittl> bzr uncommit; bzr revert? will that work when i've already made new commits?
<GaryvdM> should be bzr branch . -r-2 ../new_branc
<knittl> wtf? why is it copying 33k files?
<vila> knittl: you said you did only one additional commit (and good catch GaryvdM ;)
<lifeless> knittl: why do you think its copying that many files?
<knittl> lifeless: because it says inserting stream xxx/336923
<knittl> 336k even â¦
<lifeless> thats stored texts
<lifeless> not files
<lifeless> objects in the system
<knittl> why is it copying? i simply wanted to create a new branch
<knittl> it's taking forever
<GaryvdM> knittl: you should use a shared repo.
<GaryvdM> :-( ui fail
<knittl> i have a bzr clone
<knittl> created a new dir? without files?
<knittl> but still 51m?
<knittl> mumble mumble â¦ oO
<knittl> i'll never understand bzr
<vila> knittl: it looks like you didn't create a shared repo. Since it's the default model in git and needs an explicit command for bzr, many people do this mistake which is why GaryvdM said UI fail.
<GaryvdM> knittl: I think you ran branch with --no-tree. Not sure why vila mentioned that.
<GaryvdM> knittl: To undo --no-tree, run bzr checkout
<GaryvdM> (in branch)
<knittl> why do i need to tell bzr all that?
<lifeless> knittl: 51 minutes ?!
<knittl> also that will use twice the space on hd?
<lifeless> knittl: eeven a full clone of bzr is only a minute or so
<vila> lifeless: MO I suspect
<knittl> lifeless: megabytes
<vila> knittl: that's the whole history of the project
<knittl> i didn't want to clone, i wanted a branch
<vila> there are several kind of branches in bzr, you didn't specify which
<knittl> a normal branchy branch
<GaryvdM> knittl: We call a git branch a colocated branch, which we don't do out of the box
<vila> the default one, when you first use bzr is a standalone branch which stores its revisions in its own repo
<knittl> why isn't that default?
<GaryvdM> knittl: what we call a branch is like a git clone
<knittl> WHY?
<vila> different point of views leads to different results, you've got all the bzr history available
<vila> WHY NOT ?
<knittl> because it takes up too much space for my liking
<vila> why's questions are not wise...
<vila> don't do that then
<GaryvdM> knittl: A shared repo allows the history data to be shared between the 2 branches.
<vila> use a shared repo
<lifeless> hey hey calm
<lifeless> its like it is because thats how bzr grew
<GaryvdM> or x branches
<lifeless> and changing it - may - happen, but it needs to be done with care
<lifeless> including having the colocated stuff /really/ polished first.
<lifeless> If you're going to break 6 years of doco you want to be prepared
<knittl> i don't see any advantage in creating clones and clones and clones
<knittl> also shared repo looks really complicated
<knittl> creating directories and copying stuff and â¦
<knittl> on an unrelated note
<knittl> how can i test my code if the only way to get a signature is my code?
<knittl> where should i put the test?
<GaryvdM> knittl: Is it a gpg sig? can you not create it with gpg -a?
<knittl> GaryvdM: so echo "Hash: SHA1" > file && bzr testament >> file #?
<GaryvdM> knittl: But creating it from the code you are testing is not so bad. I dose not verify that it is currently correct, but guards against future regressions
<knittl> is a revision able to have multiple signatures?
<knittl> and if so, what would be the output of repository.get_signature_text(rev_id)?
<knittl> and how can i add new tests? it says: 0 tests OK. but it should run a single test
<GaryvdM> knittl: I think you need to add you test module to bzrlib/test/__init__.py - line 3830
<knittl> where inside that 5k line file?
<GaryvdM> line 3830...
<knittl> found it
<knittl> yeah ^^
<knittl> is there an existing test which accesses bzr.bzr?
<GaryvdM> knittl: Not sure about multiple sigs. I guess a person may have multiple keys that they want to sign with, but that would be unlikely. And the fact that the api name in not plural suggest that it is not possible.
<GaryvdM> knittl: do you maybe mean bzr.dev?
<knittl> multiple people could sign the same revision
<knittl> i mean the bzr repo
<knittl> because that's where the signature is stored
<GaryvdM> knittl: But you would only be interested in the signature of the person that committed the rev.
<knittl> why? can only the committer sign a revision?
<knittl> but i'm tired, i'm going to bed
<knittl> gn8
<GaryvdM> knittl: For me the value in a signature is that I can verify that the revision was really committed by the committer, and that it is what they committed...
<knittl> well, considering bzr signatures do not sign history that is an argument
<knittl> a dev could decide to sign an older revision though, to claim he has verified its contents
<knittl> anyway, going to bed
<GaryvdM> ok - good night.
<_habnabit> So I'm unclear on how you're supposed to configure change_editor.
<_habnabit> When you shelve something, it passes you the old file and the new file, you edit the new file, and then it shelves the changes between the new file and what it was?
#bzr 2011-09-12
<AuroraBorealis> so , i have the small changes that i made to make bazaar explorer not freak out when signing commits
<AuroraBorealis> how do i go about making a patch file to submit with the bug report?
<spiv> AuroraBorealis: commit the change, and push the branch with the change to launchpad.  If you commit with --bug=lp:1234 it'll get automatically linked to the right bug.  (If you don't, you can use the "link branch" link on the bug page to do the same thing.)
<AuroraBorealis> ah ok, will try that in a second!
<spiv> AuroraBorealis: you probably also want to add a merge proposal for the branch you push to launchpad, but just doing the above will at least make branch appear on that bug page
<AuroraBorealis> do i have to do anything on launchpad to push to it?
<AuroraBorealis> i have not done that before
<AuroraBorealis> (for a project that isn't mine)
<AuroraBorealis> or do i click "register a branch"
<spiv> AuroraBorealis: "bzr push lp:<your_lp_id>/<project_name>/<branch_name>"
<spiv> AuroraBorealis: you'll need to add an SSH public key to your LP account (if you haven't already) and run "bzr launchpad-login" (if you haven't already)
<AuroraBorealis> yeah i have that
<spiv> Er, I typoed slightly, it's lp:~<your_lp_name>
<spiv> e.g. lp:~spiv/bzr/foo
<AuroraBorealis> how do i link it to a bug in the command line?
<AuroraBorealis> ironically i can't use bazaar explorer because of the bug i'm trying to fix xD
<AuroraBorealis> oh --bug
<maxb> Does that work? The documented option is --fixes
<AuroraBorealis> yeah its --fixes
<AuroraBorealis> which i found after googling
<AuroraBorealis> ok, so i pushed it, its here: https://code.launchpad.net/~markgrandi/bzr/gpg_devttynotfound_fix
<AuroraBorealis> will it do something to the bug report after its done 'scanning' the branch?
<spiv> Yep.
<spiv> AuroraBorealis: look now
<AuroraBorealis> hooray!
<AuroraBorealis> now what
<AuroraBorealis> do i just wait for someone to do something with it?
<poolie> hi all
<AuroraBorealis> hi.
<Noldorin_> hi jelmer
<AfC> I'm using bzr builddeb. I'm backporting something. I did a build. Took 4 hours, no problem. At the very end, I discover that all though I fixed Build-Depends, I missed correcting the same entry in Depends.
<poolie> ouch
<AfC> Is there a way to get the .deb rebuilt based on new debian/control
<poolie> was the 4h in buildding the source deb or building the binary?
<AfC> without doing another 4 hour build? ie, it's just the very outside wrapper that is changing
<AfC> poolie: binary
<poolie> oh, without actually recompiling it?
<poolie> probably
<AfC> I mean, sure I could do surgery with tar :) but I'm trying to find a more proper way to do it.
<poolie> dpkg-buildpackage with '-nc' "don't clean" somewhere should do it
<AfC> The dependency was making "libgmp-dev" (oneiric, unstable) be "libgmp3-dev" (natty)
<AfC> poolie: ok. I've got a feeling that with builddeb's defaults, the build-dir/ is already gone
<AfC> [I know it is]
<poolie> hm, maybe the things you wanted to preserve are already deleted then?
<poolie> i guess you could force installation without the dependency to test the package, then do a full clean rebuild when you're happy
<AfC> yeah
<AfC> Be faster to make an empty package called "libgmp-dev" :/
<AfC> poolie: (and, yes, --force-depends has it on board now for testing)
<poolie> i think there is some way to configure that into dpkg short of making an empty package
<AfC> I'm guessing that `bzr buildpkg --dont-purge` more or less leads to `-nc`
<poolie> well, it would make it at least possible to use -nc later
<vila> hello guys !
<poolie> hello vila
<jam> morning all
<vila> poolie, jam : _o/
<poolie> hi guys
<poolie> did you do testing of the new pqm that showed a tmpfs didn't help?
<vila> poolie: replied to your mail,
<vila> but in a nutshell, I'm very surprised it doesn't give better results but I don't know which test to propose to ensure it's really active in the chroot
<jam> I'm also surprised about tmpfs, poolie. Didn't you try it locally and found it was quite useful?
<poolie> yes
<jam> poolie: though I'll also say, timing results are showing the new machine running the test suite in <30 min. Which is a pretty good starting point. As long as it is <1hr, I don't see it impacting our workflow much.
<poolie> yeah, that is nice
<poolie> i was just surprised
<vila> poolie: any idea about further tests ?
<poolie> i don't see your mail yet
<lifeless> vila: you did use the tmpfs *in the chroot* right ?
<lifeless> vila: as opposed to *outside the chroot*
<lifeless> vila: to test, schroot ...; mount :)
<vila> lifeless: I don't have access to run such commands ... but I indeed ask to check inside the chroot
<lifeless> ok. weird.
<vila> dunno what kind of check was done though...
<vila> 1f
<vila> pff
<vila> grr, I hate it when postfix stop working and I don't notice until someone tells me: 'where is your mail ?'
<poolie> guys, i might stop soon
<poolie> vila, lifeless, i reckon perhaps it was broken by the schroot fstab causing the external /tmp to be bound over the internal tmpfs
<vila> poolie: I had the same kind of feeling but... I trusted our admin
<vila> attn packagers and installer builders: 2.4.1 has been frozen ;)
<poolie> good for you
* 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: jelmer
<jelmer> vila: hmm, is it not possible to change a remote branches' configuration?
<jelmer> maxb: hi
<jelmer> maxb: bzr-builder fails to build on lucid and maverick with an error from the python helper
<jelmer> do you perhaps know what's going on there?
<jelmer> hey Riddell
<maxb> Do you have a buildlog handy?
<Riddell> good morning
<jelmer> maxb: FATAL: python-backport-helper needs updating to know which of python-support or python-central 'bzr-builder' should be build with
<jelmer> https://launchpadlibrarian.net/79653003/buildlog_ubuntu-lucid-i386.bzr-builder_0.7.1%2Bbzr144~daily10~lucid1_FAILEDTOBUILD.txt.gz
<maxb> oh, right
<maxb> Well, the error's pretty clear :-)
<jelmer> bzr-builder wasn't in the daily ppa until recently, perhaps it's not in the hardcoded list?
<maxb> I was being a bit paranoid at the time, perhaps it should just default to python-support
<jelmer> maxb: it has to be central for all bzr-related packages
<jelmer> maxb: since they install under bzrlib.plugins
<jelmer> although defaulting to python-support seems reasonable, given that's also the default e.g. debhelper uses
<daubers> Hello, I've come in this morning to bzr complaining that it hasn't got enough values to unpack  with all my branches. Pastebin of the error: http://pastebin.ubuntu.com/687544/ how can I fix this?
<jelmer> daubers: what are the contents of your .bzr/branch/last-revision file?
<daubers> jelmer: It's empty
<jelmer> daubers: did you perhaps have a recent machine crash after changing that branch?
<daubers> jelmer: Not as far as I'm aware
<vila> jelmer: it should be possible to change a remote config, if it's not, it's a bug
<vila> jelmer: unless you don't have write access of course
<jelmer> vila: I'm finding that calling set_append_revisions_only(True) doesn't work
<vila> jelmer: oh, I thought you were referring to either the new design or 'bzr config'
<vila> jelmer: that's even more surprising given that the package importer did that for a bunch of lp branches
<daubers> Hmmm.... whatever caused it has caused it on every branch on this box
<jelmer> daubers: bug 623152 seems to be what you're hitting
<ubot5> Launchpad bug 623152 in bzr (Ubuntu) "ValueError: need more than 1 value to unpack in _last_revision_info" [Medium,Triaged] https://launchpad.net/bugs/623152
<daubers> jelmer: Yeah, looks it. I'll restore them from the backup, probably easiest I think
<jelmer> daubers: It's surprising if you're hitting this without an unclean unmount though
<daubers> jelmer: This is on the remote server, all pushed through sftp
<daubers> Checked the RAID it's on, and that's fine
<jelmer> I was going to mention that newer versions of bzr can fsync after updating last-revision, but that doesn't really help if you're using sftp.
<jam> vila: ugh. package importer is *really* unhappy
<jelmer> vila: ah, this is where it gets interesting
<jam> 1092 failures, all the recent ones are: with key lazr.restfulclient.errors.HTTPError:<module>:main:get_versions:get_debian_versions:__getitem__:get:_request
<jelmer> (Pdb) print branch.get_config().get_user_option('append_revisions_only')
<jelmer> True
<jelmer> (Pdb) print branch.get_append_revisions_only()
<jelmer> False
<vila> jam: lp outage
<vila> jam: requeued
<vila> jelmer: urgh
<vila> jelmer: what kind of branch ?
<jelmer> vila: remote. it looks like we have a default get_append_revisions_only() implementation that returns False
<jam> vila: should those be marked as transient-should-always-be-retried?
<jam> (you may have already done so)
<vila> jam: in theory, yes, in practice there are potentially may root causes
<vila> jam: there is a bug about the importer making tea while lp is down
<jam> vila: well, lazr.restfulclient.errors.HTTPError sure looks transient to me.
<vila> jam: in this case yes, but it's not a hard rule
<vila> jam: not all lp errors are transient
<jam> vila: sure, though again, I was saying this specific traceback could be marked as auto-retry.
<jam> And the other discussion, all failures should be considered soft-transient, so try X times, and then mark it hard-failure.
<jam> but that is something else
<jam> vila: is there a bug # for the .xz thing?
<jam> I just saw some of the failing imports with it
<vila> jam: right, but the bug explains that you can't *start* auto-retrying until lp is up again or you end up re-trying too much too soon and it becomes a permanent failure
<jam> and it would be good to either link it to the bug, or requeue it if it has been fixed
<jam> vila: sure. Though if you round-robin 500 packages that gives you some time :)
<jam> Especially since LP isn't supposed to go down for more than 5min now.
<jam> then again, maybe it makes this more important
<jam> since they'll be going down 2-3 times / week no
<jam> now
<vila> jam: feel free to play around with it, I'm just explaining the status quo
<jam> vila, jelmer: anyway, .tar.xz thing?
<vila> jam: yes; there is an udd bug for the .xz issue, linked to the upstream bug IIRC
<jelmer> bzr-builddeb should be able to handle xz now, I haven't seen the bug for the udd issue
<jam> vila: sure, I mean linked to: http://package-import.ubuntu.com/status/bedtools.html#2011-09-11%2009:29:19.287652
<jam> the actual package-importer tracebacks, etc.
<vila> ha, that, no, not done, patches welcome
<jam> jelmer: bedtools and qtwebkit-source are at least failing with "unknown extension ...tar.xz"
<jam> jelmer: did you work out the bz2 issues for the kde packages?
<jelmer> jam: we need to update to a newer bzr-builddeb on jubany, that should fix it
<jelmer> (the .tar.xz issue)
<jelmer> jam: Riddell did, it turns out OpenSUSE's bz2 generates slightly different output because of a patch they ship
<jam> ouch
<jelmer> jam: he's filed a bug against pristine-tar: debian bug 641019
<ubot5> Debian bug 641019 in pristine-tar "pristine-tar does not work with tar files made by openSUSE" [Normal,Open] http://bugs.debian.org/641019
<vila> jelmer: oh, right, I was about to pull the newer builddeb on jubany and was interrupted by the week-end, thanks for the reminder, I'll do that now
<vila> jelmer: oh, also, you mentioned detecting dpkgmergechanlog to avoid installing a broken hook ?
<jam> vila: what's the current procedure for updating the failed-imports => bug #. Is it still just ssh to jubany and manually update the file?
<jelmer> vila: yeah, it would be nice to look into that, but I haven't actually landed any branches which help address that.
<vila> jam: the explanations file is part of the branch
<vila> jelmer: ok, np, just checking
<vila> builddeb upgraded on jubany, brace yourselves :)
<vila> requieing bedtools (last to fail with .xz)
<vila> ha crap, forgot --priority
<vila> I'll let it purge its queue first
<jam> 447 to go. Not bad, though maybe 1/minute or so?
<jam> jelmer: on RemoteBranch.get_append_only... I *think* it was meant that you could try to push things, because the real branch on the remote side would refuse it
<jam> rather than doing a round-trip just to check the bit.
<vila> jam: try analyze_log with a tail -F from jubany :-p
<jelmer> jam: ah, that makes sense
<jelmer> jam: so in that case this is a bug I introduced because I made _get_append_revisions_only public.
<jam> jelmer: could be. I won't claim 100% accuracy on my understanding.
<jam> vila: I try not to ssh into jubany unless I must :)
<jelmer> jam: wrt 2.5-better-gpm-estimate, didn't that branch already land on 2.4?
 * jelmer vaguely recalls reviewing something similar earlier
<jelmer> hmm, maybe I just looked at it earlier and then didn't have time to actually review..
<jam> jelmer: the estimation changes haven't landed anywhere IIRC
<jam> there were 2 or 3 other tweaks to get_parent_map that I've proposed that have landed
<jam> let me double check that
<jam> vila: "tail .../progress_log" | scripts/analyze_log.py -
<jam> Just gives me "- does not exist"
<jam> I'm guessing it is an out-of-date udd branch?
<jam> Is it supposed to be somewhere else?
<jam> (just running it normally shows average speed of 41s, which is close to my guessed time.)
<jam> so it will take ~5-7 hrs to finish the backlog.
<vila> jam: refresh your memory: https://code.launchpad.net/~vila/udd/analyze_log/+merge/74056
<jam> vila: says merged here, doesn't work on jubany
<vila> you don't need it on jubany, you pipe from jubany and execute locally
<jam>  /msg vila seems a bit convoluted
 * vila checks with a mirror, a bit tired, yeah, may be, but convoluted...
<jam> jelmer: any idea why installing python-lzma on natty requires installing python-2.6 ?
<jam> does lzma *only* work on 2.6?
<jam> or would it be a packaging bug?
<jelmer> jam: my guess is that it's just a packaging bug
<jam>  ./import_package.py seems to spend an awful lot of time waiting for stuff. It is at 400+s running, and only 20s CPU time.
<vila> which one ?
<jam> anon-proxy
<jam> I'm at least poking at the unicode decode errors
<jam> but so far, I haven't found a version that has anything but ascii
<vila> the one I looked at has a NFKD file
<vila> http://package-import.ubuntu.com/status/acidbase.html#2011-09-01%2007:39:12.274606
<vila> jam: bah, I mixed bzip2 and .xz issues, no bug for .xz AFAIR, I just mentioned it to jelmer who proposed a fixed that I reviewed
<vila> the bzip2 issue has a bug linked to prisitine-tar upstream
<jelmer> vila: debian bug 499489
<ubot5> Debian bug 499489 in pristine-tar "please add LZMA/XZ/Lzip support" [Wishlist,Open] http://bugs.debian.org/499489
<vila> jelmer: thanks
<vila> jelmer: this makes me feel a bit more how prisitine-tar can blow up for the package-importer... as soon as someone starts using a new compressor or a new option... boom
<vila> jelmer: I wonder if we can be more robust by getting the *tar* and compressing the tar delta instead of trying to get a delta from the compressed form
<jam> vila: fundamentally the .dsc files contain the sha1 hash of the tar.bz2
<jelmer> vila: that won't help - pristine-tar has trouble reproducing the compression
<jam> which is what we are trying to reproduce
<vila> jelmer: anyway, with your xz patch, all previsous failing imports have now passed
<jelmer> vila: it has no problems with the tar file that is compressed
<vila> jelmer: aiui, it needs to recognize the compressed form
<vila> oh, argh, doomed
<jelmer> vila: it needs to reproduce the compressed file 100% from the pristine tar delta, which means tracking all the compression parameters
<vila> yeah, yeah, hence: doomed
<jelmer> apparently that is fairly tricky for .xz
<vila> adding these parameters do the .dsc is not option ? :-}
<vila> half-kidding
<jelmer> vila: they are not known by the debian developer either..
<vila> jelmer: really ? the upstream devs already provide the compressed tarballs ?
<jelmer> vila: in a lot of cases, yes
<vila> jelmer: how about mentioning the *tarballs* sha sums instead ?
<jelmer> in some situations the tarball gets repacked, e.g. if it's zipped or if there are non-DFSG-compatible files in it
<jelmer> vila: if we do that, we still can't reproduce the tarball
<jelmer> vila: and we need to reproduce it bit for bit
<vila> jelmer: I mean: work with the uncompressed  tarballs and generate the deltas for the tarballs, compress the tarballs and the deltas
<vila> jelmer: this way we still can reproduce the tarballs bit for bit no ?
<jelmer> vila: we have to reproduce the final files, not the tarballs
<vila> and we only have to track the tar format and not the compressors formats (which doesn't mention the parameters anyway, at least for bzip2)
<jelmer> vila: we have to reproduce the *compression* as well
<vila> jelmer: why ?
<vila> to build the package you extract the tarball anyway, isn't it what matters ?
<vila> I understand the practices and toolchains requires the compressed form today, I'm just trying to find an escape from the 'sorry, no idea what parameters were used here, will never be able to reproduce the compressed form' trap
<vila> which is currently blocking the bzip2 produced on Suse with a non-standard bzip2
<vila> and even there the fix may be doable
<Noldorin_> hi jelmer
<jelmer> hi Noldorin_
<Noldorin_> jelmer, been testing this bzr-git issue over the past few days, but can't seem to get anywhere with it i'm afraid...
<jelmer> Noldorin_: what have you been testing exactly?
<jelmer> that issue you ran into earlier?
<Noldorin_> jelmer, yes with the unknown git databaser entry... you remember?
<Noldorin_> i'm trying to merge in parts of the revision that make it fial
<Noldorin_> but it gives loads of conflicts
<Noldorin_> not sure how to go about it :-S
<Noldorin_> have tried a few thigns over the past few days...
<jelmer> Noldorin_: merging it won't help in this regard, the revision itself would still be processed in its current form
<Noldorin_> how should i go about testing this problematic r47 then?
<jelmer> Noldorin_: try creating a new revision on top of r46 which has some of the changes from r47 and see what the minimal set of changes is that triggers the issue
<Noldorin_> jelmer, but how do i do that specifically?
<Noldorin_> exactly what i'm trying
<Noldorin_> it just messes up the whole branch hmm
<jelmer> Noldorin_: bzr branch -r46 /path/to/original/branch test; then create a new commit with some of the changes from r47, commit, then dpush into git
<Noldorin_> jelmer, yep yep, but how exactly do i get "some of the changes"?
<Noldorin_> doing by hand is not practical
<Noldorin_> there are many many changes
<jelmer> Noldorin_: you might be able to do "bzr merge ../path/to/individual/file -r47"
<jelmer> Noldorin_: and do that for every file
<jelmer> but you'd have to make sure it doesn't record any pending merges ("bzr st" should display this)
<Noldorin_> jelmer, wouldn't always record pending merge?
<Noldorin_> i don't know what the alternative is..
<jelmer> Noldorin_: you can also revert pending merges with "bzr revert --forget-merges"
<Noldorin_> ah ok
<Riddell> jelmer: did you say you were going to upload bzr-explorer 1.2.1 to debian?  it doesn't seem to have arrived
<jelmer> Riddell: I did say that, and then I got distracted by something else last week. Sorry about that.
<jelmer> Riddell: I'll have a look at uploading qbzr and bzr-explorer now.
<timrc> Using bzrlib, Let's say I create a local branch of a remote tree and make/commit a change in my local working tree.  Do I use "clone_on_transport" to push that change back to the remote tree?
<jelmer> timrc: hi
<jelmer> timrc: do you perhaps mean remote branch rather than remote tree?
<jelmer> timrc: If so, you should be able to use wt.branch.push(Branch.open(remote_url))
<timrc> http://paste.ubuntu.com/687688/
<timrc> that is pretty much what I have, so far
<timrc> remote branch, yeah
<jelmer> timrc: it looks like you indeed want to push to a remote branch (we don't support operations against remote working trees)
<timrc> jelmer, okay
<jelmer> timrc: it seems like you indeed want local_branch.push(remote_branch)
<jelmer> timrc: clone_on_transport creates a clone of the local branch, so would error out saying that a branch already exists (I think)
<timrc> it has an option, 'use_existing_dir' which threw me off
<timrc> I was using create_clone_on_transport to create a new remote branch and then using the launchpad mergeProposal API call, but I want to eliminate the mergeProposal step
<abentley> jam: around?
<vila> Riddell: babune's all red: http://babune.ladeuil.net:24842/job/selftest-chroot-oneiric/lastFailedBuild/testReport/junit/bzrlib.tests.test_transport/TestTransport/test_transport_fallback/
<vila> Riddell: how did you manage to pass on pqm ?
<vila> Riddell: Ouch, I see, ignore_i18n is called only once and doesn't cleanup at the end of the tests, protecting the others
<vila> Riddell: when running with --parallel=fork (as babune does) this works only for test_trans_dependency and break for the other tests
<vila> test_transport_dependency
<timrc> jelmer, that did the trick, thanks
<Riddell> vila: uh oh
<Riddell> vila: so test_transport_fallback  is the only one that's failing
<Riddell> or are there others?
<vila> Riddell: I replied to your email about this problematic test but it got delayed locally :-/ Dunno if you got it ?
<Riddell> I got a reply late on Friday
<vila> Riddell: a single one is failing on babune, but given the way we split with --parallel, there is no guarantee that it's the only one
<vila> Riddell: i.e. every test that potentially try to mutter() or whatever (exceptions ? str(e)) risk triggering the same issue
<Riddell> why does --parallel affect it?
<vila> Riddell: with --parallel, several *process* are involved
<vila> Riddell: each one running a slice of the whole test suite
<vila> Riddell: the slicing is always the same for a given test suite but can vary as soon as you add or remove a test or change the parametrization or the list goes on
<vila> Riddell: monkey-patching like you did is against all isolation rules :)
<vila> Riddell: at the very least you should use overrideAttr
<Riddell> fg
<Riddell> tsk
<vila> Riddell: so the patching is cleaned up at the end of the test
<Riddell> ok, I'll try that
<vila> Riddell: moreover, as mentioned in my mail, if the test needs disk resources (and it does as soon as it requires a config file which itself is required by i18n) it should use TestCaseInTempDir or TestCaseWithTransport
<vila> Riddell: OR
<Riddell> well I'm trying to get it to not use i18n so that's not an issue now surely
<vila> Riddell: the failing test has no idea you monkey patched i18n.install, it's running in a different process !
<vila> Riddell: an alternative is to force the install of a Null translation for *all* tests (overriden for tests that want to test specific aspects)
<Riddell> yes that might be an idea
<vila> Riddell: I thought there was some code doing that when you started working on i18n but it probably wasn't commented well enough to explain the current issue
<Riddell> where would that be?
<vila> i18n, let me refresh my memory (may be that was in a mp that never landed)
<vila> Riddell: _translations back in revno 5994
<vila> Riddell: may be incomplete
<vila> Riddell: the idea is that it's None until one is installed in the nominal case (i.e. for users)
<vila> Riddell: but tests can install whatever they need: either a null one or a test specific one
<vila> Riddell: now, poolie may ask you to put that in library_state instead, but I still don't fully understand the library_state story
<vila> Riddell: the implementation in bzrlib/i18n.py revno 5994 may be broken, you certainly know better, but the bit that should be applied here is that you don't want a test to trigger an access to a file on disk at any cost
<vila> Riddell: revno 5875.3.25 pretty much contains what I'm trying to explain (except for making sure all tests start with a null translation which should be an overrideAttr call in TestCase.setUp() roughly))
<Riddell> vila: how about this? https://code.launchpad.net/~jr/bzr/i18n-fix-tests/+merge/75037
<vila> Riddell: approved, babune will tell you if it's still unhappy ;)
<Riddell> merci
<jam> abentley: I'm around now if you're still interested in chatting
<abentley> jam: cool. Mumble?
<jam> sure, just a sec
<lamalex> guys i really like bzr-colo. thank you!
<lamalex> it would be really amazing if bzr-colo had some sort of secondary/temporary versioning system that would get rid of unknown files when you did a bzr switch
<lamalex> i think i could implement that.
<fullermd> Oh right, I forgot I can't bzr check this repo because of symlinks.  Bah.
<nigelb> fullermd: git stash like? :)
<nigelb> gah
<nigelb> lamalex: ^
<lamalex> nigelb, yes sort of but implicitily when you changed branches
<Noldorin_> hey jelmer -- are you aware that bzr-git borks on dpush when there are uncommitted changes?
<jelmer> Noldorin_: complains or actually tracebacks?
<Noldorin_> jelmer, just complains i think. i can pastebin if you like?
<jelmer> Noldorin_: please do; it might be expected behaviour though
<Noldorin_> okay
<Noldorin_> jelmer, http://pastebin.com/zs6bL0Yg
<jelmer> Noldorin_: I think this is just brokenness from the bug you were working on earlier
<Noldorin_> ah ok
<Noldorin_> i think so too
<Noldorin_> it disappears after bzr revert
<Noldorin_> of course
<Noldorin_> jelmer, ah wait, i'm just encountering this error again with "workign tree is out of date"
<Noldorin_> :-S
<Noldorin_> weird
<Noldorin_> i just did a bzr revert and then bzr st
<Noldorin_> after that
<jelmer> Noldorin_: that restores from the repository though, and that might have inconsistent data because of the failed dpush
<Noldorin_> jelmer, ohh...why shoudl the dpush corrupt the repository data though?
<jelmer> Noldorin_: because of the bug you hit
<Noldorin_> oh ok
<jelmer> which is about misrepresenting bzr data in git
<Noldorin_> jelmer, so these myriad problems are all to do with the bug eh?!
<jelmer> basically
<Noldorin_> jelmer, i guess i have to reclone the branch and do uncommit/revert for each new test?
<jelmer> Noldorin_: yep (and not in a shared repository)
<Noldorin_> ah ok
<Noldorin_> jelmer, what is a shared repository?
<jelmer> Noldorin_: in two words, "bzr init-repo"
<Noldorin_> okay got it
<Noldorin_> i don't use that, so no problem
<Noldorin_> jelmer, hmm how can i get a list of changes introduced in r47?
<jelmer> Noldorin_: bzr log -v -r47
<Noldorin_> thanks
<Noldorin_> -v was what i needed ;-)
<jelmer> from what I could tell earlier the problem is related to one of the tree shape operations
<jelmer> rather than the contents changing
<Noldorin_> yes
<Noldorin_> well as i mention in the commit message, i restructure the the directory hierarchy in this changeset
<Noldorin_> hmm
<Noldorin_> jelmer, hence i guess it's the moves/remaming of files/dirs that's messing it up?
<jelmer> Noldorin_: presumably
<Noldorin_> okay
<Noldorin_> *continues checking*
<jelmer> Noldorin_: really useful would be some sort of recipe that reproduces this issue in a clean branch
<jelmer> s/clean/empty/
<jelmer> that way we can add a regression test, then improve the code until it works
<Noldorin_> yep
<Noldorin_> i will do some more investigation on my branch first though
<nigelb> Hrm, what time does poolie start his day?
<jelmer> nigelb: usually around now
<jelmer> nigelb: I'm doubting your statements about your regular sleeping times btw :)
<nigelb> jelmer: okay :)
<nigelb> haha
<nigelb> I was working
<nigelb> Just finished :)
<nigelb> Like, $DAYJOB work.
<poolie> nigelb, hello
<nigelb> Morning!
#bzr 2011-09-13
<poolie> hi all
<poolie> our wiki software is going to be upgraded today, there may be glitches
<jelmer> hi poolie
<Noldorin_> hi jelmer
<Noldorin_> you still around?
<Noldorin_> i've done a bit more research...
<Noldorin_> jelmer, the problem is that branching and uncomitting back to r46 makes the branches diverge...
<Noldorin_> (no common ancestor, it days)
<Noldorin_> so i can't merge in :-S
<Noldorin_> from r47
<Noldorin_> how eird
<cody-somerville> Is there a function I can call that'll basically parse what I might pass to bzr at the command line and transform it into whatever Branch.open will be looking for?
<lifeless> directory service lookup is the difference there I think
<cody-somerville> lifeless, How do I use that? I assume there must be some function I need to call to get things initialized and get a DirectoryServiceRegistry object?
<lifeless> there is probably a module level instance you can use
<lifeless> you'll need a library context as usual
<cody-somerville> Figured it out.
<cody-somerville> Branch.open and stuff automatically do directory service lookup
<cody-somerville> I had to call bzrlib.initialize() and bzrlib.plugin.load_plugins() first though
<lifeless> yes :)
<poolie> wgrant, lifeless, i was going to say, people are getting things done at a good rate but it may feel a bit like one thing after another
<poolie> without them so much adding up
<poolie> john commented on something like this
<poolie> one idea is to borrow the rotation idea from lp, but for the whole team:
<poolie> for say 2 weeks all focus on one area, eg bfbia or lp bzr-git integration, or whatever
<poolie> probably for as long as it takes to get that area adequately complete
<wgrant> I think that's a good strategy, particularly for something like bzr.
<poolie> interrupted only by actually critical bugs
<wgrant> As long as the thing is of reasonable scope.
<poolie> (in the bzr definition, meaning data loss or total use blockage or whatever)
<poolie> and then do say 2 weeks of reactive work on general bugs
<mwhudson> the tricky part of this, from experience and observation is getting to the point where you can stop
<poolie> we would still continue with piloting but people would have less discretion to pick their day-to-day work
<poolie> yes
<lifeless> whats your average cycle time ?
<mwhudson> james_w can tell you lots about this too :)
<poolie> the feature you pick could easily turn out to be 3 days or 3 months instead
<poolie> i don't know, where does lp show that? :-7
<poolie> but, the mean is probably about a week
<lifeless> lpkanban should be emitting that :)
<lifeless> so, that means 2 complete patches end to end for each person (on a 2 week cycle), and if you're doing concurrent work, whatever your concurrency is in WIP when you come to change.
<lifeless> do you have a few ideas you want to run up the flag pole, or just this particular one ?
<poolie> i don't think it follows it would be 2 patches per person, because i'm including stalls there, which this could reduce
<poolie> for example its skewed by 660264 being something like 18 months old
<lifeless> k
<poolie> this is my central idea
<poolie> i think the 'typo fix' time is somewhere around 24h or less
<poolie> so, a fairly sized feature could get done in 2w
<poolie> there are some variations
<poolie> 0- change nothing
<poolie> 1- put one person (or two) on bugs, and have others ignore bugs and work on a feature
<poolie> 2- anyone can do either bugs or features on any day, but there are fewer features in play to choose from
<lifeless> how much does a [human] context switch cost in bzr?
<poolie> 3- just generally shift the bar of which bugs ought to come ahead of feature type work
<poolie> (obviously i'm using the word 'feature' here to mean proactive work rather than reactive, it may have a bug number)
<poolie> lifeless, as in, switching from one bug to another, or one area of the code to another?
<poolie> hm it seems a bit hard to generalize
<poolie> the harder issues might need a bit of mental state
<lifeless> poolie: bit of A, bit of B
<lifeless> like, if you said 'lets spend 2 weeks on looms'
<lifeless> how long before things started flowing?
<poolie> i think generally speaking if I did an hpss bug today and a udd bug tomorrow it would not hurt
<poolie> great example; i think the costs are going to be
<poolie> - i already have these other mps underway and i need to finish them off (kind of queue-draining)
<poolie> - deciding what in particular we're going to do
<poolie> - to some extent, getting familiar with the code, though .. perhaps that's not enormous, and having a specific impetus to get into eg the loom code could be beneficial
<poolie> perhaps the biggest cost of timeslicing is going to be queue draining/filling
<lifeless> a few random thoughts
<lifeless> having > 1 person on a task is enjoyable
<lifeless> jelmer: bzr-search trunk is now owned by ~bzr
<lifeless> jelmer: I've left a branch reference behind for convenience
<poolie> (yes, that's one thing i'd like to have happen more often)
<lifeless> waste [in the lean sense: time in the production of something that isn't actively moving a product through to the customer] can make things really drag out
<lifeless> and for me at least that draggy feeling can numb the sense of variety that one would otherwise get
<lifeless> e.g. exec rather than fork on lp :)
<poolie> yes, that's very true
<lifeless> so, you can either switch while you have stuff to drain, or you can switch 'new stuff' but continue to drain.
<lifeless> something that makes these behaviours closer is reducing the time to drain/time to fill figures
<poolie> mm
<lifeless> I suspect you're already pretty vigorous on that
<poolie> i think our average time from an mp to getting it merged is moderately low now
<lifeless> but its worth having in mind when considering new scheduling approaches
<poolie> i think having more people on one project tends to reduce it more, because there are informed reviewers
<lifeless> e.g. doing something that will increase the time-in-queue (like less piloting) may have a negative impact
<poolie> yes, very much
<poolie> i wouldn't cut back on piloting for this
<poolie> this is all within the slice of non-piloting work
<lifeless> sure, I'm just thinking through it all
<lifeless> releases will interact with this.
<lifeless> unless you can automate them totally out of existence.
<poolie> yep, they too are a kind of 'hygene' task
<poolie> as are srus (kind of related)
<poolie> and answering user questions
<lifeless> yah
<poolie> very likely we can or should automate them more
<lifeless> I don't know if whole-team rotations make sense, I suspect you may pay in context switches
<lifeless> OTOH if everyone is looking at the same stuff you should get some network effect.
<lifeless> my 2c: give it a go for 3 cycles.
<lifeless> measure it,
<lifeless> return to what you have now
<lifeless> measure that.
<lifeless> compare.
<lifeless> (return because otherwise the act of changing may be a placebo)
<poolie> you say placebo like it's a bad thing :)
<lifeless> it is if you want things to -stay- better ;_
<poolie> wgrant, any other thoughts?
<wgrant> Mmm.
<wgrant> It's hard to say how well it would work for bzr. I think you probably have less interrupts, so it would work well.
<wgrant> And, as you say, it would be nice to have multiple people working together on one thing.
<vila> hi all !
<poolie> hi vila
<vila> poolie: hey !
<poolie> hi there
<vila> warming up for the standup ?
<poolie> yeah
<poolie> apparently it was still owned by spiv so i was just trying to fix that
<poolie> he's still pretty much welcome to come but i doubt he wants calendar remindres
<vila> :)
<babune> Riddell: thanks :)
<poolie> for a second there i thought you set up a bot
<vila> hehe, not yet...
<vila> acting bot only so far ;)
<poolie> jam, jelmer, hi?
<poolie> o/ mrevell
<mrevell> Hi!
<vila> lp is down ? At least the high failure rate on the package importer suggests so
<vila> requeued
<poolie> not as far as i know
<vila> ~600 spurious failures
<vila> poolie, jam, jelmer, Riddell : Did one of you want to post the standup summary or should I ?
<jam> vila: Fine with me if you want to do it.
<vila> poolie, jam, jelmer, Riddell : I'll do it then, still 5 secs to shout otherwise 4... 3
<Riddell> go ahead
<vila> done
<poolie> jelmer, what's the tag for bfbia bugs?
<poolie> i know i've seen them but the link from https://dev.launchpad.net/LEP/BuildFromBranchIntoArchive has nothing
<jam> jelmer: maybe that just means the code is perfect? (*crosses fingers*)
<poolie> jam, https://code.launchpad.net/~jelmer/launchpad/bfbia-db/+merge/68990
<poolie> jelmer, what's actually up with that? it looks like it's mostly merged?
<jelmer> poolie: bfbia is the relevant tag
<poolie> so there are no bugs?
<jam> jelmer: k, there just doesn't seem to be any matches
<jelmer> poolie: though I think most of the bugs that have been closed were actually in bzr-builder/bzr-builddeb
<poolie> just the db proposal?
<poolie> oh ok
<poolie> no bugs in lp
<jelmer> poolie: there's one, but it lacks the tag :-)
<poolie> nice :)
<jelmer> bug 313602
<ubot5> Launchpad bug 313602 in Launchpad itself "Please add "build this branch" option" [High,In progress] https://launchpad.net/bugs/313602
<jelmer> the relevant changes for bfbia are that db branch, which is trivial. I haven't looked at landing because of lp's changing of its deployment process.
<jelmer> and there's the proof of concept branch at https://code.launchpad.net/~jelmer/launchpad/bfbia/+merge/64036 which works but had too many database changes. I've been working on getting it to use the existing recipe-based infrastructure instead.
<jelmer> my guess is that it's fairly close now that the other Launchpad related stuff has landed
<poolie> jam, https://bugs.launchpad.net/udd/+bug/724890
<ubot5> Ubuntu bug 724890 in Ubuntu Distributed Development "excessive memory consumption for nexuiz-data" [Critical,Confirmed]
<jam> poolie: https://bugs.launchpad.net/bugs/819604 ?
<ubot5> Ubuntu bug 819604 in Bazaar 2.4 "when an idle ssh transport is interrupted, bzrlib errors; should reconnect instead" [High,Confirmed]
<jelmer> Riddell: hi
<jelmer> Riddell: just followed up to your i18n patch
<jelmer> Riddell: I'm also wondering more generally about i18n what the best way is to translate plugins.
<Riddell> I haven't really thought about that so far
<Riddell> but they should load a separate gettext domain with their translations
<poolie> could someone look into https://bugs.launchpad.net/bzr/+bug/848064 ?
<ubot5> Ubuntu bug 848064 in Ubuntu Distributed Development "Revision not present branching from LP" [Critical,Confirmed]
<poolie> if it is similar to the earlier bugs max dealt with, it should be able to be fixed by clearing and requeuing the imports
<poolie> or something like that
<poolie> night all
<poolie> jelmer, so does that small db patch still make sense to merge?
<poolie> just +ALTER TABLE SourcePackageRecipeData ALTER COLUMN deb_version_template DROP NOT NULL;
<poolie> if so, can i remind you to push for a review, or for clarification on how/where/when to merge it?
<jelmer> poolie: I think it still makes sense, but I'd like to finish my other branch first to be sure.
<jelmer> Riddell: it would be nice to have some convenience functions in bzrlib.i18n for that
<Riddell> jelmer: for plugins?
<jelmer> Riddell: yeah
<Riddell> yes I agree, I'd like to do that
<Riddell> vila: at what stage in the release process do we make a new stable branch?
<vila> Riddell: I'd prefer an easier question before my lunch
<vila> :)
<vila> Riddell: you mean on pqm ?
<Riddell> vila: I mean when will lp:bzr/2.5  be separate from lp:bzr
<vila> or rather you mean a branch associated with a stable series
<vila> yeah
<vila> so, that should be in releasing.txt, but from memory, the branch is created to release 2.x.0
<vila> aka when we create the first stable release in a series
<vila> it shouldn't be hard to do that for the *last* beta before the first stable if that makes it easier for translations
<vila> we freeze the API after the last beta already
<Riddell> ok, I'll write that up
<vila> Riddell: search for 'Kick off the next cycle' in releasing.txt
 * vila off for lunch
<Riddell> vila: for your release manager eyes https://code.launchpad.net/~jr/bzr/i18n-release-process-doc/+merge/75161
<vila> maxb, jam : Any issue blocking 2.4.1 ?
<vila> jelmer: oops ^ :)
<jam> vila: anything blocking me from building it? (just not having done it for me)
<vila> jam: yeah, I mean, any reason to delay the announce
<jam> well, windows installers aren't built yet...
<vila> jam: discussed numerous times, unless critical bugs block building, availability should not block announce
<vila> lack of availability for that matter
<vila> :)
<jelmer> vila: not afaik
<vila> jelmer: IIUC you're first to shoot by releasing on debian right ?
<vila> sid even
<jelmer> not sure what you mean by first to shoot :)
<vila> jelmer: once it's released on debian, the ubuntu releases can be done
<jelmer> ah, yeah
<jelmer> vila: I usually upload to sid and ubuntu at the same time
<vila> ok
<vila> jelmer: any ETA ? :D
<vila> Riddell: reviewing, can we discuss it a bit ?
<jelmer> vila: I'll have a look now, if the tarball is up
<jelmer> vila: looks like the 2.4.1 tag is missing
<vila> jelmer: it's up since last Thursday. Did my '[ANN] 2.4.1 has gone gold' mail got lost ? Ha crap
<vila> it's here :-/
<vila> jelmer: oh, may be you mean not on trunk ?
<jelmer> vila: not on lp:bzr/2.4
<jam> jelmer: bzr-2.4.1            6042.1.4
<jam> looks like it is here
<jam> jelmer: also in lp:bzr/2.4 (I just confirmed)
<vila> pfew, thanks jam, I was starting to suspect pqm (I *did* sent 2 submissions with this tag (AFAIK) but just when we migrated)
<vila> and there has been some weird branch shuffling during the migration
<jelmer> sorry, my bad - we don't have the right magic in the 2.4 packaing branch yet
<vila> np np
<vila> (and I just pulled lp:bzr/2.4 and didn't get any updated tags message :-D)
<vila> and 2.4 hasn't been merged on trunk yet so trunk doesn't have the bzr-2.4.1 tag, all is well :)
<Riddell> vila: of course
<vila> Riddell: reviewed locally, I was surprised by the 27	+The final beta - branching and translations
<vila> Riddell: but it's correct
<vila> Riddell: you used (AT) in emails, why ?
<vila> Riddell: I mean, we didn't do this for the others, should we change ?
<Riddell> there's enough special casing for the last beta that I think it needs its own section
<vila> yeah, yeah, good idea, I agree
<Riddell> vila: the e-mails were just copied off what dpm gave me, I can change them to @
<vila> and enclose them in `` ``
<vila> i.e. only tweaks, I'll vote
<Riddell> updated
<vila> Riddell: generally when we say tweak, it means, no need for a second review, go :)
<Riddell> formidable
<vila> :)
<jam> vila: poke for great justice!
<jam> I have a question about some interactions with threading and socket receiving
<vila> jam: la la la , I can't hear you
<jam> specifically, I'm trying to add a 'select()' call before we start reading the next data stream
<vila> kidding :)
<jam> so that I can timeout if a connection goes idle
<jam> however, in doing so, some tests start getting "hung threads"
<vila> yeah
<jam> however, when I run the test it claims is a problem
<jam> it passes in 0.1s
<vila> don't mix timeouts and blocking calls
<jam> vila: specifically, the socket is set to blocking, and I just select.select(... timeout)
<jam> which generally seems to work
<vila> yeah, generally
<vila> but, just no
<vila> it's in the docs, let me find it again
<vila> http://docs.python.org/library/socket.html
<vila> jam: re-reading as the wording seems different from what I remember and things may have changed
<vila> ha, yeah, I think it's even more forbidden when using sockets *and* makefile() objects(which we do)
<vila> ile objects returned by the makefile() method must only be used when the socket is in blocking mode;
<vila> quteo: "File objects returned by the makefile() method must only be used when the socket is in blocking mode"
<vila> quote
<vila> so, don't do that
<vila> most of the issues in the socket/thread leaks in selftest saga (part I) were caused by timeouts
<vila> jam: IIRC, the bzr server itself cheats a bit by using a timeout but it does so on the listening socket where we don't use makefile() objects
<vila> jam: ping ?
<jam> vila: there is a difference from setting a timeout on the socket, and using select with a timeout
<jam> I'm not setting a timeout on the socket
<jam> (and, unfortunately, empathy still refuses to make noise when I get mentioned.. :(
<vila> ha, ok (empathy)
<jam> I'll probably switch to Pidgin soon
<jam> It used to work
<jam> But  I think it stopped when I installed natty
<jam> I have to see the little blue icon in the corner.
<vila> you may be right about select, but the symptom you describe reminded me of so many issues I encountered
<vila> so, back tracking,
<vila> what do you mean by "before we start reading the next data stream" ?
<jam> ugh, still so much pain. If I run the test suite, I can see what test is failing, if I run *just* those tests, no failures
<jam> vila: In SmartServerStreamMedium.serve() we loop over _build_protocol() _serve_one_request(protocol)
<jam> so for every message that comes in from the client
<jam> we read the first line, then dispatch the request and process it in 'blocking' mode
<jam> I'm trying to add a "select(..., timeout)" just before reading the first line
<jam> so if a client connects, chats with us a bit, and then never hangs up
<jam> we'll hang up after a time
<jam> as long as they *initiate* an RPC, we won't timeout on them (until that RPC has been fully responded to, and they haven't started a new one)
<jam> funny enough, I can set the select timeout to 4.0s, which is shorter than the 'hung_thread' timeout of 5s.
<jam> And then I get the exception in my code.
<jam> Running a bunch of tests, seems to deterministically pick what test will fail
<jam> running just that test, no failure
<vila> jam: hmm, my gut feeling is that this won't mix up well with the rest (and the test failure kind of confirm that, but well, easy )
<vila> Does the serve actually capture the connections or is it only the test server that does that for now ?
<vila> s/serve/server/
<vila> jam: and do you include errors in your select ?
<vila> during tests we close the sockets with prejudice so if you don't include errors in your select, you may miss that
<vila> alternatively, if the connections are captured you can update a stamp and let the main thread close/kill the idle connections
<vila> whether you want to kill a connection taking too long to process a request or not may be worth considering too
<jam> vila: currently I'm just doing select([r], [], []) however I get EBADF if the socket was closed on the server side.
<jam> I don't do any special capturing, etc.
<jam> vila: i don't *think* bzr serve --inet runs any threads
<jam> I could be wrong
<jam> (that particular case is also a PipeStreamMedium, which is not the same code path)
<jam> plain 'bzr serve' creates a SmartTCPServer that dispatches to threads
<jam> but "bzr serve --inet" just hooks up a SmartServerPipeStreamMedium to stdin/stdout
<jam> so there isn't a master process monitoring the 'connections'
<jam> further, it only fails during teardown parts of the test suite. Never in 'live' code.
<jam> so i'm tempted to say it is something incomplete with out test infrastructure, not sure what yet
<vila> I don't remember issues with SmartServerPipe, may be because I didn't work much with it
<vila> jam: which tests are failing ?
<jam> A random selection (different each run) from: ugh, still so much pain. If I run the test suite, I can see what test is failing
<jam> sorry bad paste
<jam> bzr selftest -s bt.per_branch.test_branch Remote -v
<jam> Note, I did just find:         self.clients.pop()
<jam>         self.clients.append((request, client_address, t))
<jam> which doesn't actually check that the thing popped off is the same thing we are appending
<jam> so there is at least the possibility that between 'get_request' and 'process_request' the order changes
<jam> and we close the same object 2 times, but never close another object, etc.
<vila> but why is that involved if you focus on SSPipe ?
<jam> I'm not focussing on SSPipe
<jam> since most of our test suite uses the other
<jam> and I'd *like* them to act roughly the same
<jam> *Launchpad* wants us to support the TCP stuff as well
<jam> so that stale connections get reaped
<jam> yes, we *could* do it in 2 different ways
<jam> even weirder. sometimes you clearly get a 2s timeout, but the test still passes
<jam> ugh. it seems to pass if I add a 'print' statement
<jam> sys.stderr.write is enough
<vila> timing issues are generally caused by a lack of synchro somewhere, addind timeouts in the mix.... shouldn't help
<jam> I guess that gives the other thread a chance to say "oh hey, he must be shutting down"
<vila> yeah, kind of adding sleep(abit)
<jam> vila: oddly enough adding time.sleep(0.1) does *not* fix it. but print "data" *does*
<blackarchon> hi guys :)
<blackarchon> I don't see a windows build for bazaar 2.4.1 yet
<jam> I have the feeling it is just the test suite failing to see the exception.
<jam> blackarchon: it isn't built yet
<blackarchon> is there an ETA?
<jam> blackarchon: nothing concrete. I have it building now, but if there are any failures I probably won't have time to address them
<blackarchon> jam: ok, thx :)
<jam> blackarchon: looks like the build went fine. Uploaded
 * Riddell nudges jelmer into reviewing https://code.launchpad.net/~jr/bzr/i18n-enable-translations-everywhere/+merge/75040 again before the end of the day
<jelmer> Riddell: I'll have a look
<jelmer> oh, actually
<jelmer> jam, vila: do you have an opinion on whether installation of gettext should happen by bzrlib.initialize() or lazily in bzrlib.i18n.gettext()?
<vila> both :)
<vila> it sounds like something that should be done in bzrlib.initialize() but if the cost is too high to be done unconditionally, then it should be lazy
<vila> the test suite itself doesn't really respect bzrlib.initialize though
<jelmer> Riddell: is there a way to disable i18n explicitly?
<jelmer> Riddell: I don't really want to bikeshed on this, as I'm not sure how important it is
<Riddell> jelmer: currently unset LANGUAGE and the other envirnment variables
<jelmer> Riddell: but it would be nice to give 3rd party users of bzrlib the ability to disable i18n
<Riddell> a function in i18n.py to do that would be easy enough
<jam> Riddell: you said it was "slightly less than 0.1s to slightly more than". Anything more quantifiable?
<jam> Like 0.01s or 0.08s, etc?
<jam> I do like the idea that if a command has nothing to say, it doesn't have to load the mappings
<jam> I have the feeling that the mappings will get more expensive to load when
<jam> a) they aren't just english
<jam> b) we have more stuff that gets translated
<jam> I don't know if gettext() loads all the mappings preemptively, or if it has an index and can only load the ones that are actually
<jam> translated.
<jam> I would hope the latter
<jelmer> I think it has the latter because it has some kind of binary file that it loads rather than the plain text
<blackarchon> jam: thank you, I will test it! :)
<Riddell> jam: for example http://paste.kde.org/121057/
<nigelb> Riddell: Interesting post re:OpenSuse :)
<jelmer> vila: bzr-2.4.1-1 uploaded to debian, 2.4.1-1ubuntu1 now building..
<vila> \o/
<Riddell> jelmer: i18n.disable_i18n() added
<jelmer> \o/
<jelmer> Riddell: r=me
<Riddell> pardon?
<jelmer> sorry, Launchpad jargon
<jelmer> Riddell: I've approved your merge proposal.
<Riddell> awooga
<Noldorin> hi again jelmer
<jelmer> hey Noldorin
<jam> vila: I think I've tracked it down. My guess is that we enter select.select([socket]), and then the TestCase teardown code does socket.close()
<jam> If the teardown happened *first* we would get EBADF
<jam> because it happens second, we don't see it until after the timeout.
<jam> I changed it to a loop, and now I get socket.error(EBADF) often
<jam> About 1 time in 500 or so, I get something that looks just like socket.error
<jam> but doesn't catch "exception socket.error"
<jam> but it gets caught by a generic "except Exception"
<jam> Now I have something that gets EBADF about 1-in-3 tests, but never causes the test suite to hang or crash
<vila> ...an socket.error that is not a socket.error... rings a bell, windows ?
<jam> vila: this is on Ubuntu Natty
<vila> no ssl involved ?
<jam> It *sounds* like if someone re-imported socket, so you had 2 real modules involved
<jam> vila: This is mostly loop-back stuff.
<jam> It just str(e) says "error"
<jam> well
<vila> type(e)
<jam> error(9, "bad file descriptor")
<jam> I'll check, just a sec
<vila> but first things first
<vila> your enter the teardown while in select() ?
<vila> you have a thread running and you don't join it ?
<jam> vila: I think it is your "issue a connect but don't write anything" connection
<jam> which starts a new "oh, someone wants to talk to me" thread
<jam> I'm not positive yet
<vila> oh, the hackish 'last connection to unblock the server in listen' ?
<vila> and I'll stop asking more questions, 3 pending ones is already a lot...
<jam> vila: Right, racing threads. If the select() thread happens first, it doesn't see EBADF, if it happens second, it does
<jam> if it doesn't see EBADF, it waits until timeout
<jam> before it fails
<jam> with nothing to read from
<jam> we *are* joining from it, but it fails in the mean-time with a timeout
<jam> joining to it
<jam> And maybe the hackish last connection
<jam> maybe just a connection that is still open, but gets randomly closed by the test suite
<jam> vila: Exception: <class 'socket.error'> socket [Errno 9] Bad file descriptor
<jam> thats "type(e), getattr(e, '__module__'), e"
<jam> so it is completely "socket.error", just not *this* socket.error
<jam> If you get someone who, for example, reload(socket)
 * vila puke
<jam> vila: I don't think that is the case here. But I've seen cases where a module gets loaded twice.
<jam> only times I know of are relative vs absolute imports
<jam> but there should be only one "socket" module
<jam> I suppose someone could do: "sys.modules.pop('socket'); import socket"
<jam> or something like "during teardown we  "import socket; raise socket.error()"
<jam> so socket got deleted by the garbage collector
<jam> and just after that
<jam> we re-import it creating a new socket module with all new classes.
<jam> vila: I know we have other code that does "socket_error = socket.error" with a comment
<jam> about socket.error not being around during teardown time
<jam> oh, 1 sec, I just realized I was logging all errors, not just the ones that miss "socket.error". Trying again. It takes a while to trigger.
<vila> only in the case of the threaded smart server for threads finishing after the main thread AIUI, but the explanation wasn't very clear
<vila> when you say teardown, you're referring to the server teardown shutting down the client sockets ?
<jam> vila: ah, not socket.error: select.error
<jam> <class 'select.error'> select (9, 'Bad file descriptor')
<jam> so 99/100 times it is a socket.error
<jam> and less than 1:100 times it is a select.error
<vila> haaa, makes more sense
<vila> you may need to add select.error to the  expected exception list for the test server then
<jam> vila: well, in the timeout code, I'm treating EBADF as "yeah, stop what you're doing". So no problem there. It shouldn't have to propagate to the test suite.
<jam> vila: thanks for the hint on type(e)
<jam> I *really* don't like the generic "error" classes
<vila> especially when they create aliasing problems like this
<jam> vila: yeah, I guess if __repr__ included __module__, that might be sufficient
<vila> so you're catching both select.error and socket.error and they both specify EBADF ?
<Noldorin> jelmer: hey
<jam> vila: bonus points. select.error doesn't have an 'errno' attribute, instead it just has e.args[0] == EBADF.
<mgz> is that still the case in 2.6?
<jam> mgz: python 2.7.1
<vila> jam: isn't that nice :)
<mgz> I was under the impression it became a IOError subclass
<mgz> but that may well be py3k only.
<vila> jam: and forget that windows will probably a different idiom
<vila> s//don't/ don't forget !
<jam> vila: certainly. That gets tested before this gets submitted.
<jam> I probably *can't* select.select() at all for Pipes
<jam> but at least we can do select(socket )
<vila> jam: yeah, sorry :)
<vila> jam: I think the required interface is fileno() so pipes should work (well, at least on posix)
<vila> . o O (I't be so nice if all this crap was hidden in osutils once and for all...)
<JonOomph> Hi! I am trying to test a LaunchPad recipe using the command "bzr dailydeb openshot.recipe working-dir".  It generates a folder inside the working-dir with "{" and "}" characters.  Is there a way to configure the name of the "build" folder?  Thanks!
<JonOomph> The name of the folder it creates is "openshot-{debupstream}+{revno}+{revno:packaging}"
<JonOomph> This breaks one of my build steps... which call the "xml2po" command.  Apparently, xml2po hates the { and } characters
<exarkun> http://codepad.org/lwI05OCH
<AuroraBorealis> seems that launchpad is overloaded or somethng
<Noldorin> hi jelmer
<Noldorin> guess i missed you earlier
<Noldorin> jelmer, having trouble testing here a bit..
<jelmer> hi Noldorin
<Noldorin> jelmer, the problem is that once i uncommit, i cann't merge into the testing branch :-S
<jelmer> Noldorin: how do you mean?
<Noldorin> PS C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\0.4-test> bzr merge ..\0.4\tests -r 47
<Noldorin> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<jelmer> what is in the testing branch?
<Noldorin> the testing branch is the 0.4 branch, uncommited to r46, then reverted
<jelmer> Noldorin: what does "bzr missing ..\0.4\tests" say?
<Noldorin> jelmer, ERROR: not a branch
<jelmer> sorry, what about ..\0.4 ?
<Noldorin> jelmer, "you are missing 49 revision:" etc. etc.
<jelmer> Noldorin: ah, but one of them has been dpushed?
<Noldorin> yes
<Noldorin> i think so
<Noldorin> the 0.4-test branch
<Noldorin> (successfully)
<Noldorin> since it's on r46
<jelmer> in that case you indeed won't be able to merge between them
<jelmer> dpush changes the history
<Noldorin> oh i see
<Noldorin> hrmm
 * jelmer ponders having a look
<jelmer> I'll bbiab, give me a minute or two
<Noldorin> sure
<Noldorin> :-)
<jelmer_> Noldorin, back
<Noldorin> hi
<jelmer_> Noldorin, so, the easiest way to reproduce the issue is to dpush r47 from your ircnet branch/
<Noldorin> yes
<Noldorin> i know this much
<Noldorin> it's testing it that i've been trying to do the past 3/4 days
<jelmer_> Noldorin, where is the bzr version of your ircnet branch again?
<jelmer_> (Sorry, I know you mentioned it earlier but I don't have the link here)
<Noldorin> jelmer: lp:ircdotnet/0.4 should demonstrate the issue
<Noldorin> no prob
<jelmer_> ok, reproduced
<Noldorin> jelmer, btw, writing a little script for testing here... how can i run bzr commands *without* it prompting me?
<Noldorin> i.e. no confirmation for bzr commands
<jelmer_> I think the only command that prompts is uncommit
<jelmer_> it has a --force option
<Noldorin> ok cool
<Noldorin> jelmer, written a test powershell script now, so i'm getting closer!
<Noldorin> jelmer, do i have to do one commit per merge?
<jelmer_> Noldorin, not sure I follow
<Noldorin> jelmer, well if i try to do two merges in a row, it gives ERROR: Working tree "..." has uncommitted changes.
<Noldorin> ....no away around this?
<Noldorin> or do i have to do merge, commit, merge, commit, merge, commit, ... ?
<maxb> You can --force it, but it's recommended to commit each merge individually
<jelmer_> Noldorin, you probably want to commit each merge to be able to actually see where things break
<Noldorin> jelmer, well i have to do them each at once...because as soon as i do dpush, bam, the branch is fucked
<Noldorin> can't merge in..
<Noldorin> (history has changed)
<jelmer_> Noldorin, you can push an entire branch with all the changes split up into individual commits though, and then see which one has problems
<Noldorin> yep
<Noldorin> that's my plan
<Noldorin> jelmer, okay, i have interesting results here..
<jelmer_> Noldorin, cool
<jelmer_> Noldorin, what are they?
<Noldorin> jelmer, if you look at the log for -r 47, it is specifically one line that causes the problem
<Noldorin> that is, tests/
<Noldorin> jelmer, you thought src/ i guess...but i don't think so
<Noldorin> specifically
<Noldorin> it seems to be hte line:
<Noldorin> RM  src/IrcDotNet.Tests/README.md => tests/README.md
<Noldorin> jelmer, yo uthere?
<jelmer_> Noldorin: sorry, yep
<Noldorin> cool
<Noldorin> jelmer, okay, more news if you're ready!
<jelmer_> I am :)
<Noldorin> right, so firstly i took all the changes from the r47 log individually and applied them in a series of merges to r46
<jelmer_> Noldorin, so if you reduce the changes in r47 to just that change the bug occurs?
<Noldorin> jelmer, if i then force merge (and only one commit at the end), it *works* fine
<Noldorin> however, if i commit after each merge, it fails as usual
<Noldorin> however, even in the case with force merges/single commit, it is necessary for both tests/ and samples/ (or neither) to me merged -- otherwise i get the error
<Noldorin> jelmer, beyond that, i'm struggling to find the ultimate cause
<jelmer_> Noldorin, hmm, that's interesting
<Noldorin> jelmer, but then, if the "tests/" merge is not present, everything works fine, regardless of how it's merged it :-S
<Noldorin> so evidently the tests/ change is the root of the issue
<Noldorin> but something about the samples/ change resolves it, *if* done simultaneously.
<Noldorin> (i.e. 2 forced merges in the same commit)
<Noldorin> jelmer, you see what i'm getting at?
<jelmer_> Noldorin, yep, I do
<jelmer_> Noldorin, we're getting somewhere
<Noldorin> good good
<jelmer_> I suspect the order in which we process the changes in bzr-git might be relevant
<Noldorin> indeed
<Noldorin> bzr init --git
<Noldorin> bzr: ERROR: No module named posix
<Noldorin> jelmer, any idea why that is happening? ^
<jelmer_> Noldorin, that should be fixed in newer versions of bzr-git
<Noldorin> oh ok cool
<Noldorin> i should update first indeed
#bzr 2011-09-14
<Noldorin> jelmer, doesn't like the upgrade :-(
<jelmer_> Noldorin, which upgrade?
<Noldorin> jelmer, to newest bzr-git/dulwich
<Noldorin> Unable to load plugin u'git' from u'C:/Program Files (x86)/Bazaar/plugins'
<Noldorin> bzr: ERROR: exceptions.KeyError: "Key 'git' already registered"
<jelmer_> Noldorin, the bzr log file should have more information
<Noldorin> oh wait; randomly working now hmm
<Noldorin> bzr doesn't like symlinks in program files :O
<Noldorin> jelmer, so a bit more playing around seems to reveal that this problem is due to the fact parent directories are not actually created (added to the git database?) before they get used
<fullermd> git doesn't track directories period, neh?
<Noldorin> fullermd, hmm, maybe that's the problem then?
<Kamping_Kaiser> no it doesn't
<fullermd> Noldorin: With git?  One of them anyway  ;)
<Noldorin> fullermd, no with this bug jelmer and i are discussing about bzr-git :-)
<Noldorin> fullermd, though i agree, it's a problem with git too hah
<Noldorin> jelmer, thoughts?
<jelmer_> Noldorin, I'm looking
<Noldorin> ok :-)
<Noldorin> right, so it's definitely one of the renames into tests/ failing...
<Noldorin> *continues debugging*
 * jelmer_ writes a testcase
<yshavit> hi alll, I'm trying to use bzrlib (from python), but I keep getting an unsupported protocol exception. I'm using the remote_branch_url example from http://wiki.bazaar.canonical.com/BzrLib, straight copy-paste. bzrlib.version_info=(2, 4, 0, 'final', 0).  Any ideas?
<Noldorin> jelmer_, the minimal mergeset that creates the issue is tests/IrcDotNet/ and tests/TraceAndTestImpactSettings.tracesettings
<Noldorin> there are probably other equivalent minimals
<jelmer_> yshavit: that example lacks this code: "from bzrlib.plugin import load_plugins; load_plugins()"
<jelmer_> Noldorin, thanks
<yshavit> jelmer_: thanks! is there someone I should email about that?
<jelmer_> yshavit, I'm updating the page
<yshavit> jelmer_: even better. Thanks for the quick help.
<Noldorin> jelmer, sure. just some more playing around tells me (and trying to create new test branches which i dpush) that it's a highly order-dependent issue
<Noldorin> jelmer, if you're digging through the code right now, i'll be here ready to assist :-)
<Noldorin> (just not sure if there's much more i can do by *myself*)
<jelmer_> Noldorin, thanks
<Noldorin> jelmer, will be here watching TV for the next 2 hours about, so feel free to ping me with progress at any time then
<jelmer_> heh, ok
<jelmer_> I might get some sleep soon and look closer into this tomorrow
<Noldorin> jelmer, heh okay, sure. i will be around tomorrow too
<Noldorin> we are both in European time zones i suppose?
<yshavit> jelmer_: is there any page that's somewhere between that front page and the autogenerated pydocs?  A tutorial-type thing? I can't find one on google.
<jelmer_> yshavit, for the API? Not really. I generally just look at the tests in bzr itself for inspiration
<jelmer_> what are you trying to do?
<yshavit> jelmer: ah, okay
<yshavit> jelmer_: for now, just merge. I've got the branch branched locally (through bzrlib)
<yshavit> jelmer_: but in the larger scope, I'm also trying to teach myself how to fish :)
<Noldorin> jelmer, well, feel free to ping me tomorrow after about 1pm, if that works for you better...
<poolie> hi all
<poolie> hi vila
<vila> hey poolie, hi all :)
<vila> jelmer: do we need to follow https://wiki.ubuntu.com/FreezeExceptionProcess for 2.4.1 on oneiric or is there some shortcut since we don't " introduce a new upstream version with new features and/or ABI/API changes" ?
<poolie> <jelmer> zzzzzz
<poolie> ;)
<vila> :)
<vila> jelmer, poolie: I think we qualify for "FeatureFreeze for bugfix-only updates" which says "Up through RC, if a developer believes an upload of a new upstream release that just has bug fixes in it is warranted, they may upload it."
<vila> poolie: by the way, can *you* upload ?
<poolie> i probably can, yes
<poolie> since you said it was already up i just wanted to understand the situation
<vila> that was a rhetoric question, AIUI jelmer should already have the branch/package ready for that
<poolie> i'm not sure if it's more appropriate to request a sync or to merge and upload
<poolie> ok
<vila> poolie: justasec, searching the IRC log
<vila> of course xchat history threshold is just where it shouldn't
<poolie> vila, so that "biweekly meetings" thread is quite relevant to our discussion last night
<vila> Sep 13 17:30:51 <jelmer>	vila: bzr-2.4.1-1 uploaded to debian, 2.4.1-1ubuntu1 now building..
<poolie> oh ok, cool
<vila> poolie: which thread ?!?!?!
<poolie> on udd
<poolie> you are subscribed?
<vila> AFAIK, yes
<vila> ubuntu-devel@lists.u.c right ?
<poolie> no, https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
<vila> right, both end up in the same mailbox here
<poolie> ok
<vila> ... wth, I have a filter for it but I'm not subscribed ???
<poolie> vila, i wouldn't say bug 849715 is a really high priority unless it's trivial
<vila> damn, yes I am subscribed
<ubot5> Launchpad bug 849715 in bzr Upload plugin "fails when upload_location becomes unreachable and doesn't provide an escape path" [High,Confirmed] https://launchpad.net/bugs/849715
<poolie> classic case of of course per-project priority vs team priority
<vila> poolie: high in the plugin context and yes it's trivial
<vila> I agree it's not high in the team context
<poolie> so you've got it?
<poolie> i mean, got the mail from the udd list?
<vila> yup
<vila> marked as read
<vila> except for james's one which I didn't recognize as matching your reference
<vila> ok, read, I see your point, and I can only repeat that having goals bigger than bugs but smaller than strategic goals will help
<vila> huh, did james_w moved from UTC+1 tz to UTC-4 tz ?
<bradm> hi
<poolie> yes, to canada
<bradm> so, bug#788072
<bradm> we've got two servers being bitten by it now
<poolie> bradm, does it consistently fail?
<vila> oooooh
<poolie> did something on this machine change when it started happeing?
<bradm> poolie: seems to be consistent
<bradm> I can't say if anything changed, its a lp builder so I don't know what else has been going on
<vila> bug #788072
<ubot5> Launchpad bug 788072 in Bazaar "AttributeError: 'module' object has no attribute 'trace'" [Undecided,Incomplete] https://launchpad.net/bugs/788072
<bradm> there's been general package upgrades, I don't usually use these machines all that often so I can't say when it started
<poolie> how urgent is it to fix this?
<poolie> we could change it so that it at least doesn't mask the error
<poolie> if we try a fix, would you be able to run bzr eg from a branch to see if it fails the same way
<bradm> I think its breaking our use of puppet on the boxes, since we've got etc in bzr
<poolie> for that matter, can you see if it works the same way with the latest bzr 2.3 from the ppa?
<bradm> I can certainly try some stuff
<vila> bradm: AIUI, we have never been able to reproduce it and my last debug attempts with lamont pretty much convinced me it was a weird local install issue
<poolie> vila, in the standup yesterday you said something about making udd robust about lp downtime
<bradm> vila: fwiw, I don't know if we can rule that out, since these are both lp buildds, its possible there's something local
<vila> poolie: yup, that's my targets for today
<poolie> i guess that's https://bugs.launchpad.net/udd/+bug/795321 assigned to jr, not obviously started
<ubot5> Ubuntu bug 795321 in Launchpad itself "udd importer should make tea while launchpad is down" [High,Triaged]
<vila> bradm: oh, new context then ! Can you add that to the bug ?
<vila> poolie: yup
<poolie> i'm not sure that increasing the parallelism is all that important at the moment compared to some specific failures
<bradm> this is interesting, one of them is bzr 3.2.1
<bradm> er, 2.3.1 even
<bradm> silly fingers
<vila> poolie: you mean bug #724893 ?
<ubot5> Launchpad bug 724893 in Ubuntu Distributed Development "concurrent db access are not handled" [Critical,Confirmed] https://launchpad.net/bugs/724893
<bradm> and the other is 2.3.3
<vila> poolie: the issue here is not to increase parallelism but that this bug can happen *now* triggered by any tweak anywhere
<poolie> ok
<poolie> does that show up as an actual import failure?
<poolie> if so we should be able to measure how many suffer from it
<vila> poolie: what ? bug #724893 ?
<ubot5> Launchpad bug 724893 in Ubuntu Distributed Development "concurrent db access are not handled" [Critical,Confirmed] https://launchpad.net/bugs/724893
<poolie> yes, that
<jam> morning all
<vila> poolie: it's not package specific at all, it's a bug in the design and we are lucky that it doesn't trigger more often
<poolie> let's finish with bradm first
<poolie> bradm, that's worth adding too
<poolie> so the short story is, if we have something we think will help, you can deploy and test it?
<bradm> poolie: I'd say so, given that the existing bzr stuff is busted
<poolie> ok
<poolie> i assigned it to the team
<poolie> hi jam
<bradm> just added a comment about the 2nd server and them being lp buildds
<poolie> vila, i know it's not caused by the particular package, but my question is whether the import logs will tell us how often it occurs
<poolie> if it's not actually often, it doesn't need to be critical
<vila> ok, I resign, downgrade it to low if you wish, the day we'll encounter it because some totally unrelated optimization make the imports faster... we'll marked it critical
<poolie> i'm just trying to understand the situation
<vila> poolie: both mass_import and import_package want to update a db, as of today, there is no contention because imports are slow enough
<vila> increasing parallelism (as I did as an experiment) revealed the bug and made it obvious
<vila> but the bug is there nevertheless
<jam> My 2c, if we don't have to stop everything and work on it, it isn't "Critical", it can be "High", it can be in our "bugs to work on next" list, but that doesn't make it *Critical*.
<vila> I don't think we still have the logs for the last debian massive import where this occured
<jam> I don't think anyone has said it isn't a bug
<jam> or worth fixing, etc.
<vila> jam: you already said that in the comment and I disagreed and still do
<jam> vila: then why aren't you working on it *right now*, if it is critical
<jam> ?
<poolie> vila, jam said what?
<jam> If *you* feel it is critical, then certainly it should trump the config stuff you are doing, etc.
<jam> poolie: I said I didn't feel the bug was "Critical"
<jam> vila: I'm not trying to start the argument again. But that is what Critical is supposed to mean. At least in my understanding.
<jam> "This bug should be fixed before all High priority bugs"
<poolie> jam, that is what critical ought to mean
<poolie> in fact "even ahead of other work that's already in progress"
<vila> to me it means a bug that can break the whole package importer
<poolie> we haven't always been great about doing it but we shouldn't dilute it ay further
<vila> and that needs to be fixed to resurrect it
<bradm> poolie: anyway, let me know if you need any more info, or have something for us to try
<vila> jam: I didn't start working on it because: 1) you pointed me to wal which is more complicated than a file-based locking, 2) as mentioned repeatedly this doesn't occur *yet* and I see nothing in the pipe that will trigger it (once 2.4 (and its optimizations)  is deployed on jubany, I may reconsider)
<poolie> bradm, ok, i will, i'm not personally going to start on it now
<poolie> vila, il'l see if i can get your config things unblocked soon
<bradm> poolie: no worries
<poolie> oneiric's borked, biab
<vila> jam: I'd appreciate if you could make more constructive suggestions about config instead of considering a pet project, there are numerous, real and deep issues around this area
<bradm> poolie: looks like this bug has been around for a bit and it seems to only be hitting 2 servers, so its not ultra high priority
<poolie> ok
<poolie> it would be nice to know why only those two
<poolie> if you know when the problem started perhaps you can attach the dpkg.log
<bradm> poolie: the server I'm seeing started within the last day or so I'm guessing from some puppet stuff
<bradm> poolie: but the last thing in dpkg.log was apache stuff about 2 weeks ago
<poolie> halp! puppet!
<vila> bradm: why are those builds still using bzr < 2.3.4 (not strictly related but well, who knows, may be some upgrade went wrong)
<bradm> vila: I don't know, but they're fully up to date according to the current sources.list on them
<vila> bradm: 8-/ no -updates there ?
<bradm> another random lp buildd has 2.3.1 as well
<vila> err wait, what ubuntu release are they based on ?
<bradm> vila: hardy
<vila> ha, ok, thanks
<vila> hmm, I think jelmer has backported 2.4 for hardy-cat recently
<bradm> these definately have hardy-cat on them
<vila> or is it jelmer_ :)
<bradm> interesting, and hardy-cat-buildd
<vila> dunno about that last one but I'm pretty sure jelmer is already trying to address some buildd issues so I think he targeted the right one
<bradm> vila: if there is a hardy-cat versoin of 2.4 its not on our servers
<bradm> vila: I do see lucid-cat 2.4
<vila> bradm: https://launchpad.net/~canonical-bazaar/+archive/cat-proposed IIUC
<bradm> vila: interesting - I don't know the mechanics by which that makes it into our hardy-cat suites, lamont would know more I'd say
<vila> right, so let's postpone that part of the discussion for when jelmer and lamont are around
<bradm> for sure
<bradm> I'm just a lowly GSA seeing a problem on one server ;)
<vila> bradm: sure, thanks for chiming in here
<bradm> no worries, let me know if you need more info or anything
<vila> bradm: do you have a direct access to one of the failing servers to try some diagnosis ?
<bradm> vila: sure
<bradm> vila: I'll be EODing shortly, but I can do some stuff
<vila> bradm: no problem, start reading the comments in bug #788072 and see if you can follow the proposed steps starting in comment #2
<ubot5> Launchpad bug 788072 in Bazaar "AttributeError: 'module' object has no attribute 'trace'" [Medium,Confirmed] https://launchpad.net/bugs/788072
<bradm> vila: BZR_PDB=1 bzr st looks the same as bzr st
<vila> bradm: i.e. python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' with a bzrlib reachable from your pYTHONPATH
<bradm> vila: I can't get anything from bzr version or bzr plugins -v other than the error
<vila> good, you're in the right context then (hopefully)
<vila> bradm: i.e. python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' with a bzrlib reachable from your pYTHONPATH
<vila> bradm: python -V (just to be sure)
<bradm> $ python -V
<bradm> Python 2.5.2
<vila> ok
<vila> bradm: and the python import above ?
<bradm> $ PYTHONPATH=/var/lib/python-support/python2.5 python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__'
<bradm> /var/lib/python-support/python2.5/bzrlib/_chunks_to_lines_pyx.so
 * vila blinks
<vila> and if you remove the PYTHONPATH ?
<bradm> $ PYTHONPATH=/usr/lib/python-support/python-bzrlib/python2.5/ python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__'
<bradm> Traceback (most recent call last):
<bradm>   File "<string>", line 1, in <module>
<bradm> ImportError: No module named _chunks_to_lines_pyx
<bradm> $ python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__'
<bradm> Traceback (most recent call last):
<bradm>   File "<string>", line 1, in <module>
<bradm> ImportError: No module named _chunks_to_lines_pyx
<vila> that's the issue, the install is broken
<vila> well
<vila> the install and the context are not what bzr is expected may be more accurate and less offensive ;)
<bradm> awesome, I can poke some other servers to see the difference tomorrow
<vila> bradm: find / -name _chunks_to_lines_pyx.so -print ? Or something equivalent
<vila> bradm: but if you can relate this missing files with failing servers, yeah, that would narrow down the problem space
<bradm> $ sudo find / -name _chunks_to_lines_pyx.so -print
<bradm> /var/lib/python-support/python2.4/bzrlib/_chunks_to_lines_pyx.so
<bradm> /var/lib/python-support/python2.5/bzrlib/_chunks_to_lines_pyx.so
<bradm> /usr/lib/python-support/python-bzrlib/python2.5/bzrlib/_chunks_to_lines_pyx.so
<bradm> /usr/lib/python-support/python-bzrlib/python2.4/bzrlib/_chunks_to_lines_pyx.so
<bradm> interesting, similar on another working server except it doesn't have a /var/lib/python-support/python2.4/bzrlib
<vila> if it has python-2.5 we don't care
<bradm> right, since we're using python 2.5
<vila> but the /var/lib/python-support part... I'm not sure we ever search there, let me check
<bradm> oho, interesting
<bradm> on a working server:
<bradm> $ PYTHONPATH=/usr/lib/python-support/python-bzrlib/python2.5/ python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__'
<bradm> /var/lib/python-support/python2.5/bzrlib/_chunks_to_lines_pyx.so
<vila> python -c 'from distutils.sysconfig import get_python_lib ; print get_python_lib()'
<bradm> $ python -c 'from distutils.sysconfig import get_python_lib ; print get_python_lib()'
<bradm> /usr/lib/python2.5/site-packages
<bradm> same on a working system
<vila> on a failing server ? ha, rats
<bradm> okey, I've got a 4 year old boy wanting some attention, I'll have to take this up again tomorrow
<vila> bradm: ok, no worries, that may be something in this area, some missing symlink here or there, hard to guess
<vila> bradm: take care of your boy :)
<bradm> vila: will do - thanks for the help, its given me somewhere to look :)
<poolie> vila, i'm reading the stacks patch now
<vila> poolie: \o/
<poolie> vila, i answered
<poolie> can you tell me: why a registry?
<vila> poolie: 1) you asked for it :) 2) it simplifies many issues including centralizing the way to get a stack, overriding by a plugin, etc
<vila> it doesn't address (yet) more convenient ways to build stacks (more on that soon, but roughly a stack is already a list of tuples (store, section_matcher(context)) plus one optional mutable store, to reach one read/write by store we need to centralize the way stores are acquired so they can be shared, the stack registry is a first step
<vila> poolie: i.e. it's harder to track all stores if everybody build stacks at call sites instead of using a registry
<vila> poolie: we've been there (no registry) in other areas and always ended up fixing the issues by introducing a registry,
<vila> the only exception I can think of is transports but we already encountered issues that a registry could address (replacing or behind transport.get_transport)
<poolie> why is a registry better for that than just having named functions?
<vila> poolie: because we all agree it was better when we start using registries ?
<vila> started
<poolie> uh
<poolie> i don't think it's just universally better
<poolie> it solves some particular problems
<poolie> it's not obvious to me those problems exist in this case
<poolie> i don't think people ought to build the stacks inline, but the simplest solution to that seems to be to have functions that build them
<poolie> vila?
<vila> poolie: searching the relevant mp
<poolie> i need to stop soon
<poolie> can we just talk?
<vila> ok
<poolie> here is fine
<vila> I can't find it back, but *I* don't care about whether we use a registry or named functions at this point, I seem to recall that you suggested a registry for stacks in some discussion so I took that route
<mwhudson> does accessing branches with bzr+ssh://user:pass@host/ type urls work in the way one might hope?
<vila> along this route I indeed found that a registry was addressing some issues so I followed up on this route
<vila> from a pure syntactic point of view, as explained in the cover letter, this makes sense too,
<vila> so this proposal is only about introducing the registry
<vila> it doesn't show *how* it helps addressing the other issues to keep it small
<poolie> ok
<poolie> what are the issues?
<jam> mwhudson: yes
<vila> single point of access to control which stack is returned for a single context (this became a blocker when jelmer mentioned that subversion.conf was already implementing some additional feature that requires more flexibility when building branch stacks)
<vila> this can addressed differently but since this is now needed *and* that a stack registry provides *one* way to address it, I just went ahead
<vila> s/can/can be/
<mwhudson> jam: thanks
<vila> single point of access to control which stores are used so they can be shared,
<jam> mwhudson: of course, it leaves your password in bash history, kills babies, etc. :)
<mwhudson> jam: yeah yeay
<poolie> is this to say that bzr-svn wants to hook into the creation of some stacks?
<vila> yes
<mwhudson> jam: you can use authorization.conf too right?
<jam> mwhudson: You might look at authentication.conf, but I'm pretty sure it doesn't support passwords for ssh
<poolie> so one other possible way to do this would be for it to override Branch.get_config?
<jam> since we figure "you already have ssh/config to set up a key"
<jam> which is more secure anyway
<vila> otherwise migrating the branch options to the new config scheme will break the UUID default values for options
<mwhudson> jam: is there a chance that a user:pass in a url might end up in a traceback or other console output?
<mwhudson> jam: presumably that's fixable though
<jam> mwhudson: I *believe* we are good about omitting :pass from anything we log
<vila> poolie: yes, but that makes it harder to migrate the options
<vila> poolie: and also harder to control which stores are used
<jam> mwhudson: http://paste.ubuntu.com/688966/
<jam> "does not appear in base" means it doesn't show up in stuff like tracebacks
<mwhudson> jam: ah nice
<jam> we strip it from the URL, and then hide it around as necessary
<vila> poolie: s/harder/different/ if you prefer but the proposal is an incremental progress in *one* direction
<poolie> wull
<poolie> *well, it's adding some complexity
<vila> which one ?
<poolie> it's reasonable to ask why it's there
<vila> for who ?
<poolie> adding a registry rather than just having functions
<poolie> so the point of a registry is, in short, so that plugins can control how stacks are created for some particular purposes?
<vila> but you objected (rightly) that these functions are not good examples of how to build stacks and indeed they don't address the issues I mentioned above
<poolie> which issues?
<vila> taking command line overrides into account needs a central place, not requiring eveybody to modify these functions
<vila> "which issues?" : overriding by plugins, centralizing store access
<poolie> couldn't handling command line options be done by just saying there's a global stack, which most others build upon, that includes per-command options?
<vila> I never talked about per-command options,
<poolie> i meant per-process
<poolie> command line overides
<vila> can you elaborate about build upon >
<vila> can you elaborate about build upon ?
<vila> to me it means having helpers to create the appropriate list of (stores, section_matcher(context))
<poolie> basically just that branch_stack() should return stack(BranchStore(branch), LocationStore(), global_stack())
<vila> and one central place to ensure the command-line overrides always dominate
<poolie> then global_stack can include system-wide, per-user, and command-line parts
<vila> wrong
<vila> command-line overrides should come first
<poolie> ok, i see
<poolie> that's true
<poolie> how does a registry help with this?
<vila> or do you want stacks to be able to be build recursively ?
<vila> it provides this central point
<vila> place
<poolie> but how is it more central than the config module holding some functions?
<vila> (I think recursive stacks are neat, but introduce complexity for users as well as devs so I'm more against than for)
<vila> some functions all implementing the same rules ?
<vila> but, it's not *more* central, it's just *as* central
<vila> and again, it's just one way, there are others, this one just seem to be the easiest and fastest...
<_arch> Hi
<vila> poolie: what is this added complexity you're seeing there ?
<vila> even get_config() or get_config_stack() are still possible, they are just implemented by querying the registry,
<vila> how is that complex ?
<poolie> it's basically just one more level of indirection to go through the registry
<poolie> it's not enormously complex, i just don't think you're communicating why it's helpful
<poolie> it's not obvious to me how it's going to help with plugins
<poolie> i assume the point of having it is to enable things from plugins?
<poolie> perhaps one way to move this along would be for you to give some illustrative cases of what plugins want to do with this and how they would do it through the registry?
<_arch> I have a problem: During commit, I want to inject my new revision number to each modified file
<poolie> hi _arch, you want http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html
<_arch> I checked that out but I'm not sure if it helps. The $Revision-Id$ has a bunch of stuff I don't want apparently.
<vila> poolie: how will plugins implement command-line overrides ?
<poolie> vila i'd probably just do that in the core
<vila> poolie: do you want them to explicitly change their stack builder ?
<vila> poolie: but how will they get the feature from the core ?
<_arch> So I figured I'll try to write a quick start_commit hook myself which injects the revno to the modified files
<vila> poolie: how would you output the help associated with a stack ?
<_arch> however I seem to have absolutely no clue of where to begin :)
<vila> poolie: how would support the plugin specific configs with 'bzr config' ?
<poolie> vila, i'm interested in the answers but i'm also suggesting that if in future you explain some cases like this in the mp, it might be better understood
<vila> that doesn't match my understanding of small piece easy to propose :-/
<poolie> " but how will they get the feature from the core ?" - i'm not sure what you mean, but if you mean "how will they see values from the command line", i'd expect that all of the *_stack() functions will return a stack that looks at the command line
<vila> I'm not addressing rewriting 'bzr config' for now
<vila> poolie: indeed, that puts the responsibility on the plugin authors
<poolie> i'm not sure if there needs to be help for a stack or whether that needs to be exposed to the user as such
<vila> you should do this and this and don't forget this, instead of: register your stack
<poolie> i would not expect it needs any plugin changes
<vila> ...
<poolie> " doesn't match my understanding of small piece easy to propose "-- i think generally, saying "previously, you couldn't do X.  now, it works like so" is pretty helpful to establishing the change is worthwhile
<poolie> that can be either in the mp or in a bug
<vila> but we have no idea today that plugins implement config files, nor do we have any way to know they do
<poolie> _arch, are you saying the problem is that bzr-keywords just puts in too much text? like the revision id and you just want the number?
<_arch> yeah
<poolie> maybe then the easiest thing is to just add another option to  bzr-keywords?
<poolie> you should be able to just go off the existing code
<_arch> Hmm, true. I'll check that out, thanks
<poolie> if you fix it, please push up a branch so we can merge it
<poolie> ask here if you need any help
<poolie> vila, that might be true we don't know whether plugins are looking at config files but i don't see why it's actually a problem
<_arch> Right I'll check out the source and see if I can make something out of it.
<vila> poolie: no, I said *we* don't know that plugins use their own config files and/or if they introduce new features for our own config files
<poolie> ok
<poolie> is this a bug?
<vila> and if jelmer didn't mention that subversion.conf use [UUID] sections I would have break it by migrating the branch options
<vila> bug #832036
<ubot5> Launchpad bug 832036 in Bazaar "Needs a config stack registry" [High,In progress] https://launchpad.net/bugs/832036
<vila> we're running into circles
<poolie> yeah, but that's basically the same problem
<poolie> that bug does not describe an actual problem
<vila> ok, we don't have problems
<vila> better un-migrate the global options and forget about that
<poolie> is that sarcasm?
<vila> obviously I'm not able to explain the issues in a way we can agree upon
<poolie> :/
<poolie> sorry
<vila> no, it's just that I suck at this particular point and therefore cannot progress, so it's wasted time
<poolie> ok
<poolie> let's shelve this until it's clear it's solving a pressing problem for plugins
<poolie> does it block anything else?
<vila> https://bugs.launchpad.net/bzr/+bugs?field.tag=config i.e. 40 bugs, plus all the ones I failed to file
<poolie> i think 832036 is a good example of a bad bug, because it specifies a solution, not a problem
<poolie> are you saying this blocks all those bugs?
<poolie> i have some trouble believing it
<vila> oh, there are surely alternate ways to address them, someone just have to analyze them and find a relevant fix
<poolie> ok so of those bugs
<poolie> the one i care most about is 832042
<vila> is that sarcasm ?
<poolie> nup, it's true
<poolie> well, more precisely
<poolie> if these changes have a performance impact, i care about fixing it
<vila> yes they do have one and I've added -Econfig_stats to track progress
<poolie> istm an easy way to fix 832042 would be to just create the config stacks early on in the object they correspond to
<poolie>  the global-ish ones which have no obvious owner can go onto the library_state
<vila> you need a central place to share the stores (not mentioning how it interacts with library_state)
<poolie> hm
<poolie> i think you can either have them on library_state, or inherited from one object to another
<poolie> it seems pretty possible
<poolie> i'v closed 832036  and i pushed down some of the others
<vila> then we should also revert all stack related stuff or it will make it harder to address these bugs
<poolie> i don't see how that really follows
<poolie> i think the stacks are just fine
<vila> you don't want to address sharing both stores and config files don't you ? Nor maintain both get() and get_user_option() and get_xxx APIs right ?
<poolie> i don't really understand the question
<poolie> i do need to stop
<poolie> i'm sorry this is frustrating
<vila> I mean, I don't mind getting rid of this stuff if we can't agree upon, but in this case that's a non-sense to keep it because it means we have a fragmented API and this is definitely something that makes it harder to fix the remaining bugs
<poolie> if you can think more about actual "X doesn't work as it should" bugs rather than what you want to write, i think that will help communicate it
<vila> that's what the devnotes doc was about :-/
<vila> ha, I have some bugs mentioned with the corresponding issues in my uncommitted version
<poolie> hm, so
<poolie> i can see there's something in there about plugins wanting to add new files
<poolie> i think for a particular mp just pointing to configuration.txt is not enough, because the specific connection is not clear
<vila> see also the part about not being able to delete some options ?
<vila> or the already existing fragmentation in the API ?
<poolie> i really do not see how the registry would help with deprecating options
<vila> the stack registry ? unrelated,
<poolie> i think if you filed a bug saying "there is no way to gracefully deprecate an option" we can agree on whether that's true, whether it's important, and then on whether a particular mp is a decent way to solve it
<vila> but the option registry can be used to say one option deprecates another one (or vice versa)
<poolie> right
<poolie> so
<vila> far from the top of my TODO list
<_arch> poolie: have you used the keywords plugin? Am I supposed to add the keyword template (like, $Revision-Id$) to each of my files?
<poolie> _arch, i haven't used it recently, but yes, add it where you want the text to come out
<poolie> vila, ok, so, i'm -1 on the registry until the reason is clear
<poolie> i think it would overall be most excited about you doing bug 795321 or maybe bug 832042
<ubot5> Launchpad bug 795321 in Ubuntu Distributed Development "udd importer should make tea while launchpad is down" [High,In progress] https://launchpad.net/bugs/795321
<ubot5> Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042
<poolie> or bug 836782, which is just pushing #is perhaps
<ubot5> Launchpad bug 836782 in Ubuntu Distributed Development "bzr-builddeb requires dpkg-dev >= 1.15.7" [High,In progress] https://launchpad.net/bugs/836782
<poolie> or rebuilding it?
<_arch> poolie: and once the file is pushed the keyword is going to be replaced by whatever it's supposed to be? i.e, in place of $Revision-Id$, there's going to be the revid?
<poolie> i think it will be expanded within the keyword
<poolie> ok, good night all
<_arch> Right, there's something wrong then :)
<_arch> thanks
<Riddell> jelmer: how long does it take for a package to move from debian incoming to unstable?
<jelmer> Riddell: it happens several times a day (if it doesn't have to go through NEW)
<Riddell> hmm those bzr packages are still there (according to the incoming.d.o and packages.d.o websites)
<jelmer> Riddell: http://packages.debian.org/sid/bzr-explorer already has 1.2.1-1
<Riddell> you're right, http://packages.debian.org/search?keywords=bzr-explorer is slacking
<Riddell> or maybe it's my browser cache
<Riddell> weird
<Riddell> jelmer: I'll sync bzr-explorer and qbzr, and make the necessary changes to bzr to upload that
<jelmer> Riddell: I was about to do an upload of bzr to oneiric too
<Riddell> go ahead then
<Riddell> jelmer:
<jelmer> Riddell: thanks
<Riddell> is there a reason why printing text in builting.py is often done with self.outf.write() rather than note() ?
<vila> Riddell: the FIXME in trace.note are probably part of the answer
 * Riddell discovers bzr rocks
<Riddell> that'll keep our translators amused finding suitable localised equivalents :)
<jam> Riddell: self.outf.write goes to stdout and is in terminal encoding. note() I think goes to stderr and is officially UTF-8 encoded. Further note() also goes to .bzr.log
<Riddell> hmm, so use of note() in commands might break if you're not using a utf-8 language?
<Riddell> what is the "cannot import name info" message I get all the time?
<Riddell> oh it's a plugin at fault
<jelmer> Riddell: ~/.bzr.log is your friend :)
<jam> Riddell: .bzr.log and -Derror
<jam> mgz: ping
<mgz> pong-to-avoid-what-I-should-be-doing
<jam> mgz: I just upgraded bzr and did "bzr st" outside of a working tree
<jam> and got the giant-explosion of IndexError.
<mgz> traceback in the message you just put on the lp:~gz/bzr/root_drive_file_url_841322 mp implies the branch didn't land correctly
<mgz> File "C:\dev\bzr\bzr.dev\bzrlib\urlutils.py", line 391, in
<mgz>  _win32_extract_drive_letter
<mgz>     if len(path) < 3 or path[2] not in ':|' or path[3] != '/':
<mgz> IndexError: string index out of range
<mgz> that's still `< 3` not `< 4`
<mgz> double check the branch is at the right revision?
<jam> mgz: I'm at 6125.. Looks like update *didn't*
<jam> bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_on
<jam> ly setting on branch "C:/dev/bzr/bzr.dev/".
<jam> how did we manage that?
<jam> mgz: so it looks like my branch is out-of-date.
<jam> Sorry for the noise. I'll poke at the other stuff
<mgz> ugh, not sure, don't think I have that setting on so pull works here
<jam> mgz: looks like discrepancy between PQMs
<jam> specifically, 'bzr.dev's rev 6124 is now by "Patch Queue Manager" instead of "Canonical.com Patch Queue Manager"
<jam> so it seems we landed (and I pulled) 2 revisions on the old PQM, which are now gone from history in the new PQM
<jam> vila, poolie, jelmer: ^^ Did you see this?
<jam> http://paste.ubuntu.com/689201/
<jam> I'm a little concerned that we lost revisions, but I guess if a plain "bzr pull" works, then we shouldn't have.
<vila> jam: yes, mentioned a couple of days ago, occurred during the migration to the new pqm, was considered minor enough to deal with it
<vila> jam: you have append_revisions_only set locally ?
<vila> jam: pqm doesn't
<jam> vila: Yes, I have it set here
<vila> jam: again see log for discussions about why we considered not doing that
<jam> that way I don't screw stuff up locally
<jam> vila: irc log?
<vila> yup
<vila> around pqm migration, I raised the issue as soon as I discover it on bzr.dev
<jam> vila: so we did already merge them into the actual trunk. I was trying to look at the changes, and didn't specifically see it.
<vila> jam: yes, the first succesful submission based on the trunk pushed by the old pqm carried all the diffs
<jam> vila: I'm fine with the solution, I just wanted to make sure we didn't lose anything. so good enough.
<vila> jam: nothing has been lost bar the cleaner history
<jam> vila: yeah. no problem. I often start my day by running "bzr up" but not actually reading the output. So I didn't see that it wasn't updating.
<vila> jam: yeah, same reaction here, I even blew the whistle before checking, but I did not check very deeply given that this didn't seem necessary (I was lucky enough to do a 'bzr missing' at the right time)
<jam> I did 'bzr missing' but wasn't 100% sure it wasn't lying :)
<jam> mgz: so in the end, Yay for you! I don't get the traceback anymore. :)
<mgz> good good :)
<blackarchon> hi all!
<blackarchon> I just posted bug 850004, is it maybe already solved in trunk?
<ubot5> Launchpad bug 850004 in Bazaar "Problem with non-ASCII letters" [Undecided,New] https://launchpad.net/bugs/850004
<mgz> that sounds like a bug for me.
<blackarchon> 2.4.0 was entirely broken, and 2.4.1 seems also broken :(
<mgz> there's nothing obviously wrong from your log or traceback
<mgz> does S:/v5_x/projects/10074_YYY-LÃ¼ftersteuerung/.bzr/repository/pack-names actually exist?
<mgz> and if not, which is the first parent directory that does?
<blackarchon> yes, it exists
<blackarchon> well the letter Ã¼ is (according to the log) sometimes coded in a wrong way, this may propably be the reason for this error
<mgz> it's right in all the bits in that bug, and the error isn't related to non-ascii characters, so I think that may be a red herring
<mgz> blackarchon: paste me the output of `dir S:/v5_x/projects/10074_YYY-LÃ¼ftersteuerung/.bzr/repository/pack-names` run in the cmd prompt please?
<mgz> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<blackarchon> mgz: http://paste.ubuntu.com/689235/
<mgz> okay, fun. I'll try and repo here.
<blackarchon> note I have to use \ instead of /
<mgz> one last thing for you to try, run the command bzr-explorer is passing, but at the command line
<blackarchon> I should run "bzr explorer S:/v5_x/projects/10074_YYY-LÃ¼ftersteuerung" on the command line?
<Noldorin> hi jelmer
<jelmer> hi Noldorin
<Noldorin> any progress on the issue? :-)
<mgz> blackarchon: so, `bzr commit -m "Vor 2. Wegschicken zu Hr. xxx" YYY-LÃ¼ftersteuerung.sch`
<jelmer> Noldorin: sorry, been distracted with other things so far
<Noldorin> jelmer, no prob
<jelmer> it's high on my todo list though
<Noldorin> jelmer, just thought i'd let you know i'm here to assist you when ready :-)
<Noldorin> sure
<blackarchon> mgz: If i run "bzr explorer S:/v5_x/projects/10074_YYY-LÃ¼ftersteuerung"
<blackarchon> I get an error
<blackarchon> unable to change to <path> - closing page
<mgz> paste me that, then try the command I suggested?
<blackarchon> mgz: sorry, my fault - the command was fine
<blackarchon> just had a typo
<mgz> I hope you're not having to retype LÃ¼ftersteuerung each time :)
<blackarchon> mgz: http://paste.ubuntu.com/689241/
<mgz> interesting. do `bzr add YYY-LÃ¼ftersteuerung.sch` too?
<blackarchon> why should adding a file help if it is already added?
<mgz> it's not clear what the state of the branch is, it might be there really isn't anything to do.
<mgz> if you were committing in bzr-explorer, and it gave you an error, I was presuming you had outstanding changes that still needed to be comitted.
<blackarchon> ok - well, the problem is that committing seems to work. at the moment, I have 6 revisions in this standalone tree. But I also get these errors while committing.
<mgz> that's wrong I guess, either you already did that or reverted them, or bzr left things in a funny state.
<mgz> okay.
<blackarchon> so it seems to do something right, but not all.
<mgz> can you make a new change of some kind to that file, try the commit from the command line (you can always uncommit after trying) and see if you get the same error?
<blackarchon> ok
<mgz> it looks like this may just be an problem in the explorer commit reporting code.
<blackarchon> this went fine without an error on the command line
<mgz> great, thanks for testing all of that, will help me try and reproduce it locally.
<blackarchon> but there seems to remain a little discrepancy in umlaut handling: http://paste.ubuntu.com/689250/
<blackarchon> is this really not a problem?
<mgz> yes, that does look funny but is actually correct.
<blackarchon> ok :)
<blackarchon> and thanks for your time! :)
<mgz> some parts of the code use a unicode string where Ã¼ is u'\xfc' and some use a utf-8 byte string where it's '\xc3\xbc'
<blackarchon> well this seems like a problematic approach
<mgz> it is, but I think your bug is a different problem.
<blackarchon> ok
<davi_> jelmer, hi, can you fix bzr-git trunk to work with dulwich 0.8.0? current trunk attempts to import HttpGitClient which i think is not implemented in dulwich 0.8
<Riddell> vila: is https://code.launchpad.net/~jr/bzr/i18n-unoverride-no-i18n-tests/+merge/75181 ok now?
<vila> Riddell: didn't I approve it already ?
<vila> oh no,
<vila> Riddell: gha the diff makes no sense (not enough context), let me review that locally
<vila> Riddell: ok ,so, this is better. One thing that comes to mind reading the patch though is that there are two idioms to test i18n: either you allow installing one or you install one without asking
<systemclient> how can I export a repo with multiple branches to git?
<vila> Riddell: and I don't really understand what the two TestInstall tests do. Are they just smoke tests ?
<vila> Riddell: shouldn't test_custom_languages fails if there is no translations avaiable for nl:fy ?
<Riddell> vila: I don't know, I didn't write those tests
<Riddell> vila: yes the two ways to test i18n are documented with this merge proposal
<vila> Riddell: oh, so sorry, they are indeed documented
<vila> Riddell: alright, so, TestTranslate alreday calls self.overrideAttr(i18n, '_translations', ZzzTranslations()), the tests don't need to do it again. I know, you didn't write them either, but better fix them if they need to serve as examples
<Riddell> vila: how about adding this to the end? self.assertTrue(isinstance(i18n._translations, i18n._gettext.GNUTranslations) ?
<vila> Riddell: for the TestInstall ones ?
<Riddell> yes
<vila> sounds good !
<mgz> Riddell: can use assertIsInstance there.
<vila> Riddell: does that mean that i18n.install('nl:fy') succeeds even if the translations are not available ?
<vila> Riddell: if that's true, yeah, that will make the test intent clearer (and mgz remark applies too ;)
<Riddell> I'm not sure, investigating
<Riddell> vila: it'll produce a NullTranslation always, only if the language is there will is make a GNUTranslation
<Riddell> so I've pushed a change to test for NullTranslation
<vila> Riddell: ha ha, won't that break if that translation *is* available ? Or should you have a test for a known always available translation and one for a known never available one ?
<Riddell> no because GNUTranslations inherits from NullTranslations
<vila> ok, but mgz mentioned assertIsInstance (provided by testtools maybe ?)
<vila> Riddell: and TestTranslate alreday calls self.overrideAttr(i18n, '_translations', ZzzTranslations()), the tests don't need to do it again. I know, you didn't write them either, but better fix them if they need to serve as examples
<vila> bah copying my tyops now :-/
<vila> Riddell: assertIsInstance is provided by TestCase (not testtools)
<vila> Riddell: and will give a better error message than assertTrue(isinstance(...))
<Riddell> vila: pushed
<Noldorin> jelmer, had LP support for collocated branches arrived yet?
<Noldorin> i knwo 2.5b1 is being released tomorrow
<Noldorin> which has support
<Noldorin> jelmer, let me know if you want me to send you my powershell script...
<Noldorin> for testing the issue
<lamalex> hey bzr folks- need some help
<lamalex> (i'm tying my question- don't hassle me about asking to ask)
<lamalex> i've got a branch which i want to merge into my trunk, but i want to squash the history of the old branch, as to basically not have it
<fullermd> Aw, man, you take all the fun out of it...
<lamalex> :)
<lamalex> there is some private info in the history i don't want exposed to the world
<Noldorin> lamalex, a normal merge does that
<Noldorin> just make sure it doesn't pull
<fullermd> You could merge, revert --forget-merges to dump the intermediate revs, then commit.
<lamalex> Noldorin, but can't i go and do a bzr log -n0 and see the history of the branch?
<lamalex> fullermd, ah ha, that sounds like a sane way
<lamalex> i was trying to do a bzr diff  > and then patch it
<fullermd> Oh no.  What will taht do to my reputation?
<lamalex> but there are all kinds of renamed files and whatnot
<lamalex> it was messy
<Noldorin> lamalex, oh, i forgot about that
<Noldorin> lamalex, fullermd has a decent solution :-)
<lamalex> indeed
<lamalex> oh my god that worked perfectly
<lamalex> fullermd, you're a genius
<Noldorin> bzr send --no-bundle may also work
<Noldorin> i'm not sure though
<lamalex> fullermd, do you work for canonical btw?
 * fullermd buffs his nails on his shirt and looks haughtily down on everyone.
<fullermd> Oh, no.  They'd make me run Linux and code in Python.  Who wants that?
<lamalex> ha
<lamalex> zing
<lamalex> isn't it odd, some people /like/ coding in python
 * lamalex shudders
<Noldorin> many, in fact :-P
<fullermd> Stockholm syndrome is a terrible thing   :(
<Noldorin> some people like coding in obj-c
<Noldorin> which is even worse
<fullermd> It could be worse though.  I know a guy who LIKES COBOL.
<fullermd> He has such scornful pity for the poor fools who don't like it, too.  It's incredible to watch.
<vila> fullermd: you imply he's still alive ?
<fullermd> Well, I dunno if you'd classify COBOL programmers as "alive" in any meaningful sense...
<vila> well, zombies walk but they don't TALK
 * fullermd _wishes_ he didn't talk...
<vila> on the other hand, I heard you could do subroutines and even pass parameters in COBOL these days...
<fullermd> He's actually so far off in his own world, it's impossible to argue with him about anything.
<vila> and did they fix the compiler saying: 'You miss a period here, it's a fatal error, but I will assume there is one so I can show your all your other errors' ?
<fullermd> He can actually say, with a straight face, that COBOL is totally relevant because it's kept up with the times, since it has all the modern bells and whistles like (I'm not making this up) while and for loops.
<vila> that also reminds me of this guy writing perl scripts to generate visual basic that inject data in excel documents...
<vila> fortunately I only *heard* about him
<fullermd> I use a perl script to generate my window manager config on the fly...
<vila> fullermd: pff, you miss the vb part, too easy, doesn't count
<fullermd> At one time I had perl in my shell rc file too.  Only has sed and awk now, though.
<fullermd> (at this point of course we x-ref the classic Know Your Sysadmin   :p)
<vila> :)
<Noldorin> hi jelmer
<poolie> hi
<GRiD> hi poolie
<GRiD> are you up early? :)
<poolie> i am
<poolie> how are you?
<GRiD> good thanks. saw you had the flu, over i hope?
<poolie> yes, fine now
<GRiD> cool. we're just about to get into that season here, not looking forward to that...
<abentley> poolie: Didja know Martin Poole is a character on a Canadian TV show? http://www.imdb.com/character/ch0184436/
<poolie> i did not
<abentley> poolie: it was rather bizarre watching for me.
<poolie> statik, hi?
<statik> hi poolie
<Noldorin> jelmer, hey
<jelmer> Noldorin: hi
<Noldorin> how's it going..?
<jelmer> Noldorin: it's alright
<jelmer> how are you?
<Noldorin> good good
<jelmer> g'morning poolie, statik
<Noldorin> haven't had chance to do much more investigating
<Noldorin> jelmer, how about you?
<jelmer> Noldorin: been busy with other things all day too
<jelmer> I'm going to have a look now, but might fall asleep before I have a chance to...
<poolie> hi jelmer
<poolie> well, it's a great day to bisect intermittent kernel bugs
<poolie> but i think i will anyhow
<jelmer> poolie: check out revision, recompile kernel, reboot, repeat?
<poolie> yeah
<poolie> i'm going to start just with the various sub-versions of packaged kernels
<poolie> for bug 833479 fwiw
<ubot5> Launchpad bug 833479 in linux (Ubuntu) "e1000e connection drops out" [High,Incomplete] https://launchpad.net/bugs/833479
<poolie> jelmer, can i just confirm you started the process for 2.4.1 into oneiric?
<jelmer> poolie: yep - the package built fine, it's just waiting to be uploaded now
<poolie> great
<poolie> that was really pretty smooth
<Noldorin> jelmer, ok sounds good :-)
<Noldorin> jelmer, looking forward to the 2.5b1 release tomorrow too
<Noldorin> jelmer, something tells me the fix is going to be very small....just difficult to figure out
<jelmer> Noldorin: I think the fix will be trivial once we have a test that reproduces the issue
<Noldorin> jelmer, you were away earlier today, but i offered to send you my powershell script...
<Noldorin> if you like
<Noldorin> but you know how to reproduce it anyway i think
<jelmer> Noldorin: thanks, but I don't have powershell here (Linux)
<jelmer> unless your script reproduces the issue in less revisions that the original branch?
<Noldorin> jelmer, afriad not. everything happens at r47...
<jelmer> it should still happen with the contents of r46 and the problematic changes
<Noldorin> that's what i mean yeah
<Noldorin> my script shows that
<Noldorin> we discussed it yesterday :-)
<jelmer> Noldorin: I mean, if you commit the entire set of contents of r46 in a new branch as r1 and then make the same problematic changes that triggered the bug in your r47
<jelmer> anyway, time for some sleep. g'night
<poolie> night
<poolie> GRiD, hi?
<GRiD> hi
#bzr 2011-09-15
<thumper> :(
<thumper> not for the first time have I gone bzr add in an ignored directory
<thumper> and it added a whole pile of intermediate files
<thumper> can I revert this easily?
<thumper> poolie: ? ^^
<thumper> found it
<thumper> bzr remove build
<thumper> that backs out my problems
<poolie> hi thumper
<poolie> bzr rm --keep
<thumper> poolie: I hadn't committed the add
<thumper> will bzr rm --keep remove all added files? new ones?
<poolie> it will remove whatever you ask it to
<poolie> 'bzr -0 added|xargs -0 bzr rm --keep' will likely do the exact right thing
<spiv> (IIRC, strictly speaking --keep is unnecessary for files listed in 'bzr added': it defaults to never deleting files you might not have another copy of.  --keep is probably a good habit though!)
<poolie> riht
<poolie> *right
<mwhudson> jelmer: hello
<jimis> Hi, I'm working on a local checkout of a --no-trees branch of big project. But now my version is pretty old. What's the proper way to update to latest revisions from remote repo?
<lifeless> if its a checkout, bzr update
<lifeless> if the branch is actually just a regular clone and the checkout is because you're using switch locally, then bz rpull
<lifeless> I would guess bzr pull is what you want
<jimis> thanks lifeless, I've already done bzr pull and it updated my unmodified trunk branch
<lifeless> great
<jimis> but should I use merge to also update some feature branches that have diverged from trunk?
<lifeless> perhaps you mean 'I have a branch that I'm working in,m how do I incorporate changes made in trunk?'
<lifeless> if so, then 'bzr merge + bzr commit'.
<jimis> then the merge will show as a separate commit, *after* my local changes?
<jimis> lifeless: indeed "bzr merge" created some conflicts, as expected
<jimis> bzr status also says: pending merge tips:...
<jimis> so I suppose the commit will be handled specially and won't show in history?
<lifeless> no, it will, this is normal.
<lifeless> after all your code changes in it :)
<jimis> ok to show *my* commits, but not the upstream commits as newer than mine :-p
<jimis> anyway I'll do it and see
<jimis> thanks
<lifeless> the upstream commits won't show unless you supply -n0
<lifeless> the *merge* of upstream will show.
<jimis> and while editing out the conflicts, how can I view the original version of trunk or my own tree? I'm asking since this is a no-trees branch, so I can't just find them in the filesystem
<lifeless> .BASE and .OTHER files
<lifeless> in your tree
<jimis> They always confuse them... So .BASE is my feature branch, .OTHER is the trunk I'm merging from, and .THIS is what?
<jimis> s/They/I/
<lifeless> .BASE is the common ancestor
<lifeless> .THIS is your feature branch
<jimis> yeah I just noticed that .THIS had my changes :-)
<jimis> thanks, I now understand
<jimis> How can I do a checkout from a server where I only have ssh access? For example if the branch directory is "host:stuff/project"
<jimis> If the server has commandline bzr, I can use bzr+ssh protocol?
<poolie> jimis, bzr branch bzr+ssh://host/~/stuff/project
<poolie> yes
<jimis> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<poolie> there's probably another error higher up
<jimis> I'm checking client/server logs, but can't see anything useful
<jimis> server logs almost nothing, client logs unexpected end of message
<jimis> poolie: no other error, even though I run bzr co -v
<poolie> how about 'ssh -v host bzr serve --inet'
<jimis> I'll update the server-side bzr first, just to be sure... it's running beta-5
<jimis> poolie: I should run bzr serve on the server? Is it necessary, or just for logging purposes?
<jimis> poolie: never mind I think I got it
<vila> hi all !
<jimis> hi
<jimis> poolie: even if bzr is on my path, it probably doesn't find the executable
<jimis> maybe it doesn't source my .bash_profile
<spiv> No, SSH doesn't.
<spiv> (Not when running a command rather than making an interactive shell)
<spiv> You can explicitly set a config value like bzr_ssh_remote_path in your client to workaround that
<spiv> (A good place would be in your ~/.bazaar/locations.conf in a section for just that host)
<vila> bradm: any news on that import issue ?
<vila> spiv: _o/
<jimis> spiv: It would be useful if it run bzr in a subshell, I have used BZR_REMOTE_PATH to find the executable, but now I get an error about missing bzrlib
<jimis> it's probably the same for my PYTHONPATH
<poolie> i think you can set this in some kind of ssh configuration
<jimis> I'll check, thanks
<jimis> can't find relevant ssh option
<jimis> Is there a way to set REMOTE_PYTHONPATH for bzr too?
<jimis> hmmm or I could just use sftp and get over with it :-)
<poolie> see SendEnv
<poolie> in ssh_config
<lifeless> jimis: or you can run from the source tree, where bzr will find its library
<lifeless> jimis: or you can put the PYTHONPATH setting in your .bashrc
<jimis> lifeless: bashrc? But the problem is ssh doesn't execute bzr under a shell
<bradm> vila: nope, got overrun with other work :(  I had a quick chat to lamont tho, he knows another buildd is having the issues
<vila> bradm: k
<spiv> Or you can use a separate SSH key and set the remote's authorized_keys for that key to run a script like bzr_ssh_path_limiter or bzr_access
<jimis> I've done a local install in my ~ since I have no admin privileges, hence all the trouble
<fullermd> That's not really true...  ssh always calls your shell.
<fullermd> bash just loads (or doesn't load) various files depending on whether it's being started as an interactive shell or not.
<jimis> allright, will check SendEnv first, although I think it won't do, because I'll have to change local environment too
<vila> jimis: I did the same in an old setup with bzrssh being a wrapper calling "python /Users/vila/bin/bzr $*"
<jimis> fullermd: from ssh manual: "If command is specified, it is executed on the remote host instead of a login shell."
<spiv> jimis: that doesn't actually contradict fullermd :)
<jimis> thanks vila, that will solve it for sure. And within the wrapper I'll be able to set PYTHONPATH too.
<spiv> It could just mean running "$SHELL -c cmd..." vs "$SHELL -l"
<vila> well, the bzr script manage to have its associated bzrlib accessible via sys.path IIRC
<lifeless> jimis: it does actually
<lifeless> jimis: it just does not execute bash_profile
<lifeless> because it doesn't create a login shell
<vila> jimis: you also need a dedicated section in locations.conf to set bzr_remote_path = /Users/vila/bin/bzrssh
<fullermd> You can easily demonstrate it by setting your shell to e.g. /usr/bin/false and trying to ssh $SERVER $CMD.
<fullermd> (don't close your existing session before trying though   :p)
 * lifeless would put it in .bashrc - simplest.
<lifeless> its *why* there are two two distinct files
<vila> .bashrc is still executed IIRC but not the profile nor the login one, 'ssh host echo $PATH' should help you debug these
<vila> jimis: bah, quoting $PATH to avoid local expansion of course
<jimis> yeap, you are right, "ssh host env" shows that the SHELL variable is set to /bin/bash, makes sense now that I see it :-p
<jam> morning all
<jam> mwhudson: I just remembered that bzr+ssh://user:pass@host may not do what you want. I think if the ssh implementation is Openssh then we can't pass it a password. So you'll also need to set BZR_SSH=paramiko
<jimis> wow, bzr has advanced a lot speedwise... lightweight checkout via *sftp* finished in 2 min, I didn't expect that :-)
<jimis> I'm curious now to try the smart protocol :-)
<jimis> that was for the gcc project, so 2 min is a short time, I should have mentioned that :-)
<spiv> Hopefully jam can finish the 'bzr branch --stacked' from HPSS patch soon, which I think would be nice for working on gcc.
<jam> hey spiv, good to see you around again
<spiv> I'm only slightly around :)
<jam> spiv: better than not around at all
<spiv> True!
<poolie> vila, hi?
<vila> poolie: hey
<vila> poolie: RT #47638 has been escalated to CharlieS but I couldn't get in touch with him (bad TZ overlap), can you see to it ?
<vila> poolie: the reason for escalation is worries about impacts on the rest of the system
<poolie> hi there
<poolie> vila, i hope to get around to making it report success, some time
<poolie> aside from being useful it would show a much better attitude
<jam> poolie: make what report success?
<poolie> udd
<poolie> at the moment they can only be noticed in the web page by their absence
<poolie> afaik
<jam> poolie: ah right. Also, being able to open the page for the package and have it say "last successfully imported" rather than having the page just disappear would be nice.
<jam> I was thinking about bug #795025. It looks pretty easy to do now that I have the timeout stuff working.
<ubot5> Launchpad bug 795025 in Bazaar "no way to gracefully disconnect clients and shut down the bzr server" [High,In progress] https://launchpad.net/bugs/795025
<jam> basically, just adding a trigger (something like SIGHUP) that will set self.finished
<jam> and then check that right after the timeout logic.
<jam> so SIGHUP should trigger EINTR for select.select(), which can then say "oh, you want me to stop now"
<jam> And if they are in the middle of processing, it will be set and detected once the current command ends.
<jam> Anyone have a preference for what the signal should be?
<poolie> jam, that's awesome, i'm otp with vila atm
<jam> poolie: sounds good. I changed my mind to SIGTERM, but thanks for the feedback.
<jam> mgz: question about test case logging. I believe you last said you didn't like test cases uses self.get_log() does that still hold true?
<ccxCZ> hi guys, I've recently ran into project that uses lot of patch magic in the workflow. How would you sanitize this? http://list.linux-vserver.org/archive?mss:5375:201109:dnnehlgageenpcekjlmh I have no experience with the loom plugin but I think it's the appropriate tool.
<poolie> lifeless, still here? can you help him?
<jelmer> vila: hi?
<vila> jelmer: otp with poolie
<jelmer> ah
<jam> ccxCZ: it does sound like looms would be appropriate
<jam> top level '0' would be to have the base of your loom be upstream vanilla kernel
<jam> 'unpacking' becomes switching to it, and pulling the latest
<jam> 1. => becomes 'bzr up-thread' which should apply the changes in that thread merging the upstream vanilla updates.
<jam> At that point, you'll probably have some conflicts to resolve, which aren't mentioned in the workflow
<jam> After 'bzr commit' then to generate a new diff you would do "bzr diff -rthread:" (IIRC)
<jam> that would be 1.1
<jam> 2. becomes 'bzr up-thread' again, where the next thread has the grsec changes
<jam> again, generating a diff is "bzr diff -r thread:" after you've resolved any issues
<ccxCZ> thanks a lot, I'm bit baffled by loom's terminology
<jam> if you need to consult history, "bzr log/qlog" should be useful
<jam> 4. => bzr up-thread to Rik Bobbaers
<jam> 5. compute the full diff => bzr diff -r thread:upstream
<jam> and bzr diff -r thread:vserver I think
<jam> for 5.1
<ccxCZ> manually resolving all conflicts again and again seemed silly to me
<lifeless> poolie: who, ?
<poolie> ccxCZ, but i think jam got it
<mgz> jam: what get_log does has changed completely now
<jam> ccxCZ: you may still encounter bits of that, but it should at least be better.
<jam> mgz: sure ,but if I wanted to add a test that confirms something is being logged, would you go "ew" or would it be ok?
<mgz> I think the obvious way of doing it would be fine.
<jam> vila: let me know when you're done with the phone stuff. I had a thought about config that would at least make *me* happier about how it interacts with testing.
<ccxCZ> the vserver thread is currently provided as discrete patches to specific kernel releases. any idea how to convert that to contiguous loom thread?
<mgz> hm, bug 850004 is network share related, not sure where to go from there
<ubot5> Launchpad bug 850004 in Bazaar "NoSuchFile on .bzr/repository/pack-names after committing in bzr explorer" [Undecided,Incomplete] https://launchpad.net/bugs/850004
<jam> ccxCZ: start at upstream with the oldest vanilla that the oldest vserver thread applies to
<jam> create upstream
<jam> create vserver thread
<jam> apply first patch
<jam> switch down to upstream
<jam> update to 'version for next vserver thread'
<jam> bzr up-thread
<jam> bzr revert -r thread:; apply the next patch; bzr commit
<jam> so the global loop is
<jam> bzr down-thread; bzr pull -r NEXT_VSERVER_VANILLA_BASE; bzr up-thread; bzr revert -r thread:; patch ...; bzr commit
<ccxCZ> neat, I guess I'll try to buildbotize most of the process
<jam> ccxCZ: You'll also want to "bzr record" somewhere in there. It can be considered "bzr commit" to record the current tip of each thread. You need to do it before you 'bzr push' the loom somewhere else.
<ccxCZ> okay
<jam> (bzr commit snapshots the state of the current working tree, 'bzr record' snapshots the state of the threads)
<ccxCZ> makes sense
<vila> jam: shoot !
<vila> jam: I tried your branch on natty => hangs, with --parallel => hang, on OSX (to have the *other* socket implementation ;) => hang
<vila> jelmer: about bug https://bugs.launchpad.net/udd/+bug/836782
<ubot5> Ubuntu bug 836782 in Ubuntu Distributed Development "bzr-builddeb requires dpkg-dev >= 1.15.7" [High,In progress]
<vila> well jelmer, maxb, jam, poolie, Riddell, whoever is involved with monitoring the package importer
<maxb> ?
<vila> poolie put a recent dpkg-mergchangelogs in the scripts/ directory and I've enable the merge hook again in builddeb,
<vila> so far, many imports have succeeded so I'm reasonably confident it works
<vila> but if you see weird changelogs issues, please tell me
 * jelmer nods
<vila> maxb: hi :)
<ccxCZ> I wonder how long will branching linux kernel take :]
<blackarchon> mgz: I'm here if you need further data regarding 850004
<mgz> your last post was really helpful, but I'm not sure how to debug the issue
<blackarchon> maybe a tool like 'Process monitor' from sysinternals may help, because it is able to show all activities of a process (bzr.exe)
<lifeless> mgz: perhaps a crufty server
<lifeless> blackarchon: we had a case once where a windows cluster server filesystem took several *seconds* to show in reads the impact of writes *from the same client*.
<lifeless> bah
<lifeless> mgz: ^
<mgz> ow. there's not much that can be done to mitigate that kind of thing.
<blackarchon> ok, how can I verify that this is really the reason?
<jam> vila: the test suite as a whole hangs, or something specific hangs? I would guess something like run_bzr_subprocess is waiting the 5-min for default timeout, and we aren't cleaning up our connections properly on the client side to tell it that no, you can hang up now.
<vila> in one case *all* 8 parallel processes hung
<jam> as for the config stuff... indirecting through files that have to be read for every test case seems particularly bad. Would there be a way to inject an in-memory-already-decoded Config object for the test suite?
<jam> vila: that just depends on how the tests get farmed out. But if you know what test is hanging, i'm happy to investigate.
<mgz> blackarchon: that might be tricky, but a workaround for problems with network filesystems is to use some other protocol to access that box
<vila> jam: see my comments on review
<jam> vila: the commented out ignored_exceptions was just a bogus debugging thing
<vila> jam: that's premature optimization :) But yes, that would be trivial once the stores are shared.
<jam> I certainly didn't plan on including it
<jam> vila: current experience shows that adding a config for every test case slows it down significantly, thus not really premature
<vila> jam: all TestCaseWithTransport *have* to check for bazaar.conf and locations.conf *today*
<lifeless> blackarchon: it may not be; I was noting that its a problem we've seen before, and something that ruling out would be good
<jam> vila: but we leave them empty, and thus don't have anything to do
<lifeless> blackarchon: manual testing with a little dedicated python script might be a good way to rule it out, for instance.
<vila> why would that change ?
<jam> vila: For example, the default timeout for client is ridiculous during the test suite, this is one case where production values are very different from test suite values
<jam> I'd like to avoid overrideAttr hacks
<jam> in production, the value will always be propagated from above (ultimately read in a config)
<jam> I don't really want that overhead in every test case.
<jam> You *could* do that for specific test cases where you know you'll be exercising the code, but then a bad test ends up taking 5min to timeout
<vila> there are at least 3 ways to address that:
<vila> 1) chose a default value appropriate for tests and be explicit for production,
<vila> 2) support command-line overrides for selftest (i.e. provide a value for the option so the config files are not queried at all) (not supported yet)
<vila> 3) inject config stores in each test (not supported yet)
<vila> 2 and 3 have no associated bugs AFAIK
<jam> vila: btw, consider the changes to test_server.py to be experimental and reverted (I just committed the reversion)
<jam> I was trying to debug the never timing out thing
<jam> Right now, I'm trying to work out the config stuff, while I was waiting for feedback on the rest.
<jam> I'm currently on Windows to fix up things on that side, but hopefully I'll get back to natty soon to work out if something is breaking.
<jam> vila: as for "trace.note()" we *already* print unhandled exceptions to stderr
<jam> I'm actually *reducing* the amount of stuff that goes out that way
<jam> but I didn't want to reduce it to 0.
<jam> vila: I'm actually only encountering weird things in the select.select() because of how we implemented SmartTCPServer_for_testing having it close its own sockets, etc. If we just closed the clients, it would have been happy without whack-a-mole.
<jam> which again means that testing is very little like production for this stuff
<jam> vila: I do apologize for the noise on test_server.py, I didn't intend for that part to get reviewed.
<vila> jam: I just mentioned the smart server comment, its scope is unclear to me so your usage is too
<vila> hey, no problem with that, I mentioned the hangs as in this area I found it excessively frustrating to see success while testing only to have to start again while broadening the tests
<vila> It occurred a lot and while I was fiddling with one part I didn't realize the implications (and windows was yet another different beast), so I thought it was better to warn you early
<vila> jam: but overall (and related to moles), I think your initial idea is worth trying harder (a simple select) adding more stuff around that sounds like working around timing issues, and down this path ... madness because you will never be sure you nail it down correctly or by luck
<jam> vila: yeah, thanks for the heads up. Can you try again with rev 6152
<jam> vila: I'll probably poke again. It took a while to figure out what was actually going on. And the fact that we suppress errors at various levels meant that I wasn't *seeing* EBADF propelry.
<jam> properly.
<jam> it would timeout, but then actually go to read, and I didn't know whether the read
<jam> was then returning ''
<jam> indicating the client was closed
<vila> yup, nigtmares that
<jam> when it was actually raising EBADF
<jam> which osutils.read_from_socket suppresses
<vila> did you read the select man page ?
<jam> and turns into ''
<jam> vila: I have, I didn't see anything about closing the descriptors after select has started.
<vila> they mention a race and a weird behaviour you may be interested in
<vila> 12 failures so far, but nohang
<vila> AttributeError: 'module' object has no attribute 'config' :-}
<jam> vila: the race I see here: http://linux.die.net/man/2/select
<jam> is talking about SIGNALs
<vila> There may be other circumstances in which a file descriptor is spuriously reported as ready.
<jam> vila: can you give a quick traceback?
<jam> sounds like "from bzrlib import config" is failing
<vila> it's in lazt_import
<jam> vila: yeah, because we spawn a subprocess, and I'm using config.option_registry.get('serve.client_timeout').default
<jam> to avoid repeating the default timeout
<vila> http://paste.ubuntu.com/689919/
<jam> which is some of the... how can we do this in a way that doesn't make me cry
<vila> start by using default values suitable for tests (funnily enough I *just* encounter the exact same issue (but I don't have a config there ;))
<jam> vila: that specific failure is just a bug
<jam> i accidentaly did a lazy import from "bzrlib.transport import (config)" rather than "from bzrlib import (config)"
<jam> vila: I *really* don't prefer to write test code in production code.
<jam> so writing test-applicable values is ~ the same thing.
<jam> I can do it if we must.
<jam> Anyway, I'm almost at the point that the timeout gets propagated appropriately
<jam> which might let me set the timeout in SmartTCPServer_for_testing
<jam> which would be appropriate *testing* code.
<vila> test code in production is no-go, I was proposing a temp work around
<jam> vila: interesting thing, there is no 'config.float_from_store' vs "int_from_store"
<vila> please file a bug ;)
<jam> vila: I'm likely to just implement it for this test case
<vila> stop listening to me, you're trying too hard ;)
<jam> vila: are there any direct tests of SmartTCPServer_for_testing ?
<vila> gee, can't say off hand
<jam> there are a lot of things that use it
<jam> but I don't see a "TestSmartTCPServer_for_testing", etc.
<jam> and bzrlib/tests/test_server.py doesn't have any actual test cases in it
<jam> ah, a test_test_server
<vila> isn't there a test_test_server ?
<jam> yeah, but it doesn't have TestSmartTCPServer_for_testing
<jam> but I'll add it there
<vila> quizz: how long takes the package importer to queue (and process) all packages ?
<vila> on average that is, not from scratch
<vila> maxb: any issue with 2.4.1 ? I just noticed the stable PPA still propose 2.4.0
<jam> vila: https://code.launchpad.net/~jameinel/bzr/drop-idle-connections-824797/+merge/75348 is ready for re-review, I believe. There are 2 blackbox tests that I need to write on Linux, but otherwise I think I'm happy.
<jam> rebooting now
<blackarchon> mgz: I updated bug 850004
<ubot5> Launchpad bug 850004 in Bazaar "NoSuchFile on .bzr/repository/pack-names after committing in bzr explorer" [Undecided,Incomplete] https://launchpad.net/bugs/850004
<jam> vila: ok, bunch of failing blackbox tests on Linux. Looks like I didn't hook up the PipeStreamMedium correctly
<jam> however, there is another bug
<jam> with config
<jam> that i'm hoping you might shed some light on
<jam> ah, nevermind
<jam> typo (server.* vs serve.*)
<vila> having mouse trouble here and freezing 2.5b1 too
<vila> dang, not mouse, focus issues... argh, gimme my editor back !
<mgz> blackarchon: that's great. can you also confirm that 2.4.1 *does* work if there are no umlauts involved?
<blackarchon> mgz: I will test it!
<blackarchon> ok, the same error happens also without umlauts and 2.4.1
<mgz> that's what I thought... still no luck doing similar things here
<mgz> how much more can you remove and still get the error? try using `bzr qcommit` directly, then `bzr commit`
<mgz> I want to narrow down project where the regression happened so we can try to find the specific revision.
<blackarchon> ah, I found something interesting
<blackarchon> if I do 'bzr init', 'bzr add .' and then 'bzr qcommit -m "First"', there is no error
<blackarchon> but if I use Bazaar Explorer, the errors return
<mgz> so, that makes it look like the LockContention is caused by explorer and qcommit both trying to get access, and that error then causes the later one
<mgz> this could still just be a laggy network filesystem like lifeless said earlier, but something changed at least to expose the problem for you in 2.4
<blackarchon> yes, seems so
<jam> mgz, blackarchon: Note that I think in 2.4 and maybe 2.3? We started doing the right thing and locking config files before we update them.
<jam> Otherwise there was a race in the past
<jam> where 1 bzr could update X, and the other could update Y and silently discard X
<jam> anyway, I'm off for tonight. Good luck
<mgz> this is on dirstate, which annoyingly I can't reproduce locally, I just get a hang
<throughnothing> I accidentally removed a file with bzr remove, and then I added it back with bzr add, but the diff still shows the whole file being removed then re-added, how can I 'undo' the remove (I haven't committed yet)
<mgz> `bzr revert`
<blackarchon> 'bzr revert filename' should do the trick
<mgz> and optionally the filename
<blackarchon> :)
<throughnothing> perfect, that worked
<throughnothing> thanks!
<Noldorin> hey jelmer
<jelmer> hola
<Noldorin> jelmer, i see bzr 2.5b1 is out :-)
<Noldorin> how about colocated branches support in LP...up yet?
<jelmer> Noldorin: landed, but I don't think deployed yet
<Noldorin> jelmer, ah right. so in the next day or two i suppose
<Noldorin> jelmer, can i subscribe to anythign to see when it's deployed?
<jelmer> Noldorin: yeah, bug 380871
<ubot5> Launchpad bug 380871 in Launchpad itself "support for colocated branches" [Medium,Fix committed] https://launchpad.net/bugs/380871
<Noldorin> jelmer, oh ok, already subscribed...thanks
<Noldorin> jelmer, chance to work on the bzr-git issue today you think? :-)
<blackarchon> well I'm done for today... cya
<jam> I'm seeing some test runner noise, has anyone else also seen this: http://paste.ubuntu.com/690112/
<Noldorin> jelmer, well?
<jelmer> Noldorin: nothing yet, I'll keep the bug report posted
<jelmer> jam: I haven't see the "failed to open trace file:" warning, but the import warnings look familiar
<jelmer> jam: I think they've been happening for a while in sid/oneiric
<Noldorin> jelmer, sure...i like forward to it.
<Noldorin> jelmer, will be around today again to help...but not tomorrow probably
<jelmer> jam: importing lazr.restfulclient seems to trigger them
<Noldorin> also, is there a windows redistributable release for 2.5b1 ?
<jelmer> Noldorin: see http://wiki.bazaar.canonical.com/WindowsDownloads
<jelmer> I'm not sure if we usually provide setup files for betas
<jelmer> looks like we do
<jelmer> Noldorin: see also https://launchpad.net/bzr/+download
<Noldorin> jelmer, yeah, no luck there.... i only want the installer because i want tortoisebzr really :-S
<jam> Noldorin:  Given that vincent hasn't announced it yet, and only created the tag about 3 hrs ago, we haven't built it yet
<jam> there is 2.4.1 which should have the latest tbzr
<Noldorin> jam, oh ok, but it will be released soon-ish eh? :-)
<jam> Noldorin: I would expect 2.5b1 to be announced tomorrrow
<jam> and an installer built... whenever I can get around to it
<Noldorin> jam, ok cool...i only ask about the windows build for 2.5b1 because i want colocated branch support
<Saviq> hi all, any way to only commit a subset of changes? something that `git add -p` allows?
<LeoNerd> bzr ci some file names here
<Saviq> LeoNerd: what about per-hunk?
<LeoNerd> Ah, for that case I usually use "bzr shelve" to remove all the changes I don't want to commit
<LeoNerd> That way I can run unit tests etc.. on just those bits I do want to commit, so when I  bzr ci  I know I'm committing exactly what I tested
<Saviq> found it - https://launchpad.net/bzr-interactive
<Saviq> bit inactive, but I'll try
<LeoNerd> I prefer the shelve approach
<LeoNerd> shelve is a widely-used plugin so it's well supported. And again also, the unit testing :)
<LeoNerd> Personally I really dislike the partial-hunk selection way of committing, because you don't really know if that partial selection even compiles, let alone actually works..
<Saviq> well, since you have that in separate revisions, you can easily find out
<LeoNerd> My usual workflow consists of *hack hack hack...* bzr shelve -m "Things that aren't done yet"; make test; bzr ci -m "Did stuff"; bzr unshelve..
<LeoNerd> possibly recursively.
<LeoNerd> shelves stack, you can have multiple of them, nested
<LeoNerd> This way I know that every single commit definitely passes unit tests, because it was committed immediately after "make test" passed
<Noldorin> jelmer, no rush for fixing the bzr-git bug i guess...now that i know the 2.5b1 windows installer won't be out for a few days...
<Noldorin> jelmer, nor will the LP support for colocation...they'll all come at about the same time i guess :-)
<jelmer> Noldorin: any reason you're waiting for all of them to be updated?
<Noldorin> jelmer, i want to be able to push all my LP bzr branches to github :-)
<Noldorin> can't do that until all 3 are updated/fixed
<Noldorin> brb
<Noldorin> hey jelmer
<jelmer> hi
<Noldorin> jelmer, sorry to pester again...any progress? :-)
<jelmer> Noldorin: I'll post to the bug once I've looked into it further
<Noldorin> okay :-)
<Noldorin> ta
<BasicOSX> evening
<BasicOSX> something wrong with the bzr repo?
<BasicOSX> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ebzr-pqm/bzr/bzr.dev/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<BasicOSX> bzr update before that ERROR message
<jelmer> BasicOSX: you're trying to write to a repository (bzr.dev) over http
<BasicOSX> seems strange, bzr update, just pulls from the repo right?
<jelmer> BasicOSX: this usually happens if it's trying to take a write lock for some reason
<jelmer> BasicOSX: what version of bzr are you using to do the update?
<BasicOSX> Bazaar (bzr) 2.5.0dev2   from bzr checkout /Users/tanner/projects/bzr.dev
<BasicOSX>     revision: 6141
<BasicOSX>  
<jelmer> BasicOSX: can you pastebin the output of "bzr up -Derror" ?
<BasicOSX> meh
<BasicOSX> all looks ok!
<BasicOSX> $ bzr up -Derror
<BasicOSX> Tree is up to date at revision 6141 of branch http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
<BasicOSX> oh, never mind, so sorry, I did !bzr for command recall and the last bzr operation was a bzr merge :-( apologies!
<jelmer> ah :)
 * BasicOSX goes and hides in the corner
<jelmer> though we should print a saner error message..
<Noldorin> shit. i just clobbered my branch on LP by reverting to r0
<Noldorin> can i recover it?
<Noldorin> uncommitting to r0
<Noldorin> buggggger
<jelmer> Noldorin: just push again ?
<Noldorin> jelmer, it's clobbered locally to
<Noldorin> they were bound
<Noldorin> i guess
<jelmer> you can run "bzr heads --dead-only" to find the previous tip
<jelmer> then "bzr pull -rrevid:<therevid> ." to revert back
<Noldorin> jelmer, there are no dead heads :-S
<Noldorin> jelmer, maybe you pulled the 0.4 branch recently and have it on your HD?
<Noldorin> i'm so fucked otherwise
<jelmer> Noldorin: what's the lp branch?
<jelmer> Noldorin: I see quite a few dead heads on the lp branch
<Noldorin> jelmer, lp:ircdotnet/0.4
<jelmer> Noldorin: "bzr heads --dead-only" shows a handlful of dead heads for that branch
<Noldorin> :-S
<Noldorin> jelmer, it says no revisions to pull when i try to pull again
<jelmer> Noldorin: are you specifying a particular revision>
<jelmer> ?
<Noldorin> nope
<Noldorin> just want to pull afresh
<Noldorin> so i created a new directory
<Noldorin> and bzr init
<Noldorin> then bxr pull lp:ircdotnet/0.4
<Noldorin> and it tells me nothing to pull
<jelmer> Noldorin: that won't work, because you've removed all the revisions from that branch
<jelmer> Noldorin: you can still fetch a revision from the repository though
<Noldorin> oh?
<Noldorin> how do i do that?
<jelmer> Noldorin: run "bzr heads --dead-only lp:ircdotnet/0.4"
<jelmer> then find the relevant revision id
<Noldorin> got it
<jelmer> "bzr pull -rrevid:<revid> lp:ircdotnet/0.4"
<flacoste> hi there
<flacoste> is it a known bug that bzr qannotate cause sXorg to take all available memory on Oneiric?
<jelmer> hi Francis
<jelmer> flacoste: I don't think I've heard about that one
<Noldorin> jelmer, nothing recent there :-S
<flacoste> jelmer: yeah, bzr qlog seems to work fine
<jelmer> flacoste: I can't reproduce the qannotate issue here (oneiric, bzr 2.4, qbzr 1.2.1), so there must be something specific that triggers it
<flacoste> actually
<Noldorin> bah
<flacoste> it's not qannotate so much than qdiff
<Noldorin> this is not fun..
<jelmer> Noldorin: are you sure there were ever newer revisions on launchpad?
<flacoste> as if I request a file difference in qlog, it does the same thing: Xorg goes to 2G RSS
<flacoste> in a few seconds
<jelmer> Noldorin: uncommit doesn't remove revisions from the repository
<flacoste> jelmer: that's on the LP tree
<Noldorin> jelmer, yes, up to r49. 100% sure
<flacoste> i'll check on a small tree to see if the same things happen
<Noldorin> in this case it does...
<flacoste> jelmer: yes, same behavior on a small tree
<flacoste> so must be qdiff related
<flacoste> and might be a change in the way the QT libraries does its thing
<flacoste> i'll report a bug
<jelmer> flacoste: thanks!
<jelmer> fwiw, I can't reproduce that here either on a small tree
<jelmer> Noldorin: what does "bzr heads --dead-only" on your local repository say?
<flacoste> jelmer: i have this in the terminal:
<flacoste> QWidget::setMinimumSize: (/DiffWindow) The largest allowed size is (16777215,16777215)
<Noldorin> jelmer, sorry sorry, me being an idiot... i assumed dead-only heads were in chronological order :-P
<Noldorin> jelmer, not that i want to...but is it possibly to remove dead heads?
<jelmer> flacoste: that sounds like it might be relevant, I'm not seeing that here
<flacoste> jelmer: bug 851379
<ubot5> Launchpad bug 851379 in qbzr (Ubuntu) "qdiff makes Xorg eats up all RAM on Oneiric" [Undecided,New] https://launchpad.net/bugs/851379
<flacoste> jelmer: yeah, i think it's creating a too big window that takes all RAM in the X server
<flacoste> I've now lost my code archeology tool!
<jelmer> flacoste: I'm afraid I'm not all that familiar with Qt and qbzr (other than as a user), but maybe Riddell has an idea
<Noldorin> jelmer, ?
<jelmer> Noldorin: in theory, yes. In practice we don't have a command that does it.
<Noldorin> ah ok sure
<Noldorin> jelmer, it's a good safety measure anyway so that's fine ;-)
<Riddell> flacoste: what happens if you move ~/.bazaar/qbzr.conf out the way?
<flacoste> Riddell: same thing
<flacoste> i need to run, will follow-up with any question on the bug report
<Noldorin> jelmer, no luck trying to create a minimal example of the bzr-git issue here
<Noldorin> odd
<Noldorin> :-S
<Noldorin> jelmer, what is the easiest way to join a series of commits into a single revision?
<Noldorin> for hte purpose of testing...
<poolie> hi all
<lifeless> morning
<jelmer> g'morning poolie, lifeless
<poolie> hi jelmer
#bzr 2011-09-16
<Noldorin_> jelmer, hey. is any of it making sense to you now?
<Noldorin_> this issue...
<poolie> spiv, hi
<poolie> nm
 * maxb catches up on a bit of ~bzr PPA update backlog
<poolie> hi maxb!
<maxb> morning
<maxb> Hmm. Not sure if I'm doing something wrong, but I'm finding the process of doing something in bzr to model having copied the beta-ppa line of bzr packages into the main ppa to be somewhat awkward
<poolie> hm
<poolie> do you want to talk more about it?
<maxb> Well, I have a way which works, it's just not pretty
<maxb> cd ....../ppa/natty
<maxb> bzr merge ../../beta-ppa/natty
<maxb> bzr revert -r-1:../../beta-ppa/natty
<maxb> bzr ci
<maxb> cd ../maverick
<maxb> bzr merge ../../beta-ppa/maverick
<poolie> hm
<maxb> bzr merge --force ../natty
<maxb> bzr revert -r-1:../../beta-ppa/maverick
<maxb> bzr ci
<maxb> continue for lucid
<poolie> so you want to make a merge, that actually replaces everything with the origin?
<poolie> you could just pull, perhaps
<maxb> It would be an --overwrite
<poolie> right
<poolie> but that's arguably the reality here
<poolie> hm
<poolie> it would be better if there was a revspec for "my pending merge tip" so you could revert to that, too
<poolie> i think there's a bug asking for it
<maxb> yes, yes it would
<maxb> I may have even filed it. Or me-too-ed it
<maxb> how on earth have I ended up with differing file-ids in the lucid ppa branch for various packaging bits?!
<maxb> oh, no
<maxb> just conflict files left behind
<maxb> but I do now have conflicting tags between beta-ppa/natty and ppa/natty!
<poolie> :/
<poolie> that could actually be coming out of the workflow you discuss?
<poolie> since there are going to be effectively two different revisions for 2.4.1-blah
<maxb> There should never be that
<maxb> One of the conflicting tags is 'bzr-2.3.3' !
<maxb> the rest are packaging in nature
<maxb> er, whoops
 * maxb realizes the need to revert . not revert in the above workflow
<poolie> right, or it will lose your pending merge
<poolie> i assumed that was just a typo - otherwise the ci will fail
<vila> hi all !
<maxb> Morning vila
<maxb> 2.4.1 building PPA
<vila> hay maxb !
<vila> \o/
<vila> thanks a ton !
<maxb> er, building in PPA
<maxb> we have an issue with bzr-builddeb. Its tests seem to be hinting at a bug in bzrlib.tests
<vila> yeah, I figured ;) (I'm pretty good at deciphering tyops, lots of practice in producing them myself)
<vila> ha ha, tell me more
<maxb> AttributeError: type object 'TestCaseWithMemoryTransport' has no attribute '_SAFETY_NET_PRISTINE_DIRSTATE'
<vila> riiiings a bell
<vila> what and where was it...
<vila> known and fixed issue anyway
<vila> my background daemon is whispering jelmer or Riddell
<maxb> or.... you?
<maxb> :-)
<vila> Aug 30 12:18:08 <vila>	_SAFETY_NET_PRISTINE_DIRSTATE was introduced recently, let me check
<vila> fakeroot
<maxb> bzr/2.4 r6024 looks like it might fix it
<spiv> Sounds a bit like something not calling the super class's setUp?
<poolie> hi spiv, vila
<vila> test isolation says my IRC logs, reading
<vila> hey poolie !
<maxb> i'll retry the bzr-builddeb builds once bzr 2.4.1 has built
<vila> maxb: lp:bzr/2.4 revno 6024 is: (jameinel) Bug #609187,
<vila>  check that packaging import branches are up-to-date when accessing them.
<vila>  (John A Meinel) here
<ubot5> Launchpad bug 609187 in bzr (Ubuntu) "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,Fix released] https://launchpad.net/bugs/609187
<vila> 6042 !!
<vila> pff, who said he can't figure out tyops ? Lier
<vila> maxb: yup, that's exactly the one
<vila> pff, who said he *can* figure out tyops ? Lier
<jam> morning all
<poolie> hi jam
<poolie> vila, so it looks like the changelog merge hook is working ok?
<vila> poolie: ha, ha, quizz question first: how long does it take to the package importer to queue/process all tracked packages ?
<poolie> to check them all?
<poolie> i'm not sure, good question
<poolie> a couple of hours?
<vila> nothing to win, I was surprised by the answer myself and like to see what people feel it is
<vila> exactly my feeling, ~2 hours
<jam> vila: queue and check when there is nothing to do?
<vila> jam: not exactly, on average, how long between two attempts for the same package
<vila> jam: no cheating by looking at the logs, first thought !
<jam> vila: I'm not quite sure what you're getting at. It should be trying to pull the data of what needs to be done next from LP
<poolie> maybe you can just tell us?
<jam> Are you saying to retry a failed package?
<vila> ~36 hours
<vila> i.e. on average, we try to import a given package every 36 hours
<vila> far more than the ~2 hours gut feeling I had
<vila> hence why I wanted you to tell your gut feeling before I told you
<poolie> ok
<poolie> well, that could certainly be faster
<poolie> where did you get that data? from sampling the logs?
<vila> yup
<poolie> perhaps eventually it could look at a feed-like view from launchad
<vila> looking at the output of https://code.launchpad.net/~vila/udd/analyze-log-imports/+merge/74057 instead of tail -F progress_log gives a better feeling
<vila> holistic feeling that is
<vila> poolie: and from that and to come back to your original question: no evidence yet that dpkg-mergechanlogs broke something, but still a bit more time needed to know that it has been tried for all packages
<vila> i.e. tonight, I'll mark the bug as fixed with reasonable confidence and still ask for it to be re-opened if needed
<vila> but I'm already convinced it's ok
<vila> 2011-09-15 05:00:30,456 - __main__ - INFO - All packages requeued, start again
<vila> so roughly the next occurrence is expected today ~17h00 UTC
<poolie> vila, so you're on bug 795321 now?
<ubot5> Launchpad bug 795321 in Ubuntu Distributed Development "udd importer should make tea while launchpad is down" [High,In progress] https://launchpad.net/bugs/795321
<poolie> jam that was very quick on the disconnect stuff
<poolie> is there anything i can do on it?
<vila> poolie: yup, I have a crcuit breaker implemented and tested, I'm now trying to plug it into mass_import
<poolie> nice
<vila> three events: attempt (to import), success, failure
<vila> one assumption is that when lp is down, no import can succeed
<vila> another is that failures are already classified, some of them are transient
<vila> I expect the transient ones to be easily linked to lp down
<vila> and the final one is that we have a way to say: this failure is a transient lp one from the backtrace and/or because it raises launchpadlib.HTTPError
<vila> ideally from the command line
<vila> bbiab
<jam> poolie: you can test the disconnect stuff if you like, it seems to work fine here. On Windows and Natty at least.
<jam> I think the next obvious step is to hook into that with a SIGUSR1/SIGHUP
<jam> and then get the client to gracefully reconnect
<poolie> vila, one option for concurrency is to change to use tdb
<poolie> i'm pretty sure that's multi-writer
<poolie> and simple
<poolie> and udd does very simple things with its db
<poolie> either that or whichever nosql is fashionable today
<jam> poolie: well, you could just switch to postgres
<jam> Most nosql solutions do very poorly at low scale
<jam> for example, mongodb defaults to pre-allocating 5% of your disk space (in my case, 1GB)
<poolie> awesome
<poolie> i wasn't very serious about that actually
<jam> poolie: I didn't think you were. As for tdb, we could, but sqlite seems much more well tested. With the WAL work for sqlite 3.6 or so
<jam> the actual contention between readers and writers is tiny
<jam> the only issue is if you need multi writer
<poolie> i think tdb is pretty reliable, though less commonly used
<nigelb> poolie: On the note of nosql -> http://howfuckedismydatabase.com/nosql
<poolie> upgrading sqlite would be a smaller change
<jam> nigelb: :)
<poolie> i like that
<poolie> more to the point, http://howfuckedismydatabase.com/sqlite/
<nigelb> heh
<poolie> so would anyone (maxb?) agree or disagree with me in bug 831699 that to track success, it's probably cleanest just to add a success table?
<ubot5> Launchpad bug 831699 in Ubuntu Distributed Development "no report/log of successful packages" [High,Confirmed] https://launchpad.net/bugs/831699
<poolie> and/or refactor the 'failure' thing into an 'outcome' that can be either success or failure
<vila> poolie: right, not there yet (migrating from sqlite ;)
<poolie> ?
<vila> making tea has issues with concurrency but not related to the db
<vila> . o O (Go decipher that joe random ;)
<vila> For the circuit breaker, the fact that lp can go down while several imports are running has two outcomes:
<Riddell> aloha
<vila> - you can see a failure *followed* by a success because the failure see lp down while the success still had work todo to finish the import that didn't require lp
<vila> so the success is a false positive as far as lp state is concerned
<poolie> right
<jam> poolie: I think adding a success table makes sense. It gives you a place to say *when* it last succeeded, how long it took, whatever other stats you want to track
<poolie> so there has to be some kind of trending
<poolie> one swallow does not make a spring
<jam> poolie: I always burn my coats when I see a swallow....
<vila> - you can see a failure related to lp but the classification is wrong (permanent instead of transient) which is also a false positive
<vila> poolie: right, so as far as the circuit breaker is concerned, there is little interest in waiting for more success as long as we keep trying on transient failures
<jam> vila: you could also just have it be a soft timeout that increments on failure, and decrements on success.
<jam> (not necessarily by the same amount)
<vila> another issue is that there is no fast and unambiguous way to decide if lp is up
<poolie> also
<jam> so start a new package every 30s, if they are failing, make it 45, then 60, then...
<vila> jam: right, but the issue here is more about lag
<vila> I don't know how long a package will need to tell me lp is up
<vila> so I'm more inclined to say: we have a max_threads for mass_import,
<poolie> could you look at the code i quote in bug 831699
<ubot5> Launchpad bug 831699 in Ubuntu Distributed Development "no report/log of successful packages" [High,In progress] https://launchpad.net/bugs/831699
<poolie> it seems wrong but i might be missing the point
<vila> what is wrong ?
<vila> OLD_FAILURES ?
<poolie> why does it chec kfor a failures entry, and only if that exists delete the old job
<vila> I think the JOB table is populated only if you had  a failure
<vila> or if it's a new package
<vila> err
<vila> won't work for new packages, forget that
<poolie> no, i think there's always a job created when it starts, and it's marked closed higher up in this function
<poolie> so the intention certainly seems to be that they're kept around, but inactiev
<poolie> also, why delete it if it failed on the previous attempt
<jam> poolie: "I wonder what the logic is behind deleting the job if there was previously a failure record."
<jam> I think it is deleted on any success, indicating that it doesn't need to be run again
<jam> (job completed)
<vila> so that it doesn't appear on the web page while it's queued ?
<jam> ah, nm, I see your point
<jam> poolie: I think it is just faulty logic. It seems like it checks for row, because it wanted to use it, or something like that.
<vila> mass_import starts by queuing the job table and only when it's empty does it look at the package table
<poolie> i think it's a mismatch
<poolie> well, i have to go out now
<jam> also note that the 'delete from %s' doesn't follow the rest of the SQL refactoring that pulls strings out into constants, etc.
<poolie> maybe james will reply
<jam> poolie: have a good night
<poolie> exactly
<poolie> i colud annotate it
<vila> . o O (my empire for a test framework there)
<vila> poolie: g'night
<poolie> nothing obvious there
<poolie> ok, we'll see
<poolie> i'll track successes on monday
<poolie> cheerio
<Riddell> in add_hook e.g. self.add_hook('transform_fallback_location', "Called when a stacked branch is activating its fallback " etc   is the description ever shown to the user?
<Riddell> are the strings in check.py check() self.progress.update() user visible?
<jam> Riddell: "bzr help hooks" ?
<jam> I'm not sure about the check.py stuff
<jam> but if it is "progress", then yes, most likely user-visible
<jam> vila: did you ever get a chance to re-review the patch I put up? I think I ironed out the kinks
<vila> jam: not yet
<jam> I think poolie's only comment was that I should probably be checking "errors"
<vila> yup, I agree with that
<jam> I was hoping to have a way to actually trigger that, so that I know the code works
<vila> I can list a few themes I want to mention without formally reviewing if you wish
<vila> or do that later more formally
<jam> vila: feedback is feedback if you have time to list it out
<vila> medium has a disconnect method, why do you need to implement a _close() one ?
<vila> the config stuff could be revisited once bug #491196 is fixed, in the mean time, what you did is good,
<ubot5> Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [High,Confirmed] https://launchpad.net/bugs/491196
<vila> I wouldn't require plugins to support the new timeout parameter (but I'm not sure you had a choice there)
<jam> vila: client side has .disconnect. not server side
<jam> I can call it "disconnect" if you like
<jam> vila: I don't see a way to pass the timeout parameter optionally, other than what I did
<jam> try/TypeError
<vila> jam: but is there a way to not *force* the plugins to accept it (i.e. could they just ignore it to start with and implement it later)
<vila> i.e. is loggerhead *required* to take it into account *today*
<jam> vila: I did that, try/pass_5_arguments/except TypeError/pass 4 arguments
<jam> with a deprecation warning inbetween
<jam> vila: I did mention that loggerhead works *today* with a warning.
<jam> which is suppressed in release builds
<jam> vila: I know it isn't obvious, but too-many-arguments is a TypeError
<jam> in python
<vila> jam: oh, I may have looked at on old version then, I don't remember seeing this part
<vila> s/on/an/
<vila> ok, good then
<jam> vila: possible, though I think I implemented except TypeError when I implemented the command line.
<vila> <jam> vila: client side has .disconnect. not server side
<vila> but test server side has shutdown_client (client from the server side pov)
<vila> there may be a way for the tests to use a native disconnect() if available
<jam> vila: only the test server, not this implementation
<jam> vila: what do you mean by 'native disconnect'?
<jam> SmartServerStreamMedium does not have the concept of disconnecting the client yet
<jam> you added shutdown_client only in the Test implementations
<vila> native as in supported by the server side of the client
<vila> yes, to limit the scope at the time and at least for the SmartTCPServer because spiv said he didn't care
<jam> vila: SmartServerStreamMedium *is* the server side of the client. I really feel like I'm missing something here.
<jam> vila: I'm happy to rename ._close() to .disconnect() and to change shutdown_client() to call .disconnect()
<vila> the test infrastructure didn't try to use it because that was the only existing one
<jam> though it doesn't quite match because of *what* self.clients tracks
<vila> ha
<jam> it doesn't track the medium/handlers, it tracks the actual socket connections.
<vila> that may be where the mismatch is,
<vila> I feel like you're adding stuff that is existing but may be that's because the dots are not connected
<vila> and a fallout of doing that may explain the weird behaviors you're seeing
<vila> and I'm still uncomfortable with the select loop as I have a feeling that it's needed because these dots are not connected
<jam> vila: fundamentally the test infrastructure is poking at a thread's internal state from another thread.
<jam> I don't think that is a 'stable' situation.
<jam> We do it because parts of the thread are blocking
<vila> on top of that, if the SmartTCPServer ends up needing to track its connections, it sounds like the this code should be shared
<jam> vila: well, *today* SmartTCPServer does *not* track its connections. They are set to Daemon and forgotten.
<vila> the alternative was to raise an exception in the client thread from the server thread but back in the days this wasn't easy to do and still be compatible with 2.4, 2.5 and 2.6
<jam> vila: this is like the thread.interrupt_main()?
<jam> vila: In my last comments I noted something
<jam> which is that *doesn't* interrupt socket.accept()
<vila> jam: which is why you encounter issues with "interpreter shutdown" and need to to keep references to sys.stderr and the line
<jam> it waits for it to timeout/return first
<vila> like
<jam> vila: so "interrupting" the client thread doesn't actually do such a thing
<jam> because it is blocked in a C lib
<jam> so you *still* need to do a loop
<vila> which loop ? the select one ?
<jam> vila: In that case, a loop around socket.accept()
<jam> (SmartTCPServer.serve)
<jam> it wanted a loop already
<jam> because it wants to support multiple connections
<jam> There is a test case in blackbox
<jam> that calls "thread.interrupt_main()"
<vila> interrupt_main sounds like a thread interrupting the *main* thread which can receive signals
<jam> and it doesn't actually interrupt until socket.accept() returns
<jam> you can see my notes on it
<vila> I'm talking about raising an exception *from* the main thread in another one
<jam> but if you have "socket.settimeout(1)" it takes 1s for the test to shutdown
<vila> evil, don't do that
<jam> vila: sure, *my* point is that raising an exception doesn't actually interrupt select.select() or socket.accept() or socket.recv() etc.
<jam> vila: we already have that
<jam> I "fixed" it with an optional "change the timeout parameter.
<vila> where ?
<jam> bzr selftest -s bb.test_serve
<jam> I forget the exact test
<jam> blackbox.test_serve.TestCmdServeChrooting.test_serve_tcp
<jam> And I've seen that happen with one of the other tests
<jam> I think it is a race condition with whether it gets blocked in the socket.accept() before it gets a chance to raise the exception.
<jam> vila: so our SmartTCPServer already does a 1 second timeout loop in serve
<vila> I've long suspected race conditions but 1) I stopped encountering them when adding the necessary sync points, 2) I'm not convinced anymore that *python* itself have some
<jam> vila: sync points?
<vila> jam: on the listening socket, irrelevant, this one is ok
<jam> vila: except it makes the test take 1s to shut-down
<jam> which I override down to 0.1s
<vila> but that's not a race
<jam> vila: there *is* a race in another test, where it sometimes waits an extra second to shutdown after calling thread.interrupt_main()
<jam> it isn't strictly a 'race'
<jam> as in, it always gives the same results
<jam> but how long it takes varies
<jam> because the 'main' thread is blocked
<jam> waiting on socket.accept(). I would expect the same thing for select.select()
<jam> because the 'thread.interrupt_main()' *doesn't* use signals
<jam> so if the call is in a C function
<jam> it is blocked from python seeing the 'you need to raise an exception' call.
<jam> vila: hence, you need a loop, to avoid blocking forever
<jam> vila: for example, if I wrote the _wait_for_timeout code to do select.select(..., timeout=300). I *think* you could not ^C the python process.
<jam> You technically *could*, but it may not actually trigger until the 300s times out
<jam> I've certainly seen stuff like ^C get blocked because we are in a C function.
<vila> interrupt_thread is not what I had in mind, it may shares some common parts but the one I remember was allowing raising a specific exception not KeyboardInterrupt
<vila> http://docs.python.org/library/thread.html?highlight=thread.interrupt_main#thread.interrupt_main
<jam> vila: so we sort of got off on a tangent. My specific point is that you need the loop, regardless of testing-specific interactions, because you aren't guaranteed that ^C will do what you want
<vila> says" Threads interact strangely with interrupts: the KeyboardInterrupt exception will be received by an arbitrary thread. (When the signal module is available, interrupts always go to the main thread.)
<jam> vila: you're looking at a different function than what you linked
<vila> jam: my point is: you shouldn't need the loop and we don't know *why*
<vila> ?
<jam> vila: http://paste.ubuntu.com/690681/
<vila> you mentioned interrupt_main, I don't remember the link of the alternative
<jam> follow your own link
<jam> it doesn't say what you said
<jam> vila: ah, way down at the end?
<jam> vila: I can confirm that it is a Windows thing I'm seeing.
<jam> Specifically: socket.recv(1) is blocking on windows.
<jam> such that ^C doesn't interrupt it
<jam> and you have to kill the process by other means
<jam> on Linux, I get KeyboardInterrupt reliably
<jam> on Windows, once I finally send some data
<jam> then I see KeyboardInterrupt
<vila> I don't understand what you're talking about, interrupt)main ?
<jam> vila: so there are 2 things
<jam> 1) socket.recv() blocks ^C until it returns on Windows (not on linux)
<jam> 2) socket.accept() is known to block thread.interrupt_main() from raising KeyboardInterrupt until socket.accept() returns (on all platforms)
<jam> as in, it queues up a KeyboardInterrupt *to be raised when socket.accept returns*
<vila> forget interrupt_main, not all servers run in the main thread (most don't)
<vila> right, hence the need for the *test* which runs in the main thread, to act on the socket in the server context so that either the blocking call is unblocked or it raises an exception
<jam> vila: going further, select.select() [on Windows] blocks ^C until it returns
<vila> that's the whole idea of shutdown_client
<vila> jam: even when you specify the error parameter ?
<jam> vila: thread.interrupt_main() doesn't matter if it is main thread or not, it is still blocked until socket.accept() returns.
<vila> right, so, let's forget about it
<jam> vila: i'll try that, but given that KeyboardInterupt is raised the moment select.select() returns
<jam> vila: select.select([c], [], [c], 10) doesn't respond to ^C until  I either wait the 10s or write a byte to the client socket
<vila> oh, right, TestBzrServeBase, now I remember that one, special case, probably the only one where the server runs in the main thread
<vila> or close the client socket ?
<vila> from the server end, not the client end
<jam> vila: my experience with testing, was that server-end *does not return* until the timeout if I close the socket in another thread.
<jam> I'll try again, though.
<jam> vila: *my* point, is that because select.select() blocks stuff like ^C until timeout
<jam> we should use a shorter timeout, and loop
<jam> and if we need a loop anyway
<jam> then we can not worry about it in the test suite.
<vila> dunno for select  but I can assure you that it works for read() (for the client threads))
<vila> so either the select is interrupted or the read is interrupted and as long as you catch the right exceptions you shouldn't need the loop around select
<jam> vila: there is no read(), do you mean recv() ?
<vila> yeah, recv, sorry
<jam> vila: and you mean thread.interrupt_main() or you mean ^C
<jam> ?
<vila> I mean whatever way is used to close the connection
<jam> vila: I'm setting up a test case for that on Windows. I'll let you know.
<vila> forget about interrupt_main, it's a hack and not a good example (useful shortcut for TestBzrServeBase though)
<vila> but TestBzrServeBase is about checking hook execution IIRC not really about how the server is interrupted
<jam> vila: ok, I can say that... testing a very simple test case threading.Thread(target = (sleep1, c.close()).start(); select([c], [], [], 10) returns before 10s saying that you can recv from the socket without blocking.
<vila> so not relevant for our current discussion because we *cannot* use it
<jam> on Windows
<jam> vila: I can also say, this was not borne out in the test suite
<jam> where sometimes it hangs forever
<jam> well, until timeout
<vila> borne out ?
<jam> vila: confirmed by
<jam> similar results with
<vila> oh, I can believe that
<vila> hangs are a pain to debug, therefore extremely hard to diagnose
<jam> http://answers.yahoo.com/question/index?qid=20100702014132AAcKdX8
<vila> jam: thanks ! Keep them coming ! (And always fell free to fix my broken english)
<jam> vila: so. select.select() will block ^C on windows until timeout, and seems unreliable that we detect the socket getting closed underneath us (according to the test suite).
<jam> As such, it seems that a loop is reasonable.
<vila> ...
<vila> jam: before I fixed the test suite leaks, we *were* using a similar loop
<vila> with timeouts to make matte worse
<jam> vila: if only because you can't ^C the process until timeout, I don't think we should have a 300s timeout.
<vila> you lost me there, I thought the scope of the bug was lp, why should we pay for busy loop there ?
<jam> vila: the scope of the bug is "we'd like to disconnect clients that are idle for too long", a 1s sleep loop isn't a lot of wakeups, though certainly you could reduce it if you wanted.
<jam> vila: I feel pretty strongly that we *need* a loop on windows
<jam> I can have "if sys.platform == 'win32': loop"
<jam> That seems far worse than just having a loop, which handles all the current issues, even if there may be other issues in the future.
<vila> does selec([],[], [xxx]) block ?
<vila> does select([],[], [xxx]) block ?
<jam> vila: it blocks ^C until it returns, yes.
<jam> vila: are you saying with no timeout?
<jam> or are you saying with the socket passed in the errors field
<vila> the later
<jam> (and note, there is no *error* with ^C)
<jam> vila: *on Windows*, select.select() blocks until the C function underneath it returns, and then stuff like exception handling and signal processing occur
<jam> before the python function returns
<vila> jam: wow, and recv(), listen() etc all behave this way on windows ?
<jam> vila: recv() dose
<jam> does
<jam> I'm not sure about accept
<jam> I'll check
<vila> jam: it's that easy to create an unkillable unstoppable process ?
<jam> vila: yes
<jam> vila: you can kill it
<jam> just not ^C it
<vila> meh
<jam> vila: cygwin's "kill" command kills the process just fine.
<vila> kill is certainly a way to interrupt especially if you can trap it
<jam> vila: no "real" signals on Windows.
<jam> vila: I dug into this a lot back when I implemented "SIGQUIT" for the pdb debugger for windows
<jam> i'll see if I can dig it out, just a sec
<vila> is it because only the main thread is seeing the signal ?
<jam> vila: On Windows, *there is no signal*
<jam> You have "GenerateConsoleCtrlEvent" and "TerminateProcess"
<vila> yeah, whatever C-c trigger
<jam> vila: there are some very interesting restrictions, like one Terminal cannot send "GenerateConsoleCtrlEvent" to another console
<jam> and some other things like you can only kill a process group, which kills yourself
<jam> vila: I could be wrong, I'm a bit fuzzy on the details, but in general, thinking in terms of signals doesn't work on Windows.
<vila> right, which makes it an interesting platform for servers...
<jam> vila: I think you can do a lot of things, but you have to write them in the windows way. WaitForObjectEx, etc.
<vila> jam: so, the bug mentions xinetd and inetd not really common on windows AFAIK
<jam> rather than trying to use the posix workarounds like select()
<vila> indeed
<jam> vila: sure, it doesn't work anyway because you can't select() on a pipe
<jam> that doesn't mean we have to have 2 implementations
<vila> well, it may mean it's harder to fix for windows so we'd better fix it for unix first
<jam> vila: both savannah and launchpad are using the Pipe implementation because they are using bzr+ssh
<jam> vila: I have
<jam> you just don't like that I loop
<jam> it *still* helps "bzr serve" on Windows
<jam> and "bzr serve --inet" on Linux
<jam> and the test suite passes
<jam> etc
<vila> because I suspect it hides other issues that gave us a lot of trouble in the past
<jam> vila: we leak threads in some tests, but I made sure we were already leaking threads in those tests without my code.
<jam> (again, that is pretty random, sometimes 9 leaking threads, sometimes 2, but 'bzr.dev' had the same behavior.)
<vila> huh ?
<vila> on windows you mean ?
<jam> vila: I'm pretty sure on natty, too. I don't remember which tests, let me see if I can find them.
<jam> vila: http://paste.ubuntu.com/690709/
<jam> with bzr.dev as of right now
<jam> on devpad
<jam> vila: on my machine right now on Windows, neither bzr.dev nor my code claims to leak threads.
<jam> vila: on Natty, I think I generally got the same "9 leaking threads"
<jam> I remember it varied
<jam> and the same tests did not always leak
<vila> I *never* see leaking threads here... Do I miss some special flag I can't remember ?
<jam> vila: I haven't set any flags AFAIK
<jam> maybe debug_flags=hpss
<jam> but it is consistently leaking for me on my Natty, and on devapd
<jam> devpad
<jam> vila: re-running it, I only get 1 leaking thread
<jam> so maybe your hardware is fast enough to handle it
<jam> this is without --parallel
<vila> which tests ?
<jam> vila: I don't see leaking threads with --parallel
<jam> vila: see the paste
<jam> py ./bzr selftest -s bt.test_smart_transport
<vila> ha !
<jam> L
<jam> ?
<jam> vila: they leak for you? just not with --parallel ?
<vila> yu[
<vila> yup
<vila> so we have issues :)
<vila> right, so indeed, bzrlib.tests.test_smart_transport.TestServerHooks.test_server_started_hook_memory uses smart.server.SmartTCPServer which.....
<vila> doesn't try to collect its client threads :)
<vila> but you mention the PipeServer right ?
<jam> vila: bzr serve --inet ?
<vila> yup
<vila> still can't buy the idea that this server will be used on windows where the TCP one is far better suited...
<jam> vila: I don't see it being used on Windows either
<jam> this code also explicitly doesn't work there
<vila> which one ?
<jam> vila: see line 337 of https://code.launchpad.net/~jameinel/bzr/drop-idle-connections-824797/+merge/75348
<jam> that is the SmartServerPipeStreamMedium
<vila> Or you saying your fix doesn't apply for the PipeServer on windows ?
<jam> vila: my fix doesn't select() Pipes on Windows
<jam> (it would fail anyway)
<vila> so no select() loop either, so how do you handle the interrupt ?
<jam> vila: interrupting bzr serve --inet on Windows? I don't try to do anything tere.
<jam> there.
<jam> I don't try to timeout, etc.
<vila> right, so your fix doesn't apply to PipeServer on windows, correct ?
<jam> vila: correct
<vila> ok, so trying to handle C-c during a select is irrelevant, what we want is being able to handle C-c during listen() in the TCPServer which already has a loop with a timeout correct ?
<vila> (still on windows)
<vila> jam: ?
<jam> vila: I doubt it is "irrelevant", but yes, blocking in a thread doesn't seem to block ^C for the process
<jam> sorry, was testing it to make sure
<vila> well, irrelevant as in "we don't care about that *on windows*", sorry if this came out differently on your side, not the intent, just trying to get the picture
<vila> because it's a very important distinction, even on linux, because the *main* thread doesn't have to be in a blocking call
<vila> and *can* handle more stuff
<vila> including tricks to terminate the other threads
<vila> if needed
<vila> wow, lunch time is almost past and I need some food :) bb later
<jam> vila: yeah, me too :)
<flacoste> hi Riddell
<Riddell> salut flacoste
<vila> hey flacoste
<flacoste> about your question on bug #851379, what package contains language-selector-kde?
<ubot5> Launchpad bug 851379 in qbzr (Ubuntu) "qdiff makes Xorg eats up all RAM on Oneiric" [Undecided,New] https://launchpad.net/bugs/851379
<flacoste> i don't seem to have it installed
<Riddell> flacoste: how about usb-creator-kde ?
<vila> james_w: I'm trying to understand the conditions to decide which failures are considered transient in the package importer (i.e. when a package import is retried)
<flacoste> Riddell: i only have the -gtk one installed
<flacoste> vila: salut!
<vila> james_w: is this only triggered by first asking for a package to be requeued ?
<Riddell> flacoste: could you install usb-creator-kde and check?  it's unlikely to have the same problem but at least it would discount it being a general issue
<james_w> yeah, with --auto
<vila> james_w: \o/
<vila> james_w: was visually grepping for transient and missed it ! Thanks !
<jam> vila: interestingly, I'm trying a switch to avoid the loop. It only fails on linux so far
<flacoste> Riddell: nope, usb-creator-kde works fine
<Riddell> flacoste: and can you reply with your video card
<vila> switch ? as in command-line switch ?
<Riddell> ah you did
<flacoste> Riddell: i did, it's an intel GM965/GL960 and I attached my Xorg.0.log file
<vila> jam: or as in switching main thread and client thread ? :)
<jam> vila: no. I'm just trying the code without the loop, and the test suite fails (randomly?) on linux, and after 30 runs of a reasonable subset on windows, no failures
<Riddell> flacoste: hmm, fiddly then, I've heard of a similar issue with Nvidia where the driver reports the screen size to be massive and some widgets get set as a proportion of that and break
<Riddell> but intel should be more reliable
<jam> I did see one, one time. But I was also hitting ^C around that time, so I'm not positive the failure wasn't from the interrutp.
<vila> with the err parameter to select ?
<jam> vila: just tried that, still got a timeout
<jam> and no error returns
<vila> which timeout ?
<jam> select.select() gave a timeout
<jam> "waited until timeout before returning, after which returned an empty reads and errors available"
<jam> without raising EBADF, etc.
<vila> well, I don't know what you're testing so it's hard to know if you want a timeout or not
<vila> I don't expect removing the loop is *enough*, I suspect it hides other issues, which you seem to observe now
<flacoste> Riddell: if I branch lp:qbzr/0.21 in my plugins directory, it should use that one right?
<flacoste> Riddell: i'll instrument to see which Qt call triggers the setMinimumSize log message
<Riddell> flacoste: yes if it's in a directory named qbzr
<vila> jam: basically the idea is that there is a race, sometimes you win (test pass) sometimes you lose (test fail), there should be 2 relevant threads here, the one waiting in the select and the main thread running your test (the client)
<vila> one of them is running too fast (or too slow) except in some unknown circumstances, how the time slices are given to each is less important here than *where* you need to synchronize (forcing one thread to wait for the other before a critical point)
<flacoste> Riddell: which module is responsible for the DiffWindow? ui_tag.py?
<jam> vila: test suite is failing without a loop
<jam> test suite passes with the loop
<vila> jam: I know about only *one* such race that is not fixed today but it occurs very rarely, http://babune.ladeuil.net:24842/job/selftest-chroot-oneiric/81/ for example
<vila> jam: that's the issue with the races, you *think* you've fixed it .....
<vila> until it comes back and won't go away
<Riddell> flacoste: lib/diffwindow.py
<Riddell> instansiated in lib/diff.py
<jam> vila: select.select() isn't noticing that the file handle is no longer valid, thus we time out incorrectly. If I call select.select() again, it properly notices what I wanted it to notice.
<vila> jam: I encounter this exact situation a lot while chasing the leaks and I can understand your frustration, but there is clearly one here or you wouldn't observe a random test failure
<jam> Would you prefer a double select.select with the second one having a very short timeout?
<jam> vila: I'm not particularly interested in debugging this for another 5 days after I could implement it in 1-2
<vila> I would prefer a test that clearly exhibit what you're talking about
<vila> I'm not interested in having to debug it later either
<jam> I understand the desire to avoid future confusion
<jam> I'm currently past the point of diminishing returns, however.
<jam> maybe i'll feel better next week
<jam> vila: did you make 2.5b1 publically gold?
<jam> vila: I don't see an email about it
<vila> I think I did, checking
<flacoste> Riddell: do you have an idea what all the "
<vila> grr, left in drafts....
<flacoste> Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WID
<flacoste> GET (widget)' failed
<flacoste> " warning are about?
<Riddell> flacoste: are you running gnome/unity?  I think that's Qt's GTK theme trying to make Qt fit in
<flacoste> Riddell: i am
<Riddell> check with other Qt apps that you get the same thing
<flacoste> (unity)
<Riddell> I doubt it's the cause of the problem although maybe I should try running qbzr under unity to check
<flacoste> Riddell: i don't have it with usb-creator-kde
 * Riddell installs ubuntu-desktop
<Riddell> flacoste: no problems with me in unity
<Riddell> I'm not sure how else to try and recreate the issue :(
<flacoste> Riddell: that's all-right i'm tracing it over here
<flacoste> Riddell: let you know one I have an hypothesis of what's going on
<pickscrape> Is it possible to disable an extension for a specific branch or checkout?
<SlimG_> How do I fetch a subdirectory in a launchpad branch with bzr? bzr branch lp:project/i/want/this/directory #doesn't seem to work
<Riddell> pickscrape: do you mean plugin?
<Riddell> pickscrape: you can set e.g. BZR_DISABLE_PLUGINS=cia
<Riddell> SlimG_: I don't think you can
<Riddell> does  ./bzr selftest -s bb.test_branch  pass the test suite for others in current trunk?
<SlimG_> Thanks for the info Riddell
<pickscrape> Yes, plugin sorry. Context switching. :)
<pickscrape> Riddell: thanks, that's a decent workaround. :)
<vila> Riddell: yes, ./bzr selftest -s bt.test_branch pass: Ran 84 tests in 1.992s
<vila> Riddell: try BZR_PLUGIN_PATH=-site ?
<Riddell> vila: mm, that helps
<Riddell> I wonder what plugin is breaking it then
<flacoste> Riddell: what does self.processEvents() do?
<flacoste> i assume it's a QWidget or QWindow methods
<Riddell> flacoste: just runs Qt's event queue
<flacoste> any way to see what's going on in there
<Riddell> it's a cheap way to ensure the UI is kept updated if you are running a complex task and don't want to use threads
<flacoste> that's where the setMinimumSize() calls happen
<flacoste> in DiffWindow.load_diff()
<flacoste> the first processEvents()
<flacoste> before it Xorg is at 1G of RSS (which is still high, normally it's around 300M)
<flacoste> but after it, it climbs to 2G
<flacoste> and that's when the setMinimumSize warning is output
<flacoste> Riddell: any idea what I should try next?
<Riddell> hmm, maybe finding the widget that gets set, overriding setMinimumSize() and seeing what is calling it
<flacoste> Riddell: it seems to be related to the 'Maximizing behavior'
<flacoste> for some reason, it opens the window maximized
<flacoste> hmm, scratch that
<flacoste> it doesn't seem to be related
<davi_> jelmer, hi, where fetch_tags should be set? in branch.conf?
<jelmer> davi_: sorry, in what context?
<davi_> jelmer, bzr-git, you added a change that causes tags to not be fetched if a config option 'branch.fetch_tags' is set to false
<jelmer> davi_: in the branch.conf of the branch you're fetching from, locations.conf or bazaar.conf
<davi_> jelmer, none of them seem to work. does it apply to push?
<jelmer> davi_: "branch.fetch_tags = True" ?
<davi_> jelmer, False, i'm trying to disable the fetch of tags.
<jelmer> davi_: fetching tags is disabled by default
<davi_> jelmer, hum, why do I get a GhostTagsNotSupported exception then?
<jelmer> davi_: can you paste the traceback?
<davi_> jelmer, http://pastebin.com/NuyJZYPr
<davi_> jelmer, fwiw, it only happens if the destination git repo is empty
<sorin> Hello.
<sorin> How many of you use oh-my-zsh?
<jelmer> sorin: I'm a zsh user
<jelmer> davi_: ah, that's a slightly different code path
<jelmer> davi_: I think I know what's wrong but don't have time to look now. can you file a bug ?
<davi_> jelmer, will do
<sorin> jelmer, I am specifically interested if people use oh-my-zsh, not zsh.
<jelmer> sorin: ah, sorry - I don't have experience with that
<nigelb> sorin: yes, I do
 * flacoste is happy
<flacoste> qbzr works again
<flacoste> after applying the work-around for bug 805303
<ubot5> Launchpad bug 805303 in xorg-server (Ubuntu Oneiric) "Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WIDGET (widget)' failed with the default qt4 gui" [Critical,Confirmed] https://launchpad.net/bugs/805303
<mgz> crazy.
<mgz> I hope that says something good about the way I wrote these tests.
<mgz> Completely changed the implementation of the reporting and they all still pass.
<kees> hello! I'm trying to get a list of files added per revno. using "bzr log -v" is crazy slow. is there some faster way to get that info?
<Noldorin> hi jelmer
<jelmer> hi Noldorin
<jelmer> hi kees
<Noldorin> kees, it shouldn't be that slow...isn't for me
<Noldorin> jelmer, any progress in your busy schedule? :-)
<jelmer> kees: what sort of performance are you getting?
<kees> Noldorin: my tree has about 4000 revnos
<kees> jelmer: 30 seconds per about 50 revs
<jelmer> kees: hmm, that is slow indeed
<jelmer> (I was going to say it wasn't quick here either, but at ~200 per 5 seconds it's still a lot better than for you)
<jelmer> kees: is this with a recent version of bzr, and the 2a format?
<jelmer> Noldorin: nope, sorry
<kees> yeah, 2.3.4 2a
<Noldorin> jelmer, no problem...is it proving tricky then eh?
<kees> the man page even carries a warning about the slow speeds
<Noldorin> kees, you're not running on a pentium I by chance are you? ;-)
<kees> haha no
<kees> core2 duo
<Noldorin> ok, so not terrible...
<Noldorin> jelmer, i'm tempted to think black-box debugging is not being very helpful here. we are both sturggling it seems...
<Noldorin> hrmm
<jelmer> kees: what size is the tree?
<jelmer> Noldorin: I haven't had time to look at it at all yet
<kees> 57M	.bzr
<jelmer> kees: sorry, I mean the rough number of files in a checkout
<kees> oh!
<kees> er
<kees> a bit under 9000
<jelmer> in that case, you could be hitting inventory paging issue that was fixed for 2.4
<jelmer> kees: is this is a public tree?
<kees> jelmer: yeah, one sec
<kees> lp:~ubuntu-security/ubuntu-cve-tracker/master
<kees> ah, my full bzr log -v finished. 23 minutes :)
<jelmer> kees: hmm, that is indeed surprisingly slow
<jelmer> the launchpad tree is a lot bigger and has more revisions but running "bzr log -v" there is ~200 per 5 seconds
<jelmer> kees: on your branch it's ~100 per 10 seconds
<kees> weird
<Noldorin> jelmer, ah ok. :-(
<Noldorin> jelmer, i know i'm pestering you about it so i don't want to too much... is there any other bzr-dev i should deal with?
<Noldorin> bzr-git dev *
<jelmer> Noldorin: I'm the only one who's working on bzr-git
<jelmer> Noldorin: the best thing you can do to help is still to provide some sort of script which reproduces the issue from scratch
<Noldorin> jelmer, fair enough. i just wanted to share the workload, but in this case let's just take our time :-)
<Noldorin> jelmer, yes i spent ~4 hours trying to do that yesterday with no luck
<Noldorin> black-box testing is very difficult for such problems as these
<jelmer> even if you copy all the contents out of r46, add them in an empty bzr tree and then try to make the same changes as r47?
<Noldorin> jelmer, i get shitloads of merge conflicts then
<Noldorin> not doable
<jelmer> Noldorin: I mean manually
<Noldorin> oh haven't tried
<Noldorin> that woudl take a long time
<Noldorin> i'd have to figure out which lines of code i wrote
<Noldorin> which are many
<jelmer> the code doesn't matter
<Noldorin> no?
<jelmer> it's the renames, etc that do
<jelmer> and whether the code changed
<Noldorin> oh ok
<Noldorin> i can try now then
<Noldorin> i suspect it will cause no error
<Noldorin> something tells me that...
<Noldorin> but let's see
<PawnStar> hi
#bzr 2011-09-17
<Noldorin> hi jelmer -- i have some news
<Noldorin> hi jelmer
<Noldorin> i got some interesting results last night
<Noldorin> back
<Noldorin> hey jelmer
<Noldorin> jelmer, you around yet? :-)
#bzr 2011-09-18
<Noldorin> jelmer, hello?
<jelmer> Noldorin: hi
<jelmer> Noldorin: just got home, about to get some sleep.. what's up?
<Noldorin> jelmer, sorry to bother you again, but at least it's just news :-)
<Noldorin> good news, perhaps
<Noldorin> i reproduced the issue from scratch
<Noldorin> it turns out it's *not* to do with the renames
<jelmer> ah, cool
<Noldorin> or noy *only* the renames at least
<jelmer> can you add some notes to the bug report?
<Noldorin> the tests seem to indicate that the renames and modifications together create the problem
<Noldorin> sure
<Noldorin> jelmer, first recommendation to a solution is now to make sure that the 3 sets of operations are performed in the correct order: 1) addition 2) renames 3) modifications
<Noldorin> will add some notes tomorrow. late here too :-)
<Noldorin> jelmer, good night for now!
<ricardo_sdl> I'm using bazaar version 2.3.4. Just copied the project folder from another computer and I'm getting this error message: bzr: ERROR: Unknown bzrdir format: 'Bazaar-NG meta directory, format 1\r\n'
<ricardo_sdl> I think it's probably because the bazaar on the other machined was a older version, how can I fix this?
<Noldorin> hi jelmer
<Noldorin> jelmer, well, let me know when you're around
<jelmer> Noldorin: hi
<jelmer> Noldorin: I saw your comment; do you have a recipe to reproduce the issue though ? (we already knew it had something to do with renames)
<Noldorin> jelmer, well i provided more information at least :-P
<Noldorin> jelmer, yes, I can post the workflow as a comment
<Noldorin> will do so right now
<jelmer> Noldorin: I mean how to reproduce it without using the ircdotnet tree
<Noldorin> jelmer, well i've reproduced it in a different branch using the same files, that's all
<Noldorin> jelmer, the key is renames *plyus* modifications though
<Noldorin> *plus*
<Noldorin> have you checked how your lib orders them?
<jelmer> Noldorin: it's an independent test case (that we could add to bzr-git) that I'm after.
<jelmer> Noldorin: the issue indeed has *something* to do with the order in which tree objects are created in bzr-git
<Noldorin> well i'm happy with last night's discoveries, even if you aren't :-P
<jelmer> sorry, I didn't mean to come across negative..
<Noldorin> that's fine heh
<Noldorin> i celebrate small victories :-)
<Noldorin> jelmer, got to go now, but will be back later. keep me updated!
<Noldorin> cheers, bye
<jelmer> bye
<jelmer> talk to you later
<Noldorin> back
<Noldorin> jam, hi there
#bzr 2012-09-10
<mgz> morning!
<jelmer> hi mgz
<jam> mgz: morning!
<mgz> hey jam
<mgz> we gatecrashing red's call this morning?
<mgz> and now I see we are...
<jam> mgz: so what can I do for you to get: https://code.launchpad.net/~jameinel/bzr/2.5-unending-sendall-1047309/+merge/123268 merged?
<mgz> jam: maybe we should just merge it, but I don't really like heuristic workarounds for upstream bugs
<jam> jml: I think I have a fix for your issue that has landed in lp:bzr/2.5, are you comfortable testing it out and confirming?
<jam> mgz: I don't see an explicit statement that 'send must not return 0 bytes'.
<jam> so I can't say it is strictly a bug in paramiko.
<jam> and we still need to workaround it in bzr for whatever versions people are going to use/we are going to ship.
<jml> jam: sure.
<jam> mgz: At this point I'm much more on the "lets get it working" side of the fence.
<jam> jml: It hasn't landed in trunk yet, because I have a couple other fixes I want to land, and just merge up 1 tiem.
<mgz> well, in this case returning 0 means ECONNRESET... but we don't know if that's what it'll always mean
<mgz> I think I'd prefer treating it as always ECONNRESET and muttering something, were it not for the fact this isn't a well exercised codepath in general usage
<jml> jam: I can run 'bzr di' successfully in the lightweight checkouts I have using lp:bzr/2.5.
<jam> mgz: well it arguably means ssh.EOF
<jam> or EPIPE
<jam> or...
<jam> (paramiko does have a way to single that it is disconnected, but I'm not getting that here, and I really don't know why.)
<vila> jam, mgz: http://developerweb.net/viewtopic.php?id=2956
<vila> jam, mgz : From that, I'd say: send() returns 0 because it expects something else to call recv and get the EPIPE, a test should be able to reproduce and then the unknown can vanish
<jam> vila: send returns 0 because of paramiko
<jam> completely orthogonal to EPIPE
<vila> jam: and why does paramiko do that ?
<jam> only particularly related because paramiko looks like a socket to our code
<vila> I fail to see how that answer my question
<jam> vila: it doesn't, it finishes my sentence.
<jam> paramiko does X, socketpair does Y
<jam> socketpair is raising a EPIPE
<jam> paramiko is returning 0 bytes sent
<jam> windows was using an actual PIPE to the subprocess, and was getting something else.
<jam> sometimes EINVAL, sometimes EPIPE
<vila> jam: forget about windows when it comes to sockets, that's not the best implementation to understand what *can* happen, I won't call it buggy but it certainly only exhibit only a subset of the possible behaviors
<jam> (we use a socketpair to communicate to the subprocess when we can, because then we can recv(1024) without worrying about blocking, rather than having to read(1) when we don't know how big the next reques tis)
<vila> the point of the url above is that the EPIPE *may* be available on the read side and the write side is then having a weird behavior of returning 0 on send
<jam> vila: *paramiko* is returning 0 on send, which is not a socket
<jam> we are getting an EPIPE on the write side
<jam> (not necessarily SIGPIPE, which is what you linked)
<vila> jam: what matters is that paramiko *is* using sockets, no matter what it presents to you
<jam> vila: you're missing what actual errors we are getting running things in the world.
<vila> ?
<jam> vila: If we use BZR_SSH=paramiko, and get disconnected, we hang indefinitely because paramiko returns 0 bytes for the send, and no error.
<jam> so I translate that into some other error.
<jam> If we use BZR_SSH=openssh on Linux, we communicate with the 'ssh' subprocess using socketpapi
<jam> socketpair
<jam> and we get socket.error(EPIPE) raised when we try to send() to it.
<vila> So what ? You're not explaining why paramiko behaves differently
<jam> vila: because it does
<jam> You're welcome to dig into the paramiko code to explain why it doesn't behave identically to a socket to us.
<vila> saying X does Y doesn't explain why X does Y
<jam> I don't really care enough.
<jam> it is really hard to maintain paramiko, so I'd rather just work around it.
<jam> given all versions across all platforms that bzr-2.5 should be available on.
<vila> fair enough, I'm just saying that working around without understanding is not the best way to avoid bugs in the long term
<vila> and one the key points here is the difference between shutdown and close, but hey, it's up to you to dig that or not
 * jelmer totally digs those socket shenanigans
<jam> vila: given that it is being done in your free time, you are welcome to devote as much time as you would like digging into the paramiko case :)
<vila> the more cruft added there the less incentive it is to me to touch this code :)
<ahasenack> I have a branch at r656 which gets merge conflicts when I merge it with another one
<ahasenack> at r652, the merge works fine
<ahasenack> now, my question is about bzr revert
<ahasenack> if I do "bzr revert -r 652" and commit, and then merge, there are the conflicts
<ahasenack> but, if I do "bzr branch -r 652" into a new branch, and merge that one, there are no conflicts
<ahasenack> shouldn't the result of "bzr revert -r 652 + commit" and "bzr branch -r 652" be the same?
<ahasenack> I thought revert means "bring the branch back to that revision"
<ahasenack> and branch is "copy out that revision into a new branch"
<ahasenack> funny, there is no difference in the code between the result of "bzr revert -r 652" and "bzr branch -r 652"
<ahasenack> yet only one of them merges without conflicts
<ahasenack> is this expected or a bug in bzr?
<jelmer> ahasenack: it does have an effect on the history
<jelmer> even f the contents are the same
<ahasenack> I wanted history record that I had to revert to 652, otherwise I would have used uncommit
<ahasenack> would have bzr merge . -r 653..652 (for example) produced a more merge-friendly result than revert -r 652?
<jelmer> ahasenack: I think that would have the same result as the revert
<ahasenack> so reverts are bad for merges? uncommits are better, if possible?
<ahasenack> a branch is merged, but introduces a bug
<ahasenack> you quickly revert
<ahasenack> the bug is fixed, and you merge again
<ahasenack> that's my use case, except now it's conflicting
<ahasenack> hm, revert leaves things a bit nutty
<ahasenack> after bzr merge, bzr status tells me it thinks it needs to add a .OTHER file
<ahasenack> Contents conflict in canonical/landscape/schema/main/patch_147.py
<ahasenack> and then
<ahasenack> $ bzr st
<ahasenack> added:
<ahasenack>   canonical/landscape/schema/main/patch_147.py.OTHER
<ahasenack> :)
<ahasenack> ok, let me rephrase that as :(
<jpds> ahasenack: bzr remove canonical/landscape/schema/main/patch_147.py.OTHER ?
<ahasenack> jpds: it only showed its head after bzr merge, it was never "bzr add"ed to the tree, I can't explain that
<ahasenack> I had to revert the revert, then merge
<vila> ahasenack: if I'm not mistaken, the OTHER branch added patch_147.py and so did the THIS branch, hence the conflit.
<ahasenack> vila: it was weird indeed, that patch introduced a bug
<ahasenack> vila: so I reverted it, while it was fixed upstream
<ahasenack> vila: then I merged again, and there was the conflict
<vila> ahasenack: if you dig the history with (bzr st -rx..y --show-ids) you can probably confirmed that and find some revision were the file is removed/added
<ahasenack> vila: I had to undo the revert, then merge
<ahasenack> also, it thought the code I reverted was there. Without the undo part, the merge wouldn't bring in the fixed code, it was very confusing
<ahasenack> lesson: be careful with  bzr revert
<vila> ahasenack: right, so probably reverting put you back in a time where the file had a different file-id
<ahasenack> it was like 652: ok; 653: introduced the bug; 654: revert -r 652
<ahasenack> and then things got out of hand
<ahasenack> I had to undo 654
<vila> ahasenack: it's not 'revert' per-se, more an issue with a file removed/added in one branch
<ahasenack> that patch file was added in 653, and "removed" in 654 via bzr revert
<vila> ahasenack: bzr st --show-ids -r652..653 ?
<vila> ha right
<ahasenack> yeah
<vila> *that* is the "bug"
<vila> you fooled bzr :-/
<ahasenack> something I should file?
<vila> (which is a bzr bug in itself to be fool-able this way)
<ahasenack> my situation is fixed not, btw, after I did that undo, then the merge worked fine
<ahasenack> s/not/now/
<vila> unfortunately, I don't think so, it's the same underlying issue than "parallel import"
 * vila nods
<vila> ahasenack: and you probably won't fall in this trap again
<ahasenack> oh, who knows :)
<ahasenack> I'm not sure there was another way out of this
<ahasenack> unless I used uncommit
<ahasenack> once I detected the bug
<ahasenack> but I wanted to preserve history, I wanted it to be recorded that a bug was found and the code had to be reverted
<ahasenack> and I did use revert in other occasions
<vila> ahasenack: a reverse merge is the working way
<ahasenack> but those probably didn't have an added file
<ahasenack> vila: bzr merge . -r N+1..N?
<vila> yup
<ahasenack> ok
<vila> it keeps track of the file-ods
<vila> ids
<ahasenack> good to know, and I find it more intuitive too
<vila> the root issue here is adding the same file (at the same path) with a *different* file-id which is what the confusing 'content conflict' is about
<ahasenack> a reverse patch
<vila> content here refer to the inventory content: two files want to occupy the same path (they are different as far as bzr is concerned because they have different file-ids)
<ahasenack> the content is different indeed
<ahasenack> but something feels off with revert
<ahasenack> for example, the 653 changeset brought in other fixes, not just the buggy patch_147.py one (new file)
<ahasenack> after I reverted that
<vila> but for mere mortals ignoring file-ids, it's (as you put it) nutty
<ahasenack> and then merged again with upstream after patch_147 was fixed, the other fixes I reverted weren't brought in again
<ahasenack> it's as if bzr considered them applied
<ahasenack> it was pretty "nutty", I ran bzr merge, got those conflicts, and a plain diff between the two branches still showed many changes that were not brought in
<ahasenack> all part of that reverted 653 commit
<ahasenack> anyway, lunch time
<ahasenack> vila: thanks for the discussion
<vila> ahasenack: not sure how to help here without seeing more details (not sure it's worth the trouble if you're now safe)
<vila> ahasenack: my pleasure
#bzr 2012-09-11
<JPeterson> how do i disable the scheduled tbzrcache?
<hikiko> hello, how can i see the number of current revision in bzr to compare it with the previous revision?
<vila> hikiko: bzr revno
<hikiko> thank you vila
<mgz> morning!
<jelmer> moin mgz, jam
<mgz> hey jelmer
<jam> hi jelmer, would you want to do a quick mumble before the standup in 20 min?
<jam> mgz: hi
<mgz> not standup now?
<mgz> in 20 mins is fine for me.
<jam> mgz: well, our standup before the Maas standup
<jelmer> jam: sure
<bigjools> jam: shall we do team standups separately to a maas standup?
<bigjools> not sure if it's useful
<bigjools> and, echan, sorry
<ferpeter> hi, i have a little problem. i try to init a repo to a remote machine (over sftp). the directory  tree semms to created, but i got error 13
<ferpeter> i mean i controlled the dir, they are there
<ferpeter> no one has any idea?
<ferpeter> so i know it.. i used a pendrive (in sheevaplug) formatted on fat32.
<ferpeter> i tried with a hdd with etx3 filesystem.. now it works
<ferpeter> i found a reported bug about this..
<jave> hello
<jave> I have a local branch of an upstream repo. when I merge I quite often get conflicts in automatically generated files that are checked in upstreams. Is there some way to describe to the merge algorithm that I always prefer the upstream versions af a couple of files?
<mgz> jave: you can just use `bzr resolve --take-other auto_generated_file_a ...` after the merge
<mgz> and maybe set up an alias with those filenames
<jave> mgz: thanks
<jave> Im not really sure why i get a conflict to begin with.
<mgz> presumably, you build your branch locally
<jave> but I dont generate the files afaics
<mgz> which then includes something specific to your local changes/machine/timezone...
<jave> upstream generate them
<mgz> and upstream also commits with the file having it's local stuff, which then means merge doesn't know which to pick
<jave> hmm well.
<mgz> use `bzr remerge --show-base` after it happens to see what the specifics are
<jave> ah, ok
<mgz> persuading them to unversion those files would probably be best long-term :)
<jave> its the emacs repo and there was a longish flamewar about the files that I dont have the energy to reopen
<mgz> fair enough :)
<jave> unversioning the files is the obviously correct solution
<bjp> if i have a checkout thats a couple revisions behind its parent, how do i tag the working tree's revision and not the parents latest?
<LeoNerd> bzr tag -r123 "FOO"
<bjp> i have to look up the revision first? there's no -rlocal ?
<bjp> or equiv
#bzr 2012-09-12
<jam> bjp: bzr tag -r `bzr revno --tree` foo
<vila> hi all ! ;)
<mgz> morning
<jam> mgz: morning, care to hang out in mumble?
<jam> hi vila
<vila> mgz, jam: hey
<mnn> hi... after some time with bazaar, I've stumbled upon something
<mnn> I don't understand why parent_branch is shared for pull and merge
<mnn> I push/pull to the same location - on a remote server
<mnn> however I would like to merge from local trunk
<mnn> so if I have parent_branch defined to the push location (i.e. remote server) - bazaar explorer freezes sometimes - usually on refresh (I don't have very good internet connection)
<mnn> but if I set parent_branch to local trunk, bazaar explorer's bottom panel works the other way around - if trunk has revisions that my branch does not, it shows that " Branch has changes not present in its parent branch": new files in trunk are shown as deleted in my branch
<mgz> mnn: so, it's not shared as such
<mgz> there's also a submit_branch which is more merge related
<mgz> mnn: if you do `bzr info` from the branch that upsets explorer, what does it say?
 * SamB_MacG5 is happy, he finally found the pre-built ppc/i386 universal builds of Qt
<SamB_MacG5> Okay, I just made a shiny new Mac OS X 10.5 ppc/i386 universal installer for Bazaar, but how am I supposed to *test* the thing?
<SamB_MacG5> besides the obvious "does it install"
<SamB_MacG5> and "does it seem to work"
 * SamB_MacG5 supposes "bzr selftest" is relevant
<fullermd> Well, if selftest passes, it shows it works right.  If selftest fails, it shows that the tests are awesome.  Obviously, win-win   8-}
<SamB_MacG5> hmm, what's a good way to find the latest plugin versionss supporting bzr 2.3 ?
#bzr 2012-09-13
<fullermd> Mmm.  Dig back into the windows (or mac?) binary installer package thingies and see what they had?
<SamB_MacG5> I'm updating the mac installer sources, so the latter is right out
<SamB_MacG5> (already done!)
<SamB_MacG5> fullermd: well, I've discovered that the installer fails to bundle testtools ;-)
<fullermd> Sweet!  No test failures!   ;p
<SamB_MacG5> fullermd: crashing in the test harness doesn't really count ;-P
<fullermd> That's the sort of detail that needs to be glossed over if we're going to declare success and go to the circus instead.
<SamB_MacG5> That won't get me a working & tested installer, though, now will it?
<fullermd> Well, no, but there's cotton candy and a contortionist.
<fullermd> Which is pretty much the same as dealing with installers, really.
<SamB_MacG5> Eh, it really seems to mostly be a matter of selecting the versions of packages that go in, and configuring and building them ...
<SamB_MacG5> and waiting for the bzr docs to crawl through pdflatex ...
<fullermd> Ah, I have this dream that someday I'll find a documentation toolchain that isn't a pile of misery.
<fullermd> I expect it will be delivered by my flying pony any day now.
<SamB_MacG5> it's the page numbers that get you
<fullermd> Nnooo, I'm pretty sure it's the "whole stupid thing" part   :)
<fullermd> But you never know.  There might be some bizarre concatenation of circumstances that causes somebody to actually start maintaining and improving [open]jade some day, for instance.
<SamB_MacG5> I mean, I'm pretty sure that's why pdflatex gets rerun so many times on each document, even when nothing has actually changed
 * SamB_MacG5 was actually wishing someone would do that too
<SamB_MacG5> (maintain jade and friends)
<fullermd> Or somebody might dream up an XSLT/XSL-FO implementation that is none of "buggy and worthless", "written in java", "expensive proprietary non-cross-platform", or "multiple of the above".
<SamB_MacG5> so libxslt is buggy *and* worthless?
<fullermd> Well, I presume so just on GP.  But it doesn't handle the XSL-FO side anyway.
<SamB_MacG5> oh, right, FO
 * SamB_MacG5 isn't sure what's so great about FO
<fullermd> I think it stands for "f$*%ing owful".
<fullermd> But how else do you define output into a PDF?
<fullermd> I mean, I guess you could write an XSLT sheet that translates into manual Postscript.  There are worse fates than having to do that.  Though I have a little trouble thinking of them.
<SamB_MacG5> were there even any halfway decent implementations when the spec was frozen, though?
<vila> SamB_MacG5: hmm, testtools for 2.3... It's a shame we didn't track that explicitly, so
<vila> i'd guess 0.9.2 or 0.9.4
<SamB_MacG5> I freely admit that, as a programming language, TeX seems to rival intercal...
<vila> and I'm not sure it has ever been bunbdled
<fullermd> Well, that's the flip side; given the work, that gives you great PDF-ish output.  But the choices to get HTML suck.
<fullermd> I _have_ considered things like XSLT/DSSSL/programmatic transforms to turn $random_SGML_application into TeX for the PDF side.  But I eventually sobered up.
<SamB_MacG5> vila: well, since I'm building my own installer *anyway*, it will just take a bit more work to add that ...
<fullermd> I s'pose one plausible conclusion from the state of things would be that nontrivial stuff isn't _meant_ to be documented.
<SamB_MacG5> fullermd: how does that differ from what jade does?
<fullermd> Largely, that I'd have to write it all, which...  uh...
<fullermd> No.  Just, no.
<SamB_MacG5> well, I mean, I suppose the actual "massage into TeX" part is hidden...
<fullermd> I'm not Don Knuth; I'm not about to put *my* stuff on hole for 30 years, so I can write a peripheral thing I'm not really interested in to support it  ;p
<fullermd> s/hole/hold/
<SamB_MacG5> I thought it was more like 10 years
<fullermd> Well, depends what you count as the end.  We're still only a third (a fourth?) of the way to having Vol IV out...
<vila> fullermd: just be patient...
<fullermd> vila: Yeah, yeah, patience; how long will that take?
<SamB_MacG5> but weren't volumes A through E mostly finalized in a decade?
<SamB_MacG5> granted, only fools use Volume E directly rather than using the Type 1 conversion ...
<vila> SamB_MacG5: from some random notes: 0.9.8 should be ok with 2.4, so that should give you an upper bound
<vila> fullermd: not much longer ;)
<SamB_MacG5> vila: I was just going to try 0.9.15, since that's the final release supporting Python 2.4 and 2.5
<vila> SamB_MacG5: hmm, let say the relationship between bzr and testtools has been a bumpy road so, 0.9.15 *may* include all the needed fixes, otherwise *some* precise older version will be required :)
<vila> SamB_MacG5: thanks for working on this though
<vila> SamB_MacG5: and don't forget to make a merge proposal against lp:bzr-mac-installers/2.3 when you succeed
<SamB_MacG5> vila: of course
<vila> cool, even more thanks then ;)
 * SamB_MacG5 -> bed
<mgz> morning!
<jam> morning mgz
<delinquentme> Heyyy! anyone know if there are documented issues with Bzr interacting with Git?
<delinquentme> could someone tell me aboot dem =P
<jelmer_> delinquentme: how do you mean?
<delinquentme> jelmer_, does anyone have both running on their system happily
<SamB_Mac_> delinquentme: sure
<SamB_Mac_> I thought you meant "is bzr-git perfect"
<jelmer_> delinquentme: sure, they can be installed together without problems
<delinquentme> ok cool
<delinquentme> yeah im usually a git kid but I think I might be doing some VC w bazaar
<delinquentme> any recommended " go to " tutorials for the newbie?
<jelmer_> delinquentme: http://doc.bazaar.canonical.com/latest/en/mini-tutorial/
<SamB_Mac_> darnit, I should have thought things through before running ./build.py ...
<SamB_Mac_> now I'll have to wait for pdflatex :-(
<SamB_Mac_> ... or I could reorder the packages in config.py ...
 * SamB_Mac_ puts bzr last
 * SamB_Mac_ waits for pyqt to fail to build
<delinquentme> O_o;;;
<delinquentme> im on ubuntu .. and it doesnt come preinstalled?
<jelmer_> delinquentme: apt-get install bzr
<delinquentme> yeah sudo apt-get install bzr
<SamB_MacG5> delinquentme: why would it come preinstalled?
<SamB_MacG5> I mean, unless you chose a "install a bunch of development tools and such" option during installation
<delinquentme> OMggg it was sooo easy!!!!!
<delinquentme> GNU/Linux: Bazaar is probably in your GNU/Linux distribution already.
<delinquentme> now a more complex question
<delinquentme> how to add / push to a remote repo via ssh
<delinquentme> i guess i can google dis.
<SamB_MacG5> delinquentme: "bzr help urlspec" may be useful
<delinquentme> some kind of log command?  I added files to the repo ... and now I'd like to confirm that I only added the one file.
<delinquentme> @_@
<delinquentme> http://stackoverflow.com/questions/3682817/can-i-edit-the-message-of-an-older-revision-in-bazaar
<delinquentme> I cant change the commit message without crapping on the repo?
<mgz> delinquentme: you might find it useful to follow <http://doc.bazaar.canonical.com/bzr.2.5/en/tutorials/tutorial.html>
<delinquentme> yeah I've actually got it open :D
<mgz> on changing commit messages, the important thing to understand is that dvcses let you edit history, but it's socially discouraged on public branches, because everyone needs to agree on the history to share changes
<mgz> so, if you've just committed something and made a tyop, you just uncommit, then commit again with the fix
<mgz> but rather than fixing an error from several months ago by changing all the history since then, you should generally just accept that history is history (though there are ways to do it with everyone's cooperation if it really matters)
<barry> hi folks, any possibility of getting a quick fix to the importer failure for gtimelog?  http://package-import.ubuntu.com/status/gtimelog.html#2012-07-04 19:41:22.610986
<barry> jelmer_, jam, james_w`, vila, mgz, or maxb (not to leave out any of the usual suspects :) ^^
<maxb> oh, it's one of those
<barry> ;)
<maxb> let's see what it looks like when branched locally
<mgz> maxb is quicker on the draw :)
 * maxb glares at someone who has introduced a bad launchpadlib version check in lp:udd
<maxb> ImportError: Version of launchpadlib 1.10.2 less than 1.9.0
<maxb> oh no it isn't :-)
<mgz> hm, that was probably me.
<mgz> being lazy and not wanting to split and intify
<mgz> I'll fix.
<delinquentme> a remote repository is called what?
<maxb> barry: So this looks pretty easy to fix, in terms of me knowing exactly what data needs to go into udd's sqlite db to make it accept Martin's revisions and move on, but I don't have a neat tool to do that, so I'll need to construct some manual SQL (not that much, 1 line for natty, oneiric, precise, quantal each) - probably take me half an hour to evade other things I'm busy with and get to it, though
<barry> maxb: thanks, that's fine.  it's lunch time here in us/eastern.  i *really* appreciate the fix!
<mgz> maxb: that sounds painful, is this not something we can hack into a script?
<maxb> sure, but not I'm not good enough with bzrlib to do it before I go out for the evening today
<mgz> maxb: obviously do what ever is easiest for you, I'm just aware of the fact I'd be stuck if you weren't handling it so some record of what you needed to do would be grand
<maxb> mgz: One-line summary - grab the head revision from each series branch, and insert its tag, revid and testament into the revids table
<mgz> maxb: <https://code.launchpad.net/~gz/udd/fix_launchpadlib_version_check/+merge/124250>
<maxb> mgz: It looks good to me, other than I have no clue what the behaviour is when you compare a string with an int
<maxb> I'd have to test that out before I could offer an opinion
<mgz> safe but not useful in python 2
<mgz> and udd won't be python3ing any time soon.
<mgz> I think any str is less than any int in Python 2, which is actually about what we want here
<mgz> so 1.0.0-beta < 1.0.0 if launchpadlib were insane enough to do that.
<mgz> (as "0-beta" < 0)
<maxb> heh
<maxb> In that case, MP gets my vote, though I'm not in range of a decent browser to enter it in at the moment
<SamB_MacG5> why am I not surprised that easy_install is responsible for breaking my build?
<mgz> ...didn't you approve an mp from a bus in the past? have you lost your fancy phone? :P
<mgz> SamB_MacG5: that'll learn ya
 * SamB_MacG5 really wishes there was a Python option to trace all sys.path changes
<SamB_MacG5> anyway, I commented out the bogus .pth line and it seems to be building now ... so maybe I'll be able to test an installer then ;-)
<SamB_MacG5> (It was sticking /Library/Python/2.5/site-packages before the stuff from PYTHONPATH)
<mgz> you should perhaps wish for the death of .pth files instead
<SamB_MacG5> this one was easy_install's creation, though!
<maxb> barry: Import completed.
<barry> maxb: thanks!
 * SamB_MacG5 wonders why the launchpadlib build didn't return nonzero, since it clearly failed ...
<jelmer> hmm
<SamB_MacG5> huh, this installer project seems to have stale version numbers in it ...
 * SamB_MacG5 grumbles about there not being a standard distutils target for running tests
#bzr 2012-09-14
<Noldorin> anyone here use bzr on Mac OS X??
<SamB_MacG5> yeah
<bob2> as always, better to just ask your question!
 * SamB_MacG5 is actually working on an updated OS X 10.5 installer for Bazaar 2.3
<SamB_MacG5> well, *these* plugin versions are clearly too new ...
<bjp> can i use bzr update or bzr pull in a way that discards any local workingtree changes?
<bjp> instead of creating conflicts
<LeoNerd> revert first
<LeoNerd> Or afterwards
<bjp> i thought thats what pull --overwrite did,
<bjp> can't do it in one command?
<lifeless> pull --overwrite discards conflicting history
<bjp> oh
<lifeless> there isn't a reset --hard, you need two commands - sorry.
<bjp> i wish there was a way to batch commands or something, the majority of the time for my script is ssh login/auth for bzr commands :(
<LeoNerd> Use an ssh key
<LeoNerd> Or maintain a persistent connection using ControlMaster
<bjp> i am using an ssh key, and ControlMaster doesn't work on windows :(
<bjp> i've looked into it a few times, could never find a good way to do it
<LeoNerd> Ahhh
<bjp> i do a revno + update on ~50 projects in a script
<lifeless> you can drive it through python
<bjp> so the connection/auths take a while
<bjp> that might be worthwhile
<bjp> the script is in python... i'm just using subprocess to launch bzr
<bjp> bzrlib.workingtree.WorkingTree opens and maintains a connection?
<SamB_MacG5> huh? Nobody tagged bzr-loom 2.1?
<fullermd> That's pretty warped.
<mwhudson> fullermd: you're a bad man
<fullermd> Yeah, but I look so good doing it.
<SamB_MacG5> http://bazaar.launchpad.net/~bzr-loom-devs/bzr-loom/trunk/revision/109 appears to be the revision that should have been tagged ...
 * SamB_MacG5 wonders what the point of having internet drafts expire is
<lifeless> jam: is https://bugs.launchpad.net/bzr/2.0/+bug/433779 now Fix Released ?
<ubot5> Error: ubuntu bug 2 not found
<jam> lifeless: from what I can see, the patch was *not* backported to 2.0.* it only landed in the 2.1 series.
<jam> so Won'tFix may be more appropriate
<lifeless> jam: I just want it off of my 'fix committed' related bugs list :)
<lifeless> jam: call me selfish if you like :)
<jam> yeah, i'll clear it up
<lifeless> thanks!
 * SamB_MacG5 wonders what version of bzr-svn works with subvertpy 0.8.1
<dardevelin> hi everyone, I need some help regarding bzr+launchpad , i seem to be getting ConnectionReset reading response for 'BzrDir.open_2.1', retrying Permission denied (publickey). And I don't quite understand why since i generated a ssh key and already added to my launchpad account
<dardevelin> bzr lp-login nickname works fine (i think since no warnings errors or any kind of messages is sent)
<dardevelin> i'm on debian sid system btw
<dardevelin> i do know that the package python-paramiko has a bug on using non-default ssh ports
<dardevelin> would this be a reason ?
<lifeless> bzr+ssh runs on port 22, the default
<lifeless> so it shouldn't be
<lifeless> is there anything useful in ~/.bzr.log
<dardevelin> lifeless, humm let me check
 * dardevelin now remembers that he might have been stupid and used .bzr.log from another install
<dardevelin> lifeless, it does have quite a lot of stuff in here, seems like python errors
<lifeless> well, you could empty the file, try again, and anything thats in there would be relevant
<dardevelin> ok let me try login again
<lifeless> do you have your ssh agent running, with the key added ?
<lifeless> the possible causes are:
<dardevelin> ssh agent ? what do you mean
<dardevelin> the reason i ask is because i'm able to use git ::/
<dardevelin> i do get a warning though when using i3-wm that i don't get when using gnome wm... never really associated since all worked fine
<dardevelin> sorry i'm newb with vc systesm :/
<dardevelin> lifeless, i do have ssh-agent running at least that's what htop tells me
<lifeless> ok
<lifeless> so the possible causes for the error you get are:
<lifeless>  - wrong userid
<lifeless>  - key not available to the ssh-agent
<lifeless>  - wrong host
<dardevelin> host like machine name  that matches the public key ?
<dardevelin> if that's the case i'm pretty sure is correct, i just generate it
<SamB_MacG5> that doesn't actually do anything
<SamB_MacG5> you can put whatever you want there
<dardevelin> but it does match
<dardevelin> dardevelin@ycradnileved
<dardevelin> user id is darcy-develin (it's exactly what i used on my other install )
<dardevelin> so i'm left with ssh-agent not knowing the key
<dardevelin> i do have the ssh key with a different name specific for bzr
 * dardevelin goes look on how he can see what ssh-agent knows and how to make it know 
<lifeless> ssh-add path-to-key-secret-file might wrok
<dardevelin> i did it, let me try
<dardevelin> :O working now
<dardevelin> sweet
<dardevelin> lifeless, Thank you so much...
 * dardevelin feels happy to finally be able to fix some bugs on his debian machine 
<jam> mgz: since you seem to be in the bzr-code-review mindset... https://code.launchpad.net/~jameinel/bzr/2.1-all-reconnect-819604/+merge/123901 :)
<mgz> er, morning all!
<jam> mgz :)
<mgz> how are you jam sir?
<jam> mgz: just trying to clean and finish up my reconnect patch
<jam> mgz: a slightly cleaner version of the patch for bzr-2.2 is at: https://code.launchpad.net/~jameinel/bzr/2.2-all-reconnect-819604/+merge/124346
<jam> mgz: how was your day?
<mgz> jam: yeah, the 2.1 version seemed rather scary...
<jam> well, 2.2 may not be that much better overall :)
<jam> however, if you just do a 'vim -d MY_PATCH/file.py 2.5/file.py' things may be less scary.
<jam> As it is mostly the same code.
<jam> just missing some features/bug fixes from the years inbetween
<jam> mgz: i'm happy to work through it with you over mumble or something, as it would be nice to get it landed, because the 'merge up' is a bit of work that I don't want to drag out for a long time.
<jam> mgz, also standup in 20min or so
<mgz> jam, that sounds good (to both)
<jam> mgz: I'm there
<mgz> I am coffee'd
<jelmer> coffeefication ftw
<mgz> jelmer: reviewed your ping branch before I got the bus this morning
<jelmer> mgz: \o/
<mgz> over warningness: <http://pastebin.ubuntu.com/1204324/>
 * SamB_MacG5 hopes this next installer build gives him a working bzr-svn; he's getting tired of putting BZR_DISABLED_PLUGINS=svn before every other command
 * SamB_MacG5 also wishes again that distutils had a standard "test" command, even if it were just a stub by default ...
<jelmer> SamB_MacG5: why does it not work?
<SamB_MacG5> jelmer: well, it says subvertpy 0.8.1 is too old, but then goes and sticks its hooks into things anyway for some reason...
<SamB_MacG5> which works out badly
<jelmer> SamB_MacG5: it won't magically fix itself
<jelmer> SamB_MacG5: you can update the version of subvertpy?
<SamB_MacG5> no, I'm downgrading bzr-svn
<SamB_MacG5> stupid SVN 1.4 and all ...
<jelmer> ah, that's why you filed that bug
<delinquentme> Ok soo in git I can choose to " git push origin master "    IE  git push <repo> <branch>
<delinquentme> in bzr I've got a local ... "trunk" ?
<delinquentme> and I've got an origin trunk / repo ... as well as a development server
<delinquentme> where origin would be the name of a repo in git
<delinquentme> is a "trunk" the same as a repo?
<delinquentme> or is a bzr trunk more like a branch in git?
<LeoNerd> git allows you to store multiple branches in one filesystem location
<LeoNerd> bzr does not
<LeoNerd> So the "branch" is always implicit as there's only one
<LeoNerd> bzr push $REMOTE_URL   just pushes /the/ local branch to /the/ remote branch
<LeoNerd> Usually for branches I put  .SOMENAME  on the end of the URL
<LeoNerd> $ bzr branch my-project my-project.HACKERY; cd my-project.HACKERY; bzr push bzr+ssh://my.server/var/bzr/leo/my-project.HACKERY
<delinquentme> LeoNerd, Ok so different branches reside in different folders?
<LeoNerd> Yah
<delinquentme> Ok so heres a test case for you
<delinquentme> wait!  actually what is a repo in bzr?
<delinquentme> is it a trunk?
<LeoNerd> A repo is a shared storage location for lots of branches
<LeoNerd> bzr doesn't have a notion of a "trunk".. there are just branches.
<LeoNerd> Sometimes, branches may share a common history
<delinquentme> Hmmmm
<delinquentme> ok so in bzr its called a repo as well
<delinquentme> check!
<LeoNerd> If you call one of them a trunk, that's purely an end-user concept; one branch that you just consider as the canonical source
<delinquentme> ok so I've got the remote primary repo
<LeoNerd> A repo allows multiple branches that do share history, to share on-disk storage, basically.
<delinquentme> ok I think i follow.
<delinquentme> but on the term "trunk" while its just an end user concept
<LeoNerd> A repo is a storage of revisions; a branch gives a name to some particular revision; the branch stores its history of revisions in its repo
<delinquentme> it is *semantically* tied into bazaar right?
<LeoNerd> Not really
<delinquentme> so then I could call a trunk ... a suitcase
<delinquentme> and it would be just as bazaar related?
<LeoNerd> If you have two branches that have, say, 10 common revisions, then each diverge for the final 2 each, bzr doesn't know or care which if either you consider a "trunk"
<delinquentme> IDK the devs who I'm working with say trunk alot
<LeoNerd> E.g. I keep my .vimrc in a bzr branch across all my machines; none of these could be considered any more a "trunk".. they're all just peers that I merge between
<delinquentme> like is "trunk" a term they came up with or is it something that other bzr users use as well?
<LeoNerd> It's standard VCS terminology
<LeoNerd> It goes back many decades, mostly to the non-DVCSes like CVS and SVN
<LeoNerd> The non-branch in a CVS directory is usually called the trunk; a SVN project usually has  /trunk  /branches  /tags
<delinquentme> ok cool
<delinquentme> next question
<delinquentme> I pull from a primary repository to my local machine
<delinquentme> so local machine is a direct copy of what is up on the repo
<delinquentme> now.. someone else copied the same code onto a development server... and I'm about to push my local code ... up to THAT dev server
<delinquentme> this will create something akin to a " fast forward " right?
<LeoNerd> "fast forward" IIRC is what git calls a strictly non-divergent update, where one side is an ancestor of the other
<LeoNerd> This is what bzr pull or push wants to do
<delinquentme> correct it is a non-divergent
<delinquentme> ... i guess it would also be non-convergent
<delinquentme> both code sets have the exact same history .. ending on the same commit
<delinquentme> and 1 branch has more
<delinquentme> the branch with fewer commits ... get a fast forward on merge
<LeoNerd> Yah, that's a push or pull operation
<LeoNerd> A "merge" in bzr specifically joins back together two divergent histories, where neither is a strict ancestor of the other
<delinquentme> LeoNerd, Is there a way to do something like a --dry-run?
<delinquentme> where it tells you what it would do in a push operation ... without actually doing it?
<LeoNerd> Probably -n ?
<LeoNerd> Hrm.. well,  bzr missing  will explain what's missing
<LeoNerd> And ofcourse things like  bzr diff
<delinquentme> and -n denotes what option?
<delinquentme> this is an option on "bzr push" right?
<LeoNerd> Pure guess, but from the help I'm not sure it has one.. :/
<delinquentme> hmmm
<delinquentme> and what about aliases?
<delinquentme> like instead of typing out a whole server IP and local directory path
<LeoNerd> ?
<delinquentme> can I declare say "development"
<delinquentme> bzr push development
<LeoNerd> Ah, pass. Possibly..
<delinquentme> to push to sftp://nachocheeze@109.1.2.111:3000/usr/local/
<LeoNerd> Someone else might know
<fullermd> bookmarks plugin
<LeoNerd> Also /me => lunch
<delinquentme> tanks :D
<delinquentme> I know its a bad idea ... but can a server be running a trunk
<delinquentme> by running I mean displaying the contents of a trunk to the public who happen to be accessing that server?
<delinquentme> or is it a bad idea?
<smoser> jelmer, you around?
<smoser> you've helped me with bzr recipes before
<smoser> https://launchpadlibrarian.net/115990138/buildlog.txt.gz
<smoser> failed from https://code.launchpad.net/~maas-maintainers/+archive/dailybuilds/+recipebuild/307084
<jelmer> hi smoser
<smoser> hey.
<jelmer> smoser: ah, that looks like a known bug in the bzr builder
<smoser> i'm good at finding stuff like that.
<smoser> jelmer, were you just going to hold me in suspense?
<smoser> http://paste.ubuntu.com/1205495/ is all i could come up with
<jelmer> sorry, got distracted by something.. back now
<smoser> but i can't reproduce the failure here with bzr builddeb
<jelmer> smoser: it's bzr builder that's the problem
<jelmer> smoser: it tries to apply all patches and convert the package to a native package
<smoser> but it worked before.
<smoser> ie, not long ago
<smoser> https://code.launchpad.net/~julian-edwards/+recipe/maas-daily
<SamB_MacG5> jelmer: that sounds kind of evil ...
<smoser> recipe not changed.
<smoser> the complaining file *did* change
<jelmer> smoser: you didn't have those patches previously I think?
<jelmer> or at least not patches that introduced new files?
<smoser> i didnt hvae that one specifically.
<smoser> you're probably correct
<smoser> none that introduced new files probably.
<smoser> previously in that branch the file actually lived in tests/ (ie, not patched in)
<smoser> but i intended to fix the warning/error of --source-option=--abort-on-upstream-changes
<smoser> (branch above == packaging branch)
 * SamB_MacG5 tries the installer
<jelmer> SamB_MacG5: What's evil about it? Without that behaviour building would fail.
<SamB_MacG5> jelmer: the "convert to native package" part
<jelmer> SamB_MacG5: Yes, without that behaviour the build would fail.
<SamB_MacG5> buy maybe you meant that differently than I read it
<jelmer> SamB_MacG5: as there is no orig tarball
<jelmer> SamB_MacG5: note that this is for daily builds
<smoser> jelmer, you have a suggestion for how to fix this ?
<SamB_MacG5> sure, sure, it just strikes me as a *little* evil
<smoser> if i have to at the moment i can just drop the patch (or comment it out)
<jelmer> SamB_MacG5: If you don't like it, you could always just have a recipe that is native from the start.
<jelmer> smoser: The easiest way to work around it is to have your recipe build a native package.
<jelmer> smoser: and/or somehow get rid of debian/patches
<smoser> hm.
 * jelmer looks for the relevant bug
<SamB_MacG5> man, it really seems like some of the stuff in this installer project ought to be built by the scripts rather than baked in...
<smoser> maybe for now i'll just not apply that patch.
<SamB_MacG5> jelmer: I guess I can't help but think that the "right" thing would be to build an orig tarball from the source tree ...
<smoser> well, thats what the recipe says to do.
<jelmer> SamB_MacG5: which source tree? there is only one tree, and that has the debian source
<SamB_MacG5> isn't there some code somewhere?
<jelmer> SamB_MacG5: yes, but it's not clear which code is from upstream and which code is from the debian package
<smoser> jelmer, for stop gap, do you think i can just not apply that patch ?
<SamB_MacG5> hmm, oh, right
<smoser> (just comment out in debian/patches/series )
<SamB_MacG5> native packages can still have patches...
<jelmer> smoser: yes - the easiest way to do that is to merge in an extra branch that has a change to remove that line
<smoser> as i need something "right now" to move on something else, and that patch i think can be delayed a bit.  and, then there is the fact that it actually works if i dont have it as a patch, but the file lives in test/ in the packaging branch.
<smoser> but that i didn't like becasue of --source-option=--abort-on-upstream-changes
<smoser> i guess i'll just put it back the way it was as that built on the dailybuild server at least.
<SamB_MacG5> darn, bzr-svn 1.1.0's test suite doesn't seem to like bzr 2.3 :-(
 * SamB_MacG5 wonders why the quick reference card is sideways
<SamB_MacG5> is there a way to skip asking a plugin for tests, but still load that plugin?
<jelmer> SamB_MacG5: not really
<SamB_MacG5> darn
<SamB_MacG5> so not only can I not run bzr-svn's tests, but I can't have it loaded when I run the other tests :-(
<jelmer> SamB_MacG5: really, if you have a version of bzr-svn that's incompatible you should just uninstall it.
<SamB_MacG5> jelmer: this one is supposed to be compatible, though
<SamB_MacG5> just the tests code doesn't seem to be
#bzr 2012-09-15
<delinquentme> http://pastie.org/4722903  QUESTION on this one.
<delinquentme> so it now seems that the "trunk" mentioned here is kind of akin to a branch in git
<delinquentme> like in this example ... you're initializing a project ... as well as a subset of that project with specific code
<delinquentme> silly question: is bazaar named after the practices in "the cathedral and the bazaar" ?
<delinquentme> when we're talking the information which is returned by the command " bzr info <repo> "
<delinquentme> this will be determined FIRSTLY by if there is a .bzr file within that directory
<delinquentme> right?
<SamB_MacG5> delinquentme: depending on plugins, .git and whatever SVN uses can also matter
<fullermd> info will find the nearest branch upward from where you are, and talk about stuff relative to that.
<delinquentme> bzr: ERROR: Not a branch:
<delinquentme> so if i get that ....
<delinquentme> bzr is actually checking the parent dir to my current one ?
<delinquentme> and finding nothing?
<fullermd> No, it'll check . then ../ then ../../ then ../../../ then...
<fullermd> Not a branch means it found its way up to / without hitting one.
<delinquentme> thats interesting.
<delinquentme> also does anyone in here have a diagram of which they are confident
<delinquentme> in how it portrays a correct usage of bzr branches / trunks with regards to directory structure?
<delinquentme> basically im after:
<delinquentme> " Are branches parallel directories with the same files which happen to vary only slightly ? "
<fullermd> I think you're trying to assign _way_ too much intrinsic meaning to "trunk".  Unless you're running a telco, maybe.
<delinquentme> I'm just not sure about how branches work haha
<fullermd> "trunk" isn't a technical term in any modern VCS.  It's purely a _social_ term used to refer to specific branches with social meaning.
<delinquentme> like project_main/branch_1
<delinquentme> project_main/branch_2
<delinquentme> ok check
<delinquentme> where branch_1 and branch_2 are very close in their history
<fullermd> A branch is abstractly just a particular set of files with a particular history, and concretely an instance of that in the filesystem.
<fullermd> It may be closely related to some other branch, distantly related, or completely unrelated.
<delinquentme> so wait. branches dont intrinsically map to different directories??
<delinquentme> because it seems then I've got that all wrong when it comes to bzr
<fullermd> In bzr usage (leaving aside exotic or experimental stuff), a branch exists as a single dir (tree).
<SamB_MacG5> delinquentme: well, generally they actually do have directories associated with them, but those directories need contain nothing besides .bzr ...
<delinquentme> fullermd, Ok so if I want to work on multiple branches from a single project
<delinquentme> I could possibly have a primary project dir ... and within that a dir corresponding to each branch?
<fullermd> Then you would generally have a dir for each branch.
<fullermd> Right.
<fullermd> Often, that project dir would also be a shared repo, so as to avoid extra space/IO usage.  But that doesn't change anything semantically in your operations.
<delinquentme> fullermd, in this case ... what does a shared repo mean?
<delinquentme> are you saying shared with other users?
<fullermd> No, shared between the branches.
<delinquentme> ah! ok
<delinquentme> YESSSSSSSSs
<delinquentme> I UNDERSTAND!!!!!
<fullermd> What's your VCS background (if any)?  You were talking git earlier?
<delinquentme> git =]
<delinquentme> yar
<delinquentme> right now im seeing no real issues with bzr
<delinquentme> id looove something to allow me to edit commit history
<delinquentme> but other than that im OK with it
<fullermd> 'k.  In git, "repo" is the term for the main visible thing you deal with.  You've got your working tree there, and the branches and revisions are abstract 'hidden' stuff inside it.
<delinquentme> yeah
<delinquentme> whereas in bzr branches actually have visible locations
<fullermd> In bzr, "branch" is the main visible thing you deal with, which contains the working tree, and also the branch metadata internally.
<delinquentme> OHHHHH  (tentative )
<fullermd> "repo" refers to an interal thing that holds the revisions.  In the simplest setup, that's hidden away inside each branch.
<fullermd> A "shared repo" allows a single repo to be used simultaneously by multiple branches.
<fullermd> So if you have 2 branches that are identical, with 100 revisions, and then each branch adds 1 new one:
<fullermd> - With "standalone" branches, you're storing 101 revs in one place, and 101 in another, for 202 total.
<fullermd> - With a shared repo, you're storing 100 common revs once, and 1 new one from each side, for 102 total.
<delinquentme> fullermd, you're good hahah
<fullermd> That saves disk space and IOPS and filesystem cache and inodes and blah blah blah.
<delinquentme> OK so when youve got code that you've pulled down from the main project
<delinquentme> and you're about to start on a big new feature
<fullermd> But it doesn't directly affect anything you do at the UI level; you never interact with the repo itself, just the two branches the same as if they were standalone.
<delinquentme> in git you'd make a new branch
<delinquentme> in bzr what would you do?
<SamB_MacG5> fullermd: except, of course, to set things up in the first place
<fullermd> Same thing.  Just that the branch would be another dir in your filesystem, instead of a 'name' in your existing dir.
<SamB_MacG5> and that things like qlog will care ...
<delinquentme> awesome!
<delinquentme> SamB_MacG5, I was about to jump in and ask just that
<fullermd> delinquentme: You may find http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief useful.
<delinquentme> so the separation between shared and standalone happens basically in how you initalized the directory
<fullermd> (and possibly some of the other stuff under http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs)
<fullermd> There's a little stuff at the end of the PiecesInLength page that tries to do some cross-VCS comparisons of the terminology/subdisions.
<delinquentme> fullermd, can I ask what you do?
<fullermd> Or change it afterward.  You can take a standalone branch and adjust it to use a shared repo, and vice versa.  But yeah, the only time you really do anything directly to/with a shared repo is in setting one up.  The rest of the time, you just deal with branches, and bzr does the repo stuff internally.
 * fullermd shrugs.
<fullermd> Programming, sysadmin, sit on IRC and make bad puns.  What everyone else does.
<delinquentme> like im curious how you got good wit both bzr and git
<delinquentme> are you a rails programmer?
<fullermd> Ghod no.  I have standards  ;p
<delinquentme> hahaha
<SamB_MacG5> snakes on a plane?
<delinquentme> @_@ you made that movie?
 * delinquentme calmed humility
<SamB_MacG5> what?
<fullermd> I'm good with bzr 'cuz I've been using it for...   uh...  god, like 7 years now?
<delinquentme> which do you use more?
<delinquentme> git / bzr
<delinquentme> and why?
<fullermd> I'm good with git 'cuz...  well, I'm not.  I just know enough about its general structure to make reasonably good bzr comparisons.
<fullermd> Only time I use git is when I deal with other projects that are in git.  Ditto with hg and monotone etc.
<fullermd> git just isn't confident enough to use more often.  I mean, lookit:
<delinquentme> oh and what about bzr break-lock
<fullermd> % git rocks
<fullermd> git: 'rocks' is not a git command. See 'git --help'.
<fullermd> % bzr rocks
<fullermd> It sure does!
<delinquentme> the docs are scaring me
<fullermd> break-lock is one of those escape-hatch sorta commands.  You should probably never need to know it.
<SamB_MacG5> <lambdabot> SamB says: [<lambdabot> emertens says: screw ruby on rails, I'm using snakes on a plane] <SamB> is that a Python web framework?
<delinquentme> so im thinking that if the file isn't setup as a bzr repo ... then this could be a possible reason im getting this:
<delinquentme> bzr: ERROR: Cannot lock LockDir
<delinquentme> when attempting to push
<delinquentme> haha
<fullermd> Mmm, could mean something is odd with the filesystem or something on the server, not letting it do something it thinks it should be able to.
<fullermd> Or possibly something like a half-setup branch, where there's enough that bzr thinks it's a branch (otherwise it would be trying to create one), but not enough that the lock dir is where it should be.
<delinquentme> well actually nm it has to be a bzr repo because I fetched a branch from it
<fullermd> Oh, or just some kinda permission thing, of course.
<delinquentme> ok so i've got a project_dir and within in that a trunk dir
<delinquentme> ( thats what they called it .. im not trying to make problems =P )
<delinquentme> so that should be a bzr branch
 * fullermd nods.
<delinquentme> probably what they're using as i guess you could call the "main storage branch"
<delinquentme> and then I need to fork off of that branch and create new ones to edit / test / run needle-pokey-like experimentation on
<SamB_MacG5> delinquentme: trunk is the conventional name for that sort of branch, yes
<SamB_MacG5> it's just that bzr doesn't know that
<delinquentme> YESSSSSS
<delinquentme> ( learning )
 * delinquentme 5 year old grin
<fullermd> So you'd do something like `cd $project_dir ; bzr branch trunk needle-pokey-like ; cd needle-pokey-like ; *grab needle*`
<delinquentme> ok so I think... they made a dir and didn't actually set it up
<delinquentme> so they've got a production env running at /usr/local/derp
<delinquentme> i want to copy whats in derp ... into the /home/shared/sources/derpdb/trunk
<delinquentme> cp /usr/local/derp /home/shared/sources/derpdb/trunk
<SamB_MacG5> derp?
<fullermd> derpdb.  It's the newest Web Scale NoSQL craze.  Get with the program, man.
 * SamB_MacG5 grumbles about dict(1) not getting urban dictionary defs
<delinquentme> lolol
<delinquentme> LISTEN gais its in development OKE?
<delinquentme> its a social integration specific solution.
<delinquentme> facebook meets databases for cat owners
<SamB_MacG5> do I have to sign an NDA now?
<fullermd> No need.  Your cat has already done so on your behalf.
<SamB_MacG5> darn them and their windows-only anti-cat-typing software!
<delinquentme> SamB_MacG5, have a facebook?
<delinquentme> ever looked a a cat pic online?
<delinquentme> then you've already agreed.
<delinquentme> oh.
<delinquentme> where relative to the branches ...
<delinquentme> should the .bzr file b e?
<delinquentme> they should be siblings right?
<mgrandi> should be inside the branch folder
<mgrandi> there is a .bzr folder per branch
<delinquentme> kk
<mgrandi> hidden if you are on mac and linux
<mgrandi> windows too
<delinquentme> so what might be happening if im getting "not a branch"
<delinquentme> when I attempt to branch a dir which clearly contains a .bzr file
<mgrandi> are you in the repository directory?
<mgrandi> instead of the branch dir
<delinquentme> well let me step back
<delinquentme> im trying to copy whats on the main repo
<delinquentme> to local machine
<delinquentme> is branch the right command?
<mgrandi> yeah, that will branch the entire history for that branch
<delinquentme> ok so yeah somethings wrong them
<delinquentme> then
<delinquentme> Umm when i do bzr info within that branch
<delinquentme> it lists a parent branch
<mgrandi> is this just a normal branch?
<mgrandi> does it have a repository?
<delinquentme> would that prevent me from being able to branch a child from the parent ... if a grand parent exists?
<delinquentme> so I just made the repository .. by copying what was in production
<delinquentme>  a straight cp
<delinquentme> operation
<mgrandi> i mean on the server
<fullermd> No, parent is a cosmetic thing, really.  Just a default location.
<mgrandi> was it Repo / branch
<delinquentme> oh and the server has both production and the main repo
<delinquentme> ( I know not safe )
<mgrandi> so trying to branch fromt he server is not working?
<delinquentme> yeah
<delinquentme> ditto
<delinquentme> ALSO another question ... when I go to push :parent
<delinquentme> in this situation
<mgrandi> can you do a 'du -hac' for the server directory you are trying to branch from?
<mgrandi> and paste that to pastebin or something
<delinquentme> that will push to whatever dir I branched from right?
<delinquentme> sure
<mgrandi> if you saved the push directory (by doing like bzr push --remember) then bzr push will push it to the remembered directory
<delinquentme> its large haha
<mgrandi> yeah its fine
<delinquentme> ok it overflowed my history in bash
<fullermd> "du -hac"?  Is that a Rammstein song?
<delinquentme> lol smh
<mgrandi> xD
<mgrandi> it can be
<delinquentme> so like theres just a ton of images
<delinquentme> was there something specific you were after?
<mgrandi> just do it on the .bzr directory then
<mgrandi> du -hac /repo/branch/bzr
<mgrandi> du -hac /repo/branch/.bzr
<delinquentme> http://pastebin.com/1U1M831m
<mgrandi> ok
<delinquentme> I think thats what you want :D
<mgrandi> so that seems fine
<delinquentme> aweso
<mgrandi> so
<mgrandi> branching from that directory
<mgrandi> says its not a branch?
<delinquentme> branching from trunk yeah
<mgrandi> so this is from a server -> local machine?
<delinquentme> from my local machine through sftp
<mgrandi> try doing it on the server itself (through ssh or something)
<delinquentme> bingo
<mgrandi> just make a tmp branch or something
<delinquentme> so make a local branch
<mgrandi> ?
<mgrandi> well just to see if that works
<delinquentme> do I have any options if the repo is huge?
<mgrandi> could try a lighweight branch
<mgrandi> this is just to see if it bzr thinks its a branch
<fullermd> info would be quicker.
<mgrandi> he says info was working but its  not branching?
<mgrandi> try info then
<delinquentme> yeh info works
<fullermd> Well, if info shows a branch there, branch'ing from it should work.  If it doesn't, there's probably something pretty deep going wrong somewhere.
<fullermd> And branch'ing from that same location fails?
<mgrandi> try posting your .bzrlog
<mgrandi> maybe its throwing an error
<delinquentme> http://pastebin.com/BmT6mdD4
<fullermd> 'k, and what's the 'branch' command you're trying to run and its output?
<delinquentme> soo I dont have a .bzrlog file within the trunk
<fullermd> No, it would be in ~
<delinquentme> http://pastebin.com/wDxaBiZS
<delinquentme> oic
<delinquentme> nothing in ~/ either
<mgrandi> its a hidden file
<mgrandi> .bzrlog
<fullermd> 'k, do an info on that URL you're trying to branch from.
<fullermd> .bzr.log actually.
<fullermd> But there's probably enough in UI output to track things down.
<fullermd> (also, if you have sufficient access on the server and it's got bzr, using bzr+ssh will be better than sftp as a rule.  But almost certainly not germane to the "getting things working" level)
<delinquentme> you lost me after germane
<fullermd> It's like silic except with a lower forward voltage drop.
<fullermd> 's mostly just an aside, so ignore it for the moment.
<delinquentme> lol ok
<delinquentme> so I should try bzr+ssh
<delinquentme> i get a command not found
<fullermd> It'll generally be faster (often a _lot_ faster).  But so far, that probably means it'll fail faster.
<delinquentme> $ bzr branch bzr+ssh://nacho
<delinquentme> bash: bzr: command not found
<fullermd> That probably means bzr isn't installed on the far end.
<fullermd> Which does mean that bzr+ssh won't work, and you'd need to use sftp.
<fullermd> But also makes one step back and ask if there really is a bzr branch on the server at all...
<delinquentme> here is the log file https://gist.github.com/3726216
<delinquentme> well bzr info wouldn't work if it wasn't installed right?
<fullermd> Yeah, that doesn't tell us anything; 's all about your local stuff, which presumably is fine.
<delinquentme> and IDK what having a /trunk/.bzr file means ... but I THINK that means its a bzr branch right?
<fullermd> bzr doesn't require anything bzr-ish on the server side over dumb transports (which sftp is)
<fullermd> It's entirely possible to have bzr branches hosted via those methods on servers that don't themselves have bzr installed.
<delinquentme> oh no im sshed in and running "bzr info"
<delinquentme> ive got ssh access as well as trying to setup the remote pushes for bzr
<delinquentme> so I can do like bzr push :parent
<delinquentme> and move it localmachine >> server
<fullermd> OK, I think we're (at least I'm) getting a bit overloaded with multiple questions at once here.
<delinquentme> ok so 1) I think it has bzr installed on the server
<fullermd> Let's split 'em out.  First off, the "bzr branch sftp://..." leaving to "Not a branch" error.
<mgrandi> so, have you pushed the branch locally into the server yet?
<delinquentme> I have not mgrandi
<mgrandi> so there is no branch at /nacho/whatever/trunk?
<fullermd> Why is that happening?  The most obvious is "well, there's no branch there".  Are you expecting one to be so?
<delinquentme> but I've verified that there are infact files in the dir that im attempting to branch from
<delinquentme> externally ( via ssh )
<delinquentme> so I know the files are there ... I know bzr is installed on the server
<delinquentme> and I know there is a trunk/.bzr directory
<delinquentme> mgrandi, I've not yet pulled down anything locally from *this* server
<delinquentme> they have another dev server that I managed to pull from but thats within another directory all together
<fullermd> What does bzr info sftp://nacho......   tell you?
<delinquentme> https://gist.github.com/3726216
<delinquentme> nacho was a replacement name -- this is the actual machine and links and all that action
<delinquentme> SHIT. you can see this is a rails project =P
<mgrandi> we all hate you now. (just kidding)
<fullermd> 'k.  You can ssh into the server, right?  And it does have bzr installed?
<fullermd> 's cool.  We won't make fun of you 'till after you log off.  It's only polite.
<delinquentme> yeah .. I mean I think it has it installed because Im running "bzr info trunk/"
<delinquentme> and getting solid output
<delinquentme> hahah
<delinquentme> i dont wear tight pants
<delinquentme> ... all the time
<delinquentme> but it isss friday nightttt
<fullermd> 'k.  Do an 'info' on the server, using the full path, and paste that.
<delinquentme> https://gist.github.com/3726216
<fullermd> 'k, well something doesn't match up.  You're in /home/share/source/BETYdb/ when you run that command?
<delinquentme> yar
<fullermd> Is sftp chroot'ing you somewhere?
<delinquentme> HMMMM
<delinquentme> good question
<delinquentme> well it could be .. but im giving it the full system path sooo
<delinquentme> ( when sftping in )
<fullermd> Well, if you were chroot'd, the full path would be the path under that root, which would be sure to be wrong.
<delinquentme> so that should negate that right?
<fullermd> I'd hope not.  If it did, chroot would be useless  ;p
<delinquentme> me google
<delinquentme> ah!
<fullermd> Oh no, you can probably just test it manually by sftp'ing in and ls'ing around.
<delinquentme> oh is that a real ...
<delinquentme> whats the word?
<delinquentme> http ftp ssh
<fullermd> "thingy"
<delinquentme> ROFL
<delinquentme> it might be chrooting me to my user dir
<delinquentme> fullermd, you might have just won
<fullermd> Sweet.  I'd like to thank the Academy...
<delinquentme> yarp.
<delinquentme> nailed it
 * delinquentme dances
<fullermd> I'm a little curious about bzr+ssh not working, since bzr is obviously installed.
<delinquentme> obvi-rus-ree
<fullermd> Maybe it's in a weird place your $PATH is covering in an interactive session?
<delinquentme> OK new question all together
<delinquentme> hopefully one substantially simpler
<delinquentme> How do you guys setup your development from your production servers
<delinquentme> and how do you deploy
<delinquentme> in rails ( sorry ) theres all kinds of plugins to do things on deploy and hooks and needles and spears
<delinquentme> what does a deploy look like for you guys on bzr
<fullermd> I'm old school.  I use Makefile's.
<fullermd> (well, except for the things where I use my embryonic make(1) replacement, but philosophically the same)
<fullermd> In ruby I guess you'd use rake.
<mgrandi> i wish python had rake.
<mgrandi> but installing stuff from pip is super hit or miss.
<fullermd> There's some [im]moral equivalent.
<delinquentme> so you kind of compile stuff
<delinquentme> and then shove it to the server
<delinquentme> yeah
<fullermd> No, just use make as a way to wrap the deployment stuff.
<delinquentme> rake it basically the dingo that hops everything along
<delinquentme> ^ intelligible
<fullermd> Could about as easily use a shell script for 95% of it, since it doesn't really rely on much dependancy tracking.
<fullermd> But make's there, and already provides me targets and chaining and suchlike, so..
<delinquentme> fullermd, could I see one of your makefiles?
<delinquentme> im familiar with shell scripts but not make files
<delinquentme> Makefiles*
<fullermd> For web app deployment?  Mmm.  They're mostly pretty abstracted for all the flexibility we use; not a good template to learn from.
<fullermd> (plus the incredibly nasty Stupid Tricks they do to get around the weakness of make and/or sh as languages.  Part of the reason for my replacement...)
<fullermd> Eep, didn't realize how late it was getting.  I better get back to work...
<delinquentme> yeah i need to shower
<delinquentme> THANKS A TONNNNNNNNNNNN
<mgrandi> anytime
<delinquentme> Oh... now If when I sftp into the server
<delinquentme> and I can access root FROM the sftp
<delinquentme> erm not root
<delinquentme> i mean I can access /
<SamB_MacG5> soo .. bzr bisect doesn't use the terms "good" and "bad" ...
<SamB_MacG5> gah, I hate imperative code
<delinquentme> ok talk to me about the central repo
<delinquentme> it doesnt have files in it??
<delinquentme> also which development method is closer to git? centralized?
<ScottK> No.
<SamB_MacG5> delinquentme: not much point having a checkout in a published branch
<SamB_MacG5> generally
<SamB_MacG5> er, I should say working tree
<SamB_MacG5> checkout means something a bit strange here
<delinquentme> ok so if a central repo doesnt have files
<delinquentme> when you branch from the central repo
<delinquentme> where are the files coming from?
<SamB_MacG5> what is it that you think a version control system does?
<delinquentme> Im used to git ... so like im thinking the files are in a central origin
<ScottK> Branches are branches.  There in nothing that bzr considers a mster.
<delinquentme> and git is controlling the modification to that
<ScottK> You can do checkouts, but that's more like svn than git.
<SamB_MacG5> where do the files come from when you clone a bare git repository?
<ScottK> (no offline commits for example)
<delinquentme> im not sure I know what a bare git repo is...
<delinquentme> like when you clone a repo ... all of the files are in that repo
<delinquentme> and you then copy them from the repo to your local
<delinquentme> hence why im confused about where the files reside in a bzr setup
<SamB_MacG5> delinquentme: have you never seen a plain-http-published git repository?
<delinquentme> sure
<SamB_MacG5> normally those have names ending in .git, and are bare
<delinquentme> hmm
<delinquentme> what does bare mean?
<SamB_MacG5> in git, bare means there is no working tree, it's just what would go in the .git directory
<SamB_MacG5> anyway, in bzr, the files come from the branch
<SamB_MacG5> regardless of whether or not there is a working tree
<delinquentme> ok ok yeah so you're not saying that there are no files ... by bare you mean that there are no modifications which lie outside of commits
<delinquentme> so there should infact be files within the branch?
<SamB_MacG5> basically, the files are hidden inside a database
<delinquentme> OH.
<delinquentme> so then it IS empty
<delinquentme> and when i pull from a central repo
<delinquentme> it spits out stuff from that DB
<delinquentme> to allow me to populate the branch i just made
<SamB_MacG5> that's actually where it always gets the files ;-)
<delinquentme> so is this like a special bzr DB?
<delinquentme> orrrr is it a mysql DB? or what
<SamB_MacG5> yeah, special bzr db
<delinquentme> So should the main repo be completely naked?
<delinquentme> devoid of files?
<delinquentme> not even a hidden .bzr
<SamB_MacG5> the .bzr directory is where the database is kept
<delinquentme> kk
<SamB_MacG5> (although, with shared repositories, the database with the actual file contents would be in the repo's .bzr dir)
<SamB_MacG5> (the branch's .bzr dir would then mostly serve to tell bzr which commit in the repository was the last one on this branch)
<delinquentme> you guys dont usually have a server displaying the primary repo to incoming traffic do you?
<SamB_MacG5> Many things have trunk at lp:~<user|group>/<project>/trunk
<SamB_MacG5> so, um, depends on the project
<delinquentme> so the distinction to pick --trees or --no-trees
<delinquentme> is whether you're going to be editing files within that directory?
<delinquentme> "One of the main reasons we don't want to create a working tree is that the tree needs to be updated by each push leading to potential problems where the workign tree checked out is out of date compared to the actual repository."
<delinquentme> does that make sense?
<SamB_MacG5> wow the bzr bisect tests run slowly with --coverage ...
#bzr 2012-09-16
<jelmer> SamB_MacG5: everything runs slowly with --coverage
<delinquentme> what determines that a file is a branch
<fullermd> A file isn't a branch  ;p
<delinquentme> but like for it to be a branch ... the dir only needs a .bzr dir within it right?
<fullermd> No, a .bzr dir just means there's a bzrdir there.
<fullermd> A bzrdir _may_ contain a branch.  It _may_ contain a repository.  It _may_ contain a working tree.
<fullermd> It may contain any 2 of the 3, or any 3 of the 3.  It's probably technically possible for it to contain 0 of the 3 too, though that would be stupid.
<SamB_MacG5> fullermd: of course a .bzr dir can contain none of them
 * SamB_MacG5 runs "mkdir .bzr"
 * SamB_MacG5 is rather puzzled by the way "bzr bisect run" does  a "bzr bisect start" internally, but the tests try to set up a bisect range *before* that, which will be cleared out by that ...
<fullermd> You're supposed to do things _before_ I preemptively declare them stupid, y'know   :p
<SamB_MacG5> well, I didn't actually do it, so there!
<SamB_MacG5> and why am I not reassured by the fact that none of the scenarios covered by the bisect tests have uncovered any real bugs in my attempt to add revspec ranges to "bzr bisect start" and "bzr bisect run"?
<SamB_MacG5> granted, maybe the bugs only exist in my head, but ...
<SamB_MacG5> it would be nice to find those too
#bzr 2013-09-09
<mathrick> jelmer: I might be doing something wrong, but it seems that rebase is broken with colocated branches
<mathrick> mathrick@megumi ~/Dev/LispM/opengenera-cookbook $ bzr info
<mathrick> Lightweight checkout (format: development-colo)
<mathrick> mathrick@megumi ~/Dev/LispM/opengenera-cookbook $ bzr missing co:fix-ruby-clock
<mathrick> You have 1 extra revision:
<mathrick> mathrick@megumi ~/Dev/LispM/opengenera-cookbook $ bzr rebase co:fix-ruby-clock --onto=-2
<mathrick> No revisions to rebase.
<mathrick> or maybe I'm misunderstanding something, but I want to do what I do with git rebase as well: I made a bugfix branch, but accidentally based it on another bugfix branch rather than pristine master, and want to yank out the commits and rebase them onto the revision before those other bugfixes happened
#bzr 2013-09-10
<jelmer> mathrick: that's plausible
<mathrick> jelmer: just to check, I'm correct in trying to use bzr rebase to do what I was trying to do, right?
<mathrick> I actually just retried that with 2a separate dir branches, and it still doesn't like what I'm doing
<mathrick> "No revisions to rebase"
<mathrick> I'm beginning to suspect it's replay that I want, which is somewhat inconvenient as I now have to create extra branches to do that
<mathrick> jelmer: so yeah, replay worked like a champ, and it seems to me you did it that way to make sure rebase can never lose commits (the way it can in git if you're not careful)? Which is an entirely reasonable choice to make, but it needs documentation badly
<mathrick> ie. rebase can only ever forward commits onto a newer tip, whereas to change the branching point to a non-tip revision, you need to branch + replay explicitly
<mathrick> the whole of rewrite is really, really sparsely documented given the complexity of the topic
<mathrick> seems like bzr help should have 'rewrite' listing *all* the commands in the plugin (it doesn't currently), plus 'rebase', 'rebase-tutorial', 'replay', and 'rebase-for-git-users'
<mathrick> I might write some if I manage to do the things I want to do without any undue delays
<mathrick> oh, and a bug, bzr switch -b -r X doesn't actually work
<fullermd> I had to use replay sometime earlier this year (late last?) to excise a commit.  It took a fair while figuring out rebase wouldn't do it, and a while further and several trial runs to figure out how to get replay to DTRT.
<fullermd> Sadly, it seems pretty mired in the Tuitless Abyss   :|
<fullermd> (even in bzr terms)
<jelmer> mathrick: rebase rebases the *current* branch on the one specified. Rebasing on the second to last revision doesn't really make sense.
<jelmer> mathrick: thanks for the suggestions, though unfortunately bzr-rewrite is orphaned
<mathrick> jelmer: yes, but that's because the meaning of "rebase" is different between git and bzr. In git I'd say "git rebase --onto pristine bugfix1 bugfix2", which results in both bugfix1 and bugfix2 branching out of pristine's tip, rather than the accidental bugfix2 branching out of bugfix1
<mathrick> but there's no such syntax in bzr rebase, because I cannot give it a separate target and comparison branch
<mathrick> so in bzr, it's bzr switch -b tmp; bzr switch bugfix2; bzr uncommit -r branch:co:pristine; bzr replay co:tmp -r branch:co:bugfix1..
<mathrick> bzr rmbranch co:tmp
<jelmer> mathrick: it might very well be true that bzr-rebase is unaware of colocated branches - colocated branches are still a development thing, don't use them for productiony things
<mathrick> jelmer: nah, it's not any more unaware than of regular branches, because I get the exact same thing
<mathrick> the problem is really that rebase is not supposed to do that, but it's not explicit about it
<mathrick> bzr rebase != git rebase
<mathrick> git's rebase is really bzr rebase + bzr replay + some things that just aren't there (ie. git rebase -i and edit/squash revisions)
<jelmer> mathrick: I'm not disagreeing, but I also don't really care anymore :-)
<mathrick> jelmer: why not? About bzr rewrite specifically, or bzr in general?
<jelmer> mathrick: both
<mathrick> that's a pity
<mathrick> oh, I missed your comment about rewrite being orphaned
<mathrick> jelmer: if I wrote the docs, would you review and push it though?
<mathrick> fullermd: yeah, I can see why rebase wouldn't do that even if it results in more work to get the same result, but the docs just don't tell you anything to expect that
<jelmer> mathrick: I'd be happy to hand reign of the project over to somebody else
<mathrick> jelmer: out of curiosity, what do you use for personal VCS needs these days?
<jelmer> mathrick: git
<jelmer> mathrick: anyway, it'd be great to see these projects continued even if I am no longer interested in them myself
<mathrick> yeah
<Azrael_-> hi
<jelmer> hi Azrael_-
<Azrael_-> i always fail branching a repo. i get the information "GetÃÂ¶tet  2427kB/s | Revisionen herunterladen:Inserting stream:Estimate 459382/587439" GetÃÂ¶tet = killed
<Azrael_-> any idea why this could happen and how to prevent this?
<Azrael_-> nm
<Azrael_-> never thought bzr would need so much ram. it was killed due to insufficient ram
<Azrael_-> 1gb ram wasn't enough
<Azrael_-> perhaps 4gb swap will do it
<jelmer> Azrael_-: what version are you running?
<Azrael_-> Bazaar (bzr) 2.6.0dev2
<Azrael_-> yeah, it's working now
<Azrael_-> wow, it only needed 1,3gb ram to complete this action
<Wiz_KeeD> hey guys
<Wiz_KeeD> what does this mean? Conflict adding file aluart_product_configurator/wizard/sale_config.py.BASE.  Moved existing file to aluart_product_configurator/wizard/sale_config.py.BASE.moved.
<Wiz_KeeD> when going there i see no such file
<Wiz_KeeD> maybe I deleted it
<Wiz_KeeD> but why is the error still there and how to get rid of it?
#bzr 2013-09-11
<rindolf> Hi all.
<rindolf> How do I restore a bzr checkout to its pristine state? Similar to svn revert.
<mgz> rindolf: `bzr revert`, though remember you can just branch somewhere new as well
<rindolf> mgz: thanks! That worked.
<rindolf> mgz++
#bzr 2013-09-12
<wenshan> hi guys, I have a local clone of a launchpad repository (not mine) and I have committed a few changes (so the revno has been increased), now if I want to pull in the changes from launchpad, what should I do to keep the history log clean? (something `git pull --rebase' equivalent)
<thumper> my question is why you want the history log clean?
<thumper> I'd go "bzr merge :parent"
<thumper> someone did write a bzr rebase
<thumper> but as a whole, most bzr users don't rebase
<thumper> but merge instead
<wenshan> because git uses hash string whereas bzr uses cumulative numbers, and it would be confusing (at least for me) to have different revision numbers for the same commits between my clone and the upstream.
<wenshan> but anyway, I'd like to follow the bzr convention, will give 'bzr merge :parent' a go, thanks
<wenshan> thumper: I did `bzr uncommit' to roll back to an older revision, and committed a few changes, then I did `bzr merge :parent', however, it returned "Nothing to do". What does `bzr merge :parent' do?
<thumper> it depends where :parent is set
<thumper> it defaults to the branch you branched from
<thumper> bzr info shows at the end what the parent is
<thumper> bzr merge <other branch> works too
<thumper> if you have uncommitted going back to the last revision of the parent branch
<thumper> you can just go "bzr pull"
<thumper> instead of merge
 * thumper hopes jam explains some here
<wenshan> thumper: thanks
<mgz> jam, jelmer: did either of you have a bash thingy for displaying the name of the current native colo branch in the prompt?
<jelmer> mgz: I think somebody did, can't remember who though
<mgz> what's the file you'd poke to get the current active branch name?
<mgz> just .bzr/branch/location plus some processing I guess
<jelmer> parse .bzr/branch/location IIRC
<mgz> ace, thanks jelmer!
<jelmer> mgz: y/w :-)
<frusen> hi, my friend uses bzr on windows but gets this error: File "paramiko\transport.pyo", line 1633, in _check_banner SSHException: Error reading SSH protocol banner
<frusen> 2.5.1 standalone version
<frusen> we are working on the same bzr repository and everything works for me (on gnu/linux) so i figure it's not the servers fault
<frusen> anyone have any experience with this error?
<frusen> version 2.4.2 fixed it
#bzr 2013-09-13
<Noldorin> hey jelmer
<jelmer> hi Noldorin
<Noldorin> jelmer, got a little question on dulwich if you don't mind
<jelmer> Noldorin: sure
<jelmer> (note that there's also #dulwich)
<Noldorin> oh
<jelmer> Noldorin: what are you hacking on?
<Noldorin> jelmer, hg-git
<jelmer> ah
<zodiak> hey everyone, stupid question, but I can't seem to find the answer :( I have a branch that I bzr pull'd down, but now I want to cherry pick changes. I am on bzr revision 14, but I want to pull down 15 and 17 only (skipping 16) .. how do I do this "nicely" ?
<zodiak> and yes, each changeset is unique and self contained :)
<zodiak> aahhh.. bzr merge -r takes a number of revisions .. hopefully that's the ticket :)
<soldiertn> Hi
#bzr 2013-09-14
<Wiz_KeeD> Hey guys, is there a way to do bzr branch lp:x bzr branch lp:y bzr branch lp: z into one command?
<jelmer> Wiz_KeeD: "bz rbranch lp:x & bzr branch lp:y & bzr branch lp:z" ? :-)
<Wiz_KeeD> yeah I thought of that
#bzr 2014-09-08
<ciampix> hi all. Since I do not want to experiment with important repos...is there something like a bzr sandbox server? TIA
<mgrandi> may i ask why you want a sandbox server?
<mgrandi> using bzr on a server is literally the exact same as using it locally
<mgrandi> slash what do you want to experiment exactly
<jelmer> ciampix: ^
#bzr 2014-09-10
 * LeoNerd is somewhat surprised that 'bzr shelve' in a git checkout /mostly/ works
<jelmer> LeoNerd: with bzr-git, presumably?
<LeoNerd> Yeah.. admittedly it did crash, but it seems to have crashed after storing the shelf and unpatching it from the workdir.. so it's quite servicable
<LeoNerd> I'm currently developing a server using python in git, a client using perl in bzr, and an integration-test script between the two using perl in git. So it's a bit of a mixup in my head sometimes :)
<jelmer> LeoNerd: that sounds.. suboptimal?
<thrustcore> bzr has been updating for 2 hours, should I break the lock and start again or should I wait for it to finish?
<mark06> anyone experimenting with bzr-hg or fastimport?
<mark06> I managed to make bzr-hg proceeed after a path to the mercurial lib, but then it takes hours processing the "manifests", up to failing due to some memory error
<mark06> as for fastimport, none of the mentioned commands for exporting an hg repo exists
<mark06> is there some way to merge a branch with no common ancestor?
<mark06> surprisingly it seems to be a common case: http://zakalwe.fi/~shd/articles/why_not_bazaar.html
<mark06> "Having a common ancestor is a strong "hint" that a merge is possible, but it should not be a technical requirement for merging. Git and hg both allow merging arbitrary trees together."
<mark06> any progress after this? http://fourword.fourkitchens.com/article/creating-common-branch-ancestry-hard-problem
<fullermd> I merge unrelated branches all the time.
<jelmer> mark06: that article is very ignorant
<jelmer> mark06: "bzr merge -r0..-1 <branch-to-merge>"
<mark06> fullermd: how do you do?
<mark06> full of conflicts, jelmer: http://vpaste.net/IY9Ku
<jelmer> mark06: sure, if there are paths that exist in both you'll probably get conflicts
<mark06> better formatted, http://vpaste.net/XXdgs
<mark06> jelmer: which is exactly what the article says
<jelmer> mark06: no, the article says that a merge is not possible
<mark06> no it doesn't say that
<mark06> let's put the vcs wars aside, I don't care about it, really
<jelmer> mark06: " Bazaar version control tool demands that two trees that are merged must have at least one common ancestor, or cherry-picking must be used."
<mark06> I just want to merge :)
<mark06> jelmer: you mean the first post? ok
<jelmer> mark06: merging two branches with different file ids for the same paths is problematic in bzr; you need to pick the file ids of either side
<jelmer> mark06: yes, the first post is wrong. The second post gives a reasonable explanation, at a quick glance
<jelmer> (and yes, this is an unsolved problem.. it's a fundamental issue with file ids)
<mark06> I wish they worked on "Iâm currently looking at writing a custom merge handler (subclassed from  the standard merge3 in Bazaar) that would intelligently handle merges  where file paths do represent the same files"
<jelmer> mark06: who are you referring to with "they" ?
<mark06> I managed to resolve all the conflicts with lost of "just resolve" but then I get no merge at all but a plain commit
<mark06> they = whoever was planning to write such custom merger
 * mark06 curious how fullermd handles it
<mark06> my real case is that if I ever get bzr-hg working, then I could work better with upstream repo for pidgin... currently I have committed 2.10.9 to a new branch supposed to get only upstream changes....
<jelmer> mark06: ah, you're taking up bzr-hg development?
<jelmer> mark06: there are lots of use cases for merging unrelated branches
<jelmer> mark06: one is merging unrelated branches with non-overlapping files; file ids are not an issue there
<mark06> not really, I made some progress with a small patch to mercurial's python module but then the manifests step takes too long and eventually fails with memory error (this is windows, the idea was trying it on my ubuntu server)
<mark06> yeah my case is definitely overlaping files
<jelmer> mark06: yeah, there is no good way of handling those (the name for this problem is "parallel imports")
<mark06> since I have an upstream branch with one single commit for 2.10.9, and from which I based all of my work for pidgin++
<jelmer> mark06: cool, bzr-hg is in need of some attention :)
<fullermd> I merge really-unrelated branches, so there's minimal overlap in file names (and when there is, they usually really are different files, so resolution is renaming)
<mark06> so instead of committing next version to the upstream branch (or breaking this into manual commits according to how often I update it)... I would like to merge the mercurial branch on top of that (all changesets after 2.10.9 I mean)
<mark06> hopefully these many conflicts would be only for the first time...
<mark06> I just don't understand because in my test, after solving all conflicts I got no merge at all, the commit was plain
<jelmer> mark06: resolving conflicts should not remove pending merge parents
#bzr 2014-09-11
<mark06> what do you mean?
<jelmer> mark06: if you do a merge, then that should show up in "bzr status"
<jelmer> if you then resolve some conflicts, you should still see that merge in "bzr status"
<mark06> I don't remember bzr status but when I bzr commit, the commit wasn't a merge but plain
<jelmer> in that case, are you sure you actually did a merge?
<jelmer> mark06: after that command in your paste, does "bzr status" list a merge?
<mark06> bzr branch -r 100 foo bar
<mark06> then in bar, bzr merge -r100..-1 ../foo
<mark06> but this is not my paste, that one is unresolved yet
<mark06> for my paste I have this at the end of bzr status:
<mark06> pending merge tips: (use -v to see all merge revisions)
<mark06>   Renato Silva 2014-09-10 Make the greper alias case sensitive.
<jelmer> mark06: that makes it seem like it is a cherry-pick merge
<mark06> so -r0..-1 should fix it?
<jelmer> mark06: fix what exactly?
<mark06> fix the commit
<mark06> it should be a merge
<mark06> indeed it fixes :)
<mark06> cool :) http://i.imgur.com/Ae4a8gK.png
<jelmer> mark06: so this won't actually do any textual merges, it just renames the files from one branch. is that really what you want?
<jelmer> anyway, bedtime here. g'night!
<mark06> hmm no I do want the textual merges :(
<mark06> thanks anyway jelmer
<mark06> ah I didn't notice the .moved in the bottom right, should be fixed for sure
<mark06> it's just that my resolve was like "just resolve it" for testing :)
#bzr 2015-09-11
<quicksilver> am I correct to think there is no way to pass --diff-options to bzr merge --preview?
<quicksilver> (I want to ignore whitespace on the preview diff)
<fullermd> I'd guess that, yeah.
<quicksilver> I will make do with bzr --old . --new ../other-branch
<fullermd> You could just merge ; diff ; revert.
<quicksilver> which does support --diff-options (but isn't quite the same)
<quicksilver> yeah or I could work out the common ancestor by hand
<quicksilver> and do bzr diff -r1.2.3
<fullermd> Well, that wouldn't tell you near so much.
<fullermd> And you don't have to do that by hand, you can ues ancestor:
<quicksilver> ?
<fullermd> cd branch_to_merge ; bzr diff -rancestor:/branch/to/merge/into..-1
<quicksilver> nice!
<quicksilver> do you have a workflow for merge review that goes a different way around?
<quicksilver> that's what I'm doing...
<fullermd> I always just do the merge and then check it out.
 * quicksilver nods
<fullermd> I'd actually long forgotten there even was a merge --preview.
<quicksilver> I think I broke that habit because of the way merge+revert gets upset by new directories and cruft from conflicts
<quicksilver> I mean it's not the end of the world, it's not that hard to clear up
<quicksilver> although if a directory got renamed and there was a conflict it is a pain.
<fullermd> I'd think revert should clear it out regardless.
<fullermd> If you're doing it in some sort of automation, it's easy enough to just do it in a temporary scratch checkout.
<quicksilver> revert won't delete the .OTHER, .BASE, .MINE files
<quicksilver> and if those files are in the directory it wante dto delete
<quicksilver> it then won't delete the directory
<fullermd> Ah.  I guess I don't run into that often enough for it to register.
<quicksilver> it's not really a big problem, but it's what provoked me to learn about merge --preview ;)
<fullermd> I figure it's a social problem; somebody has diverged too far and needs to be beaten  ;)
<quicksilver> haha
#bzr 2017-09-16
<mr_sm1th> The wiki seems to be down.
<mr_sm1th> The download page is thus inaccessible.
