#bzr 2008-04-21
<spiv> poolie: I'm reviewing http://bundlebuggy.aaronbentley.com/request/%3C48090895.1010406@arbash-meinel.com%3E
<poolie> thanks
<poolie> replying to list mail and queries
<joh> Eh, I just committed rev 88 to my bzr repository but when I run 'bzr update' from another local copy it says 'Tree is up to date at revision 87.' why?
<spiv> joh: how did you make the copy?
<joh> spiv: pulled earlier
<joh> spiv: Ah, 'pull' did the trick :-)
<spiv> joh: if you made it with "bzr branch", it will be an independent branch, so "bzr update" won't find the new revisions.
<joh> spiv: Right, that's what I did. So pull is the right way to update it?
<spiv> (but "bzr pull" will)
<spiv> Right.
<joh> Great, thanks :-)
<spiv> Or if you want to behave as a checkout, you can do "bzr reconfigure --checkout".
<spiv> Not a huge difference either way.
<ubotu> New bug: #220067 in bzr "poor documentation/broken link on how to use split" [Medium,Confirmed] https://launchpad.net/bugs/220067
<lifeless> poolie: ping
<poolie> lifeless: pong
<poolie> i guess that was about pqm
<Peng> Augh, 561 new messages on the list.
<poolie> spiv: what should we do re jam's fix for bug 211661?
<ubotu> Launchpad bug 211661 in bzr "bzr.dev smart client fails on log" [Critical,Fix committed] https://launchpad.net/bugs/211661
<poolie> merge it without a per-repo-impl test?
<spiv> poolie: I think so
<spiv> poolie: if the per-repo test lands a day later, I don't think it's a big issue (so long as it *does* happen)(
<poolie> maybe we should leave it unmerged in trunk and just merge it into 1.4 for today then
<spiv> That sounds like a reasonable solution.
<poolie> i'll do your tweak of not using an assertion
<poolie> indeed i'd like to write a test that we have no assertions
<jml> jetsaredim: hi
<jetsaredim> hey
<jetsaredim> so yea
<jml> jetsaredim: so, you were saying that it looks like the server is maintaining the lock?
<jetsaredim> killed all of my outgoing shh connections for bzr
<jetsaredim> still says things are locked
<jml> what's the output of bzr break-lock now?
<jetsaredim> there's output?
<jml> jetsaredim: it says nothing at all?
<jetsaredim> nada
<jml> jetsaredim: oh, wait, 'bzr break-lock <remote_url>'
<jml> right?
<jetsaredim> o
<jetsaredim> that might help
<jetsaredim> the whole bzr+ssh url?
<jml> yeah.
<spiv> Yeah.
<jml> 'bzr info' should give you something to copy and paste
<jetsaredim> k
<jetsaredim> have it from the push command
<jetsaredim> )
<jetsaredim> )
<jetsaredim> :)
<jetsaredim> should have something in there about needing a url
<clsk> is there a version of bzr-svn compatible with bzr 1.4rc1?
<jml> jetsaredim: well, no arguments means break the local lock
<jetsaredim> ah
<jml> jetsaredim: which is roughly consistent with every other bzr command.
<jetsaredim> ah
<jetsaredim> i suppose the man page would have told me that
<jml> 'bzr help break-lock' also
<jml> hmm.
<jml> we could add an example to that for 'bzr break-lock bzr+ssh://server.example.com/foo/bar/branch'
<spiv> jml: oh, hey
<jml> spiv: hi :)
<jetsaredim> ok - another seemingly random question
<jetsaredim> i added a new package a while back
<jetsaredim> firebug
<jetsaredim> i had a personal branch called firefox-extensions/firebug.ubtuntu that got merged into ubuntu-dev and into hardy
<jetsaredim> now I want to update the package for a new upstream release
<jetsaredim> i pushed to my personal firebug.ubuntu, but it doesn't show up by default in my code trees since I had previously marked the branch as merged
<jetsaredim> am I just doing this the wrong way?
<jml> jetsaredim: this is on Launchpad, right?
<jetsaredim> er yea - wrong channe;
<jetsaredim> and i think i figured out my issue anyway
<jml> good good :)
<ubotu> New bug: #220182 in bzr "After rebase failure tree got broken" [Undecided,New] https://launchpad.net/bugs/220182
<hsn_> are there any presentations on topic git vs bazaar
<hsn_> http://bazaar-vcs.org/BzrVsGit
<mw-home> How do I copy files in bzr?  bzr cp doesn't exist
<jelmer> mw-home: "cp a b"; bzr add b
<hsn_> you can do symlink
<Peng> Copying isn't supported yet.
<mw-home> gotcha.
<grutte_pier> hsn_: symlink? you mean bzr is capable of dealing with symlinks?
<Peng> Of course.
<Peng> Well, there are some problems with the UI, but absolutely.
<ubotu> New bug: #220302 in bzr-webserve "Wishlist - log display with branch graph" [Undecided,New] https://launchpad.net/bugs/220302
<ubotu> New bug: #220295 in bzrtools "[ENH] Add plugin for gnome-keyring integration" [Undecided,Invalid] https://launchpad.net/bugs/220295
<ubotu> New bug: #220331 in bzr "editor paths containing spaces are not parsed correctly" [Undecided,New] https://launchpad.net/bugs/220331
<ubotu> New bug: #220333 in bzr "incorrect indentation level in msgeditor.py" [Undecided,New] https://launchpad.net/bugs/220333
<trepca> hey
<trepca> i was wondering if its possible to limit access to bzr repository to only pushing
<trepca> so not actually changing the tree
<trepca> just having pending updates
<trepca> and when you review.. you just commit or drop them
<beuno> trepca, by default, if you push over ssh/sftp, the working tree doesn't get updated
<beuno> but I'm not sure how you can approve/reject changes later on
<beuno> as in "nicely"
<trepca> yeah, i know its default, but developer could also use push-and-update :)
<beuno> right, than you're probably better off using something like bundlebuggy
<trepca> uh, whats that ?
<beuno> trepca, http://bundlebuggy.aaronbentley.com/
<beuno> it's what we use for bzr
<trepca> interesting
<trepca> but my project is private
<trepca> ah, its open source, sorry :)
<beuno> trepca, well, just make access to BB private  :)
<trepca> what about these pending merges ?
<trepca> i merged a branch from remote location
<trepca> and it didn't automatically update the working tree
<trepca> status just says i have pending merges
<trepca> nevermind :)
<trepca> what is the best way to serve bzr ... built-in server, apache, sftp ... ?
<fullermd> Depends on your situation, I imagine.  For me, I use bzr+ssh pretty much everywhere.
<trepca> k
<trepca> me too for now
<jam> poolie: ping, are you working yet?
<igc> morning
<beuno> igc, hey  :)
<igc> hi beuno
<beuno> igc, how are you?
<igc> beuno: I was sick in bed all day yesterday - awake today but not 100%
<beuno> igc, aaw, I'm sorry to hear that...  :/
<beuno> we've missed you these past weeks  :)
<hsn_> http://bryan-murdock.blogspot.com/2007/03/cutting-edge-revision-control.html old bazaar-ng vs git benchmark, they are more or less comparable
<hsn_> i expected git to be significantly faster
<lifeless> poolie: I'm better but not up to work today;
#bzr 2008-04-22
<gambler> hi
<gambler> why doesnt the fedora bazaar version commands match the ones in the webpage documentation
<gambler> ah i c diff pkg
<gambler> thats really confusing
<poolie> gambler: you want bzr not baz
<Necoro> hey - if I've a working tree ... and want to checkout the tree from to revisions before - how do I do this?
<Necoro> s/to/two/
<Necoro> and I want to do this _in place_
<beuno> Necoro, just specify the revision with -r
<beuno> I suspect -r -2 might work
<Necoro> but using which command?
<Necoro> co does not work - as there is already a checkout in place
<Necoro> merge ... does strange things
<beuno> Necoro, I don't follow then
<beuno> you already have a checkout
<beuno> and you want to go back 2 revisions?
<Necoro> yes
<beuno> oh
<beuno> bzr revert -r X
<Necoro> that's easy -.-
<beuno> like most things with bzr  :)
<Necoro> thanks :)
<Necoro> ah ... some things are just not possible ;)
<beuno> Necoro, file bugs about it and give it time...  we've got amazing developers  :)
<Necoro> I can think of trying to merge two branches that bzr thought don't have a common ancestor ;)
<Necoro> yeah :) ... I tend to just ignore this issues ;)
 * Necoro adds #bzr to the list of standard channels
<beuno> Necoro, welcome  :)
<Necoro> *g*
<beuno> jelmer, btw, If there's anything I can help you with the bzr-gtk release, let me know  :)  I'm eager to see a new version out there
<fullermd> Hm.  I merge unrelated branches with some regularity   :p
<Necoro> fullermd: how?
 * fullermd shrugs
<fullermd> merge -r0..-1
<Necoro> hmmk
 * Necoro adds this to the list of interesting bzr commands
<fullermd> Not what you want if you INTEND them to be considered related, of course.  But mine really are unrelated.
<Necoro> oh
<Necoro> I indeed want to have them considered related ...
<fullermd> To do that requires the ability to alias file and revision id's.  Lot tricksier.
<fullermd> (both on the code side, and UI-wise doing it I expect)
<Necoro> fullermd: oh ... than it's not worth it ;)
<fullermd> Oh, most things are worth it.  Someday(tm).
<Necoro> hehe ... but not to have ~2-3 files merged ;P
<ubotu> New bug: #220464 in bzr "Bazaar doesn't detect its own stale locks" [Undecided,New] https://launchpad.net/bugs/220464
<bob2> is there any way to get data from rich-root-pack branches into pack-0.92?  even bundle doesn't work.
<jamesh> bob2: no
<jamesh> bob2: abentley says he's working on one format to rule them all though
<fullermd> Theoretically, a rich root format (not -pack, but its successor) will be The Format at some coming point.
<jamesh> fullermd: I think that's what abentley's pack-1.4 (or maybe pack-1.5 now) format is going to be
<abentley> bob2: rich-root-pack wouldn't exist if pack-0.92 could represent all its data.
<bob2> oh, I know, but since I don't care about the root richness, I was hoping I could throw some info away and get it into pack-0.92 :)
<jamesh> bob2: throwing info away would give you different revisions
<emgent> hello people
<poolie> hello emgent
<poolie> lifeless/spiv: what would you say to a source test that forbids the use of the assert statement?
<spiv> poolie: I have mixed feelings about that
<spiv> Because I think that the assert statement is a sane thing to use sometimes.  But it's very easy to misuse, so perhaps disallowing it entirely is the best policy.
<spiv> So I'm +0.5 on it, I guess.
<poolie> spiv: what kind of thing?
<poolie> i mean
<poolie> can you give me a good case for committing it in mainline code?
<spiv> For a purely internal-to-bzrlib API, an assert that e.g. "type(revision_id) is str" could be reasonable.  The sort of thing that would catch misuse of an API within bzrlib.
<poolie> in C i'd certainly do that
<poolie> but the combination of not having a clear distinction between debug and other builds
<poolie> means it just doesn't seem like a good tradeoff
<spiv> The thing that makes me lean towards banning them is plugins.
<poolie> all you really gain is slightly shorter syntax, right?
<poolie> mm?
<spiv> Because it's too easy for a plugin to accidentally trip over an assert than was intended to catch a bzrlib-only mistake, and really that shouldn't be a user-visible error.
<spiv> Right, you can explicitly use "raise AssertionError, ..." instead, but it feels a bit funny to raise AssertionError.  Probably that's not a hard habit to break.
<spiv> So I share your feeling regarding debug builds: asserts are the sort of thing that should happen for developers only, to help them know when they've misused an API or similar, to make development go faster.  They shouldn't be depended on to preserve the integrity of the system, e.g. in the face of bad user input.
<spiv> Hmm, lag.
<spiv> But of course we don't have debug builds, so I guess we never have a good time for an assert :)
<spiv> I guess I've talked myself into agreeing with you :)
<thumper> does bzr work on python 2.3?
<thumper> or does it require 2.4?
<jamesh> thumper: it uses decorators, which were introduced in 2.4
<thumper> jamesh: ta
<jamesh> do people still use 2.3? :)
<poolie> jamesh: rhel has something remarkably old iirc
<jamesh> ah.
<jamesh> 2.4 is around 3.5 years old, so I guess it'd still be in enterprise distros
<poolie> and i guess their users are also often (understandably) slow to upgrade
<poolie> but even that may be changed now
<Peng> My shared web host has 2.4 installed, but /usr/bin/python points to 2.3.
<jamesh> poolie: did you see my email about problems with the new bzrtools package?
<poolie> "import parser" ftw :)
<jamesh> I remember making pygtk-2.0 depend on Python 2.2 back in 2003 as being a bit contentious
<jamesh> that was 2 years after 2.2's release
<poolie> jamesh: i see it now
<poolie> jamesh: i'm on a call, could you file a bug and assign it to me marked High?
<poolie> thanks
<jamesh> poolie: okay.
<jamesh> poolie: bug filed at https://bugs.edge.launchpad.net/bzrtools/+bug/220519, but I can't change its importance
<ubotu> Launchpad bug 220519 in bzrtools "bzrtools 1.4.0-1~bazaar1~hardy1 package installs plugin in wrong location" [Undecided,New]
<poolie> jamesh: hm didn't someone else mention a problem like this in setup.py?
<jamesh> poolie: the thread about getting bzr to check in extra directories might be the answer to this bug
<poolie> it seems like the policy regarding this has changed in python?
<poolie> i guess not
<jamesh> having bzrtools installed the way it is is not an inherently bad thing (other than the fact that bzr can't find it)
<poolie> i just don't understand why we got those bugs all this week
<Peng> Blah, bzr.dev and bzr-svn 0.4.9 don't go together so well.
<jelmer> beuno: thanks
<awilkins> jelmer: Branching-schemes in bzr-svn ; is it essential to set them BEFORE pulling things?
<awilkins> I ask because I had pulled around 9600 revisions, then I tried pulling a branch ; the extra 100MB of revisions told me that this wasn't properly noticing that it was a branch. I've set the branching scheme and now a pull on the trunk wants to start again at r 1
<awilkins> I used the list scheme  ; I've listed trunk, branches/*
<awilkins> (lines, not CSV)
<awilkins> Should you list trunk as a branch, for starters :-)
<awilkins> Ok, answered that one ... "Yes", or it sulks
<Peng> It didn't auto-detect the scheme correctly?
<awilkins> It's a bit of a stinky repo layout
<Peng> And shouldn't that be trunkN?
<Peng> Rather than listing them or something?
<Peng> Ah.
<awilkins> Peng: There is a "list" branching scheme that just takes a list of paths (or globs)
<Peng> Ok.
<awilkins> If you do a --set it pops EDITOR open for you to enter it
<Peng> If it's just trunk and branches, trunkN should be good enough..
<awilkins> Peng: It didn't seem to be - it was adding more than 100MB of extra packs when it should have been a few extra revisions for tweaks to the files (things like changing version numbers)
<awilkins> It's a large tree, so that's what I'd expect if it was just thinking "hmm, this huge folder has been copied"
<awilkins> The tree layout has been messed around a bit since r0 as well, so the lack of some file features in bzr (like copy) is probably hurting too.
<awilkins> But these particular cases should be quick ; and it's doesn't explain the sudden desire for it to pull all 9600 trunk revisions again
<awilkins> Maybe I pulled it with an old bzr-svn and the new mappings hate the old ones.
 * awilkins trashes it and schedules a job for it to pull again overnight
<awilkins> Takes about 10 hours or more to get a full trunk pull on this repo (oh for horizon history...)
<awilkins> Horizon history would be even cooler if it automatically worked out the ancestry on a branch you asked for and pull revisions back far enough to get it.
<awilkins> So the horizon could move backwards even after it had been set at some recent revision in trunk.
<awilkins> Mind, the svn client has been pulling just a *working copy* of this trunk for the pas 2 hours (over a LAN), so 10 hours sounds almost reasonable for a 9600 revision history right now)
<awilkins> Not sure if it's the shiny new full-disk encryption crapware they've foisted on us contributing to that either
<black_> was wondering, if you have two branches, and you want them to diverge say for something like a database connection string, but you still wanted to push and pull and merge between them, how do you mark a revision such that when people pull from you they won't get that revision?  I've tried "revert ." to try to mark things but when I start merging back and forth the branches will eventually end up the same.  Please excuse the noobness of the que
<black_> stion :)
<Peng> Yeah, I don't think you can do that.
<black_> ahh, darn, that stinks then :)
<LeoNerd> Isn't a DB connection string more of a config item than source code, anyway?
<black_> well I through that out as an example
<black_> in the past I've had two branches of a website that I had running on two different servers and certain paths had to be different based on which server they were on
<black_> but I still wanted to keep them in sync
<black_> s/through/threw
<black_> I'm a long time svn user, and since you have to manage merges yourself anyway this wasn't much of a problem (other than all the hard work managing the revisions by hand)
<black_> bzr seems like just the tool to solve the problem, but I need to be able to mark certain revisions as already merged
<black_> without actually merging the content
<james_w> so you tried merging and then "revert ."?
<LeoNerd> One idea that occurs to me is you could keep the "abstract" stuff in one branch, then pull two other branches off that for the specific changes
<LeoNerd> What's really ideally needed in code I suspect would be a postwrite/preread filter hook
<LeoNerd> So you could filter the changes, so what bzr sees/writes is a generic version
<black_> I start out the same, make appropriate changes on one branch, commit the changes to that branch, switch to the other branch merge the changes in but then do a "revert ." to back out the changes while still keeping a record of the change, however in practice this doesn't work because as soon as you start merging back and forth again, bzr is smart enough to be able to reconcile everything and make them the same, which in this case isn't what I w
<black_> ant.
<black_> I really like the idea of an abstract branch
<black_> that might work nicely
<black_> just make sure you always make your changes in the abstract branch
<LeoNerd> Also, you might consider "bzr shelve" to temporarily revert out the local changes, then commit what's "clean", then unshelve it back in again
<LeoNerd> I often do that for doing partial commits
<black_> thanks for the help :)
<Necoro> hmm ... just noticed that "repository/obsolete_packs" needs the most memory in my .bzr dir
<Necoro> is this cleaned automatically sometimes, is there a command to clean it - or shouldn't it be cleaned at all?
<Peng> That's odd.
<Peng> Oh, never mind, not impossible.
<Peng> Yes, it's cleaned automatically.
<Necoro> and when? - running "bzr pack" even increased it ;P
<Peng> It's cleaned when repacking is done.
<Peng> When you run "bzr pack" or auto-packing happens, it deletes everything in obsolete_packs, copies the current packs and indexes to it, and then does the packing.
<jam> howdy all
<Peng> Wait, so is bialix just on vacation or leaving permanently?
<jam> Peng: well, last year he took "vacation" for a short time and came back
<jam> Not sure how long it will be this time
<Peng> He said he was leaving permanently last time?
<jam> no, that he was taking a break/vacation, which is what he said at the beginning of this thread, unless it has changed
<Peng> Ok.
<Peng> His message sounded very final though.
<jam> Peng: it does a bit, now that I've re-read it. We'll see, though. I seem to recall him sounding like he would be going away fairly permanently last time, and then he seemed to come back rather quickly.... It would be a shame to loose him
 * lamont wonders about .bzr.log and when/why it comes to exist
<dato> always afaik
<lamont> so..  when does bzr create it in the tree, instead of $HOME?
<dato> hm, I was talking about the one in ~
<black_> is there a way to push or otherwise backup an entire repository?  can you simply copy a repo and all it's branches to another computer and then reasonably expect to be able to push and pull from the same rep/branches it was copied from?
<black_> curious how other people were handling this
<jam> lamont: the only time I've seen it show up in the tree is when running a test which sets $HOME to $CWD
<lamont> jam or if $HOME is unset or equal to "", it would appear.
<lamont> my case was the former
<statik> black_: yes, you can
<korpios> black_: yeah, I've been wondering the same thing
<black_> I just figured it out
<black_> there is a plugin to do it
<black_> repo-push
<Noia> is there a way to pass the password as part of an alias when performing a commit?
<Noia> I commit and update a whole lot, and one of the slowest things is typing my password >.<
<james_w> Noia: over ssh>
<Noia> yea, bzr+ssh://
<james_w> have you though about ssh-agent?
<Noia> ssh-agent?
<james_w> ah, sorry, you need keys set up to do that, but it is a whole lot easier in the long run
<Noia> hmm
<Noia> I quite like this way of developing thugh
<Noia> I have a server which has the repo, then a development server and a production server, both of which build off the same repo
<Noia> so when I develop something I just push to the repo, and update the dev server, then when I want to roll out I just update the production server
<Peng> jelmer: bzr.dev isn't compatible with bzr-svn 0.4.9 anymore. What should I do? Use a different version of bzr? Is bzr-svn's 0.4 branch stable now?
<ubotu> New bug: #220453 in bzr-gentoo-overlay "Branching a read-only HTTP branch (with no working tree) fails with bzr-1.4" [High,Confirmed] https://launchpad.net/bugs/220453
<malept> hi, I've been attempting to install an HTTP smart server via fastcgi using the user guide, and I keep hitting a "NotBranchError" when trying to branch it (using 1.4rc2)
<jelmer> Peng: no, there's nonthing non-experimental you can use with bzr.dev
<Peng> That's unfortunate.
<Peng> On the off-chance the PPA works, I could use the system version when I need bzr-svn.
<Peng> I'm about to wander off, but.
<Peng> How major are the changes necessary to make 0.4.9 work with bzr.dev?
 * Peng wanders off.
<jam> Peng: I'm sure it is probably rather minor, do you know what the error is?
<jelmer> Peng: I don't know, 0.4 may not be compatible with bzr.dev yet either
<Peng> jam: Err.
<Peng> jam: From knit.py, "ValueError: No default access_method or index any more".
<jelmer> Peng: that should be a pretty easy fix to backport
<jelmer> there's a couple of other ones I think though
<jam> I think it just requires passing a single parameter
<jelmer> jam: no, it relied on default arguments that lifeless removed in KnitVersionedFile's constructor
<Peng> Oh, I didn't notice it's a VersionedFile thing. Lots of changes there...
 * Peng wanders off now, for realz!
<jam> jelmer: which means you need to pass the parameter :)
<jam> (/argument)
<jelmer> jam: I ended up using a different function to create the knit
<jelmer> since the only thing way to construct a knit index involves private classes
<jelmer> I wouldn't mind if bzr releases were less often, that would save me from doing bzr-svn releases as often
<jelmer> I'll try to do one before 1.4.0 is released though
<radix> jelmer: is it actually necessary to do bzr-svn releases for every single bzr release?
<radix> is it using internal bzr APIs that change every release?
<jam> radix: we have had a tendency to break bzr-svn, we maintain "client" compatibility, but bzr-svn tends to hook in a bit deeper as an "implementor"
<jam> so if we add an optional parameter, it needs to handle it
<radix> OK
<radix> actually I'm more annoyed with bzrtools breaking for every release:)
<malept> hrm, I fixed my fastcgi problems (I think), but I've hit an AttributeError when trying to branch from the http smart server-enabled branch: http://dpaste.com/46365/
<abentley> jam: We don't do a very good job at maintaining client compatibility either.
<foom> does ianc's benchmark suite have a webpage of historical results somewhere?
<jam> abentley: we historically have done a fairly decent job at it, I think in the last few releases we've stopped trying as hard
<foom> I ran across benchmark.bazaar-vcs.org but it seems to be dead.
<abentley> jam: beg to differ.
<malept> has anyone seen that particular error before?
<abentley> Pretty much every release breaks something, and those that don't usually deprecate something.
<jelmer> radix: yes, because bzr breaks the API every release (one exception so far in the history of bzr-svn)
<radix> abentley: deprecations are great, I love deprecations
<Peng> jelmer: Was the exception 1.3.1? :P
<abentley> radix: Most end-users don't.
<jam> abentley: I don't consider a deprecation a strict api breakage, though argubly the 'released' bzr should disable the deprecation warnings by default
<jelmer> Peng: no, 1.2
<radix> abentley: well, I don't know about user-facing things, I'm assuming we're only talking about APIs
<abentley> jam: I made a significant rewrite of graph-ancestry for bzrtools 1.4 just to avoid a deprecation warning.
<radix> however, I do think deprecations are great compared to immediate breakage :)
<abentley> radix: If I use a deprecated API, there are user-facing consequences.
<radix> abentley: what are those?
<abentley> radix: A deprecation warning is emitted.
<jam> radix: a warning that you are usinga deprecated function
<radix> abentley: IMO all python application mainpoints should filter out DeprecationWarning
<radix> the only ones that shouldn't be are UserWarning (I guess)
<abentley> radix: wearing my plugin author hat, that's not really relevant to me.  bzr's deprecation handling is what it is.  I try to cope.
<radix> I guess I was just curious if bzrlib's API is breaking all the time *without* going through a period of deprecation
<abentley> radix: Have a look at NEWS.
<radix> abentley: ok, then switch back to your bzr developer hat and add a filter for DeprecationWarning in main :-)
<jelmer> radix: it does for some APIs
<jelmer> radix: but bzr-svn touches a couple of core parts of bzrlib
<radix> jelmer: right, yeah, I understand bzr-svn is rather "deep"
<radix> jelmer: thanks
<Peng> Ba, like 5-10 seconds of network access to download one trivial revision. :P
<Peng> Bah*
<ubotu> New bug: #220806 in bzr "PyCurlTransport doesn't define the _remote_is_at_least_1_2 property" [Undecided,New] https://launchpad.net/bugs/220806
<igc> morning all
<abadger1999> Have there been any backwards incompatible API changes to bzrlib since 1.1?
<abadger1999> I saw that there's going to be some deprecations in 1.4 with removal probable in 1.5.
<abadger1999> Just checking if I missed anything else.
<beuno> abadger1999, I don't know of the top of my head, but a quick glance at NEWS should tell you
<abadger1999> Ah, good point
<beuno> :)
<LaserJock> is there a particular reason why a bzr pull would be giving bzr: ERROR: Not a branch: for a LP branch?
<beuno> LaserJock, are you in the branch's dir?
<LaserJock> yeah ... thought so
<fullermd> What version?
<LaserJock> 1.3.1rc1
<fullermd> Probably not the smart probing thing then.
<LaserJock> hmm, I did do a bzr reconfigure --branch
<LaserJock> does that matter?
<abadger1999> Darn it, there is but it's not a major break.
<fullermd> Not directly, I wouldn't think.  But it may leave you with a parent location that's not what you want.
 * abadger1999 figures out how to let the bug reporter persuade him to update over his better judgement.
<LaserJock> if the little progress wheel on the left stops turning does that mean it's stalled?
 * abadger1999 reads scrollback and sees that abentley and jam were talking about exactly his problem earlier.
<jam> abadger1999: I would never discuss your problems in public :)
#bzr 2008-04-23
<abadger1999> jam: Shh..  Not that one, the other one!
<abadger1999> :-)
<lifeless> hi guys
<lifeless> I'm back on deck
<mwhudson_> wb lifeless
<abadger1999> So I'm a bit conflicted about all the changes going into the 1.x series.  I love how it makes the code better instead of crufty.  But at the same time as a packager, I sometimes feel like I shouldn't be pushing a new update to a release.
<LaserJock> is there a way to see what branch format a branch on LP is in without branching it?
<abadger1999> Which is okay for Fedora (just update to the next release, it will be out in < 6 months)
<jam> LaserJock: bzr info URL
<jam> I would generally recommend the http url, otherwise you get something about the RemoteRepository, IIRC
<abadger1999> But it's going to be hard if I do that for RHEL (five years on an old version of bzr with no upstream bug fixes or security fixes).
<LaserJock> darn, still getting "not a branch"
<mwhudson> LaserJock: can you give us more details?
<LaserJock> trying to pull bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/
<jam> abadger1999: well i would argue that we've had lots of upstream bug fixes and security fixes, we just stamp it with a new release ... :)
<jam> but I understand your point
<jam> as of yet, there hasn't been enough impetus to backport anything
<jam> I think we've had only 1 'x.y.1' release, and maybe discussed doing it 2 or 3 times
<abadger1999> jam: Yep!  So far I've just rolled out updates with every new bzr release to gain all the new features/performance/bugfixes.
<abadger1999> But every time I see an entry under API BREAKS, I have to re-evaluate whether I can keep doing that or if doing so will break the expectations of the users consuming my package.
<abadger1999> It's just a mismatch between a fast moving product like bzr and pushing it to a distro with a long-term support cycle.
<abadger1999> Not sure what you guys could do about it except maybe emulating gnome by introducing new API (and deprecating the old one) instead of removing API when it is superseded by something better.
<abadger1999> But that's an increased support burden on you so I understand why you wouldn't want to do that.
<jam> abadger1999: we do that for most things
<jam> though "long term" is months in our case, not years
<LaserJock> mwhudson: any thoughts?
<jam> abadger1999: but sometimes we decide to cut our losses, rather than support something broken for a long time
<abadger1999> jam: heh.  Yeah :-)
<abadger1999> months vs years is the issue I face :-)
<jam> abadger1999: we've supported the disk formats for years
<foom> yeah but you can't use an old version of bzr for anything
<foom> because everyone *else* is using new formats
<bob2> LaserJock: wfm (r3377)
<LaserJock> mwhudson: so it seems that bzr+ssh didn't work but http did
<abadger1999> Which leads to problems on a long-term supported distro... introduce a new version so some users can collaborate with others using the new format or stay with the old version so some other users can continue using their in-house, custom tools.
<mwhudson> LaserJock: oh, hm
<mwhudson> LaserJock: you have done bzr launchpad-login, i take it?
<LaserJock> what do you mean?
<abadger1999> I guess another option would be to allow for multiple versions of bzr/bzrlib to be installed.
<LaserJock> oh, no, I haven't
<LaserJock> why do I need to do that?
<mwhudson> LaserJock: so bzr+ssh knows with user to use
<LaserJock> I told it to use my LP id
<mwhudson> oh, ok
<mwhudson> LaserJock: can you pastebin what happens when something goes wrong?
<abadger1999> Use deprecation until a new disk format appears/you don't want to keep supporting all the cruft.  Then release with all that fixed and the module as bzrlib2.
<LaserJock> mwhudson: it's just:
<LaserJock> Using saved location: bzr+ssh://laserjock@bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/
<LaserJock> bzr: ERROR: Not a branch: "bzr+ssh://laserjock@bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/".
<foom> abadger1999: that only really seems doable for a mature project that's not changing rapidly
<abadger1999> That works for libraries, but I don't know that it would work for bzr since it has a client app as well.
<abadger1999> foom: Definitely would be better for mature projects :-)
<abadger1999> But GNOME is a counterpoint.  They've managed not to break API compatibility for a long time despite making many changes to the API.  But they pay for it by having to drag all the compatible stuff along with the good changes.
<mwhudson> LaserJock: bzr -Dhpss pull and look at ~/.bzr.log ?
<LaserJock> mwhudson: doesn't look all that helpful to me but I can pastebin it for you
<mwhudson> LaserJock: please do
<abadger1999> Oh well, when wearing my Fedora hat I love that bzr is evolving rapidly, when wearing my EPEL maintainer hat, I often feel guilty that I'm pushing a bzr update which may break someone's code somewhere.
<abadger1999> Like I said in the beginning.  I'm conflicted about this and don't see an easy answer.
<LaserJock> mwhudson: http://paste.ubuntu.com/7807/
<mwhudson> LaserJock: can you write to this branch?
<LaserJock> in what way?
<mwhudson> push to it
<LaserJock> supposedly :-)
<mwhudson> are you a member of ~ubuntu-core-doc ?
<LaserJock> yes I am
<thumper> LaserJock: I'll take a closer look on the machine...
<LaserJock> I'm just in the middle of trying to fix a boo boo
<LaserJock> which I made need some help figuring it out
<LaserJock> we lost some revisions on the edubuntu-hardy branch
<LaserJock> and I'm not sure the best way of getting them back
<LaserJock> I think as long as I keep the formats straight I should be able to just push
<mwhudson> uh
<mwhudson> there is no .bzr directory at all in the push area for this branch!?
<LaserJock> mwhudson: which branch?
<mwhudson> LaserJock: ~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy
<LaserJock> you mean you can't find one or do I see one? :-)
<thumper> mwhudson: yes there is
<thumper> ah
<thumper> damnit looking at the wrong one
<mwhudson> LaserJock: i'm not asking you a question, don't worry
<LaserJock> mwhudson: ok, phew ;-)
<mwhudson> LaserJock: is there the slightest chance that some one has done the equivalent of "rm -rf .bzr" on this branch?
<LaserJock> mwhudson: mdke said he was updating the branch formats
<mwhudson> oh
<mwhudson> ho ho
<LaserJock> in so doing I lost 9 revisions in my edubuntu-docs branch
<LaserJock> which is what I was originally trying to fix
<LaserJock> but it got me sidetracked when I couldn't bzr pull the ubuntu-hardy branch
<LaserJock> s/edubuntu-docs/edubuntu-hardy/
<mwhudson> so, i have to admit, i don't really know what's happened here
<LaserJock> hmm, ok
<mwhudson> if mdke was trying to do format upgrades, that sounds like its probably related
<LaserJock> would be logical
<mwhudson> LaserJock: is the version you see at the http: url at the revision you expect?
<LaserJock> yeah, it pulled in a couple revisions
<LaserJock> it looked fine to me
<mwhudson> looks like 3799
<mwhudson> i can copy that back into the push area
<mwhudson> i guess i can do the upgrade on the server too while we're at it...
<LaserJock> mwhudson: so you're able to recover the branch?
<mwhudson> LaserJock: yes, if you want me to
<LaserJock> mwhudson: any reason not to?
<LaserJock> I assume we don't want it in the state it's in
<mwhudson> LaserJock: i can't think of one
<LaserJock> as long as we don't loose anything :-)
<mwhudson> LaserJock: do you want it upgraded to rich-root-pack at the same time?
<LaserJock> yeah, that's what we're after
<mwhudson> in progress
<LaserJock> mwhudson: can you see if anything happened to kubuntu-hardy and xubuntu-hardy?
<LaserJock> I know I lost 9 revisions in edubuntu-hardy but I assume I can fix that with a bzr push
<mwhudson> they look ok
<mwhudson> edubuntu-hardy has been upgraded
<mwhudson> which might be where you revisions went
<mwhudson> if mdke did it by downloading the branch, upgrading and uploading it again
<LaserJock> yeah
<LaserJock> I don't know why he wouldn't have the revisions though
<LaserJock> maybe he forgot to bzr pull first
<LaserJock> mwhudson: would it be possible to have one of you guys convert kubuntu-hardy and xubuntu-hardy on the server?
<LaserJock> so we don't end up with issues like this
<mwhudson> LaserJock: yes, sounds sane
<LaserJock> I'm sure mdke would appreciate it
<mwhudson> LaserJock: can you ask a question on launchpad-bazaar ?
<LaserJock> I can
<lifeless> abadger1999: they have actually broken ABI since 2.0, if you consider ABI in the broader sense of 'the behaviour' rather than just 'it links and structs are the same size'
<lifeless> abadger1999: but this doesn't invalidate your point about the costs
<LaserJock> mwhudson: question asked and I fixed up edubuntu-hardy
<lifeless> spiv: bug 220806
<ubotu> Launchpad bug 220806 in bzr "PyCurlTransport doesn't define the _remote_is_at_least_1_2 property" [Undecided,New] https://launchpad.net/bugs/220806
<spiv> lifeless: ta
<lifeless> :)
<abentley> lifeless, spiv: Initial branch of rocketful over bzr+ssh is excruciatingly slow.
<spiv> abentley: hmm.
<lifeless> abentley: yes
<abentley> Our new hire reported it took 4 hours.
<bob2> ow
<bob2> segwayfuel
<lifeless> we're running bzr 1.3.1 on devpad
<abentley> I'm not sure how long it took for me at first.  tens of minutes?
<lifeless> it should have the newer graph logic
<lifeless> what bzr did the hire use?
<abentley> I dunno, but it looks pretty wrong with bzr.dev.
<lifeless> did they create a pack or knit local repo?
<lifeless> there is currently transcoding required, and that can buffer pretty highly
<abentley> They just did ï»¿bzr branch bzr+ssh://devpad.canonical.com/code/rocketfuel/launchpad/devel trunk
<abentley> I can confirm that on my box, this does tons of Graph.get_parents_map calls.
<lifeless> there is a debug flag
<abentley> It's doing _walk_to_common_revisions(), which looks wrong.
<lifeless> it should be exponentially increasing in data retrieval
<lifeless> with a cap
<abentley> Many of these calls were 14k or so.
<lifeless> if you do -Dhpss
<lifeless> it reports hit rate and stuff
<abentley> I'm reporting the results I got from doing Dhpss
<abentley> There were a lot of results with 43474 bytes.
<abentley> then a lot with 83598 bytes
<lifeless> what was the retransmitted revisions count ?
<abentley> Always 0 of x
<lifeless> ok
<lifeless> how many minutes did the graph traversal take ?
<abentley> Dunno.  I killed it before it completed.
<lifeless> how many minutes in was that ?
<lifeless> and what was the last hit rate you had reached ?
<abentley> The time was 488.460
<abentley> The last hit rate was 98%
<lifeless> what was the rtt around the last request?
<lifeless> (just the tiem from sending to the hit rate output)
<abentley> Looks like 0.009
<lifeless> so something doesn't add up here to me
<abentley> No, you probably want from 439.611  hpss call w/body: ' to '444.812  Current RemoteRepositor'
<lifeless> so 5 seconds
<lifeless> 12 steps a minute
<abentley> The length of the last request was 146775 bytes
<lifeless> thats a pretty big upload
<lifeless> so there is a tradeoff we can make
<lifeless> between retransmitted revisions; network latency, and request size
<abentley> I thought for initial branches we were still doing the tarball thing.  Is that gone?
<lifeless> yes
<lifeless> we need to handle such similar cases that can't be special cased like that anyhow
<abentley> But it seems like this one could be special-cased to great benefit.
<spiv> abentley: there's a new method that will stream all the necessary revision data in a single request -- once it knows what revisions to ask for.
<lifeless> abentley: the tarball special case nearly broke the supermirror; it was very harsh on server load
<spiv> (and without the nasty 'buffer the whole response before sending' that the tarball method had)
<abentley> We probably don't need to be so extreme, but I would think _walk_to_common_revisions could be done on the server side.
<lifeless> abentley: improvements in this area are welcome; I think I've posted lots on the list in the past
<lifeless> abentley: doing _walk_to_common_revisions on the server side is something that conceptually eludes me
<abentley> So I'm wrong in thinking this is a regression?
<abentley> I could have sworn it completed in tens of minutes for me.
<lifeless> its not a 1.4/bzr.dev regression *if* the bulk of the delay is in the graph walk
<abentley> lifeless: _walk_to_common revisions is used to determine what we need to send, right?
<lifeless> abentley: what we need to request from the server yes. And it depends on our local graph
<abentley> In this case, we know the local graph is empty.
<lifeless> abentley: yes
<lifeless> abentley: though in general we don't want to do size(repo) operations, we do have a [relatively] cheap 'len()' for the revision graph.
<abentley> So in this case, we only need server-side data to know what to send.
<spiv> Ok, it took just over 1000s for the graph walking for that to complete for me.
<spiv> (from my laptop to London)
<lifeless> yah
<lifeless> this is clearly improvable
<lifeless> abentley: I'm ok with us special casing the selection somewhat; I think its important though that 'bzr branch bzr+ssh://launcpad...' into an existing non-empty repo *also* be fast
<abentley> Yeah, I agree.
<lifeless> abentley: the current worker method that is used to fetch is 'RemoteRepository.get_data_stream_for_search'
<abentley> The reason I raised it now was because it seemed plausible as a regression.  I knew you'd done some work in that area.
<lifeless> abentley: if I were to special case the empty repository case I would look at constructing a search by hand
<lifeless> yeah, its very plausible as a regression
<abentley> I'm going to see how long it takes me.
<spiv> It gets to 99% relatively quickly (only two minutes).
<abentley> spiv: It's at 97% for me at 417.137
<spiv> Actually, that's a slightly confusing measurement.
<spiv> More interesting is that after about 90s it starts getting lots of results of only 14 bytes, rather than 10s of kB.
<lifeless> spiv: I bet its running into reached parts of the graph
<lifeless> spiv: this is where I ran out of time and had to switch tracks
<lifeless> spiv: history shortcuts will lead to inconsistent round trips being needed to reach a node N
<abentley> Is it just me, or should we be implementing a graph traversal on the server side to avoid all these get_parent_map calls?
<lifeless> abentley: the get_parent_map calls are server side graph traversal
<lifeless> abentley: remember that we don't have full duplex facilities
<abentley> I'm seeing  hpss call w/body: 'Repository.get_parent_map'
<abentley> Which makes me think we're asking for a whole bunch of parents, then waiting for the result.
<abentley> Then asking for more parents.  Etc.
<lifeless> each time we do that we recieve more data than we asked for
<lifeless> the server anticipates future requests and bundles those into the response
<abentley> Cool.
<abentley> So that's why you expect it to increase exponentially.
<lifeless> it performs a breadth first search on the server side
<lifeless> and trims revisions we've already recieved
<lifeless> the result is cached in the clients RemoteRepository object
<abentley> But it is definitely not increasing exponentially.
<lifeless> have a read of remote.py's RemoteRepository._get_parent_map
<lifeless> I think I was misremembering
<lifeless> I tried a half dozen strategies when doing this
<lifeless> expoential increases, constnat sizes, etc
<lifeless> I believe it can be improved significantly while still only exposing 'get_parents_map' to the python client code
<lifeless> hmm
<lifeless> exponential backoff would be good
<abentley> It started stream_revisions_chunked at 1135s
<lifeless> I don't know if it needs a new wire flag or not
<lifeless> so 20 minutes
<lifeless> I suspect the knit conversion is a performance issue tho
<lifeless> we're going to be unpacking and repacking the entire history
<abentley> That's not a factor for this case, is it?  Rocketfuel is in pack-0.92
<lifeless> oh, it is too
<lifeless> I wonder if we annotate it on the server, send it, and then strip on the client
<abentley> Well, bazaar seems to be doing *something* fairly CPU-intensive.
<abentley> But bazaar doesn't CTRL-\ during network ops...
<lifeless> 20098 abentley  15   0 1314m 1.2g 3020 S    0 32.7  12:17.25 python
<abentley> This is how long it took you to branch rocketfuel?
<abentley> Oh, ps output.
<lifeless> spiv: ^ sure we don't buffer anymore?
<spiv> lifeless: yes
<lifeless> abentley: 'top' actually
<spiv> lifeless: jam recently reported that to me too
<spiv> lifeless: I haven't had time to dig into it yet, but it doesn't seem to be a regression
<abentley> eh?  Your 'top' output has my login name?
<spiv> On devpad
<abentley> Oh.
<lifeless> abentley: :P
<abentley> lifeless: So on my side, 'top' says:
<abentley> 15492 abentley  20   0  475m 346m 2816 R 79.6 34.3  11:20.95 python
 * spiv -> lunch
 * mneptok takes this opportunity to pimp htop
<RAOF> Mmm, sweet htop!
<mneptok> i've updated my Unix toolset from top to tail.
<mneptok> (namely, to htop and inotail) ;)
<RAOF> inotail?  Hm, haven't seen that one :)
<lifeless> really its a bug
<lifeless> should be able to select() on a disk file fd
<abentley> branch complete: 73m, 4.4 seconds.
<abentley> rockstar_: It took me 1h, 13 minutes to branch rocketfuel.  Does that jibe with your experience?
<rockstar_> I think it was closer to two hours
<mlh> I was reading themail on bzr for gedit
<mlh> option C - subprocess. This might solve a lot of problems  -- to strongly disassociate the ui from bzrlib
<mlh> you coould even haev the tui start up a bzrlib process and send it commands.
<mlh> you'd have to be careful of context/environment though
<mlh> as well as interop with gedit/win32 exlporer/nautilus etc it might help the perceived speed of bzr if the client is very small
<mlh> it's a big task though
<mlh> see http://www.martiansoftware.com/nailgun/ for a similar idea for java - in this case the client is in C
<igc> bb i a few minutes
<lifeless> ok, I have the new stream stuff functional
<lifeless> now to eliminate join, and then optimise the stream copy
<lifeless> I'm pushing up the current branch, because I'm fading now, still not entirely well I don't think
<AfC> lifeless: best wishes for a speedy recovery
<lifeless> AfC: thanks
<johnf> If I have two totally separare bzr trees with no common ancestors is it possible to merge one into the other.
<johnf> basically I have some scripts I was keeping in a different bzr branch that I want to add to the main app
<spiv> Yes, "bzr merge -r0..-1 ../unrelated"
<johnf> spiv: cool that worked. Thanks
<lifeless> all pushed anyhow - the 'versioned_files' branch
<mdke> mwhudson_: yes, I've been doing rm -rf .bzr on it overnight - on purpose
<mdke> mwhudson_: I'm just pushing the upgraded branch up now (for ubuntu-hardy)
<jamesh> mdke: how did the upgrade go?
<mdke> jamesh: seems to have gone fine, although i've discovered now that mwhudson_ has the magic ability to do it on the serverside
<mdke> https://answers.edge.launchpad.net/launchpad-bazaar/+question/30469
<jamesh> mdke: the delete-then-upgrade strategy can take a while for knit branches with a large number of files
<jamesh> since you get "2*n_files + constant" round trips
<mdke> jamesh: yeah, I left the delete on overnight
<jamesh> sftp lets you do things more efficiently (by pipelining commands), but I don't think lftp takes advantage of that
<mdke> jamesh: one thing is that it does seem to break the LP branch - when I deleted it overnight, one of the users got a bit surprised and came in here to ask about how it could be restored; so I found it restored and upgraded when i woke up :)
<jamesh> mdke: were they accessing it via http or bzr+ssh?
<jamesh> and did they have write access to the branch?
<mdke> without realising that that had been done, I redeleted it and pushed it again
<mdke> jamesh: probably bzr+ssh and yes
<jamesh> mdke: then that access would have gone through to the writable area where you were deleting stuff
<mdke> ah
<mdke> oh well, I had posted to the mailing list to warn people
<mdke> couldn't have done much more
<jamesh> pack formats comprise many fewer files, so the delete takes a lot less time
<jamesh> although people are usually upgrading to pack formats than from them
 * mdke nods
 * igc dinner
<awilkins> Hmm, bzr:// isn't always fastest is it?
 * TFKyle expects file:// would be faster personally :)
<awilkins> It is, especially into a --no-trees repo
<awilkins> bzr:// transferred about 5 MB of data then the bzr process on the server starts really chewing CPU
<awilkins> Mind, this is a rather large tree
<ubotu> New bug: #220936 in bzr "bzr report internal error when I try to access repository under other locale then repository was created" [Undecided,New] https://launchpad.net/bugs/220936
<toojays> Hi
<toojays> I'm wondering if anyone here can help me out with bug 219832.
<ubotu> Launchpad bug 219832 in bzr "KnitCorrupt: corrupt: incorrect number of lines while branching from svn" [Undecided,New] https://launchpad.net/bugs/219832
<silwol> i got a problem with bzr and paramiko installed in my home directory on a server without root access for me
<silwol> installed paramiko using "python setup.py install --home ~"
<silwol> did the same for bzr
<silwol> when I want to branch from sftp url, I get
<silwol> user@server:~$ bzr branch sftp://server/path/to/branch
<silwol> bzr: ERROR: Unsupported protocol for url "sftp://server/path/to/branch": Unable to import paramiko (required for sftp support): cannot import name util
<silwol> anybody knows what the problem could be?
<TFKyle> silwol: you might need to add where that installed paramiko to PYTHONPATH
<toojays> silwol: Do you need to set PYTHONPATH maybe?
<silwol> PYTHONPATH is set to ~/lib/python
<silwol> without it, bzr does not even run at all
<dato> silwol: and is paramiko there too?
<silwol> esd07016@hssesrv01:~$ ls $PYTHONPATH
<silwol> bzrlib	paramiko
<dato> ok
<silwol> do i need pycrypto installed?
<toojays> I reckon you do.
<TFKyle> heh, yeah
<silwol> hmmm, too bad... there is no gcc :-(
<TFKyle> silwol: out of curiosity, what version of python?
<silwol> .24
<silwol> 2.4
<silwol> a current rhel server
<TFKyle> 'k, so that wouldn't work even if it didn't need DES (which it probably does)
<TFKyle> might be able to steal someone elses binaries and hope they work :D
<silwol> well, i'll create some on my local pc
<silwol> hope there are no symbol problems
<TFKyle> silwol: hmm, you might be able to extract the rpm for rhel (I'd assume it'd have a pycrypto package, I could be wrong though) and throw the files in ~/lib/python
<silwol> TFKyle: the admin told me there is none, otherwise he would already have it installed
<TFKyle> ah
<TFKyle> guess gcc is too big for the admin to want to put on?
<silwol> i think it's a security issue... will ask him again
<silwol> thanks for your help anyway... if i run into problems again, i'll come back
 * TFKyle should probably look into doing pure-py equivs of most stuff in pycrypto, too bad everyone having 2.5 can't be relied on (makes it easier for the hashing stuff, can just call hashlib.sha256/etc. for some stuff instead of having to implement it in pure-py)
<silwol> okay, it worked by copying pycrypto compiled on my laptop
<silwol> thanks people
<awilkins> This is bugging me ; I'm trying to test some mods to gconflicts ; but I'm finding it hard to make a simple tree with text conflicts in it
<awilkins> http://pastebin.ca/994453
<awilkins> Can someone explain what I'm seeing in the link? I think it's incorrect behaviour personally, but perhaps there's a good reason.
<awilkins> What I would expect is a text conflict, not a content conflict
<james_w> so would I
<james_w> does "bzr conflicts --text" list it?
<awilkins> Nope
<awilkins> The logs correctly note each relevant revision as a modification to stuff.txt
<james_w> it seems that the file ids get mixed up then, but you're typescript suggests that they shouldn't
<awilkins> The logs never note a deletion of stuff.txt, so how can a merge produce one?
<awilkins> Let me try this in a non rich-root repo
<awilkins> Ok, trying with standalone pack.092 branches
<awilkins> Does it in plain pack.92 branches too
<luks> I get a text conflict using the same steps
<james_w> I can't reproduce either
<james_w> awilkins: are you on up-to-date bzr.dev?
<awilkins> File-ids are identical
<awilkins> james_w: No, this is 1.31
<awilkins> Erm, I thought it was, it's 1.30
<james_w> awilkins: I can't reproduce with 1.3.1 either
<awilkins> WHen I finish installing 1.3.1 I'll try it again
<james_w> thanks
<awilkins> Same again, contents conflict
<awilkins> Hmm, let me try with no plugins
<awilkins> Still the same with no plugins
<awilkins> Is this a windows-specific thing?
<james_w> could be
<awilkins> I'm presently working on the theory this may be a unicode BOM thing (?!?!?!?)
<awilkins> I'll try again with ANSI files
<ubotu> New bug: #195217 in bzr-lpreview "ReadOnly error when running bzr review-submit with no arguments" [Undecided,New] https://launchpad.net/bugs/195217
<awilkins> Bingo ; it's because the magic function in bzr is detecting the files as binary
<abentley> awilkins: Yes, it could be a unicode BOM thing.  binary detection is based on finding non-ascii bytes.
<abentley> Specifically 0
<abentley> i.e. the NUL bytes.
<abentley> So technically ASCII, but never used in text documents.
<abentley> awilkins: Your files aren't utf-16 are they?
<awilkins> abentley: Yes, they are
<abentley> Oh, they are binary, then.  Thanks for playing.
<awilkins> abentley: 'tis what you get by default as output from Powershell
<awilkins> abentley: You do the same test using cmd.exe as a shell and it works fine
<awilkins> Grr, the output encoding on PSH being utf-16 by default is bloody annoying
<abentley> awilkins: bzr does tend to assume that files are in a bytes-based encoding.  Even if I could fix it for utf-16 files, merge would act funny because it wouldn't detect newlines correctly.
<awilkins> abentley: I agree that utf-16 is something of a marginal format, especially in the west
<abentley> I suppose if we detected a BOM, we might be able to skip the rest of the test.
<awilkins> Want a bug submitted so people can spit on it?
<abentley> But that doesn't solve the problem that '\n' doesn't mean newline in utf-16
<abentley> Sure
<awilkins> No, it's \n\0 with an even offset, yes?
<abentley> Well, it depends on whether the UTF-16 is LE or BE.
<awilkins> Would a BOM convey that, perchance
<abentley> Indeed it would.
<awilkins> Python seems to be pretty encoding-savvy from what I've seen of the docs - first langauge I've seen which knows which encoding your source file is
<abentley> It's definitely much better than older languages like C, but Python 3.0 will really get it right.
<sssslang> hi could some can told me how to make bzr didn't complain differences between same dos and unix files(about the EOL).
<ubotu> New bug: #221021 in bzr "bzr send should write to a remote file when --output file provided" [Undecided,New] https://launchpad.net/bugs/221021
<ubotu> New bug: #221031 in bzr "switching between checkout and branch causes abandoned lock" [Undecided,New] https://launchpad.net/bugs/221031
<jam> morning all
<Odd_Bloke> jam: o/
<jelmer> jam, Odd_Bloke: dudes!
<Odd_Bloke> Sweet.
<james_w> hi all
<james_w> Installer testing is fun!
<james_w> jam: how was your holiday?
<awilkins> Who do I mail merges for gtk plugin to?
<Odd_Bloke> jelmer: ^
 * awilkins is poised to mail jelmer
<james_w> there's a list isn't there?
<awilkins> https://launchpad.net/~bzr-gtk
<Odd_Bloke> I think so, but jelmer probably knows the details. :p
<jelmer> awilkins: bzr-gtk@lists.canonical.com
<TFKyle> could also just ping him here :)
 * jelmer is here, but behind a very laggy sattelite connection from the UK
<Odd_Bloke> jelmer: Whereabouts are you?
<awilkins> Jelmer is team owner, but no contact details listed. Isn't there a "default place to mail stuff" field for this
<jelmer> Odd_Bloke: in a train somewhere near Wakefield
<jelmer> awilkins: yes, bzr-gtk@lists.canonical.com :-)
<awilkins> Sent, just a small patch to improve the external conflict util starter
<Odd_Bloke> jelmer: Oh, cool. What brings you to the UK?
 * awilkins muses that it can't be anything you could get in Amsterdam
<jelmer> Odd_Bloke: visiting a company here that's doing some samba-related stuff
<Odd_Bloke> jelmer: Cool.
<jelmer> awilkins: hunting would be something that's allowed in the uk but not in .nl I think :-)
<TFKyle> speaking of bzr-gtk, any way to make visualize default to showing the date column? (in current trunk)
<jelmer> it should just remember whether or not you have that column enabled
<TFKyle> doesn't seem to here, where's it normally store that?
<awilkins> TFKyle: Seems to store it in the global bzr config (or try)
<jam> james_w: my holiday went quite well, though it was a bit longer than I usually prefer
<TFKyle> awilkins: ah
<james_w> jam: better longer than shorter :-)
<awilkins> TFKyle: It stores it properly, but it doesn't seem to work here
<TFKyle> seems to be there (under the DEFAULT section), just not getting it back properly, I'll have a look at the code
<awilkins> Bug in the property settings
<awilkins> fixx0red
<awilkins> Want a merge bundle?
<TFKyle> mm, indeed
<TFKyle> sure
<awilkins>  /msg me your email addy
<TFKyle> thanks
<jam> james_w: it seems Thunderbird + Lightning + Gmail is capable of locking my machine hard when it goes to alert me about missed events
<jam> james_w: anyway, 2 shorter vacations is better than 1 longer one (for me at least)
<james_w> jam: are you using compiz?
<jam> I had to get a bit creative with holidays to string together 3-weeks uninterrupted
<jam> james_w: yes
<james_w> jam: hardy?
<jam> yep
<james_w> check you have the latest compiz-fusion-plugins-main installed
<jam> Well, there are 2 issues
<james_w> it sounds like exactly the problem I was having that I found the fix for this morning.
<jam> 1 is that I get a quick "beep beep beep" for 3 alerts
<jam> and then it freezes
<jam> 2 is that it has lightning, but not 'provider for google calendar' which means I can't *modify* any of those alerts
<jam> I'll make sure to update, though
<jam> thanks for the heads up
<james_w> hmm, maybe it's different then.
<jam> james_w: "apt-get update && apt-get upgrade" is asking to install 123MB of stuff
<jam> so something is being updated :)
<jam> compiz-fusion-plugins-main is in that list
 * james_w crosses his fingers
<jam> well, for now I've uninstalled lightning-extension, but I might bring it back
<jam> If I had "provider" I could at least silence the alarms for now, and get back to work
<jam> but without it, it prompts me every 5 minutes or so
<jam> which doesn't give a lot of uptime
<awilkins> hmm, Hardy RTW is out today, no?
<jam> I thought it was today or tomorrow
<awilkins> 01 days to to go
<awilkins> What timezone is Ubuntu Central?
<jam> Probably UTC
<jam> or maybe UTC +1
<jam> London, IIRC, is UTC + 1
<awilkins> London?
<awilkins> UTC +1 this time of year
<james_w> it will probably be about 24 hours from now.
<awilkins> I've not tried it out yet
<awilkins> I'll have to download it twice, 32 bit for wifetop and thumb, 64 for desktop
<awilkins> Do you advise a ditribution upgrade or a reinstall?
<awilkins> (ok, ok, this isn't #ubuntu)
<ubotu> New bug: #221060 in bzr "Cannot branch Python onto launchpad" [Undecided,New] https://launchpad.net/bugs/221060
<james_w> awilkins: dist-upgrade should be fine, are you on gutsy?
<awilkins> james_w: Yup, gutsy on the wifetop and desktop
<awilkins> james_w: Will that really reduce the download size any though :-P
<james_w> no, it's going to be comparable either way.
<stianse> hi guys, I have a problem on windows bazaar verson 1.3.1. When I try to run "bzr stat" or "bzr commit" I get "bzr: ERROR: [Errno 13] Permission denied". Anybody knows what's wrong?
<james_w> it would only be if you were concerned about getting a "clean" experience.
<james_w> stianse: what version of windows?
<awilkins> james_w: I only just bleached the thing clean after installing horrible Samsung printer drivers
<awilkins> They mess with your privs
<stianse> james_w: windows xp
<james_w> stianse: I think it might be something to with locking. I can't remember the details though I'm afraid.
<awilkins> Blech, my new co worker has terrible halitosis
<stianse> james_w: ok. what I've done so far is pretty basic. running init, add, commit and push to a sentalized server. using branch to get a local branch. aplied some changes. And now I'm trying to commit these locally.
<awilkins> stianse: Is your local branch a checkout or a standalone branch?
<james_w> hmm, odd that it is failing now
<james_w> stianse: can you run with "-Derror" and pastebin the result.
<james_w> stianse: as in "bzr -Derror st"
<stianse> awilkins: I used the branch commmand, so I would say a branch? (I'm more experienced in the subversion-world, but trying to convert :-)
<awilkins> stianse: Have you used a bzr bind command at all?
<stianse> awilkins: no, no bind command
<stianse> should I?
<stianse> awilkins: http://pastebin.com/m92ff482
<awilkins> stianse: Only if you want it to automatically push changes to the server
<james_w> stianse: are there any read only files in your tree?
<stianse> no, I don't want that. it's pretty experimental code i'm working on. don't want to push until it's more stable
<james_w> stianse: are you familiar with the python debugger at all?
<stianse> james_w: no, sorry. more a c-guy ;) but I have a guy in my office that probably is. but it would have to wait until tomorrow I guess
<awilkins> stianse: Do you have any of the files in the tree open in a process that is demanding an exclusive lock?
<awilkins> stianse: Your error is occuring in a routine that just calculates a hash of the file, so it's not writing to a file
<stianse> awilkins: of course, why didn't i think of that! just wait a second and i'll try one more time
<awilkins> stianse: A resource file, possibly? Source files are usually not locked up like this by the IDE.
<stianse> awilkins, james_w: thanks for your help, it works now
<stianse> well, you don't know with visual studio :-)
<stianse> perhaps i should just stick to emacs
<awilkins> Never had that specific problem with VS.
<awilkins> It's a shame the stack dump doesn't dump parameter values
<stianse> ok, I'll try to investigate what the exact problem is if I ever experience it again
<james_w> yup
<stianse> see you later, gotta go eating dinner. thanks again!
<awilkins> stianse: You might want to shove a quick catch clause into sha_file_by_name to plop the filename to the console.
<awilkins> james_w: Would it be possible to make the stack dump show parameter values?
 * awilkins knows not enough about Python
<james_w> I'm not sure, but it would be good if it did.
<james_w> you could probably write an alternative dumper that did it.
<awilkins> I mean, you have all this funky access to functions as objects and stuff.....
<abentley> awilkins: When you submit patches, a brief description of what the patch does is greatly appreciated.
<Vadi> I did a bzr ignore with a pattern, and it said this: "Warning: the following files are version controlled and match your ignore pattern:". Did it unignore those files too? Or they're still in bzr?
<abentley> They're still in bzr.
<abentley> Files are only removed from bzr if you delete them or run "bzr remove".
<Vadi> Okay thanks
<mathrick> ho-humm
<mathrick> I need some conceptual help
<mathrick> I need to do the following:
<mathrick> I have two machines, one with fast link, but no external IP (so only accessible when I'm home), and another which has external IP, but is very slow to connect to
<mathrick> so far I've been using a checkout off the slow machine
<mathrick> but I'd like to only bind it to it when I'm not home, and otherwise bind to a branch of the repo on the fast machine
<mathrick> and run a cronjob to sync from fast to slow periodically
<mathrick> I can do that, but the problem I've run into is when conflicts arise
<mathrick> it seems that neither checkouts, nor branches from a repo will tell me that the bound location / parent branch is conflicted if that happens
<mathrick> what would be the best way to run what I want then, in a way that would allow me to reliably and no-brainerly catch any conflicts?
<mathrick> conflicts as in there's another dev on my team, who can access both fast and slow repos independently from me
<mathrick> so if we commit conflicting changes to separate repos, things break down, since the conflict isn't reported anywhere besides the sync cronjob run on the fast machine
<jam> mathrick: branches can't be conflicted, only working trees, so I'm a little curious how you are getting conflicts
<jam> I suppose it depends how you are doing the sync
<jam> if you are just using "pull" then the cron script will probably be raising "DivergedBranches"
<mathrick> jam: yeah
<mathrick> but the thing is, I wont see from my checkout that there are unmerged revisions
<mathrick> ie. I won't notice the trees being out of sync unless I specifically look for that
<jam> mathrick: you could always keep an extra branch, which you could check
<jam> so you would have:
<jam> sftp://slow-host/repo/{mainline,fast-tip,slow-tip}
<jam> And then the fast-tip is always a 'pull --overwrite' of the one on fast, and 'slow-tip' is "official"
<jam> and you try to keep "mainline" at the same tip
<jam> when it fails, you'll still have the others to see that they aren't the same
<mathrick> Ã¦h, I got lost
<mathrick> <jam> and you try to keep "mainline" at the same tip <-- here
<jam> mathrick: when you are at home, you bind to "sftp://fast-host/fast-tip"
<mathrick> yep
<jam> your cron job tries to sync that to "sftp://slow-host/mainline" and always syncs it to "sftp://slow-host/fast-tip" with --overwrite
<jam> if it succeeds as syncing it to slow-host/mainline it also overwrites slow-host/slow-tip
<jam> then when you are away from home
<jam> you bind to sftp://slow-host/slow-tip
<jam> and your cron job tries to sync that to "sftp://fast-host/mainline", "sftp://fast-host/slow-tip" etc.
<jam> it's a little bit messy, but would mean you can check when you are out of date, etc.
<jam> I think I can simplify it a bit
<jam> give me a sec to think
<mathrick> jam: okay, and would I get any indicator when I try to commit and the branches have diverged?
<mathrick> commit from my laptop that is
<jam> mathrick: not at commit time, no
<jam> you would have to check
<jam> though you could add a 'pre-commit' hook that could check for you
<mathrick> that's precisely the problem I have with my current setu[
<mathrick> it doesn't blow up when the trees have diverged
<mathrick> I guess
<jam> mathrick: well, you have another problem which is that you have no way of *detecting* that the branches have diverged
<jam> I'm trying to solve the ability to detect it first
<mathrick> ah
<jam> and then work on doing the detection at commit time
<jam> mathrick: wouldn't your cron job alert you that the branches have diverged?
<mathrick> jam: okay, so lemme know if you work out a simpler version (or decide it can't be done)
<jam> mathrick: as in, send you an email because it couldn't finish the 'pull'?
<mathrick> jam: yes, I began building status notification into it, but then during testing I discovered that the checkouts continue happily
<mathrick> so instead of just having a "lesse why it failed status page", I need something to make it fail to begin with
<jam> mathrick: well, if you always did 'push --overwrite' it would probably start to complain
<jam> then  the push would always succeed
<jam> but you would have to be careful to save the other branch's tip so you could merge it
<jam> maybe that is better
<mathrick> but --overwrite is destructive in the face of a conflict, no?
<jam> I think you are slightly misunderstanding conflicts versus the revision DAG
<mathrick> possibly
<jam> *committed* revisions cannot have conflicts, they just have a graph
<mathrick> yes
<jam> It is possible for 2 branches to be at different tips
<jam> so we refuse to allow you to 'push' so you don't lose one of the tips
<jam> mathrick: anyway, I think I've worked something out, give me a sec
<fullermd> You probably mean 'divergeance', not 'conflict'.
<mathrick> most probably
<jam> mathrick: http://rafb.net/p/0tvWF366.html
<jam> ^^- Use that as the cron script on fast host
<jam> It won't tell you on 'fasthost' when you are out of sync, but I can fix that.
<jam> mathrick: http://rafb.net/p/BziHfX38.html
<jam> Basically, when it sees the branches are out of sync, it swaps them
<jam> so that your checkout will complain
<jam> The only time it will succeed accidentally
<jam> is if you had the branches out of sync
<jam> and then you switch positions at the same time the cron script runs
<jam> oh, and I guess this will eternally swap the branches, so I guess there is a 50/50 chance of it swapping it back
<jam> You could stop that by remembering the last successful push/pull and stop if that hasn't changed.
<mathrick> jam: lemme look at it
<mathrick> jam: okay, so I take it that the latter paste replaces the former one?
<jam> mathrick: it is a different way to do it, but generally yes
<mathrick> ok
<mathrick> jam: so, what it does is that when I have my branch bound to, say, fast-tip, and the branches diverged, what I'd be actually acessing is the mainline, which will trip over my commit because it won't see what it expected?
<jam> mathrick: right
<mathrick> jam: and it doesn't actually matter which is where, as long as they are swapped when they diverge, and not otherwise, right?
<jam> mathrick: correct
<mathrick> I guess that swapping not diverged branches is a no-op anyway
<vila> hi all
<awilkins> james_w: I wrote that argument dumping code, it isn't too horrible
<vila> abentley: bb down it seems
<abentley> vila: restarted.  Try again in a minute.
<vila> abentley: thks
<beuno> vila, \o/
<vila> beuno: :)
<beuno> vila, kitchen fixed up?
<vila> I thought I will never come back, RL really sucked my free time
<vila> kitchen is "usable", not finished, but enough to get some free time back :)
<abentley> vila: kitchen beta
<vila> and we are very happy with the result with *is* the point ;-)
<vila> abentley: exactly, thanks :)
<vila> hopefully that didn't apply to food ;)
<beuno> vila, I'm glad. Good to see you back
<vila> beuno: just cooking a new selftest option and I get a shot at bzr-upload ;)
<beuno> vila, yay!
<mathrick> jam: uh, I got a bit lost trying to bolt on the halting code
<mathrick> jam: would recording the current (swapped) tip in case they diverged be a good idea?
<mathrick> hmm, no, you could still commit onto it I think
<mathrick> damn, I can't find any bit of state that could be persisted and also reliably recovered from only inspecting the branches in case of divergence
<mathrick> oh, the latest common parent
<mathrick> or whatever it is called in bzr parlance
 * mathrick hits the docs
<mathrick> uh-oh
<mathrick> http://starship.python.net/crew/mwh/bzrlibapi/ is down
<abentley> mathrick: Are you trying to determine whether branches have diverged?
<mathrick> abentley: no, I want to swap them once and only once per divergence
<mathrick> abentley: I don't know if you have read my original problem and what jam said about the solution
<abentley> I glanced over it.
<abentley> It didn't make much sense to me, so I went back to what I was doing.
<jam> mathrick: common ancestor is what we generally call it
<jam> branch.repository.get_graph(other_branch.repository).find_unique_lca(branch.last_revision(), other_branch.last_revision())
<moquist> is there a good way to change a checkout into just a branch, so commits are local?
<mathrick> moquist: bzr unbind
<moquist> mathrick: thanks...apparently I should really just read through the whole man page, shouldn't I? :\
<mathrick> probably :)
<abentley> also, "bzr reconfigure --tree"
<mathrick> moquist: bzr help checkouts explains it in detail
<moquist> abentley: right; I remember that being a very helpful read, though I apparently didn't catch/grok everything last time. I'll try again.
<moquist> thx, mathrick and abentley.
<ChristopheT> When doing a "bzr status" after a merge, is it possible to see the full log lines of the merged repository?
<ubotu> New bug: #221139 in bzr-svn "bzr-svn won't remember the password." [Undecided,New] https://launchpad.net/bugs/221139
<abentley> ChristopheT: Not directly.  You could always commit and then run log.
<fullermd> I've thought from time to time that `status --show-ids` should show the revids of pending merge revs..
<mathrick> jam: awesome, it works
<mathrick> jam: and bzr up + bzr resolve do what I mean
<mathrick> which is sweet
<mathrick> well, with the exception of spurious conflicts like: Conflict adding file file.txt.BASE.  Moved existing file to file.txt.BASE.moved.
<mathrick> but I can live with it
<korpios> Is there a straightforward way to "collapse" several revisions into a single revision?  e.g., say I just committed revs 33-39, and I'd like to change the repository so that all those changes are only in a single revision 33
<jam> korpios: 2 ways to do it, but the common one is "bzr uncommit -r 33; bzr commit -m 'new 333'"
<abentley> (actually, uncommit -r 32)
<jam> abentley: right, uncommit jumps you *to* that revision
<jam> (it used to uncommit that revision)
<korpios> so uncommit doesn't touch the WC, it only alters the repository?
<jam> korpios: it leaves the working tree unchanged, just changes the branch pointer
<jam> (it doesn't remove revisions from the repository either, they just won't propagate out if they aren't referenced)
<korpios> will a recommit then pick up on moves that happened in the revisions you just jumped back from?
<jam> korpios: yes
<korpios> ah, nice
<jam> It also remembers merges you did, etc
<korpios> that makes me happy ^_^
<jam> It is *supposed* to be like you did all the work, and just didn't "bzr commit", if you find discrepancies, let us know
<jam> I don't know of any, off hand
<jam> oh, except if you repeatedly merge the same branch, it doesn't prune the ancestry
<jam> not sure if that is a big issue
<korpios> as long as it's sane enough to work with, that's the key :)
<mtaylor> hey guys - any sensible way to get a list of all files under bzr control? like bzr status, except I want to also see unchanged files, and I don't care about status?
<beuno> mtaylor, inventory gives you all the files that are versioned
<mtaylor> beuno: thanks. duh
<beuno> :)
<mtaylor> beuno: how come inventory doesn't show up in bzr help commands ?
<beuno> mtaylor, I don't think it's used very often
 * mtaylor grimaces
<jam> bbiab
<lifeless> moin
<beuno> mornin lifeless'   how are you feeling today?
<abentley> mtaylor: any functionality that is unique to "inventory" should be added to "ls".
<mtaylor> ahhhh
<beuno> abentley, so inventory is being deprecated in favour of ls?
<abentley> beuno: inventory's a hidden command.  That's as deprecated as commands get.
<beuno> abentley, ah, I had no idea  :)
<mtaylor> abentley: bzr ls makes me happy
 * beuno updates his mental DB
<mtaylor> bzr: ERROR: pycurl.error: (60, 'SSL certificate problem, verify that the CA cert is OK. Details:\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed')
<mtaylor> is there a way to tell bzr that self-signed "invalid" ssl certs on https repositories are ok?
<abentley> You can use urllib+https: to bypass cert checking.
<mtaylor> abentley: cool. know of any plans to maybe catch that exception and ask a question?
<mtaylor> abentley: I know another friend of mine was having this problem branching from a https svn repos with a self-signed-cert the other day
<abentley> mtaylor: Not as far as I know.
<mtaylor> ok
 * mtaylor supposes that means it's time for loud complaining! :)
<abentley> You're unlikely to actually get a solution that requires user interaction.
<mtaylor> abentley: bzr: ERROR: Unsupported protocol for url "urllib+https://code.launchpad.net/~sward-dev/bzr-difftools/trunk"
<thebolt> i'm also having that very same problem right now ;)
<thebolt> and svn+https://YYY gives "Not a branch: YYY"
<mtaylor> so, that url works for me on my linux box, (https://code.launchpad.net/~sward-dev/bzr-difftools/trunk - withouth urllib)
<mtaylor> but does not work for one of our devs on a windows box
<abentley> Sorry, should be "https+urllib", not the reverse.
<mtaylor> perhaps there is a python lib he's missing?
<thebolt> i'm also using windows btw..
<mtaylor> abentley: https+urllib worked
<meuserj> I can't quite figure out how to do something with bzr:
<meuserj> I have a merge that I want to remove from the history... found later that it broke the program
<meuserj> I did "bzr revert 13..14"
<meuserj> and status reports that the merge is pending
<meuserj> errr... make that "bzr merge 13..14"
<abentley> You've got the numbers in the wrong order.  That applies the change again.
<meuserj> but the affected files haven't been reverted
<abentley> You want bzr merge -r 14..13 .
<meuserj> ah.. ok
<abentley> You should probably do revert --forget-merges, too.
<thebolt> hm, whenever i try to branch or checkout a subversion repository over https i get bzr: ERROR: Not a branch: "svn+https://crystal.svn.sourceforge.net/svnroot/crystal/CS".  (both bzr 1.4.x on linux and 1.3.1 on windows), any ideas why? same repository over http goes perfectly fine
<jelmer> thebolt: see the FAQ
<thebolt> jelmer: which of them? ;)
<jelmer> the 2nd
<thebolt> i think i have read them all (ie both bazaar and bzr-svn)
<jelmer> this is a self-signed ssl certificate?
<thebolt> no
<thebolt> (its sourceforge, the CA is equifax)
 * jelmer tries
<thebolt> hmm, seems even though firefox (&ie) trusts the CA, svn and bzr doesn't..
<jelmer> that'd certainly explain it
<thebolt> but then the error message isn't really descriptive ;) (and the guides you do find online for checking if the certificate is trusted doesn't include this case where some consider it trusted & other doesn't ;)
<jelmer> thebolt: see the answer in the faq.. this is a python-subversion bug
<thebolt> anyhow, while i'm at it, i've just (as you realize;) started to play around with bzr, at first to use it as a local vcs on top of our projects central svn repository, but possibly in the long term do a more total conversion
<thebolt> well, which faq? neither http://samba.org/~jelmer/bzr-svn/FAQ.html nor http://bazaar-vcs.org/FAQ (which are the only two faqs i find links to) lists that error
<thebolt> so my question would be if there's some described "best practices" when using bazaar on top of svn? something i definitly shouldn't do, and something tahts good? ;
<jelmer> the one in the source
<jelmer> basicaally the second one on http://samba.org/~jelmer/bzr-svn/FAQ.html
<thebolt> well, the repo doesn't require name+password
<jelmer> although the question now includes untrusted ssl certificates as well
<thebolt> not in the version i have.. but i guess thats related to me using the windows installer to get the plugin
<jelmer> it may only be in the 0.4 branch atm
<thebolt> heh ok, then don't be too mad at me for not reading it.. i did try to RTFM :)
<jelmer> there is no best practices document at the moment, but I'd be happy to review if anybody decides to write one :-)
<thebolt> heh ok
<thebolt> the guides i find use branch or checkout to mirror a single directory at a time (such as the trunk), is there a way (or any good reason not to) mirror an entire repository?
<jelmer> yes, "bzr svn-import"
<thebolt> but that does a conversion, doesn't it? ie not connected to the central repository?
<jelmer> not sure I understand what you mean
<jelmer> it does the same thing as "bzr branch" but for all branches in a svn repository
<jelmer> there's no way to do imports without connecting to a central svn repository
<thebolt> i mean the difference between branch and checkout.. but i guess i can do "bind" on them after svn-import to make them mirror-branches
<jelmer> thebolt: the difference between branch and checkout is the same as without bzr-svn involved
<thebolt> yea, i understand that
<thebolt> but i want the effect of checkout but for the entire repo (&with svn ;)
<thebolt> unless there is a good reason not to
<jelmer> so you want the entire repo as one bzr branch?
<thebolt> no, my goal would be to have a bzr "repo" with all the different branches from svn as different bzr branches, on which i could then continue to base my local (and later published) branches.. now if this sounds totally stupid say so.. (this is why i asked for a best-practices document ;)
<thebolt> part of my current work is basically merging of five different branches into one (and includes some fixing of stuff where they touch the same areas ;)
<jelmer> thebolt: yes, that's what "bzr svn-import" does basically
<thebolt> ok
<thebolt> thanks. .damn i'm not used to being such a newbie at the tools i (try) to use ;)
<igc> morning
#bzr 2008-04-24
<thebolt> ok, thanks for your help so far jelmer , suspect i might be back with more another day :)
<kiko-afk> hey hey
<kiko-afk> anyone have a moment to look at https://bugs.edge.launchpad.net/bzr/+bug/195217
<ubotu> Launchpad bug 195217 in bzr-lpreview "ReadOnly error when running bzr review-submit" [Undecided,Fix committed]
<jam> nigth all
<abentley> kiko-afk: What's to look at?  I've already submitted a fix and attached it as a patch.
<spiv> jam: good night
<mwhudson> and i've merged and pushed said patch
<abentley> mwhudson: So we can mark it fix released, then?
<mwhudson> abentley: i guess so
<spiv> abentley: bundle buggy is giving 'database is locked' errors for me
<abentley> Or are there actual releases of that plugin now?
<abentley> spiv: Apologies.  It's having trouble digesting your patch.
<spiv> abentley: ah
<abentley> Of course, it *shouldn't* be.
<spiv> abentley: I should have guessed that my patch-bombing had something to do with it :)
<mwhudson> abentley: i certainly haven't released it
<abentley> mwhudson: Well, the bug statuses are problematic this way.  If there's nothing left to do, we have to say it's at the end state, i.e. fix released.
<spiv> abentley: getting connection failed from bb now -- is that a good sign or a bad sign? :)
<abentley> Sign of desperation.
<abentley> The last time it tried to handle your message, it got hung up on a lock error.
<abentley> Which appears to be due to the visitor thread.
<abentley> Which shouldn't run if there are no visitors.
<spiv> Ah :)
<spiv> A good sign then (in the short term).
<abentley> Maybe.  There's all kinds of things wrong here.
<spiv> It seems odd that it would take so long to process my message.  It's just a patch (not a merge directive w/ bundle).
<abentley> Starting with my virtual server being so slow.
<abentley> Yes, I agree wholeheartedly.
<abentley> And there's also the issue that I can't reproduce these lock errors locally.
<abentley> Well, it took 5 minutes, but it managed to process one of your messages.
<spiv> abentley: hooray!
<abentley> spiv: We now return you to your regularly-scheduled bundle buggy
<spiv> abentley: thanks!
<abentley> btw, why did you send those as patches?
<spiv> Because they're in a great big branch, and I decided just slicing the final patch by file was a good way to break it up.
<AfC> spiv: what, exactly, did you use to do that? `bzr merge --overwrite .../path/to/other/branch ?
<abentley> Ah.  I was thinking you'd done it as a loom and were firing off per-branch diffs.
<spiv> abentley: I did, but I've already merged the other bits in the loom :)
<spiv> I wasn't aggressive enough about making threads, perhaps.
<spiv> AfC: Just "bzr diff -r submit: > everything.patch", then by hand broke it into pieces (pretty easy, given that I was just splitting by file rather than trying to edit hunks).
<AfC> by hand?
<AfC> Ah
 * AfC was harbouring the hope that effective cherry picking support had arrived.
<spiv> "vim everything.patch", and remove everything except e.g. message.py + client.py, save as a new patch, send to the list.
<spiv> And repeat until I've sent everything.
<spiv> I was going to try break it down into a series of logical steps from the commit history until I realised that with this code, the individual files are actually pretty independently reviewable.
<abentley> lifeless: around?
<lifeless> abentley: hi
<abentley> So I went to start adding the checks pack-1.5, so that it wouldn't accept a revision whose inventory SHA1 didn't match the actual inventory sha1.
<abentley> And it seems that it was already clobbering the inventory sha1.
<abentley> The one in the revision, I mean.
<lifeless> *blink*
<lifeless> I didn't think I merged anything to fix them up
<abentley> repository.py:551
<lifeless> and checking bzr.dev it still looks to be missing any fixup
<lifeless> abentley: ah yes, thats not the fetch code path :)
<lifeless> abentley: I think jelmer fixed this a couple of releases ago
<abentley> It's one of them.
<abentley> This should be the codepath used when serializers differ.
<abentley> And also for old bundles.
<lifeless> abentley: so this function looks correct to me: supply an inventory and revision, and the inventory is serialised and its sha put into the revison
<lifeless> supply just a revision and the revision is assumed to be fully populated
<abentley> Well, it looks like it does what you think we should be doing.
<lifeless> *IF* the plain to rich root fetch used this code path it would
<lifeless> however, if you look at fetch.py
<lifeless> Model1toKnit2Fetcher
<lifeless> and Inter1and2Helper
<lifeless> fetching does a regular join of all the file knits
<abentley> They use GenericRepoFetcher, which uses the Store directly?
<lifeless> then adds a empty text for the root directory for all revisions
<lifeless> then reserialises the inventories (via iter_rev_trees)
<lifeless> and finally bulk copies the revisions and signatures
<abentley> So the thing I didn't understand until now is that we were already mutating revisions all over the place.
<abentley> So you can easily have wrong SHA1s in a rich-root-repo, but you can also have right ones.
<lifeless> yup
<abentley> And when you create a bundle and send it to a friend, they may wind up with different SHA1s from you, even with the same inventory format.
<abentley> So it seems like the referential integrity I was trying to preserve is already hopelessly lost.
<mathrick> jam: sweet, I got it working, so now I have a status page with error reporting, and mostly reliably failing commits
<mathrick> jam: http://sei.meidokon.net/ for a success page, http://sei.meidokon.net/status-fail.html for a fail page (except that it was deliberately triggered for non-diverged trees, so the revisions on both sides are the same)
<mathrick> jam: I'm really happy now, thanks for your help :)
<beuno> Verterok, :)
<Verterok> beuno: Hi
<lifeless> abentley: I think we're both trying to preserve a form of referential integrity
<lifeless> abentley: but xml8 should make both of us happy
<abentley> xml8 would, but I'm not sure I see the point anymore.
<abentley> If we're already rewriting SHA1s all the time, why shouldn't reconcile do it?
<lifeless> well, I don't really like the idea of reconcile doing it
<lifeless> it just seemed expedient to have the ability to repair a repository
<abentley> But if we did address that issue, you'd feel good about making rich-root-pack the default, right?
<abentley> And since it's been supported since bzr 1.0, we could do that in the next release, right?
<lifeless> I think we have a convesion bug
<lifeless> but modulo that, yes
<spiv> Should we rename 'reconcile' to 'repair'?
<abentley> spiv: How about "refurbish"?
<lifeless> spiv: possibly; I was thinking sha1 changes would need an option anyhow
<spiv> abentley: renovate!
<spiv> "bzr renovation-rescue"
<abentley> Seriously, I'd prefer a term that connoted "maintenance" rather than "data recovery".
<abentley> lifeless: I wish I'd understood in London that we were already rewriting SHA1s.
<abentley> So much time and stomach lining wasted.
<lifeless> abentley: :(.
<lifeless> I clearly failed to communicate the knowledge I had effectively
<abentley> Or maybe I didn't listen clearly.
<abentley> Oh well.
<abentley> lifeless: What's the current state of stacking?
<lifeless> abentley: the prototype works on sftp only;
<lifeless> I'm rapidly closing in on the migrated versionedfiles logic
<lifeless> which enables making it work on bzr+ssh
<lifeless> by breaking the dependency on format-matching
<abentley> Do you plan to update the prototype?
<lifeless> oh yes
<lifeless> and polish it
<lifeless> its just an ordering thing
<abentley> The last version I have doesn't pass the test suite, and doesn't merge bzr.dev cleanly.
<abentley> I'll send you my test suite fixes at least.
<lifeless> please
<jml> spiv, abentley: how about 'bzr defrag'
<lifeless> yay, no more use of KnitVersionedFile.join() from within the knit internals
<lifeless> jml: that is 'pack'
<lifeless> jml: pack rearranges. reconcile cross-checks indices, graphs etc
<mwhudson> hey guys, i can reproduce https://bugs.edge.launchpad.net/bzr/+bug/217701 with bzr.dev at both ends
<ubotu> Launchpad bug 217701 in bzr "attempt to add line-delta in non-delta knit" [Critical,Fix committed]
<mwhudson> i thought the fix was in bzr.dev by now
<mwhudson> oh er, maybe not
<mwhudson> hm
 * igc lunch
<abentley> igc: Your vote on the send documentation wasn't captured by BB because you didn't reply to the right message.
<lifeless> spiv: ping
<lifeless> meh codeslinger is spamming a huge number of bugs with a fairly aggressive tone
<thumper> Odd_Bloke: I'd like a chat at some stage when you're around
<lamalex> What's the right way to fix files that bzr resolve put "<<<<<< tree" into?
<bob2> bzr resolve won't do that
<bob2> you run bzr resolve on the file once you remove those lines
<lamalex> so is it a hand prune situation?
<lifeless> yes, you get to choose which side you want to keep
<lifeless> or if you want to merge the sides
<lamalex> gotcha
<bob2> merge or pull produced conflicts (the command will tell you), then you edit the files to resolve it the way you want, either picking a side or combining them
<igc> thanks abentley
<lamalex> sorry for asking all of these questions, I've created a bundle, now what can I do with it if my project doesn't have an email associated with it
<lamalex> can I assign one?
<bob2> you can send that to whoever would review and potentially merge your changes - the project author or the developers list or wherever
<lamalex> A[A[A[Abzr: ERROR: No mail-to address specified.
<lamalex> sorry for the preceding garbage
<lamalex> how do I specify an email for the project?
<bob2> oh, right - you can use 'bzr bundle -o somefile.bundle' to get it into a file
<lamalex> ah ok
<Peng> You should use "bzr send -o foo.patch" instead of bundle now, I think. I dunno if there's a benefit... :P
<bob2> send takes a --mailto option
<lamalex> I should really rtfm
<bob2> hrm, me too it seems
<lamalex> hehe
<lifeless> poolie: mail sent
<lamalex> so that little hash is my patch?
<lamalex> maybe I didn't do bundle right
<lifeless> bob2: 'bundle' is not meant to be used these days
<lamalex> what do we use today?
<lifeless> bzr send
<bob2> send
<lamalex> just send? it takes care of everything?
<lamalex> including making the patch?
<lifeless> yes
<lifeless> you can give it various parameters
<lamalex> So I just want to submit a patch for 1 file foo
<bob2> lifeless: ah, right
<lifeless> lamalex: make the change, commit it, then run bzr send --mail-to=xxx
<lifeless> lamalex: (or instead of --mail-to, you can use -o- to get it on the console)
<lamalex> is there a way to say only make a patch for file X?
<lifeless> yes
<lamalex> do I just give it that file as an argument?
<lifeless> 'bzr diff -r -X FOO'
<lifeless> lamalex: but this discards your commit history
<lamalex> hm, it doesn't like -X
<lifeless> lamalex: well, the X should be a number for how far back in history to go
<lamalex> ahh
<lamalex> ok
<lifeless> ou can use the send logic by doing 'bzr send -r submit: FOO'
<lamalex> maybe I'll just do this the old fashioned way with GNU diff...
<lifeless> lamalex: perhaps you could tell me the whole use case, I feel like I'm playing catchup here
<lamalex> :) ok
<lamalex> So I fixed a bug, I need to make a patch, but it's not the only file that changed in the tree
<lifeless> did you commit the bugfix on its own?
<lamalex> well the other files that changed are IDE files that we keep in the tree
<lifeless> e.g. 'bzr commit -m 'fix bug' somefile.c'
<lamalex> oh snap I had no idea you could commit a single file
<lifeless> send can send a single commit
<lifeless> or if you have just made a single local commit, just a normal send will do the right thing
<lifeless> you can use 'bzr uncommit' to pop the most recent commit
<lamalex> yeah
<lifeless> this does not alter the files in your tree, it only changes a pointer to the history
<lamalex> I know that one
<lamalex> so I commited just that file
<lamalex> now I want to bzr send --mail-to ...
<lamalex> right?
<poolie> oh suddenly it's a lot louder
<lamalex> :P
<lamalex> sorry for waking the baby
<lamalex> (not calling you a baby, referring to an imaginary infant)
<lamalex> ahh ok, this calls your mail client to send an email. hmm
<lamalex> So how does a project do code review on this? It just looks like a hash and nothing else?
<lifeless> lamalex: by default it should have the diff
<lamalex> hrm
<lamalex> I wonder what I'm doing wrong
<lifeless> lamalex: what options did you give 'bzr send'?
<lamalex> --mail-to -o
<lamalex> with arguments
<lifeless> what arguments
<lamalex> what does it diff against? the version in the parent branch?
<lamalex> bzr send --mail-to gnome-do@googlegroups.com -o RenameTo.patch
<lifeless> it picks the least common ancestor to diff against
<lifeless> --mail-to and -o are exclusive options I thought
<lifeless> and by default (unless you have told bzr otherwise) it does that comparison against the parent branch
<lamalex> bzr didn't give me any erros for using both
<lifeless> indeed; we may have a bug there
<lamalex> and it's not giving me any diff
<lifeless> lamalex: so, lets do a quick diagnostic
<lifeless> lamalex: what does 'bzr missing' tell you
<lifeless> (just that, no options)
<lamalex> my last commit of just the 1 file
<lifeless> and it says you have that locally?
<lamalex> http://www.paste2.org/p/22706
<lamalex> anything look out of place?
<lifeless> lamalex: ok, thats good. Now lets check the commit
<lifeless> lamalex: 'bzr diff -r -2'
<lifeless> lamalex: does that show the expected diffs
<lamalex> it shows more than it should actually
<lifeless> lamalex: oh, do 'bzr diff -r -2..-1'
<lamalex> looks ok
<lifeless> ok
<lifeless> now 'bzr send -o-'
<lamalex> -o-?
<lamalex> like a little airplane?
<lifeless> :P
<lifeless> yes
<spiv> (holding your arms out and making "vrrrrm!" noises is optional)
<poolie> lifeless: thanks, nice draft
<poolie> you could send the whole thing with take 1 and take 2
<lifeless> :>
<lamalex> haha
<lifeless> lamalex: so did it look better?
<lamalex> no!
<lamalex> wtf
<lamalex> http://www.paste2.org/p/22707
<lifeless> lamalex: looks like during learning about send you have overriden its heuristics
<lifeless> lamalex: try
<lamalex> ha
<lifeless> 'bzr send http://bazaar.launchpad.net/~do-core/do/devel/ -o-'
<lamalex> no that's an A+
<lamalex> so now I want to do bzr send .... -o RenameTo.patch
<lifeless> if you add --remember it will remember that url for you
<lamalex> great
<lifeless> if you want to send it to the list, just replace -o- with --mail-to= ...
<AfC> Oh, while you're on the topic of bundles,
<AfC> I'm updating the HACKING instructions for the project I maintain,
<AfC> and I'm trying to formulate a better description of the SUBMIT_BRANCH and PUBLIC_BRANCH arguments
<AfC> ... I had been telling people to do
<AfC> $ bzr bundle ../mainline
<poolie> yeah that is a bit confusing
<poolie> needs better names
<AfC> which was working fine until one day I attempted to merge that bundle in a place that didn't _have_ a ../mainline
<poolie> afc, i think they should set submit_branch in locations.conf rather than typing it every time
<poolie> it can be remote
<AfC> poolie: so, it seems to remember it
<lifeless> AfC: their ../mainline should have a 'public_location' set
<AfC> poolie: or sorry, rather, something (not necessarily bundle) sets it
<lifeless> AfC: if it has that then the resulting bundle will reference http://.....
<AfC> lifeless: that's what I figured, Rob, so what I was going to change it to was
<dennda> Hi. I can't seem to get push to work to a remote server via ssh. Isn't 'bzr push bzr+ssh://user@server.tld/some/path correct?
<AfC> bzr bundle ../mainline bzr://research.operationaldynamics.com/bzr/java-gnome/mainline > /tmp/name-that-tune.patch
<lifeless> dennda: that looks fine
<dennda> hm
<AfC> lifeless: ... but I wasn't sure if that was actually correct
<lifeless> AfC: several things can be improved there
<AfC> (in terms of me not getting a branch not found error at the other side)
<lifeless> AfC: if you set the public location of ./mainline, then the user does not need to specify the full url
<dennda> lifeless: I get this:
<dennda> http://paste.pocoo.org/show/43412/
<lamalex> thanks a lot lifeless
<lamalex> see you guys
<dennda> (And yes, of course I got bzr installed)
<spiv> dennda: that's correct, but note that "some/path" is relative to the root of the filesystem (not your home dir)
<lifeless> AfC: if you use send, better data is chosen and sent. -o /tmp/name-that.patch will output to a named file
<dennda> spiv: yes, I know
<AfC> dennda: you know that /some/path is from system /, not some hypothetical DocRoot
<spiv> dennda: ah, it seems "bzr" isn't on your path on the remote system
<dennda> spiv: I need to install bzr remotely?
<bob2> dennda: to use bzr+ssh - alternatively you can use sftp://, which doesn't require bzr on the server
<lifeless> AfC: lastly, send will remember the submit branch, and by default uses the parent branch. so generally 'bzr branch; bzr commit; bzr send --mail-to=xxxx' is all that is needed for correct operation
<bob2> confusingly, sftp urls are relative to your homedir, iirc
<spiv> To use bzr+ssh, yes.  bzr+ssh works by running bzr on the remote end and sending commands to it.
<lifeless> bob2: they are not
<lifeless> bob2: the expired I-D on sftp urls had them homedir relative, but its expired, and the gnome folk, like bzr, thought that that was crack
<spiv> bob2: the difference you are thinking of is that our sftp URLs can have /~/ at the start of the path to make them relative to your homedir.
<lifeless> AfC: I hope that helps
<AfC> lifeless: investigating...
<AfC> lifeless: (ie, comparing the various permutations)
<AfC> lifeless: I supposed one assumption I should have stipulated is that the public URL isn't available (due to disconnected operation) at time of creating the bundle.
<spiv> dennda: as bob2 says, you can use sftp:// instead of bzr+ssh://, and it works quite well
<AfC> lifeless: else
<AfC> bzr bundle bzr://research.operationaldynamics.com/bzr/java-gnome/mainline
<AfC> alone would have done it
<lifeless> AfC: thats why setting public_url is useful
<lifeless> AfC: it just tells bzr the url to use when generating a reference to the branch
<AfC> lifeless: which the full form _does_ seem to do....
<AfC> (even remembers on first use)
<lifeless> most bzr commands that take optional urls remember them the first time they are supplied
<AfC> yeah
<lifeless> poolie: I think I'll just send take 2.
<AfC> (one of the nice things about what you guys do)
<bob2> spiv: ah, oops
<AfC> Anyway, that brings me back to thinking I should recommend the full form for first use.
<lifeless> AfC: I would recommend that ../mainline have a public url set. And that users specify ../mainline on first use.
<dennda> ah great, thanks lifeless, AfC, bob2 and spiv :)
<dennda> installing bzr remotely would've been an issue... (debian etch with bzr 0.11)
<AfC> lifeless: as in, me going to the server and hacking something into the branch.conf there?
<dennda> but sftp works
<lifeless> AfC: no
<lifeless> bzr help configuration
<AfC> dennda: installing bzr manually from source is quite trivial, so don't think there is a big barrier to getting current code.
<lifeless> look for public_branch
<bob2> lifeless: I-D?
<lifeless> bob2: Internet-Draft
<spiv> dennda: (fwiw, having bzr 0.11 is technically new enough to work with bzr+ssh://, but it's not really any better than using sftp://)
<AfC> AH that's what I was looking for the other day. Couldn't really sniff it out of the topic list.
<bob2> oh, right, that is cracktastic
<dennda> AfC: as long as there's sftp:// I'm happy
<dennda> no need to install it remotely
<AfC> lifeless: ... right, but `bzr bundle ../local bzr://public` sets/remembers/whatever public_branch
<AfC> lifeless: maybe we're violently agreeing with each other
<lifeless> AfC: we're not
<lifeless> AfC: I was saying that ../local needs *its* public branch set
<AfC> lifeless: right. But I cannot impose that on someone who has already cloned.
<lifeless> AfC: sure you can, its easy for them to do
<AfC> _them_? You expect me to tell newbies to hand edit some internal configuration file?
<lifeless> AfC: that said, the target branch shouldn't matter to you when you apply the bundle
<AfC> lifeless: ... it did {somehow, due to my ignorance, my not doing something right, or my being able to do the wrong thing in the fists place), which is why I raise the topic
<lifeless> AfC: if you expect them to have a local mainline mirror
<lifeless> AfC: well, if you can reproduce it, I'll happily assist debugging it for you, or at least explaining it if its not a bug
<AfC> lifeless: I imagine it'll happen each time I do a merge now, as I'm attempting to use checkouts and switch.
<AfC> lifeless: I'll keep an eye out and report back.
<lifeless> thanks
<AfC> As for the other side of the coin, you are recommending that I _not_ adjust branch.conf on the publicly hosted branch?
<lifeless> AfC: I don't think that setting it in the branch.conf of your public mainline would be a good idea.
<AfC> Really. Huh. Puzzling.
<AfC> I guess I'll go and see if I can figure out why not.
<lifeless> AfC: either it won't propogate, in which case its pointless, or it will propogate, and all your new branches would claim to be your mainline.
<AfC> Hm
<AfC> Well, I was aware of the former. The later is a bit of a surprise, but ok.
<AfC> Fair enough.
<poolie> 29 errors to go...
<lifeless> AfC: if it propogated, then each new branch would think that when its pushed, the regular url other folk should use would be your mainlines url.
<AfC> lifeless: yeah, I get it now
<AfC> lifeless: so is http://rafb.net/p/KxYMcB25.html wrong? [I realize you have better things to do be doing than reading stuff from me, sorry]
<poolie> afc, that looks useful
<poolie> i thought we were encouraging people to use send -o instead of bundle?
<lifeless> AfC: the bundle command is problematic
<lifeless> AfC: the 'public_url' parameter is the public url of the branch being submitted
<poolie> and i think that patch would be even better with a sentence or tw oabout what the urls are for
<lifeless> AfC: and in general you *don't have one*
<AfC> So we had a big fight about this 6-8 months ago. I was on the side of "bundle is good" for numerous reasons, but
<AfC> the one that remains a big factor for me is that I am really tired of people going to the trouble of sending emails with empty bundles in them
<lifeless> AfC: irrespective of command used. 'bzr bundle ../mainline' is fine.
<lifeless> 'bzr bundle ../mainline bzr://research.operationaldynamics.com/bzr/java-gnome/mainline' is wrong
<AfC> by forcing them to glance at the file they _really_ review the diff they are proposing, and it avoids the "you didn't actually specify what branch you're comparing to" problem
<lifeless> because the branch being submitted is *not* bzr://research.operationaldynamics.com/bzr/java-gnome/mainline
<lifeless> if you want to force them to look at it, try 'bzr send ../mainline -o /tmp/name-the-patch.patch'
<lifeless> personally, I use 'bzr diff -r submit:' to preview a submissiom
<AfC> Not to mention using stdout is goodâ¢
 * spiv uses "bzr cdiff -r submit: | less -R"
<lifeless> bzr send -o- does that
<AfC> Well, until you remove it from bzr, we'll keep using it.
<lifeless> I'm not really interested in a debate about send vs bundle right now. I have a patch to finish. Helping you debug your docs is something I'm happy to do.
<AfC> spiv: you're assuming that they have any clue what -r submit: is and why they should use it. That's a pretty advanced topic.
<AfC> lifeless: I'm just explaining why it is that we're using bundle, since you noted it.
<lifeless> AfC: fair enough
<spiv> AfC: I'm not suggesting that you recommend it, just mentioning what I use in case it's of interest.
<spiv> I'm willing to trust you know more about your community than I do :)
<AfC> It doesn't really strike me as the sort of thing to suggest to people when I'm busy trying to encourage them to tolerate my using Bazaar at all in the first place. The whole repository setup malarkey is bad enoug.
<poolie> afc, so if the core issue is that people should read their diff before sending it
<AfC> poolie: indeed
<poolie> that sounds like a pretty reasonable thing, and orthogonal to internal concerns about bundle vs send
<lifeless> poolie: I've sent the bug-activity mail off
<poolie> in the way i use send, i see the diff in the editor asking me for a description
<poolie> however i think this won't happen if you're using an external mail client
<lifeless> AfC: anyhow, my key point is that for someone that hasn't published their branch using the two-parameter form of bundle is *always* wrong
<lifeless> AfC: and specifying a different branch as teh public branch is also always wrong/
<poolie> well, depending on the client it may or may not be able to open or see files attached to your draft
<lifeless> AfC: it seems to be all your users will fail on both tests with the draft doco you pastebinned
<lifeless> AfC: which is why I am saying use one-parameter form
<AfC> poolie: judging by the fact that I got empty bundles, I'd have to say that's the case
<poolie> ok
<poolie> i would think we should not generate empty bundles without warning or forcing
<poolie> but, it is exactly that kind of case that i think robert and aaron are saying is problematic in bundle
<AfC> poolie: (it was send that was generating the empty merge requests)
<AfC> ï»¿lifeless: so, transposing what you're saying, I should revert to telling people to do `bzr bundle ../mainline` or whatever and do $something different when I merge to avoid the problem that _I_ have no ../mainline for it to refer to (assuming I can duplicate that scenario and that it is indeed a problem)
<lifeless> AfC: *and*, have them set the public url for their copy of mainline
<AfC> lifeless: Ok. One last question, then: how is that different than them inheriting public_branch from the internet hosted 'mainline' they branched from in the first place?
<AfC> lifeless: which you indicated would result in all branches thinking they were 'mainline' (a statement I find weighty though, I must admit, a bit strange given all branches are peers more or less)
<lifeless> AfC: because it doesn't propogate when set in ~/.bazaar/locations.conf
<Odd_Bloke> thumper: Sure.  I'm around now, if you still are.
<fullermd> Well, I'm pretty sure it doesn't propogate when set in branch.conf either.
<Odd_Bloke> (Morning all.)
<poolie> AfC: one useful way to move this forward if you get a chance might be:
<poolie> write the doc that you wish was in the manual
<poolie> describing the hypothetical command
<poolie> then we can work out how much of it is docs, how much is defaults, etc
<AfC> fullermd: really? I thought that branch.conf _did_ propagate.
<AfC> poolie: I'll see about heading in that direction, sure.
<poolie> spiv, lifeless: every assert deleted, yay
<poolie> quite a few were bogus
<lifeless> spiv: the versioned_files branch has the absent record type we discussed
<lifeless> night all
<spiv> lifeless: hooray
<spiv> poolie: I must admit the patches I sent this morning add a few, but that should be easy to correct
<spiv> poolie: (they also remove some, though)
<poolie> spiv: naughty, smart.py already has too many :)
<poolie> spiv, as penance you can read my diff :)
<poolie> night from me too
<poolie> well done on sending yours
<poolie> 5000-line diff sent, i'm done
<spiv> poolie: I wrote the offending asserts before your rfc :P
<spiv> Good night.
<poolie> it's ok
<poolie> night
<spiv> Ooh, long weekend.  I almost forgot. :)
<igc> night spiv, poolie
 * igc dinner
<spiv> igc: g'night
<mathrick> how can I revert a pending merge, and only the merge (ie. without reverting the local changes)?
<mathrick> ahh
<mathrick> it says that in the help page, never mind
<spiv> mathrick: :)
<awilkins> How do you test a class instance to see what type it is?
 * awilkins has found isinstance
<lifeless> assertIsInstance
<awilkins> Do you just pass the class name to the second argument?
<awilkins> (not as a string, as an identifier)
<mathrick> uhh, how do I get a revno out of rev id and a branch?
<mathrick> (I'd add that API docs are down again)
<james_w> awilkins: I believe so, yes
<james_w> mathrick: revid_to_revno_map, or something like that.
<mathrick> ah, I just found branch.revision_id_to_revno
<awilkins> james_w: Hmm ; i'm trying to write "added" support into bzr ls (mostly for fun), and I've so far settled on checking whether a thing is a TreeEntry or an InventoryEntry as a test ; but it's probably not the best test in the world.
<awilkins> The only other test I can think of is checking hasattr(entry, 'has_text') ; otherwise you'd have to extend the "Entry" hierarchy a bit
<james_w> what are you trying to achieve?
<awilkins> bzr ls --added     emitting a list of added files
<james_w> yes, but why are you trying to find if it is a TreeEntry or InventoryEntry?
<awilkins> james_w: Because the entry is an InventoryEntry if it's in the inventory, but a TreeEntry if it's just been added
<james_w> ah, that doesn't sound like the right way to get the information
<james_w> tree.changes_from(other_tree) is what I would reach for first.
<awilkins> james_w: That would make the implementation of bzr ls a lot more complex, which is why I suspect this hasn't been done already
<awilkins> The all comes out of me patching some hidden commands and submitting a merge for it...
<james_w> it looks to me as though cmd_ls could use a refactoting
<james_w> refactoring, sorry
<james_w> Having all the logic in the command class isn't desirable to start with
<awilkins> Some kind of tree iterator with filter chaining that yields the data?
<james_w> but finding all this information isn't actually that easy with bzrlib currently.
<james_w> that could be alright
<james_w> tree.changes_from should have what you need for ls,
<james_w> however there is an argument against having ls --added, as it is a state change thing, rather than a single state, and so is the domain of status.
<awilkins> Which brings me full circle - I patched the hidden "added" and "modified" commands to be more consistent with "unknowns"
<awilkins> Gah, I suppse patching "status" is actually what abentley recommended...
 * awilkins beats self
<awilkins> Is there a tertiary operator in python (  false ? truthing : falsething ) ?
<dato> awilkins: only in python 2.5
<dato> (x = 1 if foo else 2)
<awilkins> Ok, I'll avoid that then
<igc> dato: I was ill a few days this week so I never did get to look at that bzr-fast-export issue
<igc> dato: did you get a chance to look into it any more?
<dato> nop, sort of crazy busy here
<igc> dato: np - I'll take a look next week
<Mez> Is there any reason I need to specifically "upgrade" a branch to use tags? (and do I lose anythign in doing so?)
<igc> Mez: some early branch formats didn't support tags
<igc> unless you're using a special format (for bzr-svn say), should should'nt lose anything
<Mez> igc, I understand that, however, do I lose anything from upgradeing from dirstate to dirstate-tags
<igc> no
<igc> it should be fine
<Mez> Repository branch (format: dirstate or knit)  = what it's showing for the remote branch
<Mez> is that correct?
<igc> Mez: do you control the format of the remote branch?
<Mez> I hope so ;)
<Mez> it's a bound branch, shouldn't it be updated automatically?
<igc> Mez: good. In that case, you should seriously consider upgrading to pack-0.92 instead of dirstate-tags
<Mez> igc, why?
<igc> pack-0.92 performs better and is more space efficient
<igc> it's the current default
<igc> it supports tags as well
<Mez> hmm - I'm on 0.9.0
<Mez> hmm - I'm on 0.90.0 *
<igc> Mez: you'd need to upgrade bzr in that case as well :-)
<Mez> igc - indeed...
 * Mez waits for hardy
<igc> there's a 1.4rc2 currently out - 1.3.1 is the latest production release
<igc> Mez: 1.3.1 is in hardy to my knowledge
<Mez> 0.90.0 is in gutsy
<Mez> hmmles..
<Mez> how do I make the tags push to the bound branch?
<igc> Mez: not sure sorry. Did you try 'bzr push branch-url'?
<james_w> Mez: I think it will happen on your next commit
<Mez> ah, push works, but looks like a fail
<Mez> igc, if a local branch and a remote branch don't have the same format, they'll still work together?
<igc> Mez: I believe so
<Mez> igc, cool - I expected errors ;)
<igc> operations can be quicker though if the formats match because less conversion of data is required
<Mez> yeah, can undersand that
<Mez> I just expected it to throw an error, or upgrade the local branch or something
<Mez> gotta get my other devs to re-checkout the branch (or upgrade it)
<awilkins> Mez: Not all branches are compatible
<awilkins> Mez: particularly branches that use rich roots
<igc> night all
<beuno> sleep well igc   :)
<igc> thanks beuno - public holiday here tomorrow so I'll see you next week
<igc> and while I'm off topic - here's to hardy! The bird has now escaped it seems :-)
<beuno> heh, I've already got the ISOs on my servers
<beuno> I grabbed them before the server bashing started  :)
<abentley> spiv: Has this merge request http://bundlebuggy.aaronbentley.com/request/%3C20080220122210.GA29155@steerpike.home.puzzling.org%3E been superseded?
<spiv> abentley: no, in fact I meant to land it today
<abentley> Oh, I thought it might be part of your patchbombing.
<spiv> No, the patchbombing was just code.
<hno> A bit of panic here.. suddenly bzr says "bzr: ERROR: Unknown record type: '\r'" on pretty much any operation to the repository.
<Odd_Bloke> hno: Could you look in ~/.bzr.log for the relevant error message?
<hno> Odd_Bloke: Only a long python backtrace..
<Odd_Bloke> hno: Could you pastebin that backtrace somewhere, please?
<hno> http://www.squid-cache.org/~hno/bzr.log
<hno> the repository is at http://www.squid-cache.org/bzr/squid3/trunk
<hno> the log is from a "bzr update" of a local checkout using file:///bzr/squid3/trunk as source. But same error is seen if I try to make a fresh checkout remotely over http.
<Odd_Bloke> hno: What version of bzr are you using?
<hno> Server is Bazaar (bzr) 1.3. The remote client is 1.3.1rc1
<Odd_Bloke> hno: When in the process to you get the error?
<hno> Odd_Bloke: On checkout it sets up the .bzr directory and control files (including last-revision) but no sources..
<hno> Odd_Bloke: not sure if that answers your question. Not sure how to tell "when".
<Odd_Bloke> Yeah, I'm not really sure what I was looking for in an answer. :p
<Odd_Bloke> I'm not sure what's going on.
<hno> My local mirror repository seems unaffected..
 * Odd_Bloke is trying to reproduce.
<hno> but I don't have all branches..
<Odd_Bloke> I'll leave that running and BBIAB.
<hno> It's seen farily quick if using bzr co --lightweight.
<hno> Hmm.. some process has also gone very wrong and set last-revision of one of the branches equal to trunk...
<hno> Argh.. out of time. Have to go. If you figure something out please mail henrik@henriknordstrom.net. I'll continue looking at this later tonight.
<awilkins> Anyone else order a WiiFit?
<pekuja> nope, I've got mass to conserve
<korpios> awilkins: I've got a metal DDR pad :p
<korpios> (I wish I could play more ... moved into a 2nd floor apartment)
<ubotu> New bug: #221414 in bzr-gtk "gcommit: unknown error "float division"" [Undecided,New] https://launchpad.net/bugs/221414
<fbond> Is there a way to rename threads?
<NfNitLoop> threads?
<fbond> In looms...
<NfNitLoop> oh.  Sorry, over my head. : )
<fbond> NfNitLoop: no problem
<NfNitLoop> I was thinking a thread of execution.
<NfNitLoop> and was a bit confused.  )
<abentley> fbond: No, not really.
<abentley> You can create a new thread with the desired name.
<abentley> And then combine-thread the other one.
<fbond> So create-thread, up-thread, merge -r thread:foo, combine-thread?
<jam> fbond: just don't try to use 'bzr nick XXX' as it will break your loom :)
<fbond> fbond: Already tried that :)
<jam> (you can get back if you 'bzr nick OLD_NAME' though)
<fbond> jam: Didn't seem to totally break things.
<jam> maybe they fixed that
<jam> when I did it, it would crash on every operation at 'unlock()' time
<fbond> jam: Yeah, I think some operation I did following that fixed things.
<fbond> abentley: Or, rather, create-thread bar, merge -r thread:foo, combine-thread should do it?
<abentley> fbond: bzr switch OLD_NAME; bzr create-thread NEW_NAME; bzr down-thread; bzr combine-thread
<abentley> jam: Not fixed yet, AFAIK
<fbond> abentley: right, thanks
 * NfNitLoop reads up on looms.
<NfNitLoop> Hmm, that's cool.
<jam> abentley: doing a 'bzr up' seems to have the same "assume the nick is in the thread dictionary" so it sounds like you are right.
<jam> I'm curious what "bzr nick 'name of another thread'" would do
<awilkins> jelmer: I have a couple of merges languising in the bzr-gtk limbo, are you the list admin?
<jam> I suppose it would be similar to a switch, just without all the merging
<abentley> jam: Well, the main thing it would need to do would be to rename the thread entry.
<jam> abentley: I'm saying that right now 'bzr nick other_thread' will implicitly jump you to that thread and record your state there.
<jam> It probably *should* just rename the current thread, and fail if there is a name conflict.
<abentley> Agreed to both.
<trepca> hi
<ubotu> New bug: #221461 in bzr "'bzr push --quiet sftp://host.com' is too chatty" [Undecided,New] https://launchpad.net/bugs/221461
<ubotu> New bug: #221465 in bzr "'bzr push sftp://host.com' does not use authentication.conf password setting" [Undecided,New] https://launchpad.net/bugs/221465
<jelmer> awilkins: yes
<jelmer> awilkins: one sec, I'll see if I can find the password..
<Necoro> hmm ... is something like "bzr branch lp:portato lp:~necoro/portato/cache" supposed to work?
<Necoro> hmm ... it works somehow but is reeeeeeally slooow
<fullermd> I'd expect so.
<Necoro> I aborted it ... it hang showing nothing ;)
<fullermd> Well, transferring bunches of data twice is kinda slow   :p
<trepca> is shared repository meant for different branches of the same project or can it contain branches for different projects too ?
<abentley> The smart server in general is slow on Launchpad today, because it shares a resource with servers affected by Hardy traffic.
<abentley> The good news is that we've got a replacement good to go for our next release.
<Necoro> abentley: launchpad is generally not the fastest server ;)
<fullermd> Well, the SS doesn't support server-side branches like that anyway, does it?
<fullermd> So you're still stuck with copy-all-down, copy-all-up
<abentley> fullermd: No, it doesn't.  I mention ss because he said lp:foo
<abentley> trepca: It's fine to use it for different projects, but repositories do get slower the bigger they are.
<jam> abentley: yeah, lool on #bzrlp was mentioning that bzr+ssh:// bazaar.launchpad is really slow today
<jam> I know he was wondering why the resources weren't more separate
<jam> I was also guessing it was a Hardy-release-day thing, but couldn't answer why the smart host shares resources with a download server
 * awilkins downloaded Hardy via a torrent, it wasn't his fault
<elmo> jam: it doesn't
<elmo> LP is on a completely separate link
<elmo> if it uses the authserver on the otherhand..
<jam> elmo: well, that would effect the connect time, but I wouldn't expect it to effect every operation once connected
<elmo> jam: well the LP link had no bandwidth problems today due to the release, trust me
<jam> elmo: it seemed to be more CPU resources than bandwidth
<jam> unless it was horribly bandwidth constrained
<jam> (100s for 70KB)
<jam> .7KB/s
<elmo> err, well, yeah - the bzr LP server doesn't share CPU (modulo authserver contention with wiki.u.c) or bandwidth  resources in any way that would make it be affected by today's release
<jam> I guess we've had "super slow" days in the past
<jam> I've only seen "we know it is slow and are working on it" posts
<jam> Maybe the same thing struck again
<jam> (but stuff like X over 'bzr+ssh' being 250s and 20s over http)
<awilkins> jam: I found it much faster to branch a local project over file:// than bzr://
<awilkins> "local" means "across a LAN"
<jam> awilkins: for a *new* branch, 'http://' is faster than 'bzr+' at the moment
<jam> but it isn't 12x faster
<jam> (that, and I was testing 'bzr log', which I haven't really compared, but it still shouldn't be *that* different)
#bzr 2008-04-25
<abentley> elmo: It does use the authserver.  In fact, it uses it multiple times per session.
<abentley> jam: option a) is significant scope creep.
<abentley> Why do I have to rewrite your code the way you wish you'd written it?
<plexq> Is there any way to get bazaar to actually check the files in the directory to see if they are new rather than just assuming they are becuase their timestamp changed?
<plexq> or will bazaar only actually check in changes that are real?
<abentley> plexq: Bazaar doesn't use the timestamp to determine whether a file is changed.
<abentley> It uses a cached SHA1 sum.
<plexq> ah-ha
<plexq> I think it's the permissions
<plexq> windows is funky
<plexq> ok - a bzr diff says 'properties changed' how can I tell what properties so I can unchange them?
<fullermd> That would probably be the executable bit...
<awilkins> james_w: Ping?
<james_w> hi awilkins
<awilkins> james_w: I wrote that "spit the arguments in the stack trace" code we talked about on Wednesday, it wasn't too horrible
<james_w> awilkins: ah cool, can I see it?
<awilkins> Let me paste it somewhere....
<awilkins> http://pastebin.ca/996915
<james_w> thanks
<awilkins> I put this in trace.py, just above report_bug, and replace the std traceback.print_tb routine with it
<james_w> awilkins: cool, and that works for positional and keyword arguments?
<awilkins> Didn't test it ; I just trusted the API docs
<james_w> any way it could print locals as well, or is that info not available?
<james_w> heh :-)
<awilkins> james_w: Yes, it works by reading the locals dict, which contains the args first
<james_w> awilkins: ah yes, I see, do you think printing all locals would be useful, or too much?
<awilkins> So you would just change the [:co._co_argcount] to [:]
<awilkins> Some of those routines have a lot of locals
<james_w> often the thing you are interested in would be a argument somewhere in the stack, but in certain cases seeing everything might be useful.
<james_w> true, I think arguments would be a great first step.
<awilkins> Even just using the sample "assert" test spews a lot if you use all locals
<james_w> I'd love it if we could have this in the core, controlled by a -D flag probably
<awilkins> You might not want to make it default ; I was thinking about the D flag
<awilkins> Because I reckon it could be very nasty with large string values (but I don't know how many bzr chucks around internally)
<james_w> yeah, default would be too much I think, when a user gets a backtrace there scary enough as it is.
<awilkins> I suppose if bzr is well designed it doesn't throw around large strings
<james_w> I don't think it does.
<james_w> the other alternative would be an environment variable, but I think I prefer the -D option
<awilkins> Likewise
<james_w> cool
<awilkins> You might even want (say) an option for a regex/glob path to match the routines you wanted "arged"
<james_w> yep, or perhaps a number of frames from the bottom, often the lowest one or two are all you care about.
<thumper> is there a simple way to just run a subset of the tests?
<thumper> Odd_Bloke: ping
<james_w> hi thumper
<thumper> hi james_w
<james_w> bzr selftest <regex>
<thumper> james_w: thanks
<james_w> it matches on the test names, including the module names.
 * thumper nods
<thumper> I don't have to register new test classes anywhere do I?
<james_w> classes, no. modules, yes.
<james_w> tests/test_foo.py has to be listed as test_foo in tests/__init__.py
<thumper> hmm, I've added a class to tests/test_config.py
<thumper> however I can't seem to get it running the test
<james_w> using a regex?
<thumper> I tried with the class name first, and that didn't work
<thumper> and I assumed that adding a .* to both ends might help, but it didn't
<james_w> odd
<james_w> you're running with the right bzrlib?
 * thumper smacks forehead
 * thumper needed ./bzr rather than bzr
<james_w> heh
<TFKyle> hmm, bundlebuggy b0rked?
<Odd_Bloke> thumper: Pong!
<awilkins> The BB for bzr-gtk doesn't seem to be eating list mails, at least
 * awilkins is answering a question from a half-hour ago, RAin Man style....
<Odd_Bloke> The bzr BB seems to be b0rked as well.
<Odd_Bloke> abentley: ^
<thumper> Odd_Bloke: I was going to talk with you about PQM
<thumper> Odd_Bloke: but it's getting late here, and my laptop is about to lose battery power
<thumper> Odd_Bloke: perhaps we could talk next week some time
<thumper> oh, and I finally got around to writing tests from by alias command for bzr
<Odd_Bloke> thumper: Yeah, that'd be good.
<thumper> Odd_Bloke: when would be good?
<thumper> Odd_Bloke: can you talk in the evening?
<Odd_Bloke> thumper: Yeah, normally.  Bear in mind that I'm on UTC+1, so evening is somewhat subjective. :p
<thumper> Odd_Bloke: what time do you head to bed?
<Odd_Bloke> thumper: Around 11pm local time on average, though it often depends.
<thumper> Odd_Bloke: how about 9:30, or 10pm Sunday night your time?
<Odd_Bloke> thumper: Sunday nights don't work well for me, unfortunately.  Both Monday and Tuesday evenings work.
<thumper> ok, how about Monday night?
<Odd_Bloke> thumper: Sure.
<thumper> Odd_Bloke: ok, I'll ping before calling (to get your number among other things)
 * thumper heads to bed now
<thumper> nightall
<abentley> thumper: night
<Odd_Bloke> thumper: Night!
<abentley> Odd_Bloke: Up now.
<Odd_Bloke> abentley: Cool, thanks.
 * Peng suggests a kill-and-restart monitor daemon for BB.
<TFKyle> abentley: assuming you were talking about the bzr bb it still seems to be b0rked here: OperationalError: (OperationalError) database is locked u'INSERT INTO visit [...]
<abentley> Peng: I already implemented one.
<Peng> :)
<abentley> TFKyle: Should be working again.
<ubotu> New bug: #221890 in bzr-loom "export-loom should be able to ignore bottom thread (at least)" [Undecided,New] https://launchpad.net/bugs/221890
<mw> The link for the latest RC on http://bazaar-vcs.org/Download is incorrect
<mw> it says bzr-1.4rc2.1.tar.gz but the actual tarball is named bzr-1.4rc2.tar.gz
<jam> morning all
<dennda> How do I reverse my whole branch to revision 16?
<LeoNerd> bzr revert -r 16
<dennda> (And, after that has been done: If I commit again, will revisions 17, etc. be overwritten?)
<radix> dennda: no
<dennda> how does that work?
<radix> dennda: revert just modifies your working tree to look like a previous revision.
<radix> dennda: so if you commit, you'll just be adding a revision that looks like the old content
<radix> dennda: if you don't want those revisions at all, you can "bzr branch -r 16 oldbranch newbranch"
<dennda> ok no the standard behaviour is fine
<vila> hi all
<vila> beuno: ping
<abentley> awilkins, james_w: One of the ways Bazaar represents file contents is as large strings.
<james_w> ah, ok.
<awilkins> james_w: Could probably do with something that represents large strings as "This is a big {....}." then
<james_w> awilkins: yep, sounds like it
<awilkins> I use this thing called HuntErr31 for VB6 (blech) stack tracing
<james_w> you could str() everything, and then len() it.
<james_w> then truncate if it's more than some number of characters.
<awilkins> Much nicer in Python, you don't have to handwrite a stack trace into every routine :-)
<james_w> heh
<awilkins> A set of formatting classes might be nice
<awilkins> (but getting ahead of things)
<james_w> if you do this it wouldn't want to be hooked in to log_exception_quietly, or whatever it is called, as then you are going to be putting a performance penalty on things.
<james_w> if the info is wanted you can just ask for -Derror -Dwhatever, that should work.
<mtaylor> post_push hook: "and the rest should be self explanatory"
<mtaylor> where "the rest" == "old_revno, old_revid, new_revno, new_revid"
<mtaylor> if I've got 7 revisions to push, rev x1-x7, (before I push) and after I push they are revs y1-y7 - does old_revno == x1 or x7 ?
<mtaylor> ok. it seems those match up with 'last-revision'
<mtaylor> so the question is - if I want to send a post-push message that contains the diff representation of what I just pushed - what's the best way to find the revision from which the push started?
<mtaylor> I've got a broken recursive function walking back up the tree at this point
<emgent> heya
<james_w> hi emgent
<kevins> hello all...I have a merge/replay question
<kevins> I think I know the answer, but want to confirm. I have been following bzr development for years, but only now finally have a chance to use it on a serious project
<kevins> If I do development on a feature branch, and then merge into the mainline, the default behavior is for all my changes to get combined into one changeset (with details available in log --long)
<kevins> But if I really want all my individual commits to be reflected in the mainline, there is no simple way to do so
<kevins> I would have to rebase, replay, and then push...is that right?
<james_w> not sure what you mean by replay, but yes.
<james_w> push or pull as the last step works.
<jelmer> beuno: ping
<beuno> jelmer, ping (vila too)
<jelmer> beuno: any chance you can review http://bundlebuggy.vernstok.nl/bzr-gtk//request/%3C1207373163.31805.6.camel@ganieda.vernstok.nl%3E ?
<beuno> jelmer, sure, let me just hide from marianom for a minute  :p
<jelmer> marianom?
<beuno> jelmer, he's here working with me on something, but ignore that comment  :)
<james_w> hi jelmer, beuno
<james_w> beuno: you have a party tonight?
<beuno> hey james_w!
<beuno> james_w, we already had one last night
<beuno> should we have another one today?
<beuno> maybe we should...
<james_w> every night!
<james_w> how was it?
<beuno> jelmer, can I log into BB directly?  It still doesn't let me vote through email
<jelmer> beuno: yes, you should be able to login directly
<kevins> james_w: I think the rebase plugin has a replay command
<jelmer> beuno: I think I sent you the password by email during the sprint
<james_w> kevins: ah, I didn't know that.
<beuno> jelmer, let me try and find it
<kevins> if not that, then how else would I be able to do a push if someone else had made changes?
<beuno> james_w, did you folks have a party at Canonical?
<james_w> kevins: ah, that's what rebase is, it does the replay I thought.
<Daviey> beuno: There was one - and it was lots of fun!
<james_w> beuno: there was one, with some of ubuntu-uk as well, but I wasn't in London so I missed it. There were reports of people getting home at 9am this morning though.
<beuno> jelmer, found it, approved. It redirects me to localhost for some reason though...
<james_w> hi Daviey. Are you going to Swindon tomorrow by any chance?
<jelmer> beuno: yeah, I think I need to update
<beuno> james_w, 9am??   oh god...
<jelmer> beuno: It should be fixed
<jelmer> beuno: (update BB that is)
<Daviey> james_w: hmm - haven't requested a weekend leave pass from MrsDaviey - i should try :)
<james_w> Daviey: you can tell her you're staying over at mine, as long as she doesn't phone we'll be ok.
<Daviey> :)
<Daviey> i would love to!  I'll work on it
<jelmer> beuno: thanks, btw :-)
<beuno> jelmer, anytime  :)
 * beuno goes back to work
<kevins> I'm not sure how to suggest it, but my question is not covered in any docs/wiki/mailing list archive that I could find. It was a big surprise to me, so it would be great if it could be documented
<jelmer> kevins: what was your question exactly?
<kevins> jelmer: I was confirming that moving full history from a feature branch to a mainline is difficult, not automatic
<kevins> jelmer: the way I do code reviews on our project, that's going to be somewhat painful for me
<jelmer> kevins: What do you mean by "moving history" exactly? "bzr merge" will reconcile the histories of a feature branch and mainline
<kevins> jelmer: by "full history", I mean that I could look at mainline, and see each individual commit that was made on the feature branch, not just a single "merge" changeset
<kevins> jelmer: and not just commit logs, but the actual diffs, so I could do code reviews from the mainline itself
<jelmer> kevins: You can do that if you use merge
<jelmer> "bzr log" will show the merged revisions indented
<jelmer> and you can use "bzr diff -c" on the revision numbers listed there
<kevins> jelmer: ah, that isn't documented (that I could find)...so you are saying that each commit gets merged, and can be individually explored...I couldn't figure out what -c was for
<kevins> jelmer: Just tried it, and with bzr visualize, it looks like it does exactly what I want. Thanks! Would be great if the merge documentation were clearer about that.
<jelmer> kevins: please file a bug report or talk to igc when he is around (he does most of the work on the docs)
<vila> beuno: pong
<korpios> pung.  pang.  peng.
<beuno> vila, hey!
<vila> beuno: tests passing again in bzr-upload, man, at least run the test suite before committing :)
<vila> Were you able to install medusa ?
<beuno> vila, I was able _after_ I committed. Sorry about that  :(
<vila> beuno: Argh, re-reading log, it looks like I reverted your ""Moved reporting of what has been done to a default instead of verbose mode"
<beuno> I'll be good now  :)
<beuno> vila, no worries, I'll add that on later
<beuno> glad you're back
<vila> But since we have a verbose option I really think we should use it, you can define an alias to put it on
<vila> Thanks for your additions anyway, good to see changes and conflicts checked !
<beuno> vila, I initially had it as verbose, but, on the other hand, who *doesn't* want to know what was uploaded?
<beuno> seems to me like 95% of the time, you will want to know
<beuno> so I moved it to a default behavour
<vila> cron jobs, people trusting the plugin, **tests** -)
<vila> But since the outf modification broke nearly all the tests I need to re-think the way they are structured so I can run them with verbose=False and put verbose=True as default
<beuno> vila, then it seems like it's the inverse, you need a --quite  :)
<beuno> s/you/we
<vila> sure
<beuno> vila, yes, I realized my outf broke the tests. But now I can run the tests, so it should be easier not to piss you off  :)
<james_w> is this the plugin you were talking about in London for people who want to have websites in bzr and upload the working tree as well?
<vila> beuno: time to bzr update then, that was fixed a couple of hours ago :)
<beuno> james_w, yeap, it's pseudo-working  :)
<vila> and wether or not verbose is True, all outf statements should be under its control :)
<vila> james_w: yup
<beuno> vila, cool. I'll pull and look at the diff/logs
<james_w> awesome, thanks guys
<beuno> james_w, http://launchpad.net/bzr-upload   :)
<ubotu> New bug: #222161 in bzr "Documentation is unclear about merge history preservation" [Undecided,New] https://launchpad.net/bugs/222161
<vila> beuno: how far have you gone in your bzr-upload use ?
<beuno> vila, not far, I'm stuck on uploading individual files to integrate it into my system
<beuno> I have, however, used it for several personal sites
<beuno> and it's working fine
<vila> hmmm, you want to upload unversioned individual files ?
<beuno> vila, upload arbitrary versioned files  :)
<vila> I can't parse that... Either you use bzr-upload to keep your wt and your remote synchronized or you don't, as soon as you modify your remote... well you broke the sync
<vila> Or do you mean you want a --uncommited option ?
<beuno> vila, that's not it.  I mean, use bzr-upload to re-upload an arbitrary versioned file. For any reason possible. Or, if not possible, *exlude* some files from being uploaded
<vila> That will break the sync, what's the use case ?
<beuno> vila, well, here, since multiple people push stuff, many times, someone doesn't want to upload the other guy's changes, so he just uploads his changed files
<vila> 8-) verbose=False to the rescue !!!
<vila> seriously, the remote could really messy with no hope to ever be able to upload incrementally, you're got really high risks of having an incoherent remote site
<vila> s/could really/could really get/
<vila> s/you're/you've/
 * vila is back with his typos
 * vila 's hands suffer to rebuild the kitchen, be gentle ;-)
<beuno> vila, right, I agree from a purist point of view. I'm just explaining what my reality is: I can't fully use it if I force people to upload every file
<beuno> and I imagine I'm not alone  :)
<vila> That's not purity at all, that's just that it will not work :)
<vila> We use bzr to know what needs to be uploaded so bzr should be informed about what is uploaded or she can't tell us
<vila> and if bzr can't tell us, either we download the remote and compare it with local or we blindly upload the full wt
<vila> which you will find equally unacceptable
<vila> AIUI, *you* force them to merge which implies you force them to upload other guys changes
<vila> if you really want that do that, but if you don't, don't force them to merge and leave them handle the consequences: a remote mess :)
<vila> What we are trying to achieve is minimizing uploads, we use bzr for that, you can't find upload less and still be able to do it incrementally
<vila> s/find//
<beuno> vila, not even if we warn the user enough?
<vila> warning the user will not give us a way to avoid a full upload
<vila> why don't they want to upload the other's guy changes ? Time ? Cost ?
<vila> Not wanting to assume the other guy bugs ?
<vila> Honestly, I'm trying to solve the problem, if it means tons of code I'll tell you come back next century, but I will not say no
<james_w> heh :-)
<beuno> vila, assuming the other guys bugs  :)
<vila> There you go, do bzr-upload in a pre-commit hook :)
<vila> or don't force htem to merge before uploading
<beuno> vila, right, well, they _have_ to merge to be able to push to the main repo
<beuno> and, I probably don't want them to upload from their own repo, but from the main one
<beuno> but I suppose I can change parts of that, or work around it when they want to upload it partially
<vila> but you leave them push without uploading ?
<beuno> vila, yeap, many times
<beuno> I don't want every change to go online
<beuno> 3 people might work on a feature (or different ones) for a few weeks before uploading
<beuno> and, suddenly, one of them want to upload the feature they've been working on
<beuno> but not the others
<beuno> so, currently, they just upload the files they've been working on
<vila> fair enough, use feature branches
<beuno> yes, I've been avoiding adding a layer of complexity for the non-techie guys
<beuno> with this less-than-perfect option of uploading specific files
<vila> but how do they know what specific files they need to upload ?
<vila> they do that without bzr ?
<vila> me is scared for them
<vila> :)
 * vila is scared for them
<vila> scared damn it (put down that hammer will you)
<vila> bzr-upload is a mix of bzr export and bzr push
<vila> it's not really a push because we can't patch the remote files, we need to upload them completely
<beuno> vila, yes, it's scary  :)
<vila> but at least we know which files have been modified because we use the revid to identify the whole remote tree
<vila> if you upload one or severa; files behind our back, there is no more revid to represent the whole remote tree, we're doomed
<vila> but we can upload any revid, so I think the solution is to give them the right branches to work with
<beuno> vila, right. I guess a more advanced interface than they currently have might work around this
<beuno> (let them choose which one of *their* revids they want to upload(
<beuno> so, you can ignore that bug, and I'll add more work to my list  :)
<vila> I don't really think it's a workaround, you want to know the history of your remote site
<beuno> vila, yeap, gotcha
<vila> My advice would be to clearly define the overall workflow including the constraint that you want to track the work done *and* the remote history, I'm under the impression that you need to define some intermediate branches from where you push to the main repo and then you upload
<vila> That way code can be shared before upload without forcing any part on anyone too early
<beuno> vila, yeap, I'll look into changing bits of my workflow
<vila> Ok, keep me informed, I'll try to make full upload more robust anyway and then have a look at the chmod bits
<beuno> vila, will do. I'll need some basic logging out of the plugin to catch errors, and then I can implement on a wider scale
<beuno> (I'm thinking error-side errors mostly)
<vila> server-side ?
<beuno> vila, random web servers going down in the middle of an upload
<beuno> I currently report back to the user what was succesfully uploaded, and what wasn't (currently comparing md5, but I'm only using SSH)
<beuno> so the user knows they have to re-upload i
<beuno> *it
<beuno> which is another use case for the bug I filed
<beuno> 100 files to upload on revid X
<beuno> 99 get uploaded, and 1 fails for random reason
<beuno> you just re-upload 1 file
<beuno> not 100
<jelmer> beuno: thanks again for looking after those reviews
<beuno> jelmer, np, I should of done it a while back anyway  :)
<vila> Hmm, yes, ftp transport should handle more gracefully transient errors, that would help a lot
<beuno> vila, maybe resume b0rked upload may be an option to implement for the case I just proposed
<beuno> of course, that means a lot of more work
<beuno> because you have to keep the state of the upload somewhere, until it's succesfull
<vila> handling transient errors will address most of the failures, is needed anyway and yes, is easier
<vila> So let's do that first and see :)
<beuno> vila, alrighty
<vila> gee midnight already gone ! night all :)
<beuno> vila, sleep well!
 * beuno waves at mwh_ 
#bzr 2008-04-26
<emgent> heya
<mathrick> hallo
<mathrick> how easy is it to use bzr's testing infrastructure for code not strictly in bzr?
<mathrick> ie. my repo sync script, which already imports parts of bzrlib
<ubotu> New bug: #222540 in bzr-gtk "Add a tags page to the revision view" [Undecided,New] https://launchpad.net/bugs/222540
<vaasu>  q: i dont want a binary file to be under a revison control,(maintain its history), so, i put it under .bzrignore, but, now problem is, once this happens, when i push to a remote repo or clone, it does not get copied. any workarounds?
<vaasu> all i want is, not to maintain the history of the file, but copy the file on clone/push.
<Odd_Bloke> vaasu: bzr will only deal with files that are version controlled, so you'd have to find an external way of doing that.
<mathrick> vaasu: you can't have a file in repo and not have its history
<mathrick> it's internally inconsistent
<vaasu> but sometimes it is sensible isn't it? such as image files.. say maintaining a website
<mathrick> a repo is not a set of files, it's a set of tree states
<mathrick> vaasu: no, it's completely meaningless
<mathrick> ie. there's no interpretation of what you want it to do that would be sensible
<vaasu> how can i force a file not in revision control to propagate on push/branching?
<mathrick> vaasu: what contents should it have on clone/push?
<mathrick> vaasu: write a plugin that does what you want
<mathrick> but be aware that the requirements you gave are NOT consistent without further clarification
<mathrick> so you have to encode the precise meaning of what you want into the plugin
<mathrick> btw, wasn't there a way to drop binary delta into bzr?
<mathrick> so that it's efficient even for binary files?
<vaasu> mathrick: binary deltas will increase the size of repo to a large extent isn't it?
<mathrick> vaasu: no, why?
<mathrick> deltas are deltas
<mathrick> well, if the changes are huge, so will be the deltas
<mathrick> but that holds for any kind of change
<mathrick> a binary diff can deal with binary files however, in a way smarter than "uh-oh, this be binary sir"
<vaasu> > well, if the changes are huge, so will be the deltas, yes exactly, thats why i dont want to keep history..
<mathrick> vaasu: okay, so what you want is not to keep a file sans history in the repo, but to attach a file to the tree without putting it in the repo?
<mathrick> I guess that makes sense when specified this way
<vaasu> yes.
<mathrick> vaasu: write a plugin then, it's not so hard
<mathrick> docs are available from the site
<mathrick> jelmer: btw, could I get some guidance with bzr-rebase please?
<mathrick> specifically, I'd like to add patch reshaping (a'la git rebase's "merge" command)
<vaasu> any otherway than writing a plugin... i mean.. plugin is the last resort if i would go..
<mathrick> though maybe just merging would be enough for my purposes, can't decide
<vaasu> ?
<mathrick> vaasu: why is it the last resort?
<mathrick> it's neither hard nor non-sensible
<vaasu> i am afraid i may write something screwy....
<mathrick> it's _the_ way of extending bzr
<mathrick> vaasu: and without a plugin you wouldn't
<mathrick> ?
<vaasu> well i assume..
<mathrick> then you're wrong
<vaasu> hmm
<mathrick> a plugin is just a way to hook a piece of code into bzr automagically
<mathrick> it doesn't make the code any more or less correct than it'd be otherwise
<mathrick> it just makes it easier to get it right
<mathrick> vaasu: btw, you can prototype your code as a separate snippet
<mathrick> and make it into a plugin once you're reasonably certain it works
<jelmer> mathrick: pong
<mathrick> jelmer: hi, read my request?
<mathrick> how hard would it be to hack that in?
<jelmer> mathrick: not sure I understand what you mean exactly
<mathrick> jelmer: do you know how git rebase can reshape patches?
<jelmer> mathrick: you mean the interactive stuff?
<mathrick> jelmer: yeah
<jelmer> mathrick: I guess it shouldn't be too hard to do something like that
<jelmer> although it doesn't really require any code in the rebase plugin
<jelmer> I think I'd rather see a different plugin for that
<mathrick> mhm, it's just that's how git does that I guess
<mathrick> though OTOH reshaping the tree and reshaping the patches kinda go togeter
<jelmer> I wouldn't mind having an extra command in the rebase plugin for this
<jelmer> patches welcome :-)
<mathrick> jelmer: well, yes, but noticed the bit in which I ask for assistance? :)
<cr3> I just ran the following command and I seem to be missing a bunch of files compared to a svn co: bzr branch svn://svn.zope.org/repos/main/Zope3/trunk
<Odd_Bloke> cr3: What files are missing?
<cr3> Odd_Bloke: lots of directories under src/zope
<Odd_Bloke> cr3: I don't know how bzr-svn deals with externals...
<Odd_Bloke> jelmer: ^ ?
<cr3> Odd_Bloke: good point, src/zope/.svn/dir-prop-base lists a bunch of externals which don't happen to be downloaded
<cr3> Odd_Bloke: README.gz says: 'svn:externals'. Externals should be mapped to Bazaar 'by-reference' nested branches and the other way around. This can't be implemented...
<Odd_Bloke> cr3: Sounds like you're out of luck. jelmer would know more.
<cr3> hm, so I'm really not sure how to deal with an upstream svn project :(
<cr3> I'm thinking of doing some shell magic to grab all the dir-prop-base files and create new bzr branches for each external repo, then create symlinks to those each of those new projects
<cr3> or, store the whole svn co (include .svn directories) into my bzr project :)
<cr3> david allouche might have something for me, his svn2bzr seems to support svn repo to bzr conversion
<cr3> is python-paramiko needed for bzr+ssh or only sftp?
<LaserJock> is there anyway to conveniently merge subdirectories of two branches on a regular basis
<LaserJock> ?
<LaserJock> cr3: I thought bzr+ssh used sftp, but I could be wrong
<cr3> LaserJock: that would be strange considering the significant performance difference between using sftp and bzr+ssh
<LaserJock> I thought it was due to more efficient use, not particularly changing underlying protocols
<LaserJock> but I'm so not a bzr expert
<GuyFromHell> Is there a solution for bzr-svn not setting that $Id$ thing in files when checking out a repository with --lightweight?
<awilkins> GuyFromHell: No, no keyword expansion in bzr yet
<GuyFromHell> awilkins, k, i guess i'll just add it by hand then and trick it :P
#bzr 2008-04-27
<nekohayo> hey there, I need to rename a hundred files or so, is there any way to not do it one by one with bazaar?
<LeoNerd> for F in `find -name *.foo`; do bzr mv $F ${F/.foo/.bar}; done
<nekohayo> LeoNerd: so this replaces the ".foo" string to ".bar" ? what is the ${F  for?
<TFKyle> nekohayo: to reference the env var F (which is set to the current filename)
<TFKyle> 'course, technically that does do it one by one
<nekohayo> TFKyle: is there a way to do a "dry run" for this? to see what it would do without actually doing the changes
<LaserJock> you could do "echo" instead of "bzr mv"
<TFKyle> nekohayo: you could use echo "bzr mv $F ${F/.foo/.bar}" instead of just bzr mv,
<nekohayo> TFKyle: hm, it just prints "bzr mv" and nothing after in the term
<nekohayo> oh no wait :)
<nekohayo> TFKyle, it prints this: bzr mv find -name 20070216* find -name 20070216*
<nekohayo> the command was               for F in 'find -name 20070216*'; do echo "bzr mv $F ${F/20070216-/}"; done
<TFKyle> nekohayo: `, not '
<TFKyle> (for the find part)
<nekohayo> ok, I found out the syntax                  for F in `find . -name '20070216*'`; do echo "bzr mv $F ${F/20070216-/}"; done
<nekohayo> TFKyle: heh, when I make it echo the command it looks all fine to me (bzr mv ./20070216-gimp_ui-09.png ./gimp_ui-09.png) but when I run it, bzr says 404.
<nekohayo> somehow, doing the rename command by hand (exactly the same input as when done through the find loop thingy), it works
<nekohayo> ah, there needs to be no quotes near the end
<acemo> $ bzr serve --directory=/home/acemo/development/bzr/repo --allow-writes
<acemo>  is what am using to start my server.. from localhost i am able to do commits, but from other computer only able to update, unable to commit, getting these msges
<acemo> added design/classDiagram.jude
<acemo> bzr: ERROR: [Errno 13] Permission denied
<acemo> what could be the reason of this and how to fix it?
<spiv> acemo: when you say "from localhost", you mean via "bzr://localhost/" ?
<spiv> If so, I have no idea what's going on.  "bzr serve" doesn't care which host you're connecting from.
<acemo> spiv: yep bzr://localhost
<spiv> I guess you could do "bzr -Dhpss commit ..." from the host getting the error, to see which particular command is failing.
<spiv> (by looking in the ~/.bzr.log after it fails)
<acemo> where in windows would the log file get placed?
<spiv> "bzr version" will tell you
<acemo> neatos
<spiv> acemo: any luck?  Feel free to pastebin the relevant part of the log file.
<acemo> spiv: friend of me is at the remote comp.. n she cant find the log file..
<acemo> spiv: doh she was just looking for .txt
<spiv> Ah :)
<acemo> http://rafb.net/p/XpkL1K11.html
<acemo> thats the full bzr.log
 * spiv looks
<acemo> after doing bzr checkout bzr://hostname/branch.. u can just commit and it will commit to that branch right?
<spiv> Right.
<spiv> It's not failing on a network operation.
<spiv> It's failing trying to read a file in the working tree on disk, if I'm reading that traceback correctly.
<acemo> yeah i saw that too...
<spiv> Check the permissions/attributes on design/caseDiagram.jude, maybe?
<acemo> she just created and bzr add them on her comp..
<spiv> Right.  But it seems for some reason that bzr can't read it.
<spiv> So I'd expect e.g. "bzr diff design/caseDiagram.jude" to fail too.
<spiv> (And that operation doesn't need the network server)
<acemo> we found the problem..
<acemo> she still had jude open, jude locked the file while having it in use
<acemo> thanks alot!
<spiv> Ah!
<spiv> Glad I could help :)
<spiv> That error could be clearer, though.  It would have helped for it to say which file it couldn't read.
<acemo> was pretty clear tbh.. right after it prints out what file its processing it says it doesnt has permissions
<acemo> just i thought it was no permission on the server instead of local comp
<spiv> Right, it's clear if you already know where the problem is :)
<acemo> :p
<jelmer> Odd_Bloke, cr3: externals will hopefully be supported once nested tree support in bzr gets merged
<vila> abentley: ping, BB flooding my mailox with 'voting error' messages and may be restarting also...
<vila> One mail is emitted every 3 minutes, this metronomic precision making me suspect a restart ;-) I voted directly on site hoping to somehow solve the problem, but no luck...
<jelmer> mathrick: I'd be happy to answer questions wrt rebase
<jelmer> *internals
<cammoblammo> Is there an easy way (ie shell agnostic) way to specify directories or files which shouldn't be committed in a tree?
<Peng> .bzrignore?
<cammoblammo> Hmm, I hadn't thought of that. It might do the trick.
<Peng> Or, just list the stuff you want to commit?
<Peng> Hm, most hg commands have include/exclude options. Maybe bzr should support that.
<cammoblammo> I have a top level tree with several directories in it. One of those directories will be committed hourly via a cron, while the others will be committed as needed. Having to specify the directories to commit every time will be a pain.
<cammoblammo> .bzrignore might work, but I'll have to unignore it as part of the cron job.
<Peng> Huh.
<Peng> Note that you don't have to commit .bzrignore before changes to it will be used.
<Peng> You might be able to kludge something together using .bzrignore.
<Peng> hg-like exclude stuff would be better.
<Peng> Well, sort of.
<jelmer> Peng: afaik bzr's .bzrignore supports regexes which can do exclusion stuff
<jelmer> not that I've ever used it..
<Peng> Yeah, it does.
<cammoblammo> How does that work?
<Peng> Not that I've ever used it either..
<cammoblammo> The problem isn't the ignoring the directory, but the unignoring of it. Also, versioned files aren't ignored.
<Peng> Oh, right, they aren't ignored. I totally forgot that.
<cammoblammo> I'll kludge something together in the shell for now. If an exclude option is ever added, though, I'll definitely be a happy camper!
<Odd_Bloke> cammoblammo: Open a bug for it, if there isn't one already.
<Odd_Bloke> Else it'll get lost in the ether.
<cammoblammo> Will do.
<cammoblammo> Argh, sorry folks. I forgot to search for this bug before I submitted. Turns out several other people have asked for it too. Sorry devs...
<emgent> heya
<Odd_Bloke> emgent: Hi.
<dwt> Hey guys
<dwt> I'm using (trying to use) bzr-svn to push to a subversion repository
<dwt> when doing so I get this error:
<dwt> Setting property 'bzr:revision-id:v3-single-open-source/animated-grid' with invalid characters in name
<dwt> bzr: ERROR: libsvn._core.SubversionException: ('Mindestens eine Eigenschafts"anderung ist fehlgeschlagen; Projektarchiv nicht ge"andert', 175008)
<dwt> Which I think (reading the code) means that it barfs on the "/" in the property name.
<dwt> Well, thats where I'm a bit stuck...
<dwt> Can anyone help me get rid of this or debug this further?
<jelmer> dwt: What version of bzr-svn are you using?
<dwt> 0.4.8
<jelmer> there was a bug like that that was fixed in 0.4.9
<dwt> Ah cool, you're the developer. :-)
<dwt> Great work by the way. :)
<Odd_Bloke> cammoblammo: None of the other bugs are _quite_ the same request (as they are command-specific, rather than 'this should generally exist').
<dwt> Yeah I'm on 0.4.8 I just updated this morning to the latest released version - had that bug in the last version (0.4.8 too, but with a less expressive error message)
<jelmer> dwt: 0.4.9 is the latest released version and should no longer contain this bug
<jelmer> you may have to throw away your local state (~/.bazaar/subversion.conf) though
<dwt> Does it work with bzr. 1.3.1?
<dwt> I'm not quite ready to go to 1.4 yet...
<jelmer> yes, it works with 1.3
<dwt> oh dang.. sorry about that, but I am on 0.4.9
<dwt> So the bug is still present
<dwt>   svn                  /Users/dwt/.bazaar/plugins/svn [0.4.9]
<jelmer> you may have to throw away your local state (~/.bazaar/subversion.conf) though
<dwt> ok, I'l try that
<dwt> indeed that changes the output
<dwt> now I'm getting this : "bzr: ERROR: These branches have diverged.  Try using "merge" and then "push"." which ges me a bit, as I'm sure I didn't commit to these directories from anywhere else
<dwt> <g> and trying "bzr merge" then gives "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified."
 * dwt is off to the manual to find out how to get the correct merge base revision.
<ubotu> New bug: #223042 in bzr "Feature request: Exclude option for some commands" [Wishlist,Confirmed] https://launchpad.net/bugs/223042
<cammoblammo> Odd_Bloke: Phew!!
<jelmer> dwt: You may have to recreate your local branch :-(
<jelmer> dwt: this is part of the bugfix
<dwt> :-/
<dwt> jelmer: Is there a way to get the changes I did locally out of the bzr repo into the new branch?
<dwt> apart from using diff and patch directly?
<jelmer> dwt: the "replay" and "rebase" commands in the rebase plugin should be able to help you
<dwt> thanks I'l look into them
<dwt> jelmer: I'm a bit confused by the documentaton of the rebase plugin
<dwt> it seems it does the exact oposite of what I want
<jelmer> you should be able to create a new copy of the branch in svn
<dwt> [x] done
<jelmer> and then run "bzr replay" from there for each revision in your previous local branch that you would like to import
<dwt> ah...
<dwt> The important bit is not to try to use rebase. :-)
<dwt> Thanks a bunch, I'l see what I can get done this way.
<dwt> Yehaw. Thanks jelmer! Now I got the commit working to svn. :-)
<dwt> On to the next question: Is there a way to make bzr remember the pasword for the svn server? Preferably in the mac os x keychain... :-)
<jelmer> dwt: bzr-svn should already be using the os x keychain but unfortunately there are some bindings missing
<jelmer> (python-subversion doesn't contain bindings for the os x keychain yet)
<dwt> damn.
<dwt> Is that going to be included in 1.5?
<jelmer> doubt it - nobody has done the patch for that yet afaik
<jelmer> you can still use the trick described in the FAQ though
<dwt> whois jelmer
<dwt> ups, sorry
<jelmer> I'm jelmer (-:
<dwt> :-) Yeah, I wanted to get your correct lastname to give credit on my blog
<dwt> got it
<abentley> vila: My apologies for the spam.
<jelmer> dwt: ah, cool
<dwt> :-) You're welcome jelmer
<awmcclain> Hey all... what's the command to change the branch's remembered location?
<radix> awmcclain: pass --remember to push or pull
<vila> abentley: no worries, BB is a good friend. You recognize *real* good friends in that, at least once, they deceive you :-)
<abentley> vila: :-)
<epsy> hi
<epsy> i'm getting problems getting a repository to work properly
<beuno_> epsy, what problems are you having?
<epsy> whenever i try to co from it (bzr+ssh://) i get this:
<epsy> bash: line 1: bzr: command not found
<epsy> i had the same problem locally, because i had bzr installed in my home dir
<epsy> so i've put an alias in my ~/.bashrc
<beuno_> epsy, do you have bzr installed remotely?
<epsy> yes
<beuno_> bzr+ssh invokes bzr on the other end too
<epsy> when i just said locally, i meant locally on the server, heh
<beuno_> epsy, and how about locally?
<epsy> so i shall try with ssh:// alone?
<epsy> beuno_, on my computer?
<beuno_> it seems you are missing bzr on one of the ends  :)
<beuno_> epsy, yeap
<beuno_> try ssh://
<beuno_> or sftp even
<epsy> ssh:// --> unsupported
<beuno_> epsy, sftp
<epsy> oh, i'll have to install paramiko, this will take a little while
<beuno_> epsy, or use http, if you have access via http
<epsy> i don't want this repo to be accessible via http
<epsy> :)
<beuno_> brb, I don'nt know why I'm here twice  :p
<beuno_> epsy, try and ssh to the remote machine
<beuno_> and run:  bzr version
<beuno_> and make sure it runs correctly
<epsy> hm, cya? :)
<epsy> wb
<epsy> $ bzr version
<epsy> Bazaar (bzr) 1.3.1
<beuno> :)
<beuno> hrm
<epsy> [goes forth with more details]
<beuno> both locally and remotely?
<epsy> note that bzr is aliased
<epsy> on the remote machine i mean
<epsy>  $ grep "bzr" ~/.bashrc
<epsy> alias bzr="python2.4 ~/bin/bzr"
<beuno> epsy, well, I can't think of anything else then. If you bzr command works fine on both ends, you shouldn't be getting a command not found
<epsy> i am trying with ftp:// right now
<epsy> $ bzr co ftp://xclan@xclan.armagetron.co.uk/xclan.armagetron.co.uk/
<epsy> FTP xclan@xclan.armagetron.co.uk password:
<epsy> /  0/0
<epsy> looks like stuck
<beuno> epsy, might take a while if the repo is big
<epsy> 2 revisions yet
<epsy> :P
<epsy> beuno, is there a way i can tell my bzr client which bzr command to use on the other end?
<Verterok> epsy: BZR_REMOTE_PATH=~/bin/bzr
<beuno> hey Verterok  :)
<Verterok> beuno: hi :)
<epsy> hi and thank you very much :)
<Verterok> epsy: Hi, np ;)
<abentley> epsy: There is also a configuration variable: bzr_remote_path.  I think this is better to use, because it can be specified on a per-location basis.
<epsy> really?
<epsy> wow, neat
<abentley> Yep, see bzr help configure.
<epsy> okay
<abentley> bzr help configuration, I should say
<epsy> haha
<Verterok> abentley: Hi, and thanks for the tip (I wasn't aware of it) :)
<abentley> Verterok: Hi, and np.
<thumper> morning
<thumper> abentley: I see you had a prolific weekend
<abentley> thumper: Heh, still having my weekend.  Might get some moe fixes for fetch ready.
<epsy> the documentation on the authentication.conf file isn't very clear
<epsy> there's an example:
<epsy> [myprojects]
<epsy> scheme=ftp
<epsy> host=host.com
<epsy> user=joe
<epsy> password=secret
<epsy> what would i put intead of myprojects?
<frsk> wild guess; the path to your project
<epsy> local path?
<frsk> maybe
<frsk> I'm just gessing :)
<frsk> guessing
<epsy> blah it's still prompting me for a password, are there characters i need to excape?
<epsy> escape*
<igc> morning
#bzr 2009-04-20
<Peng_> mwhudson: Hi.
<mwhudson> Peng_: hi
<Peng_> (Actually, I'm totally not here right now.)
<mwhudson> i was going to ask something about loggerhead, but i forget wat
<Peng_> mwhudson: Anyway, w -- ah.
<mwhudson> i was probably just going to tell you to merge your branches, but i see they have merge proposals so i'll comment there i guess :)
<igc> morning all
<mwhudson> when i emerge from my pile of email
<mwhudson> hello igc
<Peng_> igc: Good morning. :)
<Peng_> Well, if you remember what it was, I should be back in maybe 30 minutes. Or maybe 1-2 years; I'm a bit tired. :D
<Peng_> If I do sleep for 2 years, please don't deprecate pack-0.92 while I'm gone. :D
<igc> so today's focus for me: nested-tree review; benchmark, tweak & announce https://launchpad.net/bzr-historycache
<levo> hey, anyone around to help a newbie? I'm having problems with getting rename to work.
<levo> I modified and moved some files, but bzr mv complains the destination dir. isn't versioned
<levo> or if I add the destination dir, it complains the source isn't versioned, but it's marked as removed in bzr status
<Peng_> levo: Did you rename the dir as well? Have you bzr added it?
<Peng_> levo: Hmm, not sure. But you may want "bzr mv --after".
<levo> that's what I'm using, I can't find any way to get it to work though :/
<Peng_> Oh.
<Peng_> My only other suggestion is that a newer version of bzr might be better, but I really don't know. Sorry.
 * Peng_ hopes someone else is here.
<Peng_> Pastebinning the list of commands you ran may help.
<levo> OK, thanks Peng, I'm not running the RC yet but I'll try that
<bob2> did you ad the destination dir?
<bob2> bzr add -N thatdir
<bob2> then mv --after
<levo> It says the target file is already versioned:
<levo> bzr: ERROR: Could not move string.h => string.h: reusable/string.h is already versioned
<Peng_> bob2: -N?
<bob2> then un-add it
<levo> to bzr add? it says no such option
<bob2> what?
<bob2> pastebin the output of 'bzr status'
<levo> bzr add -N says no such option, not sure if that's what you mean though
<bob2> pastebin the output of 'bzr status'
<levo> http://pastebin.com/d6c2d994b
<levo> I basically moved the directories 'test' and 'reusable' out of source up to the top level, sorry its kind of spammy
<bob2> yowch
<bob2> in future, use bzr mv
<bob2> that is easy to recover, you also added a bunch of other files
<levo> lol I'm hosed aren't I?
<bob2> no
<spiv> 1.14rc1 adds "bzr mv --auto" which would probably do a good job here.
<spiv> (After unadding the moved files, of course)
<bob2> mv reusable/threading/ ,,f ; for thing in resuable/* ; do bzr rm --keep $thing ; bzr mv --after rc/$thing $thing ; done ; mv ,,f reusable/threading
<bob2> or so
<lifeless> spiv: whatcya up to today?
 * bob2 wonders if he will ever shake ,,
<levo> trying to parse all that, I'm on windows :p
<bob2> yowch
<lifeless> bob2: {{}}
<spiv> lifeless: have finally upgraded to Jaunty, happily minimal fallout so far :)
<spiv> lifeless: am about to embark on lunch, but would love a review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090417141519.GA9721%40steerpike.home.puzzling.org%3E
<Peng_> Stupid question because I'm lazy: Can "merge --uncommitted" work over a remote branch?
<spiv> Peng_: off the top of my head, no, because we don't (yet?) support reading non-local working trees.
<Peng_> Yeah, I just tried it, and you're right.
<lifeless> PathNotChild: Path "/extra" is not a child of path "/extra/"
<lifeless> spiv: it smells a little off
<levo> thanks for the help everyone, I managed to get it all sorted out
<levo> kind of understand why it wasn't working automatically now
<levo> kind of a confusing diagnostic to say that the source isn't versioned, although I don't know what it should say instead since I don't understand exactly why it couldn't be moved in terms of the internal mechanics
<lifeless> I think there is a ui bug
<lifeless> but I'm glad you're up and running
<levo> thanks! and thanks for bzr, it's awesome
<lifeless> spiv: ping
<lifeless> spiv: How would you feel if we stopped PathNotChild occuring with foo, foo/
<spiv> lifeless: so long as there's no risk of foobar being accidentally allowed, I suppose it's ok.  I'm a little surprised it's not already accepted come to think of it.
<spiv> lifeless: I thought it did a bit of path normalisation before checking for PathNotChild?
<BasicPRO> blah, bad time for LP to sit down
<spm> BasicPRO: which part is sitting down?
<BasicPRO> code
<spm> wfm. can you give a url or similar?
<BasicPRO> http://bazaar.launchpad.net/~tanner/bzr/1.14rc2/files
<BasicPRO> click "NEWS"
<spm> interesting. readme gives an internal error as well. mwhudson ^^ <==
 * mwhudson looks
<mwhudson> spm: it's timing out for me, is that what you mean?
<BasicPRO> means I broke it? :-(
<spm> mwhudson: partially. the NEWS file times out. README gives an informative "Internal Server Error" - nothing else :-(
<mwhudson> i wonder if pygments is being insane, or annotate being slow
<spm> bouncy time? see if that helps?
<mwhudson> won't make a difference for the ISE
<spm> mwhudson: I live in hope that it would :-)
<mwhudson> um
<mwhudson> BasicOSX: i presume "bzr annotate README" works for you?
<BasicOSX> yes
<mwhudson> hm
<mwhudson> BasicOSX: bzr annotate http://bazaar.launchpad.net/~tanner/bzr/1.14rc2/README fails for me
<mwhudson> BasicOSX: i don't know what's going wrong, but i plead NMF :)
<BasicOSX> does that mean I did something wrong when I setup the branch?
<spiv> BasicOSX: it appears you've been hit by bug 354036
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] https://launchpad.net/bugs/354036
<BasicOSX> heh
<spiv> BasicOSX: did you use your 1.14rc2 branch to push it up? :)
<BasicOSX> bzr.dev
<spiv> Huh!
<spiv> That's a worry :(
<BasicOSX> Bazaar (bzr) 1.15dev  r4299
<BasicOSX> It would be initial push tho right?
<BasicOSX> Not the last one I just did?
<spiv> Right.
<BasicOSX> that was bzr.dev before patch
<spiv> As in, if any pushes had been done with unfixed bzr.dev...
<spiv> Ah, phew :)
<spiv> Ok that explains it then.  Deleting the branch (or at least deleting the remote .bzr dir) and repushing will fix the problem.
<spiv> (I'm not sure that this is the cause of viewing README triggering Internal Server Error, although it could be)
<lifeless> I don't think it is
<BasicOSX> PQM playing 1.14rc2
<lifeless> cool
<lifeless> I'm beat; had a fluvax shot yesterday and my arm has been killing me
<lifeless> if anyone needs me call my mobile
<BasicOSX> grrr, comcast I hate you
<mwhudson> spiv, lifeless: it is why viewing README triggers a 50x
<mwhudson> at least, the error i got on the command line was the same one i found in the logs
<spiv> mwhudson: which error?  I get a "No such file" on the command line.
<mwhudson> spiv: maybe BasicOSX has done stuff to the branch already
<mwhudson> it ended with
<mwhudson>     parent_lines = [parent_cache[parent] for parent in parent_map[key]]
<mwhudson> KeyError: ('README-20050309040720-8f368abf9f346b9d', 'abentley@panoramicfeedback.com-20070612162140-vea2zg1sbw6kckic')
<spiv> mwhudson: ah ok.  Yes, that does look possibly related.
<jelmer> moin
<jelmer> looks like all working tree stuff on git indexes is working
<jelmer> except for commits
* BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.14rc2 released 20 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<robin_dewd> cool. :-) I got your dulwich and bzr-git stuff from trunks I think and even updated bazaar to trunk as well (1.15dev) and was not able to make much with it at this point
<igc> me dinner
<jelmer> robin_dewd: what didn't work exactly?
<jelmer> there have been a lot of changes in the last few days
<robin_dewd> i tried a couple of things with it
<robin_dewd> one was to clone a git repository from github (I was excited alright ;-)
<robin_dewd> other was to branch from a local repo on a near directory
<jelmer> rockstar: if you can get it to blow up with the current version, please file bugs :-)
<jelmer> I can get it to work on most things right now, I fixed a couple of nasty issues
<bignose> how can I remove an un-wanted loom from a branch?
<Kinnison> Not sure, the help for "combine-thread" suggests that will, in the future, unloomify a branch
<lifeless> bignose: once it has only one thread its ~= to a branch; just export the thread and remove the loom
<lifeless> bignose: obviously this could be improved
<bignose> no hackery in the branch that can be done?
<lifeless> not trivially no
<lifeless> this would work:
<lifeless> bzr export-thread ../foo
<lifeless> rm -rf .bzr/branch
<lifeless> mv ../foo/.bzr/branch .bzr
<bignose> can I branch from a loomified branch, and specify that the new branch should *not* have a loom?
<lifeless> not currently, its a good idea; you can export the top thread though
<bignose> okay, that's the chosen workaround then.
<bignose> thanks.
<bignose> hmm wait, how do I export from one branch to another branch? exporting to a directory just exports a working tree.
<bignose> oh, export-thread
<bignose> an undocumented command :-(
<bignose> actually, a non-existent command (bzr-loom 1.4.0~bzr93-2)
<bignose> so, with no "branch without getting a loom" command, and with no "export-thread" command
<bignose> how can I get a branch from branch 'foo/' without a loom?
<lifeless> bignose: sorry, its just export-loom
<lifeless> export-thread has been discussed not done
<bignose> hmm. and if I have no threads, export-loom does nothing?
<bignose> attempting to create a thread in a loom that has no threads gives an AssertionError
<bignose> assert after_thread is None or after_thread in state.get_threads_dict()
<lifeless> uhm, having no threads == having no branch - you have no tips at all
<lifeless> I'm not sure how you'd even get to that state
<bignose> well, 'bzr show-loom' shows no threads, but 'bzr info', 'bzr check' and 'bzr status' all seem happy
<bignose> 'bzr log' shows revisions as expected
<jelmer> lifeless: so, it would be nice if it would be possible to support just record_iter_changes() or record_entry_contents() in CommitBuilder implementations
<jelmer> lifeless: does it sound sensible to e.g. add a "supports_record_iter_changes" and a "supports_record_entry" contents variable to CommitBuilder
<bignose> same when I branch; the new branch is also showing fine, but has no threads when I 'show-loom'
<jelmer> lifless: that influences the decision of Commit() as to what to use?
<bignose> so, I'm stuck on this branch; if the loom is broken, I don't know what else might break and I don't want to continue relying on this branch
<bignose> but apparently I can't remove the loom.
<lifeless> jelmer: I want to migrate to just ric
<lifeless> jelmer: multiple codepaths indefinitely is not attractive
<jelmer> lifeless: Ok
<jelmer> lifeless: I'd like a way to say I'd always like ric then :-)
<jelmer> lifeless: I already have that for bzr-git
<jelmer> and I don't feel like implementing record_entry_contents, too
<lifeless> jelmer: there is a comment in commit.py about this
<lifeless> jelmer: until its safe in all those cases we can't force it to ric always
<lifeless> it will be faster once we can, so its important to aim for that
<jelmer> lifeless: hmmok
<lifeless> jelmer: in particular you can't have a iter_changes on your trees that is actually both correct-for-status and correct-for-commit when new directories are added and specific files is selected
<lifeless> and iter_changes doesn't do excludes at all yet
<lifeless> so the fastest way to get ric used only, is to fix these issues in bzr core
<bignose> lifeless: okay, a workaround that worked:
<bignose> bzr init bzr/ && cd bzr/ && bzr pull ../foo/
<bignose> erm, s/init bzr/init bar/
<bignose> causes the new branch 'bzr/' to have no loom but have all the revisions from 'foo/' as desired
<bignose> argh
<bignose> new branch 'bar/' that is.
<bignose> damned muscle memory :-)
<jelmer> lifeless: hmm
 * bignose hopes all his wild assertions about Bazaar looms on the mailing list are actually true
<finiteset> how do I checkout an old revision from my project?
<lifeless> if you have a tree you're in, bzr revert -r X, or if you want a new tree, bzr branch -r X sourcebranch / bzr checkout -r X sourcebranch
<finiteset> I have a project using in bzr and I want to check  out an older revision of it  to a different location.
<mars> why does the shelve command offer the options "yes", "no", "finish", and "quit"?  Shouldn't that be "yes", "no", "all", "quit"?
<mars> ah, nevermind - finish means "done", doesn't it?  And quit actually means "abort"?
<ddaa> Hello,
<beuno> hi,
<ddaa> When trying to use bzr-hg, "bzr pull ../hg-branch" fail with a "AssertionError: KnitPackRepository('file:///home/david/Documents/Akamao/akamao.bzr/.bzr/repository/') not in write group"
<ddaa> raised from File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 660, in add_inventory
<ddaa> Any idea what that means, and how I can work around or fix this?
<ddaa> I have no idea what this "write group" concept is. Is this something new?
<ddaa> Mh... I guess I could try adding some repo.start_write_group() and repo.commit_write_group()...
<ddaa> Maybe add in a couple of chicken bones.
<ddaa> mh... it will probably be quicker to learn hg than to turn bzr-hg into something usable
<lifeless> ddaa: jelmer has a bzr-hg branch that is more advanced, I believe
<lifeless> ddaa: write groups are broadly transactions, they are the basis of packs
<ddaa> lifeless: hello mate
<lifeless> :) hi
<ddaa> yup, actually, just after asking I started remembering, and used grep powers to find out the relevant methods.
<ddaa> I patched the write-group thing, but now I have an error where the branch head revision cannot be found in the repo.
 * ddaa is using launchpad's trunk, is going to check whether jelmer has an active personal branch.
<lifeless> catch you later
<lifeless> <afk
<LeoNerd> How do I stop this fscking annoying popup window that says there's a new revision, every time I commit to a branch? It seems to have started recently, since a debian update...
<Kinnison> presumably you now have the bzr-gtk notification doobry running
<Kinnison> look for "bzr-notify" in your process list
<LeoNerd> Ahyes. There it is. Just kill it? Or will something start it up again?
 * ddaa is kinda puzzled at how mercurial requires one to edit the ~/.hgrc in a trivial way to enable bundled extensions.
<Kinnison> I imagine it'll start on desktop start
<Kinnison> see /etc/xdg/autostart
<Kinnison> there'll be bzr-notify.desktop in there
<Kinnison> not sure how you disable it short of rm -f the file
<LeoNerd> Ahyes
 * Kinnison just got used to it
<Kinnison> :-)
<LeoNerd> $ sudo mv bzr-notify.desktop bzr-notify.desktop.NOYOUFSCKINGDONT
<LeoNerd> Hrm.. shame I can't even  chmod -x  it
<awilkins> I saw an article that put forward the idea that .desktop files were the equivalent of Outlook worms for GNOME
<LeoNerd> It is annoying that there doesn't seem to be a local policy override thing
<Kinnison> No idea if removing it from the session applet would do the trick
<Kinnison> sorry
<Kamping_Kaiser> why dont you just remove the package?
<Kinnison> bzrk is too useful I imagine
<Kinnison> Unfortunately bzr-notify is part of bzr-gtk
<ddaa> awilkins: it's not nearly as bad it sounds. The problem basically is that the rest of the system assumes that not setting the execute permission on a file will prevent it from being executed accidentally, but .desktop files can be executed by nautilus regardless of the execute permission.
<Kamping_Kaiser> ah
<james_w> LeoNerd: cp /etc/xdg/autostart/bzr-notify.desktop ~/.local/share/applications/
<james_w> then edit ~/.local/share/applications/bzr-notify.desktop to have "NoDisplay=True"
<LeoNerd> Ya.. None of my files have +x on
<james_w> "NoDisplay=true" perhaps
<LeoNerd> james_w: Ahh.. Hrm.. Can I just set that value in /etc ?
<LeoNerd> (go go magic negative-options)
<james_w> yep
<moquist> Is it possible for me to edit my bzr log messages after commit?
<Kinnison> No[*]
<moquist> james_w: hey! I was just dusting my bzr bd skillz off the other day and thought of you.
<Kinnison> [*: Yes, but not really, erm, urp]
<moquist> Kinnison: possible but highly discouraged?
<ddaa> moquist: [*] you can get a similar effect using uncommit, and rebase if you want to change a commit message that is before other commits you do not want to change.
<igc> night all - see you next week after I return from leave
<ddaa> Of course, that will confuse merge/pull, etc for every branch out there that contains revisions that were changed/rebased.
<moquist> ddaa: Hmm. I have lots of messages that say (e.g.) "yeep" b/c I was just making tiny changes in my own repo...but now I want to publish this, and I figure the rest of the world won't find "yeep" very helpful.
<ddaa> moquist: was that understandable, our do you need spelled it out more?
<moquist> ddaa: maybe. I'll look into it first.
<moquist> I might just inflict yeeps on the world.
<ddaa> Here's how I would go about it:
<ddaa> 1. inflict "yeep" on the world
<moquist> ddaa: heh. Sounds good to me. :-D
<ddaa> 2. failing that, for every revision do something like "merge -r2..3 ../orig; commit -m 'nice message'"
<james_w> hey moquist
<ddaa> when specifying a range to merge, you actually do (essentially) a diff+patch, without referring to the merged revisions in the parents.
<ddaa> But it's going to be quite tedious if you have more than a half-dozen revisions.
<moquist> ddaa: yeah. not too many more, but maybe 10-15 messages to change.
 * Kinnison recommends option 1
<Kinnison> with addendum: "Learn not to yeep in future"
 * ddaa ruffles Kinnison.
<moquist> yeah...that's the real moral of the story.
<moquist> thx!
<Kinnison> There's some *really* crap commit messages in the world from me
<moquist> Kinnison: I pledge never to hold them against you.
<Kinnison> So kind :-)
<Keybuk> jelmer: so I installed bzr-git
<Keybuk> and it doesn't show up in bzr plugins
<Keybuk> and thumper said to ask you ;)
<jelmer> Keybuk: Did you install the package or from the bzr branch?
<jelmer> Keybuk: No warnings from bzr about it not being able to load the plugin ?
<Keybuk> jelmer: the bzr branch
<Keybuk> there is no package
<Keybuk> wing-commander scott% apt-cache search bzr-git
<Keybuk> wing-commander scott%
<jelmer> Keybuk: It's not in Ubuntu (yet), just experimental for now
<jelmer> The bzr branch is probably the best source for it for now anyway, given the rate of changes
<jelmer> Keybuk: So you have it in ~/.bazaar/plugins/git, are there any warnings about it not being able to load in ~/.bzr.log?
<Keybuk> it went into /usr/local/lib somewhere
<Keybuk> it doesn't work anyway - managed to get bzr to see it and it complained it needed 1.15
<jelmer> ah, yes, it unfortunately does at the moment; remote git servers are a bit limited in what they support
<jelmer> so I had to patch bzr, and that change won't land until 1.15
<Keybuk> ok
<Keybuk> oh well
 * Kinnison wows
<Kinnison> bzr managed to use my link fully just now
 * Kinnison gives it the 1MB/s prize
<jelmer> Kinnison: :-)
<Kinnison> hah, now it's lying, claiming 1.4MB/s which is faster than my link goes, while actually doing bugger all network traffic
 * Kinnison takes the prize back and gives bzr a wooden spoon
 * Kinnison pouts -- python-dulwich is too old in intrepid
<jelmer> Kinnison: Yeah, development has been going pretty quickly (un)fortunately
<jelmer> Kinnison: I suspect it'll have slowed down enough for Koala
<awilkins> Kinnison: Is is possible your 2MBit/s connection has just been upgraded to 10Mbit/s - your ISP is doing that. I only noticed when things went _pchow_.
<awilkins> 1.4 MB/s would fit 10Mbit/s
 * awilkins could also be mad
<Kinnison> awilkins: Erm, the only thing I'm waiting for is my 10Mbit/s service to be upgraded to 20Mbit/s
 * Kinnison is on business-grade cable
 * SamB_irssi attempts to push to SVN using bzr-svn ...
<SamB_irssi> jelmer: how do I specify what user to use for a specific SVN server ?
<joaopinto> hello, I am getting the "http does not support mkdir" that is usually related to the missing launchpad-login
<joaopinto> I need to commit some changes, and it's always trying to use the http method, how to I change it to bzr+ssh ?
<cody-somerville> joaopinto, does it say that when you commit?
<cody-somerville> joaopinto, ie. do you have a binded branch/checkout?
<joaopinto> cody-somerville, yes, it shows the http branch
<cody-somerville> joaopinto, just do bzr bind <bzr+ssh url>
<joaopinto> ah
<joaopinto> the bind operation does not report an error, but does not help either
<joaopinto> Cannot lock LockDir(http://bazaar.launchpad.net/%7Egetdeb-web-developers/getdeb-web/main/.bzr/branch/lock)
<SamB_irssi> jelmer: having to use "svn propdel" to get a username into the SVN auth cache isn't ideal!
<SamB_irssi> hmm.
<SamB_irssi> didn't even work?
<joaopinto> cody-somerville, ops, bind did help, tks
<cody-somerville> joaopinto, :)
<LarstiQ> SamB_irssi: *blink*
<stephank> I have a project I started working on in a bazaar tree. Now I'd like to reuse large parts of this application for another customer. I stripped down the application to remove functionality specific to my first customer, and now have a bazaar branch with a minimal functional version of the application. Now I'm about to branch that again so I can start work for the new customer.
<stephank> My question is, how do I do merges across these three branches?
<stephank> If I merge changes from the shared branch back into my original branch for customer 'A', I'd lose all the functionality because it take in the commits where I stripped everything down.
<stephank> Basically, I want to move to a /\ shape, but at the moment only have the bottom left node of that graph.
 * LarstiQ nods
<LarstiQ> stephank: I haven't tested it out to that level, but what you should be able to do is merge your stripped branch into A, and then reject all the changes.
<LarstiQ> stephank: basically by doing `bzr merge stripped; bzr revert; bzr ci -m 'Reject strippage'`
<LarstiQ> stephank: afaics that should from then on allow you to merge changes without having to deal with the huge diff of removed functionality each time.
<LarstiQ> stephank: I do something similar like this (but only two branches) for merging the Debian unstable packaging of bzr-svn into the Ubuntu bzr-svn ppa packages
<stephank> LarstiQ: Aha! I'll try that out immediatly. :)
<LarstiQ> (for which I don't want the Debian changelog entries that mess up the chronological order in the Ubuntu changelog)
<LarstiQ> besides some real packaging differences
<stephank> LarstiQ: hmm.. when I revert, it really reverts the merge as well, and the commit is not picking up any changes.
<ddaa> stephank: you MUST do "revert ."
<ddaa> the final dot is important
<ddaa> or "revert $PATH" if you prefer
<stephank> ddaa: Aha, ofcourse
<LarstiQ> stephank: sorry, what ddaa said
<LarstiQ> ddaa: I actually left the . off in my advice, mea culpa.
<stephank> LarstiQ: no problem, thanks for the excellent help, and ddaa, this did the trick. :)
<fbond> What's the word on merging ancestry with cherry-picks?
<jelmer> SamB_irssi: hi
<jelmer> SamB_irssi: still there?
<SamB_irssi> jelmer: again
<SamB_irssi> I am here again
<SamB_irssi> jelmer: it's an https URL on sf.net, if that makes any difference
<jelmer> SamB_irssi: hi
<jelmer> SamB_irssi: Did you see the thread on the bazaar mailing list?
<jelmer> SamB_irssi: basically, you need to use svn+https://
<SamB_irssi> jelmer: on a completely different subject, are you going to vote for http://bundlebuggy.aaronbentley.com/project/bzr/request/%3CE1LupWj-0005Cp-WD%40hydrogen%3E ?
<SamB_irssi> jelmer: I tried svn+https://
<SamB_irssi> it didn't seem to help me get a "username" prompt
<SamB_irssi> hmm.
<SamB_irssi> maybe my bzr.dev is too old?
<jelmer> SamB_irssi: which version of bzr are you running?
<jelmer> SamB_irssi: you'd need a fairly recent one
<jelmer> SamB_irssi: or bzr.foreign
<SamB_irssi> fwiw, svn+https:// failed in the same exact way, not in a different way -- it asked me for the password for "naesten"
 * SamB_irssi wonders if there is a way to make irssi warn you that you are scrolled up
<LarstiQ> SamB_irssi: if there is more text after you scrolled up it says - more -
<SamB_irssi> LarstiQ: where does that show up?
 * SamB_irssi waits for someone to say something so he can see where it shows up
<SamB_irssi> oh, there it is
<SamB_irssi> LarstiQ: is there some way to change that to a different color?
<LarstiQ> SamB_irssi: euh, I suppose
<SamB_irssi> jelmer: ah, with latest bzr.dev it works better
<LarstiQ> SamB_irssi: may I recommend the trackbar script to you?
<SamB_irssi> now it just looks horrible ;-)
<LarstiQ> SamB_irssi: it's white for me
<SamB_irssi> LarstiQ: yeah, it was white here too
<LarstiQ> SamB_irssi: I think I'm using whatever is default in Debian qua style
<SamB_irssi> (the "ugly" refers to bzr-svn's username prompt, btw)
<LarstiQ> ah :)
<SamB_irssi> jelmer: uh-oh ... it's asking me first for a username, then for a password ... but now it's asking me for a password for naesten again!
<LarstiQ> what a naesty behaviour!
<LarstiQ> ok, time for bed if my jokes are that bad
<LarstiQ> ciao
<SamB_irssi> that is, first it asks for a username and I say "sbronson" ... then it asks for a password for sbronson ... then it asks for a password for naesten!
 * SamB_irssi puts back the svn+
<SamB_irssi> arg, apparantly it found "naesten" cached???
<jelmer> SamB_irssi: can you reproduce this with the latest bzr.foreign and the latest bzr-svn?
<SamB_irssi> what's bzr.foreign ???
<jelmer> SamB_irssi: http://people.samba.org/bzr/jelmer/bzr/foreign
<SamB_irssi> that looks kind of like a dash to me ...
<SamB_irssi> oh, wait
<jelmer> contains a few pending patches for bzr.dev and a workaround for the fact that bzr.dev asks for passwords more often than necessary
<SamB_irssi> different url
 * SamB_irssi was looking at something from google with a desciptively similar sounding url
<SamB_irssi> s/descip/descep
<yacoob> is there any way to stop bzr from merging a file that has been deleted in destination branch?
<james_w> yacoob: no, but if you revert that path after merging then it will be remembered
<SamB_irssi> jelmer: okay, yes, I still have the problem
<SamB_irssi> but it might now just be a configuration/cache issue of some kind
<jelmer> SamB_irssi: so this is happening while you are pulling?
<SamB_irssi> jelmer: I don't believe so
<jelmer> SamB_irssi: so it's only while pushing?
<jelmer> SamB_irssi: and Bazaar is asking you for a username+password more than once?
<SamB_irssi> no credentials show up in ~/.bzr.log for pull
<SamB_irssi> oh, actually I don't get any prompts now ...
<SamB_irssi> sorry :-)
<SamB_irssi> or ... one password prompt
<SamB_irssi> for the wrong username, though
<SamB_irssi> and I can't figure out where it's getting the username/password from :-(
<jelmer> SamB_irssi: It should be getting it from ~/.subversion/auth if you tried to use svn itself on that URL before
<SamB_irssi> This is my bzr.log output:
<SamB_irssi> http://paste.lisp.org/display/78916
<SamB_irssi> but I don't see anything in ~/.subversion/auth ...
<jelmer> ah, bzr-svn wasn't prompting yet
<jelmer> SamB_irssi: I'm pushing a fix for bzr-svn
<SamB_irssi> jelmer: but I'm still puzzled as to where it came up with the "password"
<SamB_irssi> jelmer: but I'm still puzzled as to where it came up with the "password"
<SamB_irssi> EWIN
 * SamB_irssi meant to re-do a bzr pull ...
 * SamB_irssi wonders when/where jelmer is pushing it
<asabil> hi all
<asabil> is there a way to stop the Commit().commit() from using the progress bar ?
<james_w> asabil: programatically?
<asabil> james_w: yes
<james_w> I think you pass in a progress bar
<james_w> Dummy or Null or something
<asabil> james_w: not for commit ()
<james_w> ah
<james_w> that sounds like an omission
<jelmer> SamB_irssi: Just pushed it, to the 0.6 branch
<SamB_irssi> jelmer: I still seem to have the same problem :-(
<jelmer> SamB_irssi: It's not prompting you for a username?
<SamB_irssi> indeed
<SamB_irssi> but I also seem to need to pass --username to svn every time ...
<jelmer> SamB_irssi: so it looks like the username is cached in ~/.subversion/auth then
<SamB_irssi> I can't see it !
<jelmer> SamB_irssi: have you grepped for it?
<jelmer> it should be in one of the files in ~/.subversion/auth/svn.username/
<asabil> jelmer: can you take a look at this branch: https://code.launchpad.net/~asabil/bzr-rebase/filter-branch ?
<SamB_irssi> jelmer: I don't seem to *have* any files there
<jelmer> SamB_irssi: I'm not sure where it gets it from then, but if svn is assuming it knows the username then bzr-svn probably would too
<jelmer> asabil: sure, what about it?
<asabil> jelmer: what do you think about merging it into the rebase plugin ?
<asabil> and maybe rename bzr-rebase to bzr-rewrite ?
<asabil> with all the history manipulation related commands
<yacoob> james_w, doesn't quite work, still get conflicts on next merge.
<james_w> yacoob: you did a "revert; commit; merge"?
<james_w> and you get the same deleted conflict?
<SamB_irssi> jelmer: hmm.
<SamB_irssi> jelmer: would be nice if bzr-svn had a way to override that :-(
<yacoob> merge from branch a to branch b, revert addition of a file x, commit. Then made a change in file x in branch a. Merge from a to be gives a conflict.
 * SamB_irssi tries updating to a more recent subversion package
<jelmer> asabil: can you send me a merge request?
<asabil> jelmer: to your personal mail box ?
<jelmer> asabil: I'm at a conference at the moment, don't have a lot of time to look into it atm
<jelmer> asabil: yeah
<asabil> jelmer: I can also ask for a merge from launchpad
<jelmer> SamB_irssi: You can override it by specifying the username in the url
<SamB_irssi> hmm ... it looks like if I hit "enter" at the password prompt for "naesten", vanilla svn asks me for another username
<jelmer> asabil: Launchpad's merges don't include merge directives though unfortunately
<SamB_irssi> jelmer: that didn't seem to work
<asabil> jelmer:  okidoki, I will do then, thanks
<SamB_irssi> I think ..
<SamB_irssi> subversion doesn't seem to care if I put something before @ in the http url ?
<SamB_irssi> er. https ...
<yacoob> bug or feature?
<jelmer> SamB_irssi: bzr-svn does
<jelmer> yacoob: that's intentional
<jelmer> yacoob: as bzr doesn't know what to do with changes to a file that's removed
<jelmer> yacoob: it doesn't want to throw away those changes that have been made silently
<yacoob> so I'd have to deal with this on every subsequent merge...
<Peng_> Only if the file was modified.
<yacoob> well, yes.
<yacoob> no way to work around it, I presume?
 * SamB_irssi heads home ... hasn't failed yet with the username@ in the URL, but he's still not happy about having to use that :-(
 * SamB_irssi ... and it still might
<lifeless> yacoob: you only have to deal with it once for each change; if upstream stop changing it it will stop conflicting
<lifeless> yacoob: its arguably a bug to have subsequent changes generate conflicts again; could go either way - may be worth some discussion on the list
<yacoob> lifeless, I'm the upstream :) and I keep config files in bzr. Branch a is 'desktop', b - 'laptop'. Some of the stuff is not needed on the laptop, so it would be nice to say once 'no, I don't need this on the laptop'.
<lifeless> yacoob: righto; still the analogy holds
<lifeless> you'd like the delete to stay deleted
<lifeless> even on later changes to the file
<yacoob>  very much so. I'll open a bug about that. --flag for this would be okay I think.
<yacoob> https://bugs.launchpad.net/bzr/+bug/364336
<ubottu> Launchpad bug 364336 in bzr "bzr merge should allow user to ignore changes in deleted files" [Undecided,New]
<yacoob> ah :>
#bzr 2009-04-21
<SamB_irssi> jelmer: oh ... that doesn't seem to have helped. even with sbronson@ in the https:// url, it still finds "sbronson" as the user to authenticate as ...
<SamB_irssi> jelmer: also, apparantly subversion always defaults username to the user's account name?
<SamB_irssi> maybe you should allow multiple authentication attempts ...
<thunderbolt> I'm having a bit of difficulty doing a bzr get through sftp. I have a repository at example at come and use this command: bzr get sftp://user@example.com/path/to/repo. But I'm getting a EOF during negotiation error.
<thunderbolt> I'm on windows and have installed paramiko and pycrypto.
<thunderbolt> Would it be a bad idea just to download the repo from example.com using sftp? Could I still merge between them in that case?
<mwhudson> hmm
<thunderbolt> Hmm?
<kingos> lifeless: you there?
 * lifeless checks
<lifeless> yup, I seem to be
<kingos> lifeless: hi. Anything else you wanted me to do about that bzr check failing stuff?
<lifeless> oh uhm, what bug number was it
<kingos> 356028
<lifeless> bug 356028
<ubottu> Launchpad bug 356028 in bzr "bzr check fails with KeyError" [Undecided,New] https://launchpad.net/bugs/356028
<lifeless> kingos: no, sorry I had lost it from my queue; I've assigned it to me
<kingos> lifeless: thanks.
<mlh_> thunderbolt: example.com - really?
<thunderbolt> Yes. ;-)
<mlh_> test taht you can just do plain sftp
<mlh_> your own private example.com?
<thunderbolt> Thanks mlh_, I can plain sftp to it.
<thunderbolt> Yeah, it's actually a domain for my work, it's been changed to example.com to protect the guilty :)
<mlh_> me <-- not bzr expert but
<mlh_> you can rsync I believe or scp -pr it all and have it work
<thunderbolt> Cool!
<thunderbolt> Thanks mlh_.
<thunderbolt> Now the only problem is pushing it back, I guess I could make a patch/bundle.
 * thunderbolt was using bzr for deployment of some django onto a website.
<mlh_> perhaps try bzr+svn scheme instead of sftp
<mlh_> bzr+svn ?!?!?
<thunderbolt> bzr+svn? Do you mean bzr+sftp? I tried that with similar results :(
<mlh_> I mean bzr+ssh
<thunderbolt> Ah.
<thunderbolt> right.
 * thunderbolt had no luck with that, either :(
<jfroy> jelmer: I just got the weirdest error. I tried to branch a foreign Subversion branch on machine A (which doesn't have the branch). bzr errored out telling me the branch had no revision. Yet I pushed to that branch on machine B not one minute ago >.>
<mlh_> Oh dear.  I'll have to pass to 2nd level support then :-)
 * thunderbolt chuckles
<mlh_> using <your VCS here> for deployment is widely frowned upon
<mlh_> but everybody (including me) still does it
<thunderbolt> It is?
<thunderbolt> Why is it frowned upon?
<mlh_> I think you should have a make/scons/maven/... target dir then rsync that target dir to the deployed area
<mlh_> because things like .bzr don't belong on  a website
<mlh_> there's a chance of inadvertantly exposing too much info
<thunderbolt> mlh_: Ah, in my setup .bzr lives in a directory that isn't web accessable.
<mlh_> so you think :-)
<thunderbolt> It's along with all my Django config stuff (including database passwords)
<thunderbolt> So if .bzr is accessable, so is my database, so I'm screwed.
<lifeless> there is also a 'bzr upload' plugin
<lifeless> mlh_: ^ thunderbolt ^
<lifeless> which is expressly for web deployment
<thunderbolt> lifeless: Ah, cool!
<thunderbolt> Neat, kinda like rsync.
<sidnei> seems like my checkout got stuck :(
 * sidnei tries once more
<lifeless> jam: hi
<jam> hi lifeless
<jam> just made it into San Jose
<jam> I figured I might try to ping rockstar
<rockstar> jam, hi.
<rockstar> jam, are you in the hotel?
<jam> hey rockstar, how and where did you want to meet up tomorrow?
<jam> rockstar: yeah
<rockstar> jam, um, shall we meet down in the breakfast area for breakfast tomorrow, say, 9ish?
<jam> sounds good
<rockstar> jam, I'll probably want you to review my notes for the BoF tomorrow night.
<jam> certainly
<lifeless> jam: I'm analysing the index insertion issue
<jam> lifeless: you may want to check out lp:~jameinel/bzr/btree_with_bloom
<jam> (just pushed up after I got off the plane)
<jam> I haven't done any benchmarking, etc.
<lifeless> jam: thanks; I have one here :)
<lifeless> jam: I'll be letting you do the tuning I suspect. I just wanted to put some math around it.
<jam> lifeless: so I think branching *from* a repo with 500k nodes isn't terrible, because we make large requests (50k roots, 200k internal, 200k leaf)
<jam> and that code sorts the request, etc
<jam> the issue I was seeing was that *insert* was doing it one at a time
<lifeless> yes
<lifeless> its NlogN disk reads
<lifeless> which is better than N^2 but not that much
<lifeless> its superlinear and as its read-and-parse operations per key, it sucks
<lifeless> e.g.
<lifeless> 95% of time is 1.54M queries (this test data has some duplicates)
<lifeless> 3% of time is 1.49M insertions
<lifeless> 1.38% is the final read-and-serialise to the finished index.
<lifeless> jam: one thing I observed was that bloom probing rehashed
<lifeless> jam: we need to have a __contains__ that allows passing in the md5
<jam> lifeless: we *can*, but I might point you to BloomMurmur
<jam> which is about 5-10x faster
<lifeless> I'll leave that in your hands
<lifeless> my mail will be finished in < 10 minutes I think
<jam> so in my testing
<jam> ''.join() was 160ms
<jam> str in BloomMurmur
<jam> was 500ms
<jam> for ~ 100k keys
<jam> sorry 24k*20 = 500k keys
<jam> I was going to look at allowing tuples, so we don't have to do a string join
<jam> anyway, at that point, I wasn't sure if it was specifically worthwhile to cache
<jam> versus the complexity
<SamB_irssi> jam: but you could just put them in a dict!
 * SamB_irssi teases
<jam> SamB_irssi: :)
<lifeless> SamB_irssi: we're talking about the implementation of a dict on disk :)
<jam> right, the whole point here is to use a lightweight memory object that lets us drop the actual keys, etc to disk
<SamB_irssi> (yeah, my "suggestion" *was* intended as utter point-defeating  nonsense ;-)
<jam> rockstar: I was looking over the schedule, and it seems the first sessions start at 8:30, do you want to meet up a bit earlier?
 * rockstar looks at the schedule again.
<rockstar> jam, oh dear.  Yea, how 'bout 730 or so?
<jam> rockstar: sure
<jam> http://www.mysqlconf.com/mysql2009/public/schedule/grid
<jam> btw
<jam> ah, I was reading Monday it looks like 8:30 is keynotes
<jam> but still good to go to
<rockstar> jam, yea, I have that bookmarked.  For some reason, my brain skipped the keynotes.
<rockstar> jam, maybe we ought to skip out on some talks and go visit this: http://www.mysqlconf.com/mysql2009/public/schedule/detail/7791
<jam> rockstar: yeah, I think we will
<rockstar> jam, it seems to kinda go all day long.
<jam> yep
<rockstar> "a community organized event designed to share and improve the essential skills required to participate in collaborative, free and open online projects"
<SamB_irssi> "bug reporting", "grepping", and "patching"?
<lifeless> jam: mail sent
<mwhudson> Peng_: fwiw, i like the idea of a single LoggerheadConfig object being created in serve-branches and being passed around the various wsgi app instances
<mwhudson> (and i still haven't reviewed your branches properly)
<Peng_> mwhudson: Okay, cool. :)
<lifeless> mwhudson: is my search fix landed?
<mwhudson> lifeless: yes, i think so
<lifeless> good
<lifeless> now, to get it working on bzr-playground.gnome.org
<lifeless> also, that needs to start pulling git :(
<BasicOSX> What options do I need to pass to bzr init to test the latest branch format? And will LP support it?
<lifeless> BasicOSX: do you mean the development6-rich-root format?
<BasicOSX> lifeless:  yes
<BasicOSX> --development6-rich-root
<BasicOSX> is what I thought
<lifeless> -format=development6-rich-root
<lifeless> lp won't support it
<lifeless> and its a one-way migration, stuff you commit in there can't be moved to regular formats
<Peng_> LP won't support it? Why not?
<lifeless> Peng_: lp is running 1.13
<BasicOSX> won't support it "now" is probably what he means :-)
<lifeless> right
<Peng_> Oh. I misunderstood.
<lifeless> :)
<BasicOSX> Peng:  it's ok, I spent the whole day being misunderstood. Endless debate over Free (speech) and free (beer) and the GPLv1, GPLv2, and GPLV3
<lifeless> BasicOSX: at a conference?
<lifeless> and zomg gpl1?!?!?!
<BasicOSX> lifeless:  /blush in my  WoW guild :-P related to Curse/WoWI blocking WoWMatrix from  downloading Addon source code
<lifeless> heh
<lifeless> curse are very odd
<BasicOSX> waaay of topic here, but 3 of the addons I use are GPL and I stated that the GPL requires, if request, access to the source code
<lifeless> BasicOSX: #ubuntu-wow :P
<BasicOSX> to anyone, and those addons are only on curse, so in effect they are not compliant with with the GPL then religion kicked in and everything go ugly :-)
<lifeless> heh
<BasicOSX> endless rounds of emacs vs vi
<BasicOSX> windows vs linux
<BasicOSX> GPL vs BSD
<lifeless> so they don't have to allow anyone without the binary access, but blocking by client is arguably a violation yes
<BasicOSX> open source vs Free software vs commercial software
<Kamping_Kaiser> s/commercial/proprietary
<Peng_> Cue endless debate over *that*. :D
<Kamping_Kaiser> not really, commercial just means 'for money' :)
<jamesh> lifeless: if they distribute binaries without source, they need to provide source access to anyone on request.
<jamesh> if everyone who had access to the binaries also had access to the source at the same time, then they could deny requests from third parties
<jamesh> they wouldn't be required to support any particular method of source distribution, as long as they use "a medium customarily used for software interchange"
<lifeless> jamesh: its more subtle than that
<lifeless> jamesh: and not very interesting
<robin_dewd> I don't know when it started, but I have some branches that when I commit changes to them locally, they automatically want to commit to the remote (bzr+ssh) repository and this causes some delay for me when committing that I would rather not at times
<robin_dewd> how do I turn that off? ;-)
<bob2> bzr unbind
<robin_dewd> thanks
<jelmer> jfroy: hi
<jelmer> jfroy: this seems similar to the problem you were reporting earlier
<jfroy> jelmer: hey
<jfroy> I filed a bug to report it
<jfroy> jelmer: Ah I see, yes the 2 bugs may be duplicates.
<jfroy> Didn't catch my eye at fist because the exception and error message are different.
<Lambo_> hi folks
<Lambo_> is it possible to create a PHP comment block on top of a PHP file via Bazaar, with the whoami name + last commit?
<Mez> we seem to be having regular issues where we get "too many concurrent connections" - it's gotten to a point where one branch is unusable.
<Mez> is there any reason that this could happen on a regular basis
<bob2> Lambo_: bzr has nothing like cvs's $Id$, if that's what you're talking about
<Lambo_> bob2, i just want bzr to insert the last commit in each file
<bob2> Lambo_: nope
<Mez> this just doesnt seem to work. and it's getting extremely frustrating
<bob2> to lp?
<lifeless> Mez: didn't we debug this last week?
<lifeless> bob2: we have filters now that can do $id$ if people want
<Mez> lifeless: yes, we were, and we've just worked out the issue.
<Mez> Zen's "magic filtering"
<teknico> hi guys, stumbled into #354036 again
<teknico> I added the traceback to the ticket
<Mez> which doesn't like us using SSH, and kills the connection if we send across a certain control char
<lifeless> Mez: !!!
<Mez> lifeless: after changing the route on the box, it worked straight away
<Mez> lifeless: such a horrid issue :(
<lifeless> Mez: might be worth a faq entry on answers.launchpad.net/bzr for this
<Mez> lifeless: really? I think it's just our setup to be honest
<lifeless> Mez: well, up to you. Be nice if someone else runs into it to have an easy answer ;)
<lifeless> anyhow, ciao, /wave everyone
<Mez> "change ISP" isn't a valid answer
<asabil> hi all
<asabil> is it normal that bzr locks when using bzr send with gmail ?
<poolie> asabil: did someone answer?
<Peng_> poolie: Nope.
<Peng_> You didn't miss anything.
<poolie> asabil: no, it's not normal
<poolie> what happens if you hit Ctrl-C?
<asabil> poolie: nothing happens when I hit ctrl-C
<poolie> it's still hung?
<asabil> but later I get a error: (110, 'Connection timed out')
<poolie> like this? https://bugs.launchpad.net/bugs/364462
<ubottu> Ubuntu bug 364462 in bzr-email ""connection timed out" causes full stack trace to be dumped" [Undecided,New]
<asabil> the smtp server address seems correct to me: smtp.gmail.com
<asabil> poolie: well it is the same issue, but unrelated to the bzr-email plugin
<asabil> which I don't have installed
<poolie> right
<poolie> i've just commented that i think it's actually a core issue
<asabil> thanks
<poolie> asabil, i'd guess there was just some transient outage on your network causing it to be unreachable
<poolie> or indeed it's not impossible there was a glitch at google
<poolie> unless it's reproducible
<asabil> poolie: to me it seems like gmail only accepts smtp over ssl
<VSpike> Am I completely misunderstanding what bzr missing does?  I run it between two branches where one is massively ahead of another, and it says "Branches are up to date."
<awilkins> Anyone going to the Jaunty release party in London?
<VSpike> I'd expect it to show me committed revisions that are present in one branch but not the other
<awilkins> Arse, that's Thursday
<lifeless> VSpike: it should list both sides; are you running bzr mising other-url?
<poolie> VSpike:  that is what it's supposed to do
<lifeless> hi poolie
<lifeless> gnight all
<poolie> hi lifeless
<VSpike> Ah. Perhaps I see the problem. Both branches were bound to the same parent, but one had not had bzr update run
<VSpike> So bzr st showed a very old revisions
<VSpike> but doing the bzr missing seemed to do a bzr update at the same time, which sort of makes sense.
<SamB> VSpike: I don't see how that makes sense
<SamB> are you trying to call bzr missing with two arguments?
 * SamB doesn't have any idea what that would do
<VSpike> Nope.. I mean I was trying to compare two branches, so I cd'd into one and did "bzr st", then "bzr missing <Other>".  It said they were up to dat.e
<VSpike> So I cd'd into other and did "bzr log | head" and "bzr missing <First>" and it said up to date - yet the head revisions were totally different
<VSpike> sorry, in the above replace "bzr st" with "bzr log | head"
<VSpike> But when I cd'd back into <First>, and did "bzr log | head" again, it showed the same head.  And bzr info revealed they were both checkouts of the same branch, a third one.
<bialix> jelmer: ping
<SamB> VSpike: ah. checkouts! right.
<SamB> I forgot about heavyweight checkouts. I ran into some strange mergy issues with them ...
<SamB> ... and haven't used 'em since
<VSpike> I started using them because I'm terrible at remembering to commit, let alone push :)
<SamB> ah
<SamB> well, I'm more interested in not losing changes to unintended "merge"s
<SamB> maybe I should instead figure out how to reproduce the issue and report it ...
<SamB> jelmer: shouldn't the subvertpy docs be online ?
<SamB> jelmer: also, the "epydoc" target doesn't seem to work right in an unbuilt subvertpy source tree
<huf> hi. how do i set the parent branch?
<SamB> you can use pull --remember
<SamB> or you could edit the .bzr/branch/branch.conf file
<huf> can i use some short-names for other remote branches?
<LarstiQ> huf: with the bookmark plugin, bm:<name>
<LarstiQ> huf: next to the builtin :parent, :public, :submit etc
<SamB> LarstiQ: and where do you get it ?
<huf> where can i find docs on those builtins?
<huf> and what each is for, and when each is chosen as a default
<LarstiQ> SamB: without look at http://bazaar-vcs.org/BzrPlugins I'd guess lp:bzr-bookmark
<poolie> jam, hi?
<huf> cool, i think i got it
<huf> thanks
<SamB> LarstiQ: I don't suppose you can bookmark just a URL prefix?
<luks> you can
<luks> then you can use bm:foo/path/to/branch
<SamB> neato
<luks> where foo is e.g bzr+ssh://example.com/path/to/repo
<SamB> or it could be svn+https://dosemu.svn.sourceforge.net/svnroot/dosemu, no?
<luks> yes
<SamB> of course, I still haven't gotten authentication to work for me ...
<huf> what happened to the bzr versions? what came after 1.5?
<SamB> presumably 1.6?
<huf> oh, 14... i cant read.
<SamB> then .7, .8, .9, .10 ...
<huf> yes yes, i see now
 * SamB wishes the NFS at his school's cs department was faster ... 
 * SamB wonders why SVN doesn't check out files in alphabetical order
<awilkins> SamB: It does it in inode order
<awilkins> (SVN FS inode, not normal-world fs inode)
<SamB> awilkins: but the inodes don't exist yet
<SamB> oh
<SamB> some kind of progress indicator would be nice ...
<jelmer> SamB: yeah, the docs could be online, it's just too much effort to keep them up to date
<SamB> jelmer: buildbot? cron job?
<jelmer> SamB: No python on the machine that my homepage is on
<jelmer> SamB: It also seems like it's not too much effort for whoever is going to use subvertpy to build it
<Peng_> I dunno. I find building docs to be easy, but copying and pasting the URL into Firefox a pain. :D
<LarstiQ> SamB: I relatively frequently do things like `bzr missing :parent/../foo`
<Peng_> Hey, that works?
<Peng_> I totally didn't know that.
<SamB_irssi> jelmer: well, maybe you should at least debianize the docs ?
<SamB_irssi> because I don't currently build subvertpy myself on my own machine, and the one at school lacks all the doc-building tools ...
<SamB_irssi> (I also don't think I have room for the build-deps on my personal machine)
<jelmer> SamB_irssi: any chance you can file a wishlist bug?
<SamB_irssi> ah, sure
 * SamB_irssi wonders if there is something wrong with Debian's subversion ...
<jelmer> SamB_irssi: why is that?
<SamB_irssi> jelmer: is there an up-to-date ppa for subvertpy?
<jelmer> SamB_irssi: no
<SamB_irssi> jelmer: oh, well, it doesn't seem to cache my auth credentials for that repository I've been having so much trouble with ...
<jelmer> SamB_irssi: svn itself (not bzr involved) ?
<SamB_irssi> even with the options explicitly set
<SamB_irssi> yes, SVN
<SamB_irssi> though I admit I haven't actually done a commit
<SamB_irssi> just revision property manipulations
<jelmer> do you perhaps have subversion configured to not store password /
<jelmer> s?
<SamB_irssi> jelmer: not entirely, but I'm trying not to!
<SamB_irssi> and I can't see how to make subversion mumble aloud what it's doing ...
<LarstiQ> SamB: strace? ;)
<SamB_irssi> LarstiQ: strace doesn't tell me what configuration settings subversion has determined ...
<SamB_irssi> or what it's basing it's decisions on ...
<SamB_irssi> jelmer: oh, I guess you want me to file a debian bug huh ...
<jelmer> SamB_irssi: yeah
<SamB_irssi> almost filed it in launchpad ;-)
<SamB_irssi> jelmer: oh, did you catch that I still haven't managed to commit to sf.net via bzr-svn?
 * Kinnison yays as his answer to problem 67 on projecteuler.net is correct
<jfroy> jelmer: any thoughts on the branch problem? It
<jfroy> *It's kind of a bummer not being able to get that branch out of svn, especially since it started as a bzr branch :p
<ricardokirkner> hi. I want to use bzr for our project, but due to internal policies, we have to keep all our code inside a svn repo. In order to cope with that, I thought of using a post-commit hook, that would just push the changes to the svn repo. In that way, every time someone commits to our bzr main branch, it gets pushed to the central svn repo
<ricardokirkner> how can I do this? (what is the best way to achieve this?)
<ricardokirkner> from my research I see I can write hooks for branches, but not for the whole repo...  (i am using a shared repo)
<pygi> ricardokirkner, is it just you who wants to use bzr?
<ricardokirkner> do I have to write a hook for each branch in the repo, or is there a way to make this easier?
<ricardokirkner> pygi, no.. its a team of people
<ricardokirkner> otherwise I would just use bzr-svn
<ricardokirkner> I want to use bzr.. just push to svn as a side-effect
<pygi> hmmm
<SamB_irssi> jelmer: I've noticed a message about refusing a basic authentication challange now ...
<pygi> ricardokirkner, you can set global hook for a user
<pygi> would that work?
<ricardokirkner> mhhh
<fullermd> You could just use a bzr central branch, and cron pushing it to svn Every So Often(tm)...
<ricardokirkner> I dont think so, as that would require that every team member commits with the same user
<fullermd> If everybody's going to actually use bzr, that could work....
<ricardokirkner> fullermd, that might work...
<ricardokirkner> it's not 'clean' ,. but it might work
<ricardokirkner> thx
 * fullermd specializes in 'not clean'   8-}
<ricardokirkner> :-)
<phinze> how difficult would it be to implement a "poor man's PQM" with a pre-commit hook on a shared branch?
<rockstar> phinze, are you using Launchpad?
<phinze> no i'm in a dev group at a university
<phinze> trying to see if there's a way to get PQM-like functionality without significantly changing the workflow of the developers
<rockstar> phinze, well, I guess it wouldn't be too hard.  Tarmac is more lightweight than PQM, but is (currently) specific to Launchpad.
<phinze> ahh that's why you ask
<rockstar> Tarmac doesn't use a hook though.
<LarstiQ> ricardokirkner: does the policy state how soon the code must be in the svn repo?
<phinze> rockstar: you think it would be better to look into modifying tarmac?
 * phinze knows nothing about tarmac
<rockstar> phinze, bzr branch lp:tarmac
<rockstar> phinze, it's undergone some big changes since 0.1, but I don't see a direct way currently to have it be non-launchpad specific.  If you do, I'd be glad to review and merge it.
<LarstiQ> phinze: james_w has recently worked on a poor man's PQM
<phinze> LarstiQ: thanks, james_w: ping?
<phinze> rockstar: cool, rooting around in it now... so it's based off the Launchpad concept of " Branch Merge Proposals"?
<rockstar> phinze, yes.
<rockstar> phinze, actually, the best way to do a poor man's PQM with Tarmac would probably be to create a new TarmacScript
<phinze> yeah that makes sense
<phinze> okay here's a dumber question about hooks
<phinze> given a pre-commit hook in a BzrBranch... is there a way of failing the commit?
 * LarstiQ would assume raising an exception
<phinze> or is the hook only allowed to spin off side effects and not get in the way
 * LarstiQ looks at the docs
 * phinze is looking as well, and not finding...
<james_w> phinze: http://paste.ubuntu.com/155496/
<phinze> james_w: you come in and answer all the questions! :)
<phinze> raise errors.TipChangeRejected("The testsuite failed")
<james_w> phinze: it can raise any exception
<LarstiQ> phinze: hmm, mention of this should be more clear in `bzr help hooks`
<james_w> that one says "I didn't go wrong, I want to cleanly stop the operation please", which means bzr formats it differently
<james_w> it's specific to the tip_change hooks though
<james_w> I don't think it works for pre_commit
<phinze> gotchya
<phinze> well tip_change is good enough in our case
<phinze> we're using append_revisions_only on the shared branches anyways
<LarstiQ> errors.HookFailed
<LarstiQ> might still not be entirely correct, given its docstring
<phinze> in fact, tip_change is probably more correct
<phinze> well this definitely gives me some stuff to play with... rockstar, LarstiQ, james_w: thanks
<james_w> phinze: if it suits you we could turn the above in a project and work to make it useful to more people
<james_w> it was a quick hack the other day after I get fed up of committing broken stuff myself :-)
<phinze> haha that's exactly what brings me here with the interest
<phinze> i would definitely be interested in that
 * phinze is still in the process of making the snippet work ATM
<james_w> my snippet?
<phinze> yeah, just shuffling some branches around here
<james_w> install it as ~/.bazaar/plugins/testrunner.py
<james_w> then edit ~/.bazaar/locations.conf to ahve
<james_w> [/path/to/branch]
<phinze> ... hmm so it needs to be installed under the user's home dir who will be doing the tip change?
<james_w> pre_change_branch_tip_test_command = ./run-tests
<phinze> any way to install it system-wide...?
<LarstiQ> phinze: sure, bzrlib/plugins
<phinze> this will be going on a shared server to protect a branch shared by many users using bzr+ssh
<james_w> you can set it to a parent directory, and the same command will be run for all users under that directory
<phinze> cool
<james_w> phinze: "bzr version | grep bzrlib"
<james_w> and install it in the plugins/ directory there
<james_w> you will need to tweak it to use branch.conf as well in that case
<james_w> otherwise each user would have to edit their locations.cond
<phinze> gotchya
<phinze> command = config._get_best_value("pre_change_branch_tip_test_command") # ...ok?
<phinze> james_w: ^^
<james_w> phinze: I think so
<james_w> phinze: how's it working for you?
<phinze> james_w: working great!
<james_w> cool
<phinze> hmm ok
<phinze> james_w: bzr: ERROR: Received bad protocol version marker: '(in /tmp/tmpzMKiVL/export)\n-
<phinze> i get that when running this over bzr+ssh
<james_w> urgh
<phinze> any idea what that means?
<james_w> it's presumably redirecing stdout or stderr back to the client
<kirkland> is there some configuration place that I can set my default signature to be appended on bzr commits?
<james_w> hey kirkland
<james_w> you mean line email signature>
<james_w> ?
<kirkland> eg, Signed-off-by: Dustin Kirkland <kirkland@example.com>
<james_w> not currently
<kirkland> james_w: yeah, perhaps
<james_w> oh
<james_w> no there is
<kirkland> james_w: sweet, pray tell
<james_w> you need to write a few lines of python though
<kirkland> james_w: i'm okay with that
<kirkland> james_w: though that would be a nice thing to set in .bazaar/bazaar.conf
<kirkland> james_w: commit_signoff = Foo
<james_w> from bzrlib import msgeditor
<james_w> def add_signoff(commit, start_message):
<james_w>     branch = commit.branch
<james_w>     config = branch.get_config()
<phinze> james_w: sounds like i just need to give subprocess.call the correct pipes for output
<phinze> i'm guessing bzrlib.trace might have them...?
<james_w>     message = config._get_best_value("commit_signoff")
<james_w> if message is None:
<james_w> err, scratch that last line
<james_w>     if message is None:
<phinze> james_w: actually it was command = config._get_user_option("pre_change_branch_tip_test_command")
<james_w>         return start_message
<phinze> er whoops
<phinze> wrong case :(...
 * phinze steps back a minute
<james_w>     return start_message + "\n\n%s\n" % (str(message),)
<james_w> kirkland: if you can piece that together :-)
<james_w> I can stick it in a pastebin if you like
<james_w> save it as "~/.bazaar/plugins/commit_signoff.py"
<james_w> oh, you'll need a start_message is None check before appending to it as well
<james_w> phinze: what do you mean by "correct pipes"?
<kirkland> james_w: neat, thanks
<kirkland> james_w: pastebin would be cool
<phinze> idk wondering if subprocess.call by default is looking to the wrong place for stdout and stderr when it's being run over bzr+ssh
<james_w> kirkland: http://paste.ubuntu.com/155535/
<james_w> kirkland: even with the call to actually register the hook :-)
<james_w> you should be able to set commit_signoff either globally, or per-location
<james_w> I don't think it does entirely what you want, but it
<james_w> 's the best you can do from a plugin right now I think
<james_w> phinze: I'm not sure there is a correct place for them
<phinze> james_w: lemme try None
<james_w> I don't know if it's possible, but you would really want to send this information back to the client somehow
<phinze> indeed
<james_w> fg
<phinze> hmm that didn't help
<phinze> received bad protocol version marker...
<james_w> None is the default
<james_w> you can use subprocess.PIPE to redirect
<phinze> perhaps need to prefix bzr+ssh:// to the tmp thing
<kirkland> james_w: cool, were does this plugin go?
<kirkland> james_w: .bazaar/plugins/*
<james_w> that'll work
<kirkland> james_w: does it need to be in a subdir of that?
<kirkland> james_w: named anything special?  __init.py__ or some such?
<james_w>  "~/.bazaar/plugins/commit_signoff.py" will be fine
<kirkland> james_w: The MessageEditorHooks hook 'commit_signoff' is unknown in this version of bzrlib.
<kirkland> Unable to load plugin 'commit_signoff' from '/home/kirkland/.bazaar/plugins'
<kirkland> james_w: do i need to register it?
<james_w> kirkland: sorry
<james_w> "commit_message_template"
<james_w> change the first arg to install_named_hook to that
<kirkland> k
<kirkland> aborting commit write group: AttributeError("'LocationConfig' object has no attribute 'commit_signoff'",)
<kirkland> bzr: ERROR: exceptions.AttributeError: 'LocationConfig' object has no attribute 'commit_signoff'
<kirkland> [DEFAULT]
<kirkland> email = Dustin Kirkland <kirkland@canonical.com>
<kirkland> launchpad_username = kirkland
<kirkland> commit_signoff = Signed-off-by: Dustin Kirkland <kirkland@canonical.com>
<kirkland> that's in my bazaar.conf
<james_w> phinze> command = config._get_best_value("pre_change_branch_tip_test_command") # ...ok?
<james_w> phinze: ^ was that correct?
<phinze> james_w: no --> command = config._get_user_option("pre_change_branch_tip_test_command")
<phinze> that did
<james_w> kirkland: try changing "_get_best_value" to "_get_user_option"
<james_w> thanks phinze
<kirkland> james_w: bingo
<kirkland> james_w: you da man
 * kirkland owes james_w a beer
 * phinze does as well
<james_w> kirkland: not that it won't work with "-m"
<james_w> ^note
<kirkland> james_w: tis okay
<kirkland> james_w: this get's me much closer
<james_w> it modifies what the editor shows to you, so if you never see the editor then it won't do anything
<kirkland> james_w: i was using vim bindings
<kirkland> james_w: but this is much nicer
<james_w> cool
<jelmer> SamB_irssi: how do you mean?
<SamB_irssi> jelmer: with svn from unstable, I get this error:
<SamB_irssi> naesten@hydrogen:~/hacking/dosemu% bzr push svn+https://dosemu.svn.sourceforge.net/svnroot/dosemu/branches/debugger/
<SamB_irssi> bzr: ERROR: Permission denied: ".": MKACTIVITY of '/svnroot/dosemu/!svn/act/5d67fa37-fa8b-4227-a397-f31dd0b8dee7': authorization failed: Could not authenticate to server: rejected Basic challenge (https://dosemu.svn.sourceforge.net)
<jelmer> SamB_irssi: does it work with "plain" svn?
<SamB_irssi> is there some?
<jelmer> SamB_irssi: I mean, does it work without using bzr but only svn
<SamB_irssi> it let me edit revision properties
<SamB_irssi> without rejecting any basic authentication
<jelmer> does it let you do commits?
<SamB_irssi> hmm ...
<jelmer> SamB_irssi: ah, that's svn+https:// that's not prompting
<SamB_irssi> jelmer: hmm?
<SamB_irssi> and yes, I can commit
<jelmer> SamB_irssi: https:// works fine
<SamB_irssi> jelmer: wasn't the svn+ your idea?
<jelmer> SamB_irssi: well, it does work as a workaround to bzr triggering the smart server
<SamB_irssi> I mean ... didn't you suggest I use that for this ... ?
<SamB_irssi> oh well.
<SamB_irssi> now I'm getting something about a failing is_canonical assertion ...
<jelmer> SamB_irssi: one sec
<jelmer> SamB_irssi: I've pushed a fix for the svn+https:// auth issue
<jelmer> SamB_irssi: not sure about the is_canonical one issue, are you running the latest subvertpy?
<SamB_irssi> jelmer: where would I get the .deb for that?
<jelmer> SamB_irssi: In Debian (sid)
<SamB_irssi> jelmer: well, last I checked, it was the latest that I'd seen in apt ...
<jelmer> SamB_irssi: ah, sorry
<jelmer> SamB_irssi: in that case, please run inside of gdb and pastebin the backtrace
<jelmer> SamB_irssi: sorry this is a bit of a bumpy road..
 * SamB_irssi hopes he won't need a -dbg package -- those things are getting kind of big lately
<jelmer> SamB_irssi: You might need the libsvn-dbg one actually, for a sensible backtrace :-/
<SamB_irssi> well, I'll try without first
<SamB_irssi> the svn+ fix does seem to help, though
<jelmer> cool
<SamB_irssi> jelmer: what did you want to see?
<jelmer> SamB_irssi: the output of the 'bt' command inside of gdb
<SamB_irssi> well, yeah, I was getting ahead of myself
<SamB_irssi> http://paste.ubuntu.com/155563/ is what I get so far
<SamB_irssi> which function would you like to know something about the arguments of?
<jelmer> basically which subvertpy function is triggering the crash
<SamB_irssi> oh
 * LarstiQ votes for ra.Auth()!
<LarstiQ> jelmer: but I saw you fixed that, thanks :)
 * SamB_irssi mumbles something about there not being a libsvn-dbg package ?
<jelmer> SamB_irssi: libsvn1-dbgsym
<jelmer> LarstiQ: np :-) I think that's not actually used by bzr-svn though
<LarstiQ> jelmer: it was step1 in trying to figure out why password_encoding=subversion didn't work
<jelmer> LarstiQ: oh, ok
<SamB_irssi> jelmer: well ... I don't see that either
<SamB_irssi> what repository are you getting it from ?
<jelmer> SamB_irssi: it's in the debug repository
<jelmer> deb http://debug.debian.net/debian unstable/debug main
<LarstiQ> jelmer: credentials would raise StopIteration and I had no clue why
<jelmer> LarstiQ: because it didn't have any credentials cached ? (-:
<LarstiQ> jelmer: bollocks!
<LarstiQ> jelmer: it does, and it works for svn
<LarstiQ> but I'll figure it out later
<LarstiQ> sleep now
<SamB_irssi> jelmer: unfortunately I don't seem to be able to get that version of libsvn1
<jelmer> SamB_irssi: :-/
<jelmer> SamB_irssi: another thing that may help is using a subvertpy built with debugging symbols
<jelmer> LarstiQ: this is with the latest bzr-svn?
<SamB_irssi> jelmer: if you were to upload such a python-subvertpy-dbg to experimental, I'd be happy to try it
<jelmer> SamB_irssi: I can't, subvertpy is in sid and adding a new binary package would mean another 3 or 4 weeks for it to go through NEW
<SamB_irssi> jelmer: oh :-(
<SamB_irssi> well, to anywhere, really
<jelmer> SamB_irssi: Is there any chance you can just try with a manually built subvertpy?
<SamB_irssi> (experimental messes up sid?)
<jelmer> SamB_irssi: all binary packages from one source package end up in the same distribution, not multiple
<jelmer> SamB_irssi: there shouldn't be a need to install subvertpy to try this
<jelmer> just set PYTHONPATH appropriately
<SamB_irssi> yes but I'd need the svn headers :-(
<jelmer> yeah
<SKArfaceGC> is there any documentation on cvsps-import other than the README file?
<SamB_irssi> which seems to need 35 megs ... in /usr ...
<SamB_irssi> I might have them ...
<jelmer> SamB_irssi: You should be able to remove it again once you've run this
 * SamB_irssi doesn't get why subversion's headers require the installation of so many others -- Suggests:, sure, but Requires: ?
<jelmer> SamB_irssi: they include the others
<SamB_irssi> all of them?
<jelmer> samb_irssi: indirectly, but yes
<SamB_irssi> it still seems pretty sick ...
<jelmer> directly it only depends on libapr-dev and libapr-util-dev IIRC
<jelmer> apr depends on a lot I think
<SamB_irssi> I mean, seriously -- why are the headers for 3 different DBMS-type things needed?
<SamB_irssi> (BDB, mysql, and sqlite)
<SamB_irssi> jelmer: okay, how do I build subvertpy with debug flags ? I haven't done that sort of thing in a while ...
<jelmer> SamB_irssi: ./setup.py build_ext -i -g
<SamB_irssi> and how would you suggest I bzr-svn to use this one?
<SamB_irssi> +get
<jelmer> export PYTHONPATH=/path/to/subvertpy
<SamB_irssi> (there sure were a lot of deprecation warnings...)
<jelmer> yeah, that's correct, we'd like to stay compatible with old verisons
<SamB_irssi> it would be better if they cited a version since which they were deprecated ...
<jelmer> SamB_irssi: that's not possible in C afaik
<SamB_irssi> jelmer: ... since when are deprecation warnings even possible ?
<SamB_irssi> (in C)
<jelmer> SamB_irssi: gcc extensions
<SamB_irssi> oh
 * SamB_irssi gets it to actually load on his 3rd try ...
<SamB_irssi> (1st time I added it to the end of PYTHONPATH, second try I used ~ in a place it wasn't expanded ...)
 * SamB_irssi is tired of waiting for "finding fileprop revids" or whatever ...
<SamB_irssi> jelmer: great. now it has to go and work on me!
<jelmer> SamB_irssi: ok, so looks like it's probably a bug fixed in the current subvertpy
<SamB_irssi> jelmer: what do you mean about "experimental" uploads delaying movement from unstable to testing ?
<jelmer> SamB_irssi: ? That's not what I said
<SamB_irssi> oh. maybe you missed where I said "experimental" and not unstable?
<jelmer> SamB_irssi: no, I never said experimental uploads delay movements from unstable
<jelmer> SamB_irssi: it's just not possible to upload a source package from which the binary packages are in different distributions
<jelmer> the source package's distribution determines where the binary packages go
<SamB_irssi> well, I mean, you could upload the whole thing to experimental, couldn't you ?
<jelmer> so the source package subvertpy would have the binary packages python-subvertpy and python-subvertpy-dbg
<jelmer> SamB_irssi: yes, but why would I upload to experimental? subvertpy lives happily in sid
<SamB_irssi> hmm, well, I dunno ;-)
<SamB_irssi> I'm not a DD
<SamB_irssi> right now, I'm just thinking it would be nice to have a subvertpy which actually allows me to push the way I just did in some Debian repository would be nice
<jelmer> SamB_irssi: I don't see why that would have to be with a experimental rather than an unstable package though
<jelmer> SamB_irssi: The problem is I don't have time to upload either at the moment
<SamB_irssi> ah
 * SamB_irssi mumbles something like "why do they have to make these things take time?"
<jelmer> I should have time for it in about a weeks time, when I get back home
<SamB_irssi> oh, that's a nice and short moment I guess ;-)
<SamB_irssi> oh, how would you merge a subversion branch back into the trunk with bzr-svn ?
<SamB_irssi> (supposing that there were no changes on trunk)
<jelmer> SamB_irssi: bzr pull
<jelmer> (as you would with a regular bzr branch)
<SamB_irssi> does that need to be in an actual checkout, or is it fine if it's just a branch with all the same commits ... ?
<jelmer> SamB_irssi: not sure if I follow..
<SamB_irssi> it's okay if I pull into something that isn't actually a bzr checkout of the SVN trunk, yes?
<jelmer> yeah
<SamB_irssi> okay ... actually there were some changes on trunk(!) but it seems okay ...
<SamB_irssi> hmm. svn annotate still leaves something to be desired :-(
<SamB_irssi> (all the changes are attributed to the merge: see http://dosemu.svn.sourceforge.net/viewvc/dosemu/trunk/src/arch/linux/debugger/mhpdbgc.c?annotate=1888, notice that all my changes are marked 1888)
<phinze> dev-noob question: how to get bzr to print out full errors rather than just the "friendly" and terse bzr: ERROR: Received bad protocol version marker: '(in /tmp/tmppPHYeP/export)\n-'
<SamB_irssi> jelmer: but you can't do anything about that :-)
<phinze> i know python has a backtrace for me somewhere in there
<phinze> i could pdb i suppose
<SamB_irssi> BZR_PDB=on bzr foo ...
<phinze> aha
<SamB_irssi> (if you want to pdb, that is)
<phinze> SamB_irssi: perfect; thanks
<bob2> phinze: full tracebacks are in ~/.bzr.log, too
<phinze> bob2: mmm also helpful
 * phinze is trying to debug a hook that runs tests and rejects commits... works locally but when run through bzr+ssh gets raise errors.UnexpectedProtocolVersionMarker(in_buf)
<Peng_> You can also see the full tracebacks with -Derror, right?
<lifeless> phinze: interesting
<lifeless> phinze: where is that raised from?
<phinze> lifeless: subprocess.call of an external command... looks like the output of that command is getting into in_buf... which expects something
<phinze> oop may have just fixed it
<lifeless> phinze: subprocess by default using stdin and stdout
<phinze>  subprocess.call(command, cwd=export_dir, shell=True, **stdout=subprocess.PIPE**)
<lifeless> so you may have been sending your output back over the wire to the client
<lifeless> yup
<phinze> happy days are here again
<phinze> :)
<lifeless> phinze: you may want stderr=subprocess.STDOUT
<phinze> lifeless: yeah i'm poking around with that, but for some reason i get 0 output from the subprocess command on my terminal when i specify it
<lifeless> phinze: thats correct, your plugin will get it all
<lifeless> phinze: imagine that you are committing over bzr+http
<lifeless> in that situation stderr and stdout are effectively /dev/null *unless* you capture them via subprocess with stdout=PIPE and stderr *either* PIPE or STDOUT
<phinze> riight ok
<lifeless> now, we don't have a way at the moment for you to send an output stream during the commit process
<lifeless> because its a hook happening at the end of a push
<phinze> hmm okay so to a relative python dunce... is there a way for me to get that output displayed to the user?
<phinze> (which in this case is the output from a testsuite running..?)
<lifeless> phinze: not at the moment - think of it like a cronn job running on the server
<phinze> with just stdout=subprocess.PIPE i get about half the output on my terminal when running push
<lifeless> if it fails, you can raise an exception with any data you want
<lifeless> the exception is stringified and passed back over the wire
<lifeless> if it succeeds, no output is shown
#bzr 2009-04-22
<phinze> right that makes sense; the behavior i describe above is what's confusing to me
<lifeless> oh right
<lifeless> so the reason that happens is this:
<phinze> our entire testsuite spits out to stdout
<phinze> if i'm not making any silly mistakes
<lifeless> bzr+ssh invokes bzr on the server by doing 'ssh host bzr'
<phinze> sure
<lifeless> so the bzr on the server, when it writes to stdout, the local bzr gets that on the socket read fd
<phinze> right that makes sense
<lifeless> when something on the server writes to stderr, ssh cpatures that and sends it back to the client, where it goes to the ssh's std err
<lifeless> which bzr hasn't redirected
<phinze> ahh so it must be stderr that is making it through
<phinze> so i might be able to exploit that behavior to get my testsuite output shown to the user? :)
<lifeless> phinze: yes, as long as you don't start serving bzr+hhtp ;)
<phinze> so basically add 2>&1 on the end of my commands and i'm right as rain
<phinze> err
<phinze> other way around
<phinze> hah, beautiful
<lifeless> phinze: I'm going to file a bug to capture this requirement
<phinze> lifeless: you've been incredibly helpful, great explanations
<lifeless> its one we deferred in getting streaming up
<lifeless> and it would be lovely to have some sort of answer for bzr+http
<lifeless> phinze: anytime
<phinze> yeah an official way of handling this would be better
<phinze> awesome; based off james_w's code i now have a 30 line "poor man's PQM"
<james_w> phinze: perhaps the plugin should do that
<phinze> james_w: where 'that' == the output redirection?
<james_w> yeah
<phinze> well it doesn't look like subprocess.Popen has a clear way of doing that
<phinze> can't just set stdout=subprocess.STDERR (STDERR not defined)
<phinze> stdout can be set to an int though
<makiolo> bazaar is down ?
<phinze>             elif isinstance(stderr, int): errwrite = msvcrt.get_osfhandle(stderr)
<makiolo> can download ? bzr branch lp:wiithon i have timeout
<phinze> makiolo: i branched that with no problems
<makiolo> ok ...
<makiolo> thx
<phinze> sure
<phinze> james_w: this works, but there must be a cleaner way? subprocess.call(command, cwd=export_dir, shell=True, stdout=2)
<james_w> phinze: you can set stdout=suprocess.STDIN though
<james_w> err
<james_w> nonsense
<james_w> you can set stderr=subprocess.STDOUT
<james_w> which is what we want isn't it?
<james_w> oh, no, I see now
<phinze> james_w: no, re above discussion w/ lifeless... stdout is interpreted as server communication, but stderr makes it all the way through
<lifeless> james_w: there isn't a way to send the data via bzr+ssh atm
<james_w> phinze:
<phinze> so stdout=STDERR is what i want... but is STDERR=2 set somewhere in python for me to reference?
<james_w> so we want to write nothing on stdout?
<james_w> and everything on stdin
<phinze> as everything is working beautifully now with stdout=2... test suite runs; i see output; and if it passes, my push is accepted
<james_w> that's possible, but it's a pain
<phinze> s/stdin/sterr yes
<phinze> sigh: STDERR
<james_w> err, yeah, I don't know what's wrong with me tonight :-)
<phinze> typing plague
<james_w> redirect stderr -> stdout by calling with stderr=subprocess.STDOUT
<james_w> so that both streams are interleaved as you want
<james_w> then capture stdout
<james_w> with stdout=subprocess.PIPE
<phinze> right, but stdout is not sent across the wire currently; bzr+ssh offers no way of getting it though
<james_w> so that stdout isn't sent and you don't get the failure
<phinze> yeah i tried that but then i get no output on the terminal
<james_w> then manually output stdout on stderr
<phinze> i have no way of accessing subprocess.PIPE from my remote bzr client... so i get no output
<james_w> by reading from proc.stdout and using "info" on each line
<phinze> well then it would be all in one chunk wouldn't it?
<james_w> or "warning" perhaps
<james_w> both from bzrlib.trace
<james_w> nope, you can read per-line
<phinze> i like how it's working now because as the testsuite runs i see the output
<james_w> for line in subprocess.stdout:
<james_w>     trace.warning(line)
<phinze> but i have to wait for subprocess.call to complete
<james_w> retcode = subprocess.wait()
<james_w> the other way would be to redirect both to a pipe, and then select on the two filehandles, and "info" the stdout, and "warning" the stderr, so that "commit -q" suppresses the normal output
<phinze> ahh then use subprocess.Popen() rather than subprocess.call() ..?
<james_w> your stdout=2 might be a simple way to do it, but I don't know if that would work on windows
<james_w> yeah Popen
<james_w> perhaps sys.stderr would be more robust than "2"
<phinze> yeah you're thinking in terms of doing it the right way rather than my hacking things together :)
<phinze> will sys.stderr be coerced into an integer?
<phinze> suppose i can check
<phinze> yes, yes it will
<jam> phinze: sys.stderr.fileno() if you need it
<jam> But Popen() already knows about fileno() for file objects
<james_w> hi jam
<jam> hi james_w
<phinze> jam look what james_w gifted me: http://paste.ubuntu.com/155612/
<jam> phinze: poor mans PQM, looks good
<phinze> we're just cleaning up the input redirection
<phinze> works with no redirection on local machine, but over bzr+ssh stdout of testsuite iinterpreted as smart server output over wire and barfs
<phinze> can take advantage of the fact that stderr makes it all the way through because of ssh
<lifeless> james_w: info on the server won't do the right thing
<james_w> oh, of course not
<jam> I thought there was a way to suppress stdin, etc
<jam> but I don't see it specifically
<jam> phinze: well, stdout *is* being redirected via ssh
<jam> it just happens that we listed to the ssh stdout locally as bzr+ssh return values :)
<jam> and don't directly listen to stderr
<phinze> exactly, so it's a bit of a hack that pushing output through stderr happens to work :()
<lifeless> using stderr today is your best bet
<lifeless> I've filed a bug to enhance things to improve on that
<phinze> lifeless: can you link?
<jam> phinze: I would say that you could use 'close_fds' to force stdin to be closed
<jam> however, that raises exceptions on windows (if you care)
<phinze> jam: why do i care about stdin in this case?
<jam> phinze: I would set it to "/dev/null" so that anything that wants input aborts immediately
<jam> rather than hanging indefinitely
<jam> I also see stuff like: http://paste.ubuntu.com/155618/
<jam> so you may not really care about windows
<phinze> ahh gotchya, because we're executing an arbitrarily specified command
 * phinze indeed does not care about windows... but wouldn't mind supporting them if it's easy :)
<lifeless> jam: stdin=PIPE; process.stdin.close() is better
<jam> lifeless: sure
<jam> I thought there was a way to do 'stdin=NULL'
<jam> but I think stdin.close() is the best you can get
<jam> phinze: for your case, it would mean using Popen() rather than .call()
<jam> the other odd thing
<jam> you can pass "stderr=subprocess.STDOUT"
<jam> but there doesn't seem to be a "stdout=subprocess.STDERR"
<jam> weird
<phinze> yeah i know isn't it?
<jam> as that is probably what you would want over sys.stderr
<phinze> yeah i went down that same path
<lifeless> jam: was my index building thoughts mail useful to you?
<jam> lifeless: so I'm not sure that it is N log N, I have the feeling it is N*C where C is the number of entries in a single page
<jam> I did like the info about how many keys we read, etc.
<jam> as for checking 'late'
<jam> I think we need to check as we go in at least the local dict
<jam> and then we could check during the recombine step
<lifeless> we currently check the local dict
<jam> lifeless: right, we currently check both the local dict and the spilled
<lifeless> jam: actually we don't
<lifeless> jam: add_node checks self._keys, not the spilled indices
<lifeless> jam: its definitely superlinear, N*C would be linear with a high constant
<jam> lifeless: _insert_record_stream calls add_records() which calls _get_entries(keys)
<jam> which goes through iter_entries(keys)
<lifeless> I am quite sure its NlogN with a large down-scale factor
<jam> Which *definitely* checks everything
<phinze> jam: better? http://paste.ubuntu.com/155622/
<lifeless> jam: yes, thats in how we use the index though, I'm talking specifically about the contract the index offers
<jam> phinze: looks good to me
<lifeless> jam: I think it would be ok if it *either* errors in add_node on dupes, *or* errors in finish on dupes
<phinze> jam: danke :)
<lifeless> jam: erroring *sometimes* in add_node and *sometimes* in finish, depending on whether the dupe has been paged out would be odd to work with and surprising for users of the index layer
<jam> well, if you wanted to error always during finish
<jam> you would have to check during add, and queue it for a later error
<jam> since otherwise you are just doing dict[key] = value
<jam> and it just overwrites the previous value
<lifeless> jam: thats true. Ok, scratch that, erroring in both add_node and finish, depending on when the collision is found
<SamB> jelmer: thanks for the help, btw
<phinze> thanks all
 * SamB wishes someone would bother to vote for http://bundlebuggy.aaronbentley.com/project/bzr/request/<E1LupWj-0005Cp-WD%40hydrogen> -- it just adds a sentence to an error message!
<jfroy> jelmer: sorry that I pinged you and then dropped off the face of the earth. I've been debugging a kernel panic all day :p
<SamB> jfroy: on real hardware?
<jfroy> SamB: yeah, graphics drivers
<jfroy> (my day job, etc. etc.)
<SamB> not fun :-(
<jfroy> loads of fun :p
<SamB> well ... I don't find it fun to have to debug stuff like that running on real hardware ...
<jfroy> Eh, it's OK with 2 computers
<SamB> maybe if you have an ICE
<SamB> or, okay, a kernel debugger
<jfroy> yeah, using our kernel debugging facilities
<jfroy> I haven't been able to resurrect a kernel yet though :p
<jfroy> It's a feat only the masters know the secrets of :p
<SamB> I can't even do that for DOS
<fullermd> DOS can't even do it for DOS   :p
<SamB> (not that it's worth bothering ;-)
<SamB> (rebooting gives better results anyway ;-)
 * SamB wonders if there are any kernel debuggers of the sort jfroy uses for DOS ...
<fullermd> You don't need a kernel debugger for DOS.  It's, what, like 20 lines of code?  You find bugs by inspection.
<lifeless> fullermd: you can get a lot in 20 lines of forth :)
<SamB> fullermd: er, not the one I looked at!
<SamB> of course, that one was written in C
<fullermd> Well, maybe later versions are longer, after they added all those decadent extra features like directories...
<lifeless> jam: is phinx @ the drizzle con?
<SamB> fullermd: what's the point of using a DOS if it doesn't give you directories ... okay, sure, I suppose file names are nice ...
<fullermd> Well, that was sorta my meta-point   ;)
<SamB> but really, I have never in my life used DOS 1!
<lifeless> original disks were too small to bother with directories
<lifeless> waste of disk space
 * SamB is still bothered by the fixed-size root dir in FAT
<fullermd> Yeah.  Only so much room in 360k to put stuff.  Heck, I've got directories bigger than that now...
<SamB> fullermd: you mean just the directory entries occupy more space than that, I assume ?
<Peng_> I've got a 1,024,000k directory entry from when a program spammed my /tmp dir. :D
<Peng_> Err, byte, not kilobyte, I suppose. :P
<SamB> jelmer: shouldnsvn-set-revprops
<SamB> er.
<SamB> jelmer: shouldn't svn-set-revprops be in "bzr help svn"?
<wgrant> SamB: Only FAT1[26] have a fixed root dir size.
<SamB> wgrant: okay, sure. I was reading a book that didn't talk about any version of DOS more recent than 3.x, so ...
<wgrant> SamB: Ah, that could do it.
<lifeless> spiv: I'm still futzing around with refactoring the start of push
<lifeless> its rather unsatisfying
<lamalex> so i just pushed from a branch right into our trunk, instead of merging my branch and then pushing
<lamalex> is there a way i can revert this?
<jfroy> jelmer: I just had a thought.
<jfroy> I am fairly certain I did an uncommit on the branch I am having trouble with.
<jfroy> Could it be the root cause of the missing revision problem?
<fullermd> lamalex: Find the rev that should be its head, and use push or pull to set it.
<lamalex> fullermd: can you give me example syntax?
<fullermd> lamalex: "cd $TRUNK ; bzr pull --overwrite -r$OLD_HEAD ."  or  "cd mybranch ; bzr push --overwrite -r$OLD_HEAD $TRUNK"
<fullermd> Then set append_revisions_only in the $TRUNK/.bzr/branch/branch.conf to guardrail it a bit in the future   8-}
<lamalex> :)
<lamalex> fullermd: thank you!
<lifeless> later folks
<BasicOSX> lifeless made a funny on the mailing list :-)
<lifeless> I did?
<BasicOSX> response to my final vs rc3
<BasicOSX> I don't think additional testing will make this bug more severe. :)
<lifeless> right
<BasicOSX> 2am that's funny to me for some reason
<lifeless> :)
<BasicOSX> ;-P
<lifeless> it was ironic I guess
<jelmer> jfroy: it shouldn't but I guess it could
<jelmer> jfroy: did you push the original branch (from before the uncommit) anywhere?
<jfroy> jelmer: urg sorry, just noticed your messages
<jfroy> I don't remember if I pushed the branch to svn before doing the uncommit or after
<jelmer> jfroy: so you didn't use anything like --overwrite when pushing?
<jfroy> I don't believe so.
<jfroy> jelmer: so in any case, if you need data to figure it out, just let me know.
<jelmer> jfroy: Ok
<SUPERSONICXX5> HOLAS
<SUPERSONICXX5> ALGUIEN ME HECHA UNA MANO
<SUPERSONICXX5> NO PUEDO ENTRAR EN NINGUN CHAT CASI, OPERA ME DICE QUE AHY UN ERROR CON UN DDL
<SUPERSONICXX5> FIREFOX NO LOS CARGA
<SUPERSONICXX5> GOOGLE CRHOME O COMO SEA VALE CALLAMPA
<SUPERSONICXX5> Y EXPLORER ME SACA, DICE ID NO VALIDA
<huf> are you for real?
<LarstiQ> jelmer: no, the bzr-svn at the time I filed the bug, with recent improvements I hope it is all fixed now, but I'll let you know when I try again
<jelmer> LarstiQ: I suspect so
<fullermd> Furrfu.  Remember those wonderful days when everybody's on vacation and the list is silent?
<LarstiQ> fullermd: I can't keep track anymore, at 1910 unread now :/
<fullermd> However did we survive without 30 rounds of "No, see, it does XYZ."  "You're wrong, it does exactly what you said."  "Yes, that's my point, it does what I said."  "No, you're blowing FUD, it does exactly what you said."  [..........]
<yogsototh> Hi all! What is the good way to handle this? make a modifications m1 and commit then a modification m2 and commit in branch B. How to push only modifications m2 on a branch A?
<yogsototh> I already made the error not making an m2 branch
<fullermd> In a strict sense, you can't.  The nearest you can do is cherrypick it over with merge.  There's no ancestral link behind that, though.
<yogsototh> so bad! Thanks fullermd
<LarstiQ> or well, rebase
<fullermd> Or use a loom.  That's just like rebase, right?
<LarstiQ> fullermd: tsk :P
 * LarstiQ read part of that thread yesterday
<fullermd> Did you read at least 2 mails of it?
<LarstiQ> yes
<fullermd> You pretty much read the whole thing then.
<yogsototh> ok I'll look for that, thanks
<fullermd> yogsototh: Cherrypicking with merge is almost certainly what you want.  In this case, rebase is probably just a really roundable way of doing exactly that.
<yogsototh> I see, I can also play with bzr diff and bzr patch I suppose. Thanks
<fullermd> That'll end up in the same place as the cherrypick.  Using merge will be a bit simpler.
<yogsototh> Yep
<ricardokirkner> guys.. I am trying to push to an svn repo , and I am getting a traceback
<ricardokirkner> http://ricardokirkner.pastebin.com/d61d26395
<ricardokirkner> can anyone help me figure out why this is happening?
<lifeless> jelmer: ^ this one is for you
<lifeless> jelmer: do you highlight on 'svn' yet?
<sohmestra> how do I display the revid for a given revision? bzr log --verbose doesn't show it. I'm using bzr 1.13
<LarstiQ> lifeless: I think he stopped
<LarstiQ> ricardokirkner: are the bzr branch and svn repo public btw?
<ricardokirkner> LarstiQ, no, sorry... they are internal to our company
<LarstiQ> ricardokirkner: k
<ricardokirkner> if you need any info, tell me and I will provide it if I can
<LarstiQ> ricardokirkner: just enough to reproduce it :)
<LarstiQ> ricardokirkner: are there merged revisions in what you are trying to push?
<LarstiQ> ricardokirkner: what does bzr think the revno for the local bzr branch and what is in svn are?
<ricardokirkner> LarstiQ, yes, there are merged revisions in there
<jelmer> ricardokirkner: one sec
<jelmer> ricardokirkner: please file a bug
<ricardokirkner> jelmer, alright...
<ricardokirkner> jelmer, bug on bzr, or bzr-svn?
<jelmer> ricardokirkner: bzr-svn
<jelmer> ricardokirkner: actually
<ricardokirkner> right
<jelmer> ricardokirkner: this is fixed in a recent version of bzr-svn
<ricardokirkner> jelmer, the thing is 0.5.3 (what I am using) is the latest version compatible with bzr 1.13 (the latest release version of bzr)
<ricardokirkner> for 0.6 I need 1.14
<ricardokirkner> which is rc
<ricardokirkner> should I post the bug anyway?
<jelmer> ricardokirkner: 0.5.4 is for 1.14
<ricardokirkner> jelmer, so, in order to avoid this issue I have to use bzr 1.14?
<jelmer> ricardokirkner: Yes, it looks similar to a bug I fixed for 0.5.4
<lifeless> sohmestra: log --show-ids
<sohmestra> lifeless: thanks
<ricardokirkner> mhhh... I'll try to test it using 1.14
<ricardokirkner> and let you know
<ricardokirkner> thx
<jelmer> lifeless: no, I don't do svn highlights, it would be annoying for #svn-dev :-)
<LarstiQ> ricardokirkner: I'd like to know if that fixes it for you too, it looks similar to something I have trouble reproducing but my colleagues run into from time to time.
<phinze> so can bzr-email be used in a hook on a shared branch or is it only for client-based hooking
 * phinze knows about bzr-hookless-email as well but is evaluating the options
<LarstiQ> phinze: afaik, bzr-email will be used on a remote branch regardeless of client installs _if_ you are using the smartserver and have email configured for that branch
<LarstiQ> phinze: but not if people use transports like sftp://
<phinze> LarstiQ: cool; my group uses bzr+ssh so i think we should be good if i install it systemwide on the shared server then
<ricardokirkner> LarstiQ, as soon as I finish testing I let you know
<LarstiQ> ricardokirkner: thanks
<LarstiQ> phinze: I admit to not knowing exactly how to configure it
<LarstiQ> phinze: but branch.conf I'd think
<phinze> LarstiQ: yeah that's my guess... i'll try it out
<phinze> james_w: ping
<james_w> hi phinze
<phinze> hey, you interested in throwing bzr-testrunner out to the world?
<james_w> sure
<phinze> i'm not well versed in lp-fu, but i assume it wouldn't be too difficult?
<james_w> maybe it should have a better name first though?
<james_w> yeah, it's easy to set up a project for it
<phinze> yeah i'm at a loss for names
<phinze> bzr-sentinel, bzr-branchguard, bzr-guardian
<phinze> thinking something more generic to imply that testsuite is not required but any command?
<ricardokirkner> jelmer, LarstiQ no luck. I tried with 1.14rc2 and bzr-svn 0.5.4 and 0.6
<ricardokirkner> and neither solves the push issue
<jelmer> ricardokirkner: please file a bug
<ricardokirkner> I do that now
<jelmer> ricardokirkner:  thanks
<james_w> bzr-canary
<james_w> also, I'm not sure if the shell-hooks plugin makes it unnecessary
<james_w> phinze: have you put it in a branch?
<ricardokirkner> jelmer, the bug is https://bugs.launchpad.net/bzr-svn/+bug/365108
<ubottu> Launchpad bug 365108 in bzr-svn "AssertionError on push" [Undecided,New]
<ricardokirkner> thanks for the support
<ivan> why does switching branches and switching back crap all over my working tree?
<ivan> http://rafb.net/p/tUZ9c479.html
<ivan> maybe because the branch is old :(
<ivan> and now that I switched back I have all these conflicts, http://rafb.net/p/bfiY8c60.html
<phinze> james_w: just locally... latest version is http://paste.ubuntu.com/155933/
<james_w> phinze: cool, thanks
<james_w> phinze: bzr-testrunner seems to be the best name to me, what do you think?
<phinze> yeah straightforward
 * phinze looks at shell-hooks quickly
<james_w> probably still useful to save every script having to implement the "checkout the tree" bit
<james_w> and the redirection
<phinze> yeah plus shell-hooks sends a bunch of arguments along
<phinze> yeah i think it's still worthwhile to throw out there
<james_w> phinze: https://launchpad.net/bzr-testrunner
<james_w> please push your branch to lp:~bzr/bzr-testrunner/trunk
<phinze> james_w: will do
<Stavros> hello
<Stavros> i am trying to merge from a diverged branch, how can i see the uncommited changes i had before the merge?
<jelmer> ricardokirkner: do you have a way to reproduce this bug?
<phinze> james_w: Paul Hinze is not a member of Bazaar Developers...
<phinze> james_w: looking into https://launchpad.net/~bzr/+mentoring ... ~= "fix a bug to join the club"?
<james_w> a new team for this plugin seems like overkill
<phinze> i would hope to contribute enough to be considered for Bazaar Developers membership... but i have not yet
<james_w> I could push the branch up, then merge your changes as needed until you are a member
<james_w> how would that suit you?
<phinze> james_w: works for me... lp:~phinze/+junk/bzr-testrunner
<lifeless> a new team is fine
<lifeless> teams are cheap
<lifeless> and its appropriate if phinze is maintainer
<lifeless> names wise, I'd suggest bzr-testoncommit or something
<lifeless> testrunner is ok, but perhaps it can be improved
<lifeless> *night all*
<james_w> night
<james_w> and it's not just commits
<lifeless> phinze: oh the bug number - Ididn't have that before, just look at bzr's new bugs
<lifeless> james_w: I know that
<ricardokirkner> jelmer, sort of... I don't know when this was first introduced, but since then, (almost) every push crashes
<ricardokirkner> jelmer, I think at some point I merged changes from two different branches and  then tried to push them to the svn repo
<ricardokirkner> and after that the problems started, but I am not entirely sure about that
<jelmer> ricardokirkner: is it a public branch?
<ricardokirkner>  jelmer no... sorry .. it's customer private code
<ricardokirkner> if I can run the tests you need, just tell me
<ricardokirkner> and I tell you back the results
<james_w> phinze: pushed as lp:bzr-testrunner. It should be added to http://bazaar-vcs.org/BzrPlugins as well so that people can find it
<james_w> do you want to do that?
<phinze> james_w: awesome, thanks... yeah i can add it
<james_w> cool, thanks
<phinze> james_w: did you want to try and mess with a group as suggested by lifeless?  or just let me bother you with merge requests :)
<james_w> I don't mind you bothering me, but we can set up a group if you want to be recognised as an author
<phinze> https://launchpad.net/%7Ebzr-testrunner <-- james_w
<james_w> thanks
<james_w> all changed
<james_w> you should have full access now
<phinze> beautiful, ty
 * SamB_irssi wonders what he should do with his debugger branch in the DOSEMU svn repository now that he's merged it back to trunk with bzr-svn
<SamB_irssi> I want to make more debugger changes ... should I pull in trunk and make more, or delete and make a new branch, or what?
<LarstiQ> disregarding svn backing, I'd pull trunk to debugger and then continue there
 * SamB_irssi wonders if he should disregard svn backing
<Kobaz> is there an unmerge?
 * SamB_irssi wonders why sf.net isn't allowing svn:mergeinfo
<LarstiQ> Kobaz: what would that do?
<Kobaz> LarstiQ: undo the merge that was just done
<LarstiQ> Kobaz: bzr revert?
<SamB_irssi> what about the merge did you want to undo?
<Kobaz> the whole thing?
<LarstiQ> evening bialix
<bialix> jam: are you here?
<bialix> heyo LarstiQ
<bialix> LarstiQ: how are you?
<bialix> does anybody knows about new dependency in 1.14: pylzma. I assume it's optional. Is it correct?
<LarstiQ> bialix: mistakenly thought it was no longer cold weather with the sun, and thus caught a cold
 * LarstiQ could be better
<LarstiQ> bialix: how about you?
<bialix> ah
<bialix> too much work. and my daughter going to the school this year, I have to help her
<bialix> do you know when the jam appears here usually this week?
<asac> lifeless: hi. now that gnome moved to git, is there any bzr-git in sight?
<bialix> https://launchpad.net/bzr-git
<LarstiQ> bialix: ah, primary school?
 * LarstiQ would expect jam awake by now
<LarstiQ> bialix: I expect pylzma is optional too
<asac> how good does that work?
<LarstiQ> asac: not as good as bzr-svn, but better than bzr-hg
<bialix> LarstiQ: yes, primary school
<LarstiQ> bialix: cool, I imagine that's very exiting for her?
<asac> LarstiQ: hmm. guess i will have to try ... thanks
<bialix> LarstiQ: the school today seems much complex than in my time. sometimes I think it's much harder to get to the school than to University
<LarstiQ> bialix: woha. How much complexity can there be in primary schooling?
<LarstiQ> apparently more than I think
<LarstiQ> asac: I haven't used it, so I can't really make definitive statements.
<bialix> LarstiQ: may be it's my country made it so complex. or may be I am
<LarstiQ> asac: I know people use it and developt it, but yes, trying seems best
<bialix> LarstiQ: there is something like entrance examination
<LarstiQ> bialix: well, I don't have kids yet, so maybe I'm just ignorant :)
 * LarstiQ blinks
<bialix> yep
<LarstiQ> bialix: can that be failed? And if so, what is one supposed to do then
<bialix> LarstiQ: yes, there is very high chances to fail the examination in the good school. of course men who have enough money can ignore this
<bialix> and there is less good schools there
<LarstiQ> bialix: ah, so the implication is that you have to go to a less good school?
<LarstiQ> right
<bialix> things are too complex, or at least seem so. in m time we go to the school 10 years. now it's 12 years
<bialix> things are changed
<bialix> hi Gary
<bialix> it seems jam traveling these days. (sigh) ok, will wait for his response in ML
 * bialix waves
<bialix> I have questions about http://doc.bazaar-vcs.org/bzr.dev/developers/plugin-api.html
<bialix> especially about section "Plugin metadata before installation". why for it supposed to be?
<SamB_irssi> jelmer: can bzr-svn put in svn:mergeinfo properties retroactively ?
 * SamB_irssi wishes bzr viz was as good as gitk :-(
<luks> what features are you missing?
<SamB_irssi> well, it doesn't seem to have great graph layout
<luks> maybe you should try bzr qlog
<SamB_irssi> luks: it looks like that would require too much disk space to install
<garyvdm> Hi bialix
<luks> SamB_irssi: let me guess, gentoo user? :)
<ricardokirkner> jelmer, regarding the svn push bug... I have some update
<ricardokirkner> sometimes the push is performed correctly (although bzr crashes) -- I can see the commit done in svn
<ricardokirkner> sometimes the push is done partially -- only a few revisions are committed and then it breaks
<ricardokirkner> for example, the last push I did was submitted correctly, but bzr crashes
<ricardokirkner> I will wait until there is something to update my branch, and after a pull, it should work again
<phinze> so... rails has some fixtures in its tests that ensure that some of its functions pull in templates properly
<phinze> so it has files called like template.erb~ and template.erb~1~
<phinze> will bzr clean-tree --detritus nuke those?
<garyvdm> I don't know, but you can test with --dry-run
<sevenseeker> I just updated bzr, subvertpy, and bzr-svn to the latest via easy_install, but when trying to add a file to my local working copy I receive:
<sevenseeker> zr: ERROR: The API for "<module 'bzrlib' from '/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/bzr-1.14rc2-py2.6-macosx-10.5-i386.egg/bzrlib/__init__.pyc'>" is not compatible with "(1, 12, 0)". It supports versions "(1, 13, 0)" to "(1, 14, 0)"
<james_w> sevenseeker: it sounds like that bzr-svn is too old for that bzr
<sevenseeker> according to http://bazaar-vcs.org/BzrForeignBranches/Subversion 0.5.4 works with 1.14, and that is what I have
<sevenseeker> maybe it is just a config bug, I will make a backup and try editing the reqs
<james_w> do you by any chance have two copies of bzr-svn installed?
<sevenseeker> checking
<sevenseeker> ah drat... yes somehow I still have 0.5.3 lurking around
<ja1> phinze: Also clean-tree prompts before deleting
<ja1> (sorry if I'm coming late)
<ja1> oh, and I think our pattern is ".~1~" not "~1~" so it may ignore them
<ja1> that said, *who* uses ~1~ in real files ... :)
<phinze> ja1: yeah turns out rails is inappropriately *preferring* those files when selecting templates
<phinze> bad rails
 * davidstrauss can't wait for the next Stephen Turnbull post to the mailing list.
<phinze> we've got a bug open with the rails folks though... hopefully it will be fixed soon on their end
<lamalex> Is there a thing in bzr that does something similar to git's url config shortening?
<lamalex> like in git I can do git config --global url.git://git.gnome.org/.insteadof gnome: to use gnome: as the prefix for my gnome git branches
<lamalex> this looks like lp: so I assume I can, but is this a specific plugin?
<lamalex> im not sure what to google for
<lifeless> hmm
<lifeless> I *think* the url bookmarks thing can do that
<lamalex> how does  launchpad do it?
<lifeless> also plugins can, I know jamesh did one for gnome
<lifeless> lamalex: the launchpad plugin registers with the bzr directory service provider api
<lifeless> lamalex: so it gets called into, and the plugin then does an xmlrpc lookup
<lifeless> I'm not sure what to google for either :(
<lifeless> jamesh may know if someone generalised/made configurable his plugin for gnome, he'll be up in about 3-4 hours
<lamalex> lifeless: ok, so right now at least it's not a simple as it is with git
<lamalex> ill look at the bookmarks plugin
<mwhudson> it may be prejudice, but i'm not sure that git config line is entirely 'simple' :)
<lamalex> mwhudson: but it appears to be simpler than in bzr
<mwhudson> in some sense
<mwhudson> yes
<lamalex> and the git config line is pretty straight forward
<lamalex> discoverable maybe not
<mwhudson> more convenient, for sure
<lamalex> but looking at the line it's clear what it does
<lamalex> and zsh autocompletes git commands, so that helps
<lamalex> including the config variables
<lamalex> yah, i <3 bzr im not here to say bzr sucks git rules
<mwhudson> that completion sounds nice :)
<lamalex> indeed
 * mwhudson should go back to doing useful stuff, not grousing
<lamalex> :)
<james_w> bzr-bookmarks can do it I think
<james_w> well, that's what it's intended to do, but I'm not sure how slick it is
<lamalex> so is there /any/ kind of documentation about the bookmarks plugins? even just a "this is what it does" blog post?
<lamalex> ah, in the code
<james_w> "bzr help bookmarks"
<james_w> if you've installed it that is :-)
<lamalex> right, i wanted to see what it did before installing it
<lamalex> looking at it in lp now
<james_w> yeah, it's not good you have to do that
<lamalex> agreed
<lifeless> memo to self, plugin-info should be able to do that
<lamalex> even if just the lp front page had "this is what I am"
<lamalex> hm, bzr needs sexy zsh expansions
<lamalex> my TODO list seems to be ever expanding
<lamalex> hm, it also has no usage info
<lamalex> ah, i am mistaken
<bob2> it is relatively sexy already
<lamalex> yah the bookmarks plugin seems to let me make a shortcut to a specific branch which is nice, but not a prefix like lp or gnome
<lifeless> lamalex: I'd file a bug somewhere
<lifeless> actually
<lifeless> have a look through bzr help configuration
<luks> it can do a prefix
<luks> just bookmark the prefix and use bm:foo/path/to/branch
<lamalex> ah, i had no idea help configuration existed
<lamalex> it doesn't show up in zsh tab expansion
<lamalex> when other stuff does- hence i never looked further
<lifeless> lamalex: anyhow luks has rescued the day
<lamalex> kind of, i still dont see it in there
<lifeless> lamalex: luks says use the bookmarks plugin, which won't be patching bzr help configuration (perhaps it should :P).
<lifeless> lamalex: so bookmark gnome as <whatever> then do gnome:/foo/bar/baz
<luks> bm:gnome/foo/bar/baz actually
<luks> it doesn't register a new protocol for each bookmark
<lamalex> literally bm:
<lamalex> ?
<lifeless> luks: ah ok
<lifeless> lamalex: bm:BOOKMARKNAME/suffix
<lamalex> not as nice, but it works
<luks> it *could* register gnome:suffix, but that would get messy pretty soon
<lifeless> luks: it might be nice though, when people want it
<lamalex> just dont go crazy with it, it's not the same a bookmark
<lamalex> but being able to easily register a protocol is a nice thing to be able to do
<lifeless> I'm all for allowing people to have rope
<lifeless> as long as its not actually dangerous
#bzr 2009-04-23
<xiaohui> there is connection time out ERROR when I use *bzr push URL*  under the proxy
<xiaohui> but I could connect the URL in browser
<xiaohui> I also set the enviroment variable http_proxy correctly, so what is the matter?
<spiv> xiaohui: is it an lp: URL?  ISTR a bug about the XML-RPC query that does not using the proxy.
<spiv> xiaohui: the other common problem is that http_proxy needs to look like "http://host:port/", not just "host:port".
<xiaohui> yeah , the URL is https://code.launchpad.net/~MY_LANUCHPADID/PROJECT/name
<spiv> Ah, so two things:
<xiaohui> and I have set the right http_proxy
<xiaohui> spiv: Is there some difference between http and https by using the bzr
<distatica> Is there a way to perform a command on every file under bzr control, while ignoring files that aren't?
<lifeless> bzr ls --recursive | xargs command
<spiv> xiaohui: sorry, my network dropped out
<xiaohui> spiv,  you there? what are the two things you mentioned above? Thank you
<xiaohui> oh, it doesn't matter
<xiaohui> :)
<spiv> xiaohui: so, that URL will redirect bzr, the actual URL for writing to the branch is bzr+ssh://~MY_LAUNCHPADID/PROJECT/name
<spiv> xiaohui: Er,
<lifeless> bln ;)
<spiv> xiaohui: ... is bzr+ssh://bazaar.launchpad.net/~MY_LAUNCHPADID/PROJECT/name I mean :)
<spiv> (I can't blame that typo on a network dropout!)
<xiaohui> so, how could I push then?
<spiv> The other thing I was going to say is that typically you'd just use lp:~MY_LAUNCHPADID/PROJECT/name as a shorthand for that.
<spiv> bzr+ssh://bazaar.launchpad.net/~MY_LAUNCHPADID/PROJECT/namebzr push
<spiv> Gar,
<spiv> bzr push bzr+ssh://bazaar.launchpad.net/~MY_LAUNCHPADID/PROJECT/name
<xiaohui> you mean I should replace the *https * to *bzr+ssh*
<spiv> And replace code.launchpad.net with bazaar.launchpad.net
<xiaohui> oh , I will try it
<xiaohui> spiv: I had use the lp:~MY_LAUNCHPADID/PROJECT/name beforre , but it had the same ERROR
<xiaohui> opps, it cannot works
<lifeless> xiaohui: bzr+ssh needs port 22 open
<xiaohui> how to open the port 22
<lifeless> xiaohui: it will depend on your firewall/system administrator
<lifeless> xiaohui: if you're in an office environment, talk to your system administrator, ask for port 22 opened to 'bazaar.launchpad.net'
<lifeless> xiaohui: in a home environment it should be a setting on your firewall/modem/router
<lifeless> mwhudson: bzr+https writing please :)
<distatica> thank you lifeless. Another question, how can I completely remove bzr from a directory? I have done bzr remove * to get all files to the unknown state, but I need to remove .bzr from any subdirectories.
<mwhudson> lifeless: how does that work with auth?
<distatica> or just find them and delete them manually?
<xiaohui> thank you ,lifeless
<AfC> lifeless: [is there a way to specify a high port for a bzr+ssh urlspec if that's the workaround? I would have guessed bzr+ssh://host.example.com:12345/... but presumably if not then .ssh/config is entirely reasonable to use instead]
<lifeless> distatica: find . -name ".bzr" | xargs :)
<lifeless> AfC: either should work
<lifeless> mwhudson: https - certificate, or basic or digest
<lifeless> mwhudson: apache ends up doing the auth, just like ssh in bzr+ssh
<mwhudson> lifeless: so for launchpad we could tell people to generate a certificate and upload it to their profile?
<distatica> lifeless: ok, was wondering if there was a way through bzr. That worked great. thanks again
<lifeless> distatica: anytime
<lifeless> mwhudson: we could, but using basic auth (safe over https) and their lp password would be easier
<mwhudson> ah right
<mwhudson> well, "not a 3.0 goal"
 * mwhudson goes back to git imports
<lifeless> mwhudson: 'stretch goal' :P
<lifeless> (man I hate that term)
<mwhudson> lifeless: we need stretch goals like we need holes in the head
<lifeless> mwhudson: they are what let us shit?
<lifeless> [if you don't eat you dont ...]
<distatica> box
<lifeless> circle
<elmo> triangle
<AfC> tetracontakaidigon (there, take that)
<AfC> [which seems an awful lot of trouble just to say 42-gon]
<xiaohui> lifeless , if I don't use the http_proxy, do I need to use the bzr+ssh?
<lifeless> xiaohui: if you want to push to launchpad, you need to use bzr+ssh. the 'lp:' short syntax expands to bzr+ssh
<xiaohui> that is a terrible thing
<AfC> xiaohui: um, so, do you follow that http:// and bzr:// are different protocols [to accomplish the same goal of transporting (in this case, receiving) revisions]? The "receiving" part is important; you can't use those to push revisions. That's where (for example) bzr+ssh:// comes in. It is the Bazaar network protocol, but tunnelled over SSH (and invoking a bzr --server instance on the far side one-time).
<lifeless> xiaohui: ssh is very secure, its a standard protocol.
<xiaohui> do you know how to set the proxy for ssh? BTW, I use ccproxy for proxy the http
<lifeless> xiaohui: you may be able to use socks in your environment. I don't know what ccproxy is
<xiaohui> Afc: yeah  I see
<AfC> [there are corner case scenarios whereby you can push over HTTP and Bazaar, but both have ... weaknesses ... whereas SSH is the standard for providing secure connections (in practice, actually, it's more used for the authentication and access part)
<AfC> whereas (say) raw HTTP PUT and bzr (pushing) would imply that the server end is configured to allow such connections & to do something with them.
<AfC> Which would be silly, because then anyone or anything could "push" to your repo. Bad. So {shrug} we ride over ssh, letting that handle the logging in part]
<AfC> (which is all bog-standard and widely accepted)
<xiaohui> lifeless: when I use *ssh https://launchpad.net* ,it return 'cannot resove the hostname'
<lifeless> xiaohui: if you want to test ssh, use something like 'ssh bazaar.launchpad.net'
<xiaohui> lifeless: Oh, I should learn something about ssh
<xiaohui> lifeless: how to use the socks for ssh
<lifeless> xiaohui: I don't know, I don't have firewalls blocking me
<lifeless> xiaohui: socks is a way to proxy many things, and *if* your operating system and firewall support it you could use it.
<lifeless> xiaohui: but that is really up to you
<lifeless> xiaohui: you haven't told use anything about your environment, so I have to be very vague in trying to help you
<lifeless> xiaohui: because just about anything could be wrong
<xiaohui> lifeless:I am working on Debian lenny
<lifeless> xiaohui: ok. And why do you need a proxy?
<xiaohui> and I use an ccproxy as the http proxy server on the WinXP
<lifeless> ok, ccproxy lists SOCKS as a supported protocol
<xiaohui> lifeless: I am working in an LAN of my school
<xiaohui> lifeless: yeah ,ccproxy support socks proxy
<lifeless> http://www.debian-administration.org/articles/449 refers to a thing called tsocks
<lifeless> http://packages.debian.org/lenny/tsocks
<lifeless> there may be other things that will get your debian machine using socks
<lifeless> [like I say, I don't have a need to use socks myself, so I don't know what will or won't work for you]
<xiaohui> lifeless: thank you very much
<xiaohui> I will learn something about ssh
<lifeless> ok
<xiaohui> thanks ,lifeless :)
<lifeless> we'll be here to offer more guidance once you can get ssh to connect to bazaar.launchpad.net via socks
<xiaohui> lifeless: :)
<mwhudson> lifeless, spiv: streaming pull is totally awesome, thanks guys :)
<spiv> mwhudson: :)
<mwhudson> pushing a new stacked branch is still a bit chatty, but i guess you know that
<spiv> Yeah, getting slowly better though.
<lifeless> mwhudson: should be 22 round trips
<lifeless> mwhudson: if its not, upgrade your server :)
<mwhudson> lifeless: funny you should suggest that...
<lifeless> mwhudson: did you have thoughts on minilanguage for the server?
<mwhudson> lifeless: not really
<lifeless> spiv: how are you going
<lifeless> spiv: haven't heard boo from you this week :(
<spiv> lifeless: alright, although I seem to be fighting off headaches a bit more than I'd like
<lifeless> :(
<lifeless> you need some fresh air!
<lifeless> going to the release party tonight?
<spiv> lifeless: I have an updated patch for checking for parent inventories.
<lifeless> I'm very close to a api permitting 'get me a repository ready for making a branch on'
<spiv> James Squire, isn't it?  Tempting!
<lifeless> which is about as far as I could push the refactoring without 'big questions'
<spiv> Yeah, I can imagine :)
<lifeless> finding holes in the refactored code [the code is fine, the definition was less so, and as that was just refactored - well you know the mess and cluster of bugs we started with]
<spiv> I think it'll be a quiet night and try to get to sleep early for me, though.
<lifeless> so i'm now tweaking to make the behaviour be something I'm happy with
<lifeless> I'm not going to the release, slug is frida
<lifeless> y
<spiv> I'm seeing Jerry Springer: The Opera on Friday.
<lifeless> *blink*
<lifeless> I had no idea that even existed
<spiv> Yeah, that was pretty much my reaction.  Then I found it starred David Wenham...
<lifeless> I vant a vull report
<spiv> I'll do my best.
<mwhudson> Jerry Springer: The Opera caused a record number of complaints when it was on the bbc in the uk
<mwhudson> many before it was screened and most from people who hadn't watched it
<mwhudson> not a very pretty sight :(
<lifeless> spiv: found a stacking upgrade bug
<lifeless> spiv: may fix bug $whatever
<lifeless> ok, time to go - ciao!
<spiv> lifeless: cool.  ciao
<spiv> lifeless: heh, "initialize_on_transport_ex"
<lifeless> better names whileuwait
<beuno> lifeless, was about to propose upgrading loggerhead to --dev6-rr, but, bug #365433
<ubottu> Launchpad bug 365433 in bzr "Must end write group before releasing write lock on CHKInventoryRepository" [Undecided,New] https://launchpad.net/bugs/365433
<beuno> and hi  :)
<Peng_> You mean upgrading lp:loggerhead?
<Peng_> Or just a copy of it?
<beuno> Peng_, well, it *could* be lp:lh  :)
<beuno> but that's up for discussion
<beuno> mwhudson, Peng_, how would you feel about that  ^^
<beuno> assuming it actually worked  :)
<Peng_> How do we feel about upgrading lp:loggerhead?
<beuno> we will most likely won't (or shouldn't) do it before bzr 1.14 gets rolled out in Launchpad next week
<beuno> Peng_, yes
<Peng_> Personally, I'm being very conservative about dev6, but that's just my possibly-somewhat-misinformed opinion, and I don't think anyone else should necessarily follow it.
<beuno> Peng_, well, we want the format to kick ass
<beuno> so we have to test it
<beuno> right?
<beuno> it's this chicken and egg thing
<Peng_> With all of the bugs being actively fixed, and the fact that it's a big upgrade with can be wonky about ghosts and stuff, and the discussion about changing how upgrading to rich-roots works, I'm not planning to use it soon.
<Peng_> OTOH, dogfooding is good, so I'm feeling bad about that.
<beuno> heh
<beuno> well
<Peng_> I'm all for testing upgrading different things to dev6rr, but I'm not interested in using it in production.
<Peng_> It *is* a beta format, yaknow.
<beuno> I don't want to do it at the expense of making it more painful to work on LH, so it's either unanimous or no-go
<Peng_> Well, unless it broke, it wouldn't be very painful.
<Peng_> Oh, right, the rich-root upgrade. Still, I don't mind that.
<beuno> it will mean you need to have it rich-root locally as well
<Peng_> Yeah.
<Peng_> But I can always use 1.9-rich-root if I'm afraid of dev6rr. :D
<beuno> haha
<beuno> true
<Peng_> Yeah.Like I said, there's that discussion about changing how upgrading to rich-roots works. I don't understand if matters or not, so I'm personally blocking on it until I do.
<Peng_> Err, s/^Yeah,//
<Peng_> Backspace fail.
<beuno> sure
<beuno> to some extent
<beuno> upgrading LH was under 2 minutes
<beuno> so if the format changes
<beuno> it's not really too painful to re-upgrade
<Peng_> brb
<Peng_> Take everything I say today with a small grain of salt. I'm feeling extremely apathetic and unmotivated.
<Peng_> Still, I am interested in testing dev6rr (until the first branch I tried failed, which kind of killed the mood...), but I'm wary of using it in production yet.
<beuno> Peng_, sure, we'll come back to it as time goes by
<beuno> for starters, I couldn't upgrade locally
<beuno> and launchpad doesn't support it yet
<beuno> so it's al least a few weeks away
<Peng_> You couldn't upgrade locally?
<Peng_> Woah! I just tried upgrading that branch again, and it worked!
<Peng_> Wasn't there a fix for ghosts, recently? Maybe it was that.
<beuno> Peng_, bug #365433
<ubottu> Launchpad bug 365433 in bzr "Must end write group before releasing write lock on CHKInventoryRepository" [Undecided,New] https://launchpad.net/bugs/365433
<mwhudson> beuno: no, let's not make lp:loggerhead a development format
<beuno> ok ok, so everyone except me is sane
<LarstiQ> grrr, why won't bzr+ssh trigger a bzr-email run!
 * LarstiQ SMASH
<Peng_> I didn't say *that*. I'm hardly sane, I just happen to disagree with you on this. :D
<Peng_> Hmm, is it just me, or does dev6rr make check & reconcile much faster? :D
<beuno> it should do everything faster  :)
<Peng_> Wuh-ohs, bzr-search doesn't like the branch, though.
<Peng_> The branch seems to work otherwise, though. :) http://bzr.mattnordhoff.com/loggerhead/pytz/pytz-2008f.dev6rr/
<Peng_> Indexing with the Python version of _btree_serializer works.
<LarstiQ> spiv: you still awake?
<spiv> LarstiQ: yep
<spiv> LarstiQ: somewhat distracted by imminent dinner, though :)
<LarstiQ> spiv: I'm struggling with the smart server executing my email hook, and you seemed to be clued in bug 211967 ;)
<ubottu> Launchpad bug 211967 in bzr "bzr smart server should support hooks" [Medium,Fix released] https://launchpad.net/bugs/211967
<LarstiQ> spiv: ah, eet smakelijk! :)
<spiv> LarstiQ: the things I'd check are a) is the plugin that adds the hook actually getting loaded
<spiv> LarstiQ: and b) is that plugin registering a post_change_branch_tip hook?  (post_commit won't work for you, for example)
<LarstiQ> spiv: right, I'll have to read some code to see what 'post_commit_push_pull' actually does
<awilkins> Anyone in Oregon?
 * awilkins is going to be in Bend, OR for a week
<spiv> LarstiQ: IIRC, the only hooks you can rely on in the server context are {pre,post}_change_branch_tip
<spiv> LarstiQ: (and even then only if the client is 1.5+ or so)
<LarstiQ> spiv: 1.14rc2+, so that should be fine
<LarstiQ> spiv: k, thanks
<spiv> LarstiQ: "commit", "push" and "pull" aren't actions that a smart client will trigger on the server, but updating the branch tip is.
<spiv> LarstiQ: (Well, unless a post_change_branch_tip has a hook function registered that then does a push!)
<jml> can I use loggerhead to subscribe to changes to a single file?
<Peng_> jml: Subscribe how?
<Peng_> If you mean the Atom feed, it seems that you can't.
<Peng_> Hm, I thought that was possible.
<Peng_> Oh, cripes. My bzr+http server is running an old copy of bzr.dev thanks to a bug, which means it doesn't know about development6-rich-root. Sigh.
<jml> RSS
<jml> that's what I meant
<Peng_> (Bug 348308, hinthint. :D )
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [Undecided,New] https://launchpad.net/bugs/348308
<mwhudson> jml: finding changes to a file is moderately expensive
<mwhudson> (and possibly loggerhead goes about it in a fairly daft way)
<Talden> cd ..
<Talden> Sigh... damn focus grabbers
<mwhudson> talden@iron:~/porn$
<mwhudson> Talden: where are you in nz?
<Talden> Hamilton
 * mwhudson is in palmerston north
<Talden> Getting cold down there yet?
<mwhudson> night before last was pretty damn cold
<mwhudson> first frost of the year
<Talden> We should be due for the regular morning fog - not yet though.
<spiv> Peng_: time for me to do something about that bug I gues
 * Peng_ hugs spiv
<Peng_> Hmm, I can't branch that branch anyway. Something or other in groupcompress dies.
<Peng_> I can pull, just not branch. :\
<LarstiQ> spiv: it does get loaded, and called, but my section in locations.conf doesn't match
<LarstiQ> spiv: ok, solved, thanks :)
<lifeless> beuno: I am pro dogfooding but: I wouldn't move mainlines to a beta format
<lifeless> beuno: move to rich root now (see my thread on bazaar@ for details of what is involved - its not a no-brainer)
<beuno> lifeless, sure, sounds like a saner upgrade path
<beuno> Peng, mwhudson, are you guys ok to moving to 1.9-rich-root?
<mwhudson> beuno: mmmmmmmmmmmmm
<mwhudson> beuno: you need to upgrade all stacked branches before you update the trunk
<beuno> argh
<mwhudson> beuno: so it's a bit hostile to our part time contributors
<lifeless> mwhudson: beuno: you should both read my posts about this on bazaar@
<lifeless> mwhudson: has to bbe done sometime
<spiv> LarstiQ: oh, right, yes
<spiv> LarstiQ: the URLs on the server aren't so helpful...
<mwhudson> ah man, i'm behind on the list again, after having caught up with it on tuesday
<spiv> mwhudson: that's ok, I hear that rebase is a fast and drawback-free way to catch up!
<mwhudson> spiv: is that the one where i read the most recent mail and delete the rest?
<spiv> mwhudson: not sure, but that doesn't sound like a bad strategy anyway...
<alsuren> I just tried to do a commit, and forgot that there was a 10GB file in the repo
<alsuren> when I hit ctrl-C it just hung, so I killed it using kill
<alsuren> now I'm slightly scared that I could lose a lot of data
<alsuren> or already have: bzr status hangs and grinds away at my hard drive
<bob2> stop, copy the repo if you have enough disk
<bob2> does bzr log show that commit?
<alsuren> no
<alsuren> *plugs in his external hard drive*
<alsuren> once it's copied, what should I do?
<alsuren> bob2: what now?
<james_w> alsuren: I would suspect that status is hashing the huge file
<james_w> if you "bzr rm --keep huge_file" it might work
<pmezard> with bzr1.14, replacing a file with a directory does not generate the same (API level) log output whether i remove the file with 'rm' or with 'bzr rm'. is there any reason to this ?
<alsuren> *removes the lock*
<pmezard> (and remove with 'rm' crashes with < 1.14)
<lifeless> pmezard: start by filing a bug
<pmezard> should it be considered a bug ?
<lifeless> alsuren: move the file out of the tree, so that bzr *can't* read it
<lifeless> pmezard: any crash is a bug
<pmezard> the crash is fixed in 1.14
<lifeless> pmezard: ok, kk
<pmezard> but the fix seems to introduce a different behaviour
<lifeless> what is different in the api ?
<lifeless> alsuren: and after moving it, do 'bzr rm --keep path' to tell bzr not to version it
<pmezard> lifeless: with bzr rm, iter_changes() yields for paths and kind: (None, u'd') (None, 'directory'), then (u'd', None) ('file', None)
<pmezard> lifeless: and with 'rm': (u'd', u'd') ('file', 'directory') and (None, u'd/a') (None, 'file')
<pmezard> lifeless: (ah yes, i am also adding a file to the newly created dir in the same commit)
<MvG> Hi! I'm again looking at https://bugs.launchpad.net/bzr/+bug/248932 for which I wrote http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/56725 about a week ago, without much of a reply so far.
<ubottu> Launchpad bug 248932 in bzr "reconfigure --standalone raises IncompatibleRepositories" [High,Confirmed]
<pmezard> lifeless: to summarize 'bzr rm' yields: remove file, add dir, add file in dir
<pmezard> lifeless: while 'rm' yield: change file into dir, add file in dir
<pmezard> not a big deal, just unexpected
<pmezard> bbl
<lifeless> pmezard: thats expected
<lifeless> pmezard: here is why:
<lifeless> bzr rm removes the fileid - think 'inode'
<lifeless> rm does't remove the fileid
<MvG> jelmer had responded here on IRC while I had been away, pointing out similarity to "bzr upgrade". I'm not sure I agree, so I've got this question for you: Would you expect "bzr reconfigure --standalone" to use current default formats, or rather the format used by the former shared repository? I'd expect the latter, I believe.
<lifeless> so bzr thinks its the same object changing state
<lifeless> MvG: I'd expect the latter
<MvG> In that case, I think there is not overly much code to be shared between "bzr upgrade" and "bzr reconfigure" I think.
<lifeless> I'd say, write any code needed, and we can look for similarities and refactor during review
<MvG> Am I right that symbols starting in an underscore, like Repository._format, are considered private and should not be accessed outside their class?
<lifeless> but upgrade is different - it needs to plan an upgrade path rather than just change state/location
<lifeless> MvG: generally yes. But more specifically read docstrings
<lifeless> MvG: because python has no 'friends' / 'protected' / 'private' we can't write code 'private to bzrlib' substantially more clearly than 'private to module' or 'private to class'
<lifeless> MvG: which is why a lot of _FOO's are used from other modules within bzrlib
<lifeless> the only thing that is definite is that an _FOO should only be used by client code or plugin code if they are willing to track and change their code each time we change it...which we feel free to do on _FOO's.
<MvG> The patch at http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/56725 lists which ones I'm actually thinking of. Grepping the corresponding sources for occurrences in docstrings right now...
<lifeless> MvG: definitely don't add getter/setters for _format
<MvG> OK, saves me some work, so I'm glad. :-)
<lifeless> MvG: a) _format reflects whats on disk, setting it would be semantically odd
<lifeless> and b) its private-to-bzrlib so its fine for it to be used whereever
<MvG> BzrDir._format doesn't reflect what's on disk if there is no repository within the current .bzr dir.
<lifeless> yes it does, because it reflects the fact that the .bzr dir is e.g. a metadir, or an svn control dir or whatever
<MvG> Thus setting that makes sense prior to creation of a non-shared repo.
<MvG> Ah yes, sorry, you are right.
<lifeless> MvG: BzrDir._format.repository_format = foo is what you are doing?
<MvG> Right now, yes.
<lifeless> MvG: you might consider
<MvG> And I want to massage that code so far it has a chance to get merged.
<lifeless> originaldir.open_repository()._format.initialize(new_bzrdir)
<MvG> I do have the repo open... initialize on an existing dir should work? Will try that.
<lifeless> thats the API :)
<lifeless> as long as the target bzrdir has no repository
<lifeless> so 'add a repository to this branch which currently shares one' is:
<lifeless> refs = branch.tags.get_tags.dict.keys() + branch.last_revision_id()
<lifeless> repo = branch.repository._format.initialize(branch.bzrdir)
<lifeless> for ref in refs:
<lifeless>    repo.fetch(branch.repository, ref)
<lifeless> fini
<lifeless> (and it might be nice to supply an appropriate bit of logic to delete the repository in the event of failure)
<MvG> Good point, but not urgent.
<ronald__thompson> Is there something like trac for bazaar instead of svn?
<awilkins> Trace with the bzr plugin?
<awilkins> *Trac
<awilkins> Loggerhead? Launchpad?
<pmezard> lifeless: ok, got it, thanks
<ronald__thompson> oh I didn't know there was a bzr plugin.  Thanks!
<MvG> lifeless: Thanks to your hints I improved my patch: http://rafb.net/p/nTSrQQ25.html
<MvG> Do you think this has a chance being merged? Should I submit a merge request?
<SamB> awilkins: launchpad doesn't seem to have a wiki engine ...
<SamB> (for tickets or wiki pages)
<MvG> How would I figure out whether a formerly lightweight repo requiores rich roots when reconfigured to standalone?
 * SamB hasn't used trac with the VCS support, so wouldn't miss anything in using it with bzr even without a bzr plugin ...
<MvG> Is there some API to delete a repository inside a .bzr dir, or should I access the file system directly if reconfigure fails to import form the shared repo?
<SamB> MvG: lightweight -- I thought that didn't have a repository ?
<awilkins> SamB: There's a wiki for Launchpad dev at dev.launchpad.net, but I'm not sure what relationship it bears to the actual Launchpad code
<SamB> that is, not in it's own directory
 * MvG is waiting for sourceforge to include trac-bzr with their trac setup...
<MvG> SamB: That's the reason I wrote "formerly lightweight": It is lightweight, you want to reconfigure it to a standalone branch, so you have to choose a suitable repo format.
<MvG> lifeless: Up there you wrote "refs = branch.tags.get_tags.dict.keys() + branch.last_revision_id()" for importing. Why do you need the tags, shouldn't they all be ancestors of the last revision id?
<thumper> jelmer: ping
<alsuren> I'm trying to split off a sub-directory into its own repo, and I'm very confused.
<jelmer> thumper: pong
<thumper> jelmer: LP is soon to use bzr 1.14, and I'm wondering which revnos for dulwich and bzr-git we should use for best performance given we aren't using bzr.dev
<alsuren> what is the proper workflow for bzr split?
<alsuren> bzr split proj; bzr commmit; ... what do I need to do in order to make proj a nested branch, rather than just an ignored folder?
<jelmer> thumper: It should be possible to allow bzr-git trunk to be used with bzr 1.14 if we disable some features if bzr doesn't provide them
<jelmer> thumper: but pull from remote git branches won't be possible with 1.14
<jelmer> thumper: (just "fresh" clones)
<MvG> Can I get the selftest to keep its temporary files, so that I can have a look at the file system situation where the error occurred?
<jelmer> thumper: still there?
<lifeless> MvG: no, they don't have to be
<lifeless> MvG: lightweight checkout ? - tree.branch.repository ;)
<lifeless> MvG: I have tosleep, can't chat much mor tonight
<MvG> OK... I might get a merge request on the way in the meantime.
<jelmer> thumper: looks like I was wrong about 1.14, it already has my patch for update_revisions
<thumper> jelmer: sorry, dragged into another meeting
<thumper> jelmer: I can wait for 1.15 to upgrade bzr-git and dulwich
<thumper> jelmer: however I am interested in your suggestions for sizes of git branches that are supportable with bzr-git on 1.14, and 1.15, and future
<max_r> is brisbane-core in bzr.dev ready for testing?
<jelmer> max_r: yes
<jelmer> --development6
<MvG> I've got two merge requests waiting in BB. I'd be happy to answer any questions that arise while I'm here on IRC.
<jelmer> MvG: feedback/review is generally done over email
<MvG> OK. Last time I sent a patch asking for feedback, I got none per mail but some here on IRC, including yours... :-)
<jelmer> I might have a look at the reconfigure one at some point
<MvG> They both concern reconfigure.
<jelmer> sorry, the incompatible revisions one
<MvG> Thanks. That's the more important one for me as well.
<Dejan> hello everybody
<Dejan> i was wondering if bazaar can use some CGI on remote website for a certain repository
<Dejan> ?
<Dejan> is something like that done, does anyone know?
<bob2> Dejan: to do what?
<Dejan> bob2 to push/pull
<bob2> why do you want to involve a cgi?
<bob2> to do writes ovver http without webdav?
<Dejan> yes
<Dejan> and quite often people have only one account to access their hosted website
<Dejan> so they would setup a CGI script there to be used by VCS
<Dejan> there are some who can use this
<Dejan> fossil project for an example
<Dejan> (by Sqlite guys)
<bob2> dunno if such a thing exists
<bob2> there's less pressure in a dvcs, since you only need one person able to push to that repository
<Dejan> true
<Dejan> can i use ftp to push, but users would use http to pull?
<Dejan> because i do not want to give my ftp access details to anyone
<Dejan> :D
<jearl> Dejan: yes you can push via ftp and pull via http
<Dejan> jearl, excellent
<Dejan> ty guys, i will try that
<Dejan> i appreciate your help
<jearl> Dejan: Yes, this makes bzr the easiest (and cheapest) to host of all of the DVCSes.
<Dejan> jearl, i think this CGI i talked about would make it a #1 choice for some users
<Dejan> and it is not difficult to do
<Dejan> if it works via ftp, it should work via HTTP GET/POST methods
<Dejan> I see no reason why such thing would be impossible, and i certainly see why it would be feasible to do
<bob2> someone just needs to do it!
<bob2> or convince your host to do webdav
<jearl> Dejan: It seems to me that I remember something about a bzr+http protocol.  The problem was that it didn't do authentication.
<Dejan> that is another thing
<jearl> Dejan: I might just be imagining things though.
<Dejan> i just guess, but it most likely uses PUSH
<Dejan> it is also a nice thing
<Dejan> but not many web servers do that
<lifeless> Dejan: our server already can work via fastcgi
<lifeless> not much plumbing would be needed t support regular cgi I suppose
<eferraiuolo> I was curious if there are bzr commands you can use to modify a branch.conf file?
<bob2> some
<bob2> not in general
<Dejan> lifeless, care to elaborate?
<jearl> eferraiuolo: What modifications would you like to make?
<Dejan> i use fastcgi too
<Dejan> in fact i use it exclusively
<eferraiuolo> like the name and public url
<Dejan> (lighty)
<eferraiuolo> jearl: I'm trying to setup loggerhead on a big shared repo and realizing that it needs some meta info to be useful
<eferraiuolo> I wasn't sure if I had to modify each branch's branch.conf or could run some commands to add the info I wanted
<bob2> url is set by push --remember, iirc
<eferraiuolo> I was just curious how people add meta info like name public_url to the branch.conf without cd-ing into the dir and editing it manually
<bob2> no need to cd ;p
<bob2> though, if it is neccessary, the loggerhead docs should mention it
<jearl> eferraiuolo: when I configured loggerhead I think I put this information in the loggerhead.conf file.
<jearl> eferraiuolo: it's been a while though.
<eferraiuolo> yeah, that's one place
<eferraiuolo> but not good for people making a clone of my branch
<eferraiuolo> I would prefer to keep the metadata with the branch
<eferraiuolo> jearl: do you know if you can have multiple loggerhead servers running on different ports? It didn't seem possible when I was looking into it
<lifeless> Dejan: http://doc.bazaar-vcs.org/bzr.1.14/en/user-guide/index.html#serving-bazaar-with-fastcgi
<lifeless> eferraiuolo: eferraiuolo often people setup locations.conf with cascading configurations
<lifeless> eferraiuolo: setting=root_setting\nsetting:path_policy=append\n
<lifeless> eferraiuolo: this is in 'bzr help configuration
<Dejan> lifeless, and i use bzr http://.. for it?
<lifeless> http will autoprobe, or bzr+http will assume it is configured and use it
<mwhudson> jelmer's not here!?  gasp
<Dejan> lifeless, so bzr+http assumes cgi??
<Dejan> i thought both are using dav
<lifeless> Dejan: no, it assumes POST
<Dejan> awesome!
<lifeless> DAV is only used by the bzr-webdav plugin
<Dejan> so bzr-webdav:// is the correct URI then?
<lifeless> huh?
<Dejan> which scheme is used if one uses dav?
<lifeless> you've lost me, what are you actually trying to ascertain
<Dejan> also http:// ?
<lifeless> yes
<lifeless> [i think - see the bzr-webdav plugin README though for details]
#bzr 2009-04-24
<mwhudson> Peng_: are you here?
<mwhudson> ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")
<mwhudson> will that not go away until we upgrade the server?
<lifeless> mwhudson: bug 354036
<ubottu> Launchpad bug 354036 in bzr/1.13 "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [High,Confirmed] https://launchpad.net/bugs/354036
<mwhudson> lifeless: oh right
<spiv> Or, possibly, https://bugs.edge.launchpad.net/bzr/+bug/365615 ?
<ubottu> Launchpad bug 365615 in bzr "Random 'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository" [Undecided,New]
<mwhudson> spiv: no, not that one, for sure
<spiv> mwhudson: upgrading the server won't fix affected branches.  When http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090422071133.GE10211%40steerpike.home.puzzling.org%3E lands upgrading the server will cause 1.13 smart clients to push unbroken stacked branches, but that won't help e.g. SFTP or <= 1.12.
<mwhudson> spiv: right, i read the bug report now
<spiv> mwhudson: once 1.14 is out, or the server-side fix is landed and cherry-picked to LP, (so we can hope that most new branches will be ok rather than broken) we should apply Robert's fix script to all the stacked branches on Launchpad.
<lifeless> spiv: welcome to the connected
<spiv> lifeless: :)
<lifeless> spiv: I have a need
<lifeless> spiv: I want a way to say 'dammit this medium is > X'
<lifeless> spiv: and/or to fix the 3 insert stream round trips
<mwhudson> spiv: ok
<mwhudson> spiv: please tell someone when your fix lands :)
<mwhudson> spiv: hang on, 1.14 isn't out yet?
<spiv> mwhudson: still at rc2
<mwhudson> spiv: when will it be out?
<mwhudson> spiv: and how many changes are pending for lp:bzr/1.14 ?
<spiv> lifeless: yeah, that would be good to have!
<spiv> mwhudson: none that I know of, BasicOSX would know more but he just quit IRC...
<lifeless> mwhudson: basicosx knows
<mwhudson> oh hooray
<spiv> lifeless: I can't reproduce your SSH auth problem with 1.14
<lifeless> spiv: you don't see an explicit username passed to ssh?
<spiv> Nope.
<lifeless> thats extremely odd
<lifeless> I'm presuming you have a host that you need such a config entry on for it to work
<spiv> Right.
<spiv> (Several :)
<spiv> Wild guess: does your ~/.bazaar/authentication.conf accidentally have entries for that host?
<mwhudson> fairly terrible, but interesting script for playing with loggerhead memory consumption: http://pastebin.ubuntu.com/156842/
<lifeless> spiv: no such file
<Dejan> ok guys, thanks for help
<Dejan> lifeless especially
<Dejan> \o/
<lifeless> Dejan: anytime
<spiv> lifeless: well, I'm out of wild guesses.
<spiv> lifeless: I'd look at the code, but I'm pretty sure you've already done that...
<lifeless> spiv: I'm hoping vila will
 * spiv nods
<lifeless> spiv: I just deleted the relevant lines from my local bzr and got on with $primary goal
<spiv> lifeless: oh, I see, that patch in your mail is a patch that you'd like reversed?
<lifeless> spiv: that would be one way to get it going
<lifeless> I don't want to under vila's work though, so I'm leaving it open to him to decide how to reconcile the different needs and goals he has
 * spiv nods
<lifeless> s/under/undo/
<spiv> Is there a bug tag for brisbane-core bugs?
 * spiv blinks
<spiv> There's now "official bug tags"
<spiv> I just set all the tags listed on http://bazaar-vcs.org/BugGuidelines as official on LP, except for those that don't seem to be used.
<lifeless> spiv: talk to me about error mapping
<lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/message.py", line 355, in _translate_error
<lifeless>     raise errors.ErrorFromSmartServer(error_tuple)
<lifeless> ErrorFromSmartServer: Error received from smart server: ('FileExists', 'dir')
<lifeless> how do I make that raise that actual error
<lifeless> is it safe to just extend translate-message?
<spiv> lifeless: in remote.py?  Yeah.
<lifeless> smart/message.py
<spiv> lifeless: hmm
<spiv> lifeless: that exception should be ok to do in message.py
<lifeless> how can I tell which are and are not
<spiv> lifeless: many exceptions need to be translated by remote.py, because they need context (e.g. a Branch object) that message.py doesn't have
<spiv> lifeless: although
<lifeless> nearly all exceptions (I'd like to make it all) only stringify their args
<spiv> lifeless: remote.py already translates FileExists!
<lifeless> spiv: the vfs perhaps; I'm calling in from bzrdir.py
<spiv> lifeless: (also, remote.py translates some errors that message.py could do, the evolution is incomplete...)
<lifeless> I vant to vinish zis damn branch
<spiv> lifeless: so shifting the FileExists translation from _translate_error in remote.py to _translate_error in message.py should do what you need.
<lifeless> spiv: for now I've just added to message.py
<spiv> lifeless: or even duplicating if you like
<lifeless> because I don't want to destabilise stuff I'm not working on
<mwhudson_> uh
<mwhudson_> why would list(branch.iter_merge_sorted_revisions()) be [] for a patently non-empty branch?
<mwhudson_> ah because historycache is buggy
<magcius> When trying to push to Launchpad, I get this error:
<magcius> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ejstpierre/%2Bjunk/its2ass/.bzr/branch/lock): Transport operation not possible: http does not supp
<spiv> magcius: you need to run "bzr lp-login jstpierre" (or whatever your username is)
<magcius> spiv, bah, okay.
<spiv> magcius: (assuming you're using a lp:FOO url?)
<magcius> spiv, yeah, thanks, that solved it.
<Peng_> mwhudson_: I'm semi-here.
<lifeless> spiv: getting there
<lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/tests/bzrdir_implementations/test_bzrdir.py", line 1234, in test_format_initialize_on_transport_ex_stacked_on
<lifeless>     repo_format_name=repo_name, stacked_on='../trunk', stack_on_pwd=t.base)
<lifeless> ErrorFromSmartServer: Error received from smart server: ('error', "jail break: 'bzr://127.0.0.1:54060/extra/trunk/'")
<Peng_> mwhudson_: Thanks for merging my branches. :)
<spiv> lifeless: cool
<mwhudson_> Peng_: np, thanks for the branches :)
<mwhudson_> Peng_: feel free to carry on unifiying things onto the LoggerheadConfig object :)
<garyvdm> How can one do graph.iter_ancestry and stop a revision, and be sure that all decedents of that revision have been returned, without the graph having to load the ancestors of the stop revision?
<garyvdm> s/stop a rev/stop at a rev...
<garyvdm> I want to load the parent_map for a ancestors of list of heads to the lca of those heads.
<lifeless> garyvdm: probably you need to modify graph so that you can call lca(heads) and capture the parents
<lifeless> garyvdm: but we memoise parents in various ways, so mmm, no quick answer sorry.
<garyvdm> lifeless: thanks - I'll look at that.
<mwhudson_> hm
<garyvdm> lifeless: I fingered out a way: http://pastebin.com/d584a90fb
<lifeless> spiv: all implemented, same round trip count :P
<lifeless> now to find out why
<lifeless> spiv: ping
<lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/transport/__init__.py", line 1361, in _split_url
<lifeless>     return urlutils.parse_url(url)
<lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/urlutils.py", line 728, in parse_url
<lifeless>     raise errors.InvalidURL('Host empty in: %s' % url)
<lifeless> InvalidURL: Invalid url supplied to transport: "Host empty in: file:///tmp/testbzr-hWEuIa.tmp/bzrlib.tests.blackbox.test_push.TestPush.test_push_smart_stacked_streaming_acceptance/work/local/"
<spiv> lifeless: weird.
<spiv> lifeless: I haven't seen that sort of traceback before.
<lifeless> so
<lifeless> I the host is empty
<lifeless> but why does parse_url /care/
<spiv> Yeah, I've no idea why it cares, or why you'd suddenly bump into that.
<lifeless> I'm bumping into that because our push test stacks on a local path
<lifeless> it stacks [over there] on ../local
 * fullermd just got bit by that add-local-username-to-url thingy   :(
<lifeless> fullermd: reply to the thread then please
<lifeless> fullermd: or perhaps turn it into a bug
<lifeless> and assign to vila
<lifeless> :)
<fullermd> Oh, man, is THAT what happens to you when you log off IRC?
 * fullermd sets up a cron job...
<lifeless> spiv: as soon as I wired up BzrDirFormat.initialize_ex to forward to RemoteBzrDirFormat.initialize_ex when there is a smart transport I triggered that
<lifeless> spiv:
<lifeless> AssertionError: Incorrect length: wanted 18, got 11 for [BzrDir.open, BzrDirFormat.initialize_ex, BzrDir.open, Repository.lock_write, Repository.insert_stream, Repository.insert_stream, BzrDir.create_branch, Branch.lock_write, Branch.set_last_revision_info, Branch.unlock, Branch.get_stacked_on_url]
<spiv> lifeless: nice
<lifeless> there is an issue
<lifeless> we can't upgrade without doing a jailbreak
<spiv> Really?  Why's that?
<lifeless> consider:
<lifeless> local is pack-0.92
<lifeless> remote has a stacking policy pointing at $third-party
<lifeless> our current rule says 'upgrade if the thing pointed at is stackable'
<lifeless> but we can't examine it
<lifeless> I could error with the policy details I guess
<lifeless> but I'm going to punt and do the old hardcoded formats number in this case
<spiv> *nod*
<lifeless> (oh and the client can't examine for us, because the policy is found by the server)
<lifeless> === modified file 'bzrlib/tests/blackbox/test_push.py'
<lifeless> --- bzrlib/tests/blackbox/test_push.py  2009-04-22 02:36:23 +0000
<lifeless> +++ bzrlib/tests/blackbox/test_push.py  2009-04-24 04:58:12 +0000
<lifeless> @@ -201,7 +201,7 @@
<lifeless>          # being too low. If rpc_count increases, more network roundtrips have
<lifeless>          # become necessary for this use case. Please do not adjust this number
<lifeless>          # upwards without agreement from bzr's network support maintainers.
<lifeless> -        self.assertLength(18, self.hpss_calls)
<lifeless> +        self.assertLength(11, self.hpss_calls)
<lifeless>  
<lifeless>      def test_push_smart_stacked_streaming_acceptance(self):
<lifeless>          self.setup_smart_server_with_call_log()
<lifeless> @@ -217,7 +217,7 @@
<lifeless>          # being too low. If rpc_count increases, more network roundtrips have
<lifeless>          # become necessary for this use case. Please do not adjust this number
<lifeless>          # upwards without agreement from bzr's network support maintainers.
<lifeless> -        self.assertLength(22, self.hpss_calls)
<lifeless> +        self.assertLength(18, self.hpss_calls)
<lifeless>          remote = Branch.open('public')
<lifeless>          self.assertEndsWith(remote.get_stacked_on_url(), '/parent')
<lifeless> spiv: ^ woo
<spiv> Woo!
<spiv> lifeless: nice work
<lifeless> theres now a low hanging fruit of one more
<lifeless> the possibly two
<lifeless> the BzrDirFormat.initialize_ex, BzrDir.open, Repository.lock_write,
<lifeless> second and third elements in that sequence
<spiv> Yeah.
<lifeless> I've sent it up for review
<lifeless> schlepping it off to amazon in a second
<lifeless> spiv: small number of failures, will clean up post review/monday
<lifeless> spiv: I started early today, going to head into the city soon
<AnAnt> Hello, I got several packages hosted in the same branch: lp:sabily-artwork
<AnAnt> is it possible to migrate each package to a separate branch, keeping along the history ?
<thumper> I wonder if the split command does that
<Peng_> That's what the split command is for. Whether it's safe to use is another question.
<AnAnt> how ?
<Peng_> AnAnt: bzr help split :D
<Peng_> But you might have to upgrade the branches to an experimental format.
<AnAnt> it says : bzr split tree
<AnAnt> ok, I'll look at it
<AnAnt> thanks
<jelmer> thumper: hi
<thumper> hi jelmer
<jelmer> thumper: So, current bzr-git trunk should now work with bzr 1.14 proper
<thumper> fantastic
<thumper> how does that relate to dulwich?
<thumper> does that matter?
<thumper> or do we just take tip?
<jelmer> You'll need the tip from dulwich as well
<thumper> cool
<thumper> I'll look to get it into LP ASAP
<MvG> Hi! Is there some huma readable specification or documentation of the bzr smart protocol?
<MvG> In particular, does the command allow removal of stuff like a bzr.backup directory from the remote file system?
<MvG> Because I've upgraded a remote repo once, and trying to upgrade yet again via bzr fails as bzr.backup already exists, and removing that dir fails as ssh access is restricted to the bzr server.
<Peng_> MvG: Sure, it supports VFS access, so you can do whatever you want.
<MvG> VFS = virtual file system? Virtualized by whom?
<Peng_> MvG: bzr
<Peng_> MvG: It might be easier to use hitchhiker (sort of like a CLI FTP client, only for the bzr smart protocol) https://launchpad.net/hitchhiker
<MvG> Sounds good. Will have a look.
<MvG> Yes, that's exactly the tool I needed. Thanks ever so much!
<thumper> there is a bug about the upgrade dirs
<thumper> the upgrade command should be able to remove old backup dirs
<MvG> Would make sense.
<MvG> At least if it were sufficiently sure the upgrade went well and could be reverted if need be.
<MvG> s/reverted/reversed/
<mwhudson> thumper, jelmer: yay
<thumper> hi mwhudson
<thumper> mwhudson: do you want to do the honours?
<thumper> mwhudson: if not, I'll get abentley or rockstar to
<thumper> when they start their day
<MvG> BTW: I've got two merge requests waiting in BB. So if anyone dev around here feels bored, I would appreciate votes on those.
<MvG> I'll accept comments evenm from non-devs. :-)
<mwhudson> thumper: not really at this time on a friday night
<thumper> mwhudson: I guessed as much :)
<Peng_> Whatwhat?
<thumper> what?
 * Peng_ babbles incoherently and falls asleep
<poolie> the bzr wiki is having some trouble; IS is working on it
<garyvdm> Hi - is it possible to ignore a file in a branch, with out committing a change to the branch? I.e. I want the ignore to only be for my copy of the branch.
<g0ph3r> garyvdm: regarding your earlier question: AFAIK you can configure a global ignore list in your bzr settings. ("global" in this case means that you do configure it for all of _your_ branches, and that this is not visible to others)
<g0ph3r> i don't know if this is the best way, though
<ignas> hi
<ignas> is there a way to find a commit in a shared repository?
<ignas> bzr rebase messed up the history of my branch and I have a lost commit now somewhere
<ignas> that I would like to recover
 * SamB mumbles something about --heads
<hmeland> ignas: I think "bzr heads" from bzrtools can help.
<SamB> oh, is that what it was
 * SamB knew there was a reason he was mumbling
<ignas> i am not sure it will help me now... because I have performed a bunch of operations to recover the state on the branch
<garyvdm> ignas: bzr heads --dead
<garyvdm> find the revid of the head you want
<SamB> as long as none of them involved garbage collection, you should be fine
<garyvdm> bzr pull . -r revid:... --overwrite
<SamB> (garbage collection of the repository, that is ;-)
<garyvdm> SamB: the only way to do that with bzr is to create a new repository, branch, and delete the old one.
 * SamB thought there was some command for it in bzr.dev
<garyvdm> Oh
<SamB> I could be wrong
<mwhudson> i think there's a plugin somewhere or something
<ignas> SubversionException: ('Unable to open an ra_local session to URL', 180001)
<ignas> ouch
<SamB> ignas: what URL ?
<ignas> don't know
<SamB> ouch
<ignas> the message is not giving any
 * SamB wonders where jelmer is
<SamB> you should report it as a bug on subvertpy, I think, that the URL isn't in the message anywhere
<ignas> first - find the commit and make another release, sorry
<ignas> will do while waiting for PPA to build a package ;)
<ignas> Samb, hmeland, GaryvdM: thanks, that worked
<SamB> ignas: what'd I do besides mumble misleading information and attempt to reassure you that your commit was probably still there?
<ignas> SamB: on further review, probably not much ;)
<ignas> but still, being a part of the community counts ;)
<ignas> how do I only merge last 2 revisions from a branch?
<GaryvdM> bzr merge -r ..-2
<GaryvdM> or bzr merge -r -2..
<GaryvdM> I can never remember which way
<ignas> -2.. remove most of the changes from the checkout
<ignas> and ..-2 still includes changes from earlier
<GaryvdM> bzr merge -r -1..-2 ?
<thumper> that'll do a reverse merge (I think)
<thumper> it will apply the reverse of -2..-1
<ignas> yeah, though if I want 2 last revisions it seems i have to do -3..-1
<xiaohui> lifeless, is there a default ssh login name for using *bzr push bzr+ssh://bazzar.lauchpad.net/~MY_LAUNCHPADID/PROJECT/name*
<xiaohui> When I use it , it shows me that Permission denied
<james_w> your local username is the default
<james_w> you can do MY_LAUNCHPADID@bazaar.launchpad.net
<james_w> if you do "bzr lp-login MY_LAUNCHPADID" and the do "bzr push lp:~MY_LAUNCHPADID/PROJECT/name" it should work
<xiaohui> I am behind the firewall
<xiaohui> james_W, I have to use the URL for push and pull
<xiaohui> james_w, It works now,thank you
<phinze> hmm on bzr switch --force of a lightweight checkout to a completely different branch, i get "Conflict: can't delete features because it is not empty.  Not deleting."
<phinze> any way i can tell bzr "yes yes just nuke this copy and make it like that branch"
<phinze> rm -rf + bzr resolve is my best solution currently; just wondering if there's something i can do up front that's faster
<phinze> and perhaps those here would know if maybe at the end of the day it would be faster just to kill the lw-checkout and make it again
<phinze> rather than switching
<ignas> don't know really, not using lw checkouts since I found out that a simple checkout is actually faster to do with my connection
<ignas> lw checkout saves bandwith (for me - only a bit), but takes longer
<jml> lifeless: I've upgraded the tribunal branch anyway.
<ignas> and if you are working on more than one branch - shared repository will take less time and bandwith than 2 lightweight checkouts
<ignas> at least for me
<xiaohui> when I push to lp it returned the *pipe broken ERROR*
<xiaohui> and the connection is closed by remote host
<xiaohui> what should I do then?
<poolie> xiaohui: maybe your ssh key is not registered with launchpad
<xiaohui> poolie, I have put my ssh public key to the launchpad
<xiaohui> and the progress showed that has push 2/5
<xiaohui> I use bzr push again, it directly come to 2/5 amd stoped
<max_r> I have question about bzr
<max_r> I dir bzr branch lp:aa, did bzr pull for some time
<max_r> the commited local changes and it forces me to do bzr merge && bzr ci -m"merged" all the time
<max_r> as far as I understand git allows simply use git pull even after local changes get commited, with forcing merge only on conflicts
<max_r> could  I get same beheaviour for bzr?
<james_w> max_r: not currently, no
<rockstar> thumper, did you get your review?
<max_r> james_w: is it planned? quite bad that simple operations takes twice as much steps
<james_w> I don't know of anybody working on it
<max_r> james_w: as I understand it is more UI problem than problem of repository or other low level stuff? I saw UI redesign planning for 2.0. Is it finalized yet?
<james_w> UI redesign is planned for 3.0
<james_w> I don't think adding an option to make it do that is something that requires a UI redesign though
<max_r> and what is approximate eta for 3.0?
<max_r> In bzr help pull I see:
<max_r>   If branches have diverged, you can use 'bzr merge' to integrate the changes
<max_r>   from one into the other.  Once one branch has merged, the other should
<max_r>   be able to pull it again.
<max_r> It seems rather strange
<james_w> 3.0 in a 9 months or something
<max_r> I merged branches, but I couldn't pull any more
<james_w> I don't know if a timeline has been decided
<james_w> after the merge you will be able to pull the other way
<max_r> seen now "bzr merge --pull" what it does?
<james_w> that doesn't do what you want
<james_w> that will fast-forward where possible, which is another thing that "git pull" does that "bzr merge" doesn't
<max_r> I need something like "bzr merge --commit-if-no-conflicts", right?
<james_w> yep
<max_r> could it be done as plugin?
<james_w> yep
<max_r> is relativly hard?
<max_r> or easy?
<james_w> shouldn't be too hard
<max_r> is there any simple sample plugin to base on?
<james_w> actually, it may not be that easy in a plugin
<max_r> why? It looks easy as bash script, just running "bzr merge && bzr ci -m 'merged'" with some error checking on the first step to see if there was conflicts
<james_w> because you don't want to open the objects more than once
<james_w> and you don't want the tree to be modified between the merge and commit
<james_w> that's probably the basic thing that is needed: http://paste.ubuntu.com/157278/
<james_w> it needs tests and polish though
<max_r> any chance it go into 1.15?
<max_r> and what is more correct "pull --merge-if-needed" or "merge --commit-if-no-conflicts"?
<james_w> that patch won't go in 1.15
<james_w> a better version could if it passed review
<james_w> and those two commands mean different things
<max_r> james_w: could you please explain difference?
<james_w> whether pull does something when the branches have diverged, or tells you to use merge is different to whether the a merge will commit if there are no conflicts
<james_w> and the first option is already there, it's just spelt "merge --pull" instead of "pull --merge"
<max_r> and how "pull --merge-if-needed" ("merge --pull" in bzr language) differs from "get all changes from that branch, and apply it locally" which as I understand is "merge --commit"
<max_r> ?
<james_w> pull means "make my branch the same as that one"
<james_w> which doesn't work if you have diverged
<james_w> merge means "merge my changes with theirs"
<james_w> and when you do that you end up with something new, so you may want to check it before you commit, as the merge can't do everything
<max_r> got it, i thought pull means "pull all changes from that branch"
<james_w> nope
<james_w> "pull" is different in git and bzr
<max_r> which is quite confusing
<MvG> I hope I don't start to annoy you yet, but I'm again trying to interest devs into reviewing my two open merge requests, related to reconfigure and bug 248932. Anyone willing to have a look? I'd like to get this off my head.
<ubottu> Launchpad bug 248932 in bzr "reconfigure --standalone raises IncompatibleRepositories" [High,Confirmed] https://launchpad.net/bugs/248932
<AnAnt> which is better way to use bzr:
<AnAnt> 1) bzr co <URL> , do some changes, bzr ci
<AnAnt> or 2) bzr branch <URL> , changes, bzr ci, changes bzr ci , .. , bzr push  ?
<james_w> AnAnt: I prefer 2, but they are equally valid
<AnAnt> james_w: ok
<AnAnt> I tried bzr split, but I don't think it works
<AnAnt> I have 3 packages in the same bzr branch
<AnAnt> I want to have separate branches for each package, yet I want to keep the bzr history of each package, is that possible ?
<james_w> split would be the way to do it, but it may not do what you expect
<james_w> it will keep the full history in each branch
<AnAnt> how ?
<AnAnt> I just done this: bzr split <packageone>
<AnAnt> then cd <packageone>
<AnAnt> bzr push file:///tmp/test
<AnAnt> I got this: bzr: ERROR: Not a branch:
<AnAnt> oh, I got an error actually when I do a bzr split:
<AnAnt> bzr: ERROR: To use this feature you must upgrade your branch at file:///tmp/sabily-keyring/.
<james_w> ah
<james_w> not that helpful of a message
<james_w> "bzr upgrade --default-rich-root" is probably what you want
<AnAnt> k
<AnAnt> ok, cool
<AnAnt> btw, there's no --default-rich-root option
<AnAnt> I used --rich-root-pack
<BasicOSX> ja1: Bug 355238 really set to Milestone 1.14rc2?
<ubottu> Launchpad bug 355238 in bzr "TypeError upgrading branch to gc-chk255-big" [Undecided,Fix released] https://launchpad.net/bugs/355238
<ja1> BasicOSX: I'm pretty sure the bug listed there was fixed for the rc2
<BasicOSX> thanks for quick response, research further
<jam> BasicOSX: rev 4250 on bzr.1.14
<jam> 4250 Canonical.com Patch Queue Manager 2009-04-19 [merge]
<jam>      (jam) Tweaks to the new --dev6-rich-root format support.
<jam> 4251 Canonical.com Patch Queue Manager 2009-04-19 [merge]
<jam>      (tanner) prepare-1.14rc2
<jam> at least according to *my* branch of 1.14, my patch landed before rc2
<AnAnt> hmmm, problem with splitting, is that I can't revert to older revisions !
 * BasicOSX blinks 
<BasicOSX> Who needs search when you have jam ! :-)
<AnAnt> oh, I ccan
<AnAnt> ok, thanks !
<jam> well, as i just did the searches myself, I knew where to look
<dereine> hi, i want to use bazaar together with a "checkout" on ftp, how can i do this
#bzr 2009-04-25
<Evanlec> Would anyone mind pointing out some of the advantages of Bazaar over other dvcs's ? I primarily use Git, but due to its lack of Windows compatibility options I've been experimenting with Mercurial (and not liking it very much)...will Bazaar give me a workflow similar to Git ?
<bob2> the major difference is that bzr doesn't bundle checkouts, branches and repositories into one thing
<Evanlec> bob2: and git does? can you elaborate on that?
<Evanlec> bob2: hmm, i'm just reading now, it appears that branches want to go in seperate directories...this is one thing about mercurial i didn't like
<bob2> mercurial does it in a bizarre way, afaict
<bob2> bzr's is very simple: a branch is a directory with some stuff in it
<davidstrauss> bob2: I don't think that's an accurate depiction of bzr vs. git
<bob2> davidstrauss: fair enough
<Evanlec> bob2: well people in #mercurial tell me they prefer a workflow where you have multiple clones of a reposiitory (each in their own dir)
<davidstrauss> bob2: Using shared branch storage with branches in immediate subdirectories is basically the same
<Evanlec> hm
<bob2> except more annoying
<davidstrauss> bob2: the depends on what you're doing
<davidstrauss> that*
<Evanlec> I kind of liked git's "transparent" branches, where you could do everything from only 1 dir
<bob2> anyway
<bob2> bzr has repositories, and bzr switch
<davidstrauss> Multiple branches per directory support will likely be in core eventually because it's a foundation of the Looms module.
<Evanlec> in fact thats the major thing keeping me from liking mercurial, i dont want my project folder littered with extra dir
<bob2> well, that's unrelated to bzr
<bob2> repository can go anywhere
<bob2> one checkout can move amongst branches with 'bzr switch'
<Evanlec> i run my development server out of the folder i'm using, so if i switch branches, i would have to restart the development server in that other folder, which is not ideal
<davidstrauss> bob2: Yes, and you can bzr switch using local branches as the source, which keeps your working tree in one directory
<Evanlec> if that makes any sense
<bob2> yup, which works well
<bob2> Evanlec: nope
<Evanlec> i do web development
<bob2> Evanlec: bzr switch is the same as git co - change this working copy to point at another branch
<Evanlec> bob2: oh
<bob2> Evanlec: the only difference is the branches aren't hidden in .git
<davidstrauss> Evanlec: The more fundamental differences between bzr and git are the commit interface, the merge model, and file vs. content tracking
<Evanlec> bob2: what do you mean hidden ?
<bob2> Evanlec: might be easier to just try out bzr
<Evanlec> bob2: yea, i spose
<Evanlec> does bzr have an equivalent of the git rebase command?
<Evanlec> that is also something sorely lacking in mercurial
<davidstrauss> Evanlec: yes, though an extension, though i argue it's unnecessary
<Evanlec> they made an extension that does it, but its really not as good as gits
<davidstrauss> Evanlec: http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar
<Evanlec> davidstrauss: i don't understand how it could be unnecessary
<davidstrauss> Evanlec: then read my post :-)
<Evanlec> davidstrauss: the link you just posted u mean?
<Evanlec> k
<davidstrauss> Evanlec: yes
<bob2> davidstrauss: I don't find the latter two matter much ime, but the index is an important difference, true
<Evanlec> reading
<bob2> Evanlec: anyway, in bzr, a branch is a directory, not a magic file in .git/refs
<davidstrauss> Evanlec: also, bzr supports the checkout workflow, which git does not
<bob2> Evanlec: a checkout points at a branch (and can move amongst them with bzr switch)
<bob2> Evanlec: sometimes the checkout and branch are the same dir, sometimes not
<Evanlec> a branch is a directory...but i can use bzr switch in the same dir and not notice any directory 'change', like as if i didn't 'cd /some-new-branch'
<davidstrauss> Evanlec: yes, though you would do so on a checkout directory
<bob2> branch != checkout
<bob2> checkout = working set of files
<bob2> branch = pointer to a particular revision
<Evanlec> ah k
<bob2> repository = big bag of revision data
<Evanlec> so a branch is just a modified version of the same checkout ?
<Evanlec> so to speak
<bob2> they can all be in the same dir (e.g. when you do 'bzr branch http://blah/blah') or not
<davidstrauss> bob2: checkout is possibly the most poorly named command. checkout can create a checkout or it can populate the working tree of a branch
<bob2> not at all
<davidstrauss> bob2: so, "checkout" in a branch creates a working tree, but you run "bind" if you want to turn it into a checkout :-/
<davidstrauss> bob2: I think the former usage needs to go away
<bob2> a branch is like a branch in git - it points at a partinaclr revision in the repository
<Evanlec> yea
<Evanlec> in git you just 'checkout' branches
<Evanlec> and thats about all checkout does
<Evanlec> altho, you can also check out a revision
<Evanlec> i dont understand why this is saying that gits rebase throws away history
<Evanlec> to me, it seem like ti just adds to history
<Evanlec> and then sticks your commits in that branch on top
<Evanlec> i'm only doing primarily 2-person workflow here, i've no need to share my local branches
<Evanlec> so rebase works fine for me
<bob2> outside of git-land, people just don't bother
<bob2> you commit, commit, commit, then merge
<Evanlec> what if the mainline trunk moves ahead while you're commiting ?
<lifeless> Evanlec: you merge it in and commit
<Evanlec> merge the mainline into your exp branch ?
<lifeless> Evanlec: naturally
<Evanlec> but then when you merge your exp branch into mainline you get these out-of-place commits (of the merges in the toher branch)
<lifeless> Evanlec: so, bzr has rebase, and you can use it.
<Evanlec> does it behave exactly teh same as git rebase ?
<lifeless> close enough, as I understand it
<lifeless> I don't rebase in either tool, so I can't really say
<Evanlec> i was dissapointed with mercurials rebase
<lifeless> to understand the concern some people have with rebase, consider a change in mainline that breaks your code
<lifeless> if you rebase on top of mainline, your commits are now broken
<lifeless> even though they may not have conflicts
<Evanlec> you mean when i merge back into mainline from my branch ?
<lifeless> if instead you were to merge mainline into your branch, and fix it as you merge, you don't have that problem - every commit still works.
<Evanlec> or just when i rebase from mainline
<Evanlec> ah i see
<lifeless> Evanlec: when you rebase from mainline
<Evanlec> yea that makes sense now
<lifeless> so when you rebase, and this happens, you have to go back to your first commit and rewrite it to work against whatever rev of mainline you grabbed
<lifeless> and the next and so on
<Evanlec> so you dont haev any problem with these extra 'merge' commits when you merge mainline into your own branch ?
<lifeless> this is neither good or bad, its just something you have to do with a rebase workflow.
<lifeless> Evanlec: no problem at all; bzr puts them off to the side and [in recent versions] doesn't show (any commit that isn't itself a mainline commit) by default
<Evanlec> well the case you speak of sounds bad to me
<Evanlec> lifeless: interesting
<Evanlec> i was thinking that mercurial was going to be a 'simpler' version of git
<Evanlec> but come to find out, its actually more complex for me because of the strange way i have to do things im used to doing in git
<lifeless> bzr is also quite different to git
<Evanlec> yea
<lifeless> and trying to use your git workflow in bzr won't be the easiest thing
<Evanlec> i guess i was hoping i could find a git clone (no pun intended) that was easier to use on Windows (for my new partner)
<lifeless> but the workflow people use with bzr is very easy and natural
<lifeless> just different
<Evanlec> lifeless: thats what mercurial people said, but it didnt seem very easy, and certainly not natural, to me
<lifeless> was git your first DVCS?
<Evanlec> yea
<Evanlec> in fact my first vcs really
<Evanlec> havent even used svn really
<lifeless> so with bzr the general thing is to just do your development
<lifeless> and not to spend a lot of time making the history pretty
<Evanlec> heh
<Evanlec> well not that my git history was very pretty
<lifeless> rather we try to have bzr report effectively
<lifeless> but thats what trying to not record merges and so on is all about ;)
<Evanlec> everytime my local branch diverged from the remote, would get these merge commits (without asking for them) for a silly merge when they diverged by only 1 or 2 commits
<Evanlec> so someone suggested i just use rebase instead of merge
<Evanlec> and that seemed to solve that problem
<lifeless> it does remove the merge commits
<lifeless> but it has other tradeoffs
<lifeless> anyhow,
<lifeless> we have rebase
<lifeless> I have to head off for a while
<lifeless> enjoy!
<Evanlec> alright thanks
<davidstrauss> Evanlec: So, did you get your question adequately answered?
<Evanlec> davidstrauss: yes i suppose, thank you
<AnAnt> Hello, is there an impact if I upgrade the bzr branch format to --rich-root-pack or --rich-root ?
<xiaohui> hey, I have a question about the bzr push
<xiaohui> I am working behind the firewall , I need a proxy to access the web
<davidstrauss> xiaohui: ok
<xiaohui> when I solved the problem of using ssh through the proxy and bzr push it
<xiaohui> I use *bzr push bzr+ssh://bazaar.launchpad.net/~MY_LAUNCHPAD_ID/PROJECT/name* and it show the progress bar
<xiaohui> But it always stopped at the "coping inventory texts 2/5"
<xiaohui> and some minutes later , it said that *connection was closed by the remote host , pipe broken ERROR*
<bob2> does ssh reliably work otherwise?
<lifeless> AnAnt: yes there is, its a one way upgrade *and everyone that pulls or merges from you has to do it too*
<AnAnt> lifeless: doesn't the upgrade happen if they pull ?
<xiaohui> now, the progress show that *coping content texts*
<mwhudson> will be life fail to be enriched in any way if i don't read that huge rebase thread?
<Peng_> I just moved the VM I run Loggerhead on from UML to a faster machine with Xen. I should've done some benchmarks beforehand. :\
<mwhudson> Peng_: did you see my branches targeted at using less ram?
<Peng_> mwhudson: Yeah.
<Peng_> Well, one.
<Peng_> My eyes glazed over at the tuple unpacking and I didn't try it. :P
<Peng_> Oh, right, the other was already merged.
<mwhudson> :)
<Peng_> Hmm. Your other changes might've brought my normal memory usage from almost 125 MB to almost 115.
<Peng_> But it's only been a day or two, and I've crashed the machine twice and rebooted it two more times, so I can't say anything for sure.
<Peng_> mwhudson: So, do you want me to test anything? If so, what?
<robin_dewd> saved for posterity. I found it a pretty good short discussion
<robin_dewd> http://www.deze9.com/jp/wiki/?p=to_rebase_or_not_to_rebase
<xiaohui> could some one of you  give an URL of ssh server  for testing my ssh is work behind the firewall? Thank you
<mwhudson> Peng_: i guess testing the branch works would be cool
<mwhudson> Peng_: have you had problems with memory consumption?
<Peng_> mwhudson: Define "problems". I've never woken up to find it swapping to death.
<mwhudson> Peng_: well we have on launchpad, so i guess you haven't :)
<Peng_> mwhudson: Which branch? less-stupid or persist-_rev_info?
<mwhudson> Peng_: persist-_rev_info contains less-stupid, so testing it would be more revealing i guess
 * mwhudson afk
<mwhudson> Peng: email me any problems you find :)
<Peng_> mwhudson: Oh god. The AbsentContentFactory exception attacks.
<Peng_> Anyway, unimportant.
<Peng_> mwhudson: Well, I'm running persist-_rev_info now. So far, nothing is exploding. :)
<mlh_> you've made reddit: http://www.reddit.com/r/programming/comments/8fbk6/to_rebase_or_not_to_rebase_bzr_irc_log/
<Waldir> Hi there. I never used version control before, and after some investigation I'm now deciding whether I should try bazaar, mercurial or plain svn. I wanted to try out each before deciding, and found out that bazaar is already installed in my ubuntu machine. can someone help me getting started? note: I'm new to linux as well
<dereine> Waldir: do you have a project or do you want to start from scratch?
 * dereine also startet only a short time ago
<Waldir> I was wondering whether I could test it on my website
<dereine> ok then you have a folder?
<Waldir> er... where, on the server, on my machine? i currently have the site both online and in my machine
<dereine> you can do both
<dereine> its decentral so you don't have to worry about remote, you can work offline without knowing anything about the www
<Waldir> so I read. I don't know how to put that theory in practice though :P
<dereine> so you have a folder
<huf> http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
<Waldir> ok, i'm installing the bzr-gtk so I have a GUI. huf, thanks, but I prefer not using the command line because the other people who will be working on this are even less familiar with the vcs than I am... I want the easiest possible, painless way to get started (assuming there is one :) )
<Waldir> dereine: yes, please continue
<dereine> Waldir: uh, not commandline ;) thats hard i will start bzr-gtk
<huf> Waldir: that is the command line
<Waldir> lol... it's not for me, its more for the others. even though most of them will probably be using windows anyway..
<huf> see, you have to understand what you're doing, and the gui tools only help to hide that
<huf> oh, well... is there a better client for windows than tortoisebzr?
<dereine> shouldn't the gtk and the qt version also works?
<huf> ooh
<Waldir> huf: I know but I was given very little time to choose a vcs and I can't have them wasting too much time learning to wotk with it. some have already used svn+tortoise (including me) but that's all
<Waldir> huf: anyway I read a lot about vcs in the last two days so I do understand the basics
<Waldir> (i guess, lol)
<dereine> ok
<dereine> click to your folder
<Waldir> ok
<dereine> then menu -> branch -> intialize
<dereine> current folder
<Waldir> it's something like /var/www/mysite.com right?
<dereine> you can use every folder
<dereine> so if you did this you can add files
<Waldir> just making sure :)
<dereine> arg gui, its so "hard" to use ^^
<Waldir> lol :(
<Waldir> you mean the context menu, with right-click?
<dereine> yes
<dereine> there you can add files
<Waldir> cause I can't find "branch" anywhere...
<dereine> if you are ready with adding some files
<dereine> see http://imagebin.ca/view/x8PyaX.html
<Waldir> thanks. but that's not the context menu, it's the menu bar on top, right? (on eihter case, there's no "branch" anywhere... sould I start bazaar somehow first?)
<dereine> do you have olive?
<Waldir> i found it now
<Waldir> (olive)
<Waldir> lol I thought it integrated with nautilus somewhat like tortoise
<Waldir> hmm I clicked the applications -> programming -> olive menu item it but nothing happened..
<Waldir> nevermind i tried again and it worked this time :/
<Waldir> ok, I initialized the directory. the files that are inside it are added by default? or do I have to add them manually?
<dereine> no you have to add them
<Waldir> ok
<Waldir> oh, there's no multiple selection! I have to add them one by one right?
<Waldir> ok, I added three files. there are some folders, can I add them as well or do I have to open them and add each file?
<LarstiQ> no clue, I just do bzr add; bzr ci -m 'Initial import'
<LarstiQ> Waldir: you should be able to add folders
<dereine> ci?
<LarstiQ> dereine: commit
<dereine> ah i have to learn the shortcuts
<Waldir> LarstiQ: thanks :)
<Waldir> ok, what now?
<LarstiQ> Waldir: commit it
<Waldir> am I supposed not to see the output of individual files inside the folders I added?
 * LarstiQ blinks at Waldir 
<LarstiQ> Waldir: what do you mean?
<Waldir> the files and inside the folders are showing status "unknown". the others in the root level had "added", and after the commit, "unchanged"
<LarstiQ> Waldir: ah hmm, that seems to mean the gui does not recursively add files in a dir if you add the directory.
<Waldir> I mean that the commit dialog showed something like "=== added file 'index.php' and then a diff, for each file in the root level. but for folders only showed "=== added directory 'app'" and nothing else
<Waldir> yes, it seems so
<Waldir> the tortoise client is able to do the recursion, I hope?
<Waldir> I believe I'll be the only one using linux for this project so if I have to use command line it shouldn't be too much of a problem
<Waldir> hello?
<dereine> try it out :)
<LarstiQ> Waldir: I don't know if it can. If you could try it out and report bugs that would be nice.
<LarstiQ> Waldir: it should, imho.
<Waldir> I would love to submit bugs, it's just that I have external pressure to do this fast :)
<Waldir> I'll try it in my windows VM
<Waldir> oops.. it seems this version of virtualbox wont work with jaunty :(
<Waldir> i'll ask my colleague to do it on his win machine
<dereine> how can i checkout a branch to a ftp?
<LarstiQ> dereine: it isn't clear to me what that would mean. Can you elaborate?
<Waldir> LarstiQ, dereine: ok, we installed bazaar+tortoisebzr on the win pc. how can i update my own files here with what he has there? (note: they are exactly the same)
<LarstiQ> Waldir: for sharing committed revisions, pull/push/merge
<Waldir> yes but he heas to put that on somewhere I can access from my machine, right? he has his own website, can we use that, via ftp or http?
<LarstiQ> Waldir: yes, any place you can both reach should do
<LarstiQ> Waldir: sftp is preferable to ftp though
<LarstiQ> Waldir: (you could also use `bzr send` to email revisions across)
<Waldir> LarstiQ: I think the centralized workfow could work best, since we are more than two
<LarstiQ> Waldir: he could do something like, `bzr push sftp://webhost/~/public_html/branch` and then you could `bzr pull http://webhost/~friend/branch`
<LarstiQ> Waldir: ok, then you will need a location all of you have write access to
<LarstiQ> gah, running out of power already
<Waldir> yes, that can be arranged. but doesnt sftp require authentication? will those commands work just like that?
<LarstiQ> Waldir: you'll need credentials. If you have an appropriate ~/.ssh/config or remote user same as local, and a key, it will work just like that.
<LarstiQ> otherwise it will prompt for a password
<LarstiQ> Waldir: you can also include the username in the url if you want
<LarstiQ> it isn't needed per se
<Waldir> LarstiQ: ok :) now, does the push command need to be done from the directory where the repository is right now in the window machine? that is, do i have to cd there first?
<Waldir> by the way, tortoise does the recursive add and commit ^^
<LarstiQ> ah, good about the add
<LarstiQ> Waldir: bzr needs to know which branch you are pushing. Doing the push from within the branch would do that, or you could use -d to designate another branch.
<LarstiQ> Frequently you want to push after a bunch of commits, so that then turns into `bzr ci; bzr ci; bzr push;` from the same branch.
<Waldir> ok i didnt get this last one
<Waldir> why would i commit twice?
<LarstiQ> Waldir: `*hack hack*; bzr ci; *hack hack*; bzr ci; *decide to publish*; bzr push` would be less terse.
<Waldir> ok, I got it :)
<Waldir> I'll try this
<Waldir> LarstiQ: i just connected to my ftp server using the places menu (connect to server). However, using olive it keeps asking for my password. Can it be because I am already connected with this username?
<Waldir> LarstiQ: ok, I signed off from the ftp in nautilus, then tried the command line. the error returned was: bzr: ERROR: Target directory ftp://my-web-host/~/public_html/branch  already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway.
<LarstiQ> Waldir: I pretty much only know the commandline interface well enough.
<LarstiQ> Waldir: for that last error, it is saying the directory already exists while it didn't expect that. You can tell it to go ahead by supplying that option.
<Waldir> perhaps it already existed because of the previous attempt using olive? even though it didnt accept my password :/ I'll try with that option
<Waldir> LarstiQ: FTP temporary error: 451 /httpdocs/branch-name/.bzr/repository/upload/7wwumk8piyp4jgva3o2k.fetch: Append/Restart not permitted, try again. Retrying.
<LarstiQ> Waldir: ick, you have a terrible ftp server there.
<Waldir> lol
<Waldir> too bad my friend went to lunch, I can't try his ftp server :/
<Waldir> but this was already good for a start. I suppose tortoise will allow push and pull from the GUI so i should be able to convince the rest of them to use this :)
<Waldir> hmmm
<LarstiQ> Waldir: it certainly should.
<Waldir> perhaps I can try via http?
<LarstiQ> Waldir: note that with more people working on the branch, divergence will start to occur. At that point you will also need the merge command next to pull.
<LarstiQ> Waldir: pulling, yes. But http itself is not a writable transport so push doesn't work on that.
<Waldir> yes, i was afraid you'd say that :) about the merge, doesnt push/pull try automatic merge?
<LarstiQ> Waldir: if your http server supports WebDAV you can use the webdav plugin
<LarstiQ> Waldir: no, they do not.
<Waldir> but they'll tell me that I need to use merge if there is a conflict, right?
<LarstiQ> Waldir: yes.
<LarstiQ> Waldir: since you're going with a centralized style, you may also consider using checkouts instead: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#team-collaboration-central-style
<Waldir> I will try this out later when I get the pull and push working. about the WebDAV, I don't even know what that means :P
<LarstiQ> Waldir: that way you would not use pull/merge/push but update/commit for regular operation
<Waldir> hmmmm
<LarstiQ> Waldir: I'm guessing no then ;)
<Waldir> lolol
<Waldir> thanks for the link, I'll read that
<LarstiQ> Waldir: your host does probably support sftp instead of ftp, sftp is a waaaay nicer protocol
<Waldir> hmmm. let's see then
<Waldir> ssh: connect to host ftp.webhost.com port 22: Connection refused
<Waldir> bzr: ERROR: Unable to connect to SSH host ftp.webhost.com; EOF during negotiation
<LarstiQ> Waldir: perhaps another hostname than ftp.webhost.com for ssh access? But maybe they don't offer ssh (boo!)
<Waldir> (obs: I'm editing off my website's url cause it's so embarassing right now :P I have a redesign almost ready that will hopefully not make eyes bleed xD)
<Waldir> I'll check the email they sent me when they set up my hosting
<LarstiQ> hah, I have a high tolerance for eye bleedage ;)
<LarstiQ> k
<Waldir> perhaps there's something there
<LarstiQ> Waldir: if you're going to deploy websites with bzr, I suggest you look into the bzr-upload plugin. (http://bazaar-vcs.org/BzrPlugins)
<Waldir> there seems to be something right for the needs of everyone :) I am guessing this could be put in an easier to find location, perhaps in the main page have a set of common "I am a xxx and I want to use bazaar for xxxx" with links that have all the correct instructions and resources... do you think it would be a good idea?
<Waldir> (just the most common combinations, especially newbies, experts, svn/cvs guys, something like that)
<LarstiQ> Waldir: does http://bazaar-vcs.org/Scenarios fit what you're thinking of?
<Waldir> LarstiQ: more or less. perhaps the entries could be grouped to allow easier browsing, and the "newbie getting started" guide is missing there :P
<LarstiQ> Waldir: would you like to contribute that guide?
<Waldir> lolol I really think I should first be able to get my project working :P
<LarstiQ> Waldir: well, the good thing is that you can note things as you encounter them
<LarstiQ> although, looking at the scenarios, 'newbie' isn't really a scenario
<Waldir> I suppose so. I think I'll save this first conversation for future reference
<LarstiQ> ok
<Waldir> yes, it doesnt fit very well there, but such a guide would be really good
<LarstiQ> Waldir: how does http://bazaar-vcs.org/BazaarForWebDevs compare?
<Waldir> LarstiQ: it's pretty nice. However I think something specific for say windows users with tortoise, using minimal (if at all) command line instructions, with screenshots, would really help the, you know, hardcore newbies (or people not very much wanting to learn to use a new tool). I'm not one of these but I know many, many people who are
<Waldir> It's nice having something powerful that an experienced user can use and learn really fast, but we all have to start sometime, and by then we're kinda clueless
<LarstiQ> Waldir: yes, I agree.
<Waldir> my friend is back, we'll try his ftp server now
<LarstiQ> Waldir: launchpad.net might also be appropriate space for hosting your branch
<Waldir> I thought it wasnt possible to host closed projects there
<LarstiQ> Waldir: ah, that would count as not appropriate then :)
<LarstiQ> carry on, nothing to see here! ;)
<Waldir> lolol
 * LarstiQ frowns at his bike keys still being lost
<Waldir> well, the ftp server accepted the push, but the files don't seem to be there. does push only save the .bzr branch there?
<Waldir> hmm, pull seems to be working, so I'm assuming that's the case
<Waldir> LarstiQ: I got this with pull: bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<Waldir> and then, running merge: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<Waldir> I suspect this might have something to do with the fact that we both created a repository in our machines, so they don't recognize each other as the same even though the file contents are indentical... is that right?
<LarstiQ> Waldir: exactly
<Waldir> LarstiQ: "Subversion and CVS are good choices for implementing this [centralized] workflow because they make it easy." on http://bazaar-vcs.org/Workflows#head-22b1dac636e54e501e9b5a0a235f21bb686b80ac I wonder if I really should be trying to set up bazaar... 9.9
<Waldir> but still what should I do then, to fix that 2 repos problem?
<LarstiQ> Waldir: two main approaches: 1) drop one of them 2) graft them together
<LarstiQ> Waldir: seeing as you have just started, I would go with 1)
<LarstiQ> Waldir: the reason CVS/svn make the centralized workflow easy to set up is because you can't do anything else with them.
<LarstiQ> Waldir: given a svn setup and a centralized bzr setup, I find bzr easier to work with.
<LarstiQ> Waldir: YMMV
<Waldir> Well, I'm taking some time to get started, but that is not the problem. I think I won't be able to convince the rest of the guys to use this if they have to fiddle with the command line...
<LarstiQ> I see.
<LarstiQ> Waldir: Tortoise svn is certainly more mature than Tortoise bzr.
<Waldir> I'm afraid we'll have to go with that one for this project, then. I'd use bzr myself for my website if my host's ftp support was better :(
<LarstiQ> which sorely needs people using it and improving it if it wants to get to the TSVN level, but I digress.
<LarstiQ> Waldir: you can also use bzr with svn as a backend btw
<Waldir> my concern is just the interface. I'd rather use tortoisesvn with bzr as a backend instead, since it seems to be better for merging and stuff :P
 * LarstiQ shudders
<LarstiQ> I really don't think so, but feel free to try :P
<Waldir> I don't know, I was just guessing :P
<Waldir> LarstiQ: Your solution worked btw: I just tried doing a change then commit then push and then pull on the windows machine (which is called "update" in the tortoise interface), and it worked. We were able to see the diff there, of the change I did here :) Only question now is how to revert a change, but that will be another day's lesson :) anyway, I already got started with this. Thanks a lot for helping with that.
<Waldir> I gotta leave now. See you next time!
<LarstiQ> Waldir: `bzr revert`?
<LarstiQ> Waldir: ciao!
<Waldir> LarstiQ: thanks :) bye!
<dereine> LarstiQ: can i use bzr push for ftp to have a current version of a repo as checkout on ftp
<LarstiQ> dereine: in bzr terminology, push will not create or update working trees on ftp
<LarstiQ> or any remote transport
<LarstiQ> dereine: if you want to do something like deploy a website, the bzr-upload is a better choice ime
<LarstiQ> dereine: if you don't actually want a checkout, but just publish your branch so others can use bzr to interact with it, `bzr push` is all you need.
<LarstiQ> and it will work with ftp, presuming the ftp server isn't broken.
<dereine> LarstiQ: no i need exact the checkout
<LarstiQ> dereine: sftp or bzr+ssh:// are usually better choices if available
<dereine> i know :(
<LarstiQ> dereine: what do you need a checkout for?
<dereine> the designer there don't use bazaar
<dereine> so he edits the file with ftp
<dereine> and i work on a local branch
<dereine> thx anyway for the links
 * SamB thiinks dereine should delette some of his files "by accident"
<dereine> ^^
<dereine> i'm just wondering if its possible
<LarstiQ> dereine: ouch
<dereine> ok i will force him to use bzr :)
<LarstiQ> dereine: it is possible, but very awkard.
<LarstiQ> dereine: you'll need ssh access to the ftp machine, and bzr installed on it
<dereine> mh this will be hard :) i asced the support yesterday evening they don't support ssh even for really business accounts which costs too much :)
<nadavoid> Hello, I set up bazaar on my mac for a project a couple of weeks ago. I'm still very much a bzr noob. When I initially set it up, I checked in the whole project. Since then, I've done a lot of work - added a lot of directories and files, edited a lot of files.
<nadavoid> What's a recommended way for me to update my repository?
<nadavoid> It's just a local repository. .bzr directory inside my top level directory. nothing more.
<nadavoid> Should I just do "bzr add" then "bzr commit"
<nadavoid> OK, well, that's what I did. And it seemed to work. bzr seems very simple and straightforward. I'm glad I met it. :)
<knielsen> when I bzr branch a copy of lp:maria, bzr 1.13 uses up >600Mb of memory during the process, which is a bit of a bummer. Any way to reduce this?
<knielsen> [this is a branch of the MySQL server tree. which has a lot of history, around 500Mb or so]
<mwhudson> knielsen: you can probably pull in stages, bzr branch -r1000 lp:maria, cd maria; bzr pull -r 2000 etc
#bzr 2009-04-26
<lifeless> knielsen: thats odd, it should be streaming, which would mean you don't need remote indices cached or anything
<lifeless> knielsen: please file a bug!
<ovnicraft> hi, is there trac-bzr developers?
<Peng_> mwhudson: FWIW, I've been running the Loggerhead memory stuff for nearly a day now. I haven't noticed any issues, not that I've looked. I can't say for sure, but RAM usage seems surprisingly low and stable.
<mwhudson> Peng_: cool :)
<mwhudson> Peng_: it will probably be a little slower, but not i'd expect you to notice
<AnMaster> hm
<AnMaster> in bzr info output. What does "submit branch:" mean.
<AnMaster> it isn't same as push branch, nor is this branch bound.
<AfC> AnMaster: I've got a feeling it might be the place you `bzr send`'d to. It's all a bit arbitrary. Bazaar's UI isn't very consistent.
<james_w> submit branch is for merge and send
<james_w> AfC: why is that inconsistent?
<AnMaster> AfC, bzr send...? mhm
<AfC> Mostly the fact that no one can infer what any of those things mean. If it means send destination, then perhaps call it that.
<AnMaster> actually that branch was the old name for this one, When I changed to using a shared repo for all the branches of this project I branched the freestanding branches into the shared repo.
<AfC> AnMaster: that's the alternate form of what was originally `bzr bundle`. If you like to review your patches before you send them and attach them to your emails personally, then bundle might be what you're used to.
<AnMaster> then later deleted the freestanding ones
<james_w> well, it's the operation that decides which branch to use, so it's a little trickier than that
<AnMaster> AfC, something I never used either
<spiv> AfC: I think the names for those things are pretty reasonable, but the actual rules about how they are determined are too fiddly and unpredictable.
<AfC> spiv: yes, that's what I'm talking about.
<spiv> "$url is the submit location?  Hmm, I wonder why..."
<AfC> And just wait until you try to find out what that means & how to change it in the help list. Yup.
<arj_> hi
<arj_> how do I make bzr upgrade remove an old backup.bzr dir?
<arj_> it fails to upgrade because it's there
<arj_> I'm hosted on launchpad
<arj_> and using bzr 1.13.1
<mwhudson> arj_: this is a bit of a wart
<mwhudson> arj_: you can use lftp to remove it
<mwhudson> arj_: or i can do it for you if you want
<arj_> would be nice if you could remove it: bzr+ssh://anders-gnulinux@bazaar.launchpad.net/~team-mms/mms/1.1.0/
<mwhudson> arj_: done
<arj_> thanks! :)
<Enisseo> hi everyone!
<Enisseo> I'd like to make a GNU-like diff, does anyone know how to do so with bazaar?
<luks> Enisseo: is there anything wrong with bzr diff?
<luks> GNU patch has no problems understanding it
<Enisseo> Well... I need to create a patch for a git project (I think)
<luks> is that a problem?
<Enisseo> I tried using an external diff tool, with the --using=... option
<luks> the output if bzr diff is a standard unified diff patch
<luks> of
<Enisseo> but the binary files are not included
<Enisseo> (I'm on Windows XP)
<luks> I don't think there is a way to include raw binary files in the patch
<luks> I don't know of any other VCS with that ability either
<Enisseo> so, the best way to send my "patch" may be a .tar.gz file...
<Mez> is there an easy way to setup bzr so that it can use webdav or similar (commit via HTTP - preferably locked down to allow only certain accounts)
<luks> the best way to send a patch to a bzr project is to use "bzr send -o mypatch.patch"
<Enisseo> I've read that some versions of the GNU diff manage binary files
<luks> Enisseo: yes, "diff -Naur" for example will include binary files
<luks> Enisseo: but even git will include encoded file in their internal patch implementation
<Enisseo> luks > but this patch will not work with non-bazaar projects, right?
<luks> Enisseo: generally it will, but will not add binary files
<Enisseo> okay, thanks, I think I will send a compressed file, it will be more convenient
<luks> I'd send the patch for text files, and separately send the binary files
<luks> that what I normally do for projects that use svn
<luks> *that's
<Enisseo> (and this is the exact time I'd need a "bzr export -r firstRev..lastRev" feature...)
<LarstiQ> Enisseo: what would that do?
<Enisseo> LarstiQ: export the files that have been modified or added between two revisions
<LarstiQ> Enisseo: hmja. That's not really the semantics of the export command.
 * LarstiQ ponders a solution
<Enisseo> well, not really indeed, but it's the command that matches best what I need right now ;)
<LarstiQ> Enisseo: what version would you export, all changed versions? The version of the file at the first revision, last revision?
<Enisseo> the version of the file at the last revision
<LarstiQ> Enisseo: I'd combine bzr st -r rev1..rev2 with bzr cat -r rev2
<Enisseo> in order to apply a patch just by copying the exported files to the project folder
<LarstiQ> Enisseo: which will overwrite previous changes, but yeah.
<Enisseo> yes
<LarstiQ> Enisseo: status to get the list of files changed between two revisions, and cat to get the files
<Enisseo> I'm trying with the status command, the COPY (on windows) and a bunch of text transformations
<awilkins> It's a bit quiet in here
<fullermd> Shhh.  I'm hunting wabbits.
<thumper> hello people
<thumper> I have bzr 1.15dev from the nightly ppa
<thumper> and pushing a branch to LP appears to work
<thumper> but I get an error when branching the branch from LP on another machine
<thumper> ErrorFromSmartServer: Error received from smart server: ('NoSuchRevision',)
<lifeless> hi
<thumper> the other machine also has 1.15dev
<lifeless> where you pushing a new branch?
<thumper> launchpad
<lifeless> or does the branch already exist?
<thumper> I renamed the existing one, which exhibited the same symptopms
<thumper> so pushed a new stacked branch
<thumper> plz excuse spelling, v.tired
<lifeless> please file a new bug; it sounds like you may have found a new issue
<thumper> ok
<thumper> lifeless: bug 367631
<ubottu> Launchpad bug 367631 in bzr "Branching a stacked branch from Launchpad gives ErrorFromSmartServer: Error received from smart server: ('NoSuchRevision',)" [Undecided,New] https://launchpad.net/bugs/367631
<lifeless> thumper: please include the revno of your nightly bzr package
<lifeless> (dpkg -l bzr)
<thumper> I did
<thumper> it is in the description
<lifeless> ok
#bzr 2010-04-26
<jelmer> luke-jr: yes, use bzr:file-ids as revprop
<jelmer> luke-jr: and set that on a revision in which the file was introduced
<jelmer> luke-jr: alternatively, "bzr reconcile" might do what you want
<luke-jr> jelmer: another problem that I just thought of... :/
<luke-jr> somehow I'll need to rebase the merged branches :\
<luke-jr> I suspect I'm going to want to introduce 2 new revs for each original bzr rev
<luke-jr> a rebased one and a merge of the rebased one and the original one
<luke-jr> or perhaps I can have the rebased one list the original one as a parent... hmm
<luke-jr> jelmer: I can't find that mapping spec
<jelmer> luke-jr: specs/mappingv4.txt
<luke-jr> ah
<luke-jr> README had referred to some weird path :(
<luke-jr> bzr:file-ids revprop doesn't seem to do anything :(
<luke-jr> nor bzr:skip :/
<jelmer> luke-jr: have you erased the cache ?
<jelmer> luke-jr: also, have you set other bzr: revprops?
<luke-jr> yes; not yet
<luke-jr> bzr:skip looks to just be poorly documented
<luke-jr> I expected to be able to set it on svn-r1 and get bzr to skip over that rev
<jelmer> luke-jr: this is a design document, not a document aimed at users so they can set their own revision properties
<luke-jr> anyhow, bzr:file-ids still seems to be ignored
<luke-jr> do I need to set other properties to make it take effect? (perhaps bzr:mapping-version?)
<jelmer> luke-jr: bzr:skip only means bzr-svn can avoid checking any other bzr-svn metadata for that revision
<jelmer> luke-jr: yes, you need to set more than just bzr:file-ids
<jelmer> luke-jr: at least bzr:mapping-version and bzr:root IIRC
<luke-jr> what should they be?
<luke-jr> the real repo has no bzr:mapping-version at least. :/
<jelmer> luke-jr: I would recommend running "bzr reconcile" and checking what that sets
<xnox> bzr nested trees rock way better than git subtree merge =)
<xnox> I now do $ bzr merge svn://svn.server.org/path/to/external
<xnox> and get everything i want =)! in the correct subdir of my project ;-)
<jbowtie> xnox: I was under them impression that nested trees hadn't landed. Am I confused or are you working off a dev branch?
<xnox> jbowtie, by reference nested trees are not here yet.
<xnox> jbowtie, but you can do this $ bzr branch URL subdir/
<xnox> $ bzr join subdir
<xnox> $ bzr ci -m "Merging external code from any URL"
<xnox> and from now on you can do
<xnox> $ bzr merge URL
<xnox> to update the code
<xnox> but this makes history of that subdir part of your history
<xnox> join & split have landed in bzr a while ago
<jbowtie> xnox: Oh, OK. I'd never seen the join/split commands before, must read release notes more in future.
<jbowtie> xnox: That gives me the benefits of svn:externals under Bazaar, right?
<xnox> jbowtie, when we have by reference trees you will be able to have stuff like externals where that code is almost not part of your history & has independed branch on it's own.
<xnox> jbowtie, almost =)
<jbowtie> xnox: Almost is good enough for most of my scenarios.
<xnox> jbowtie, yes almost good =)
<xnox> if you want to work & submit patches to that external you are better off branching it on it's own, then try to commit stuff in your containing project
<xnox> "then" = "than"
<jbowtie> OK, my TFS plugin seems to be working well enough for read-only access to TFS repositories. (Microsoft Team Foundation Server)
<jbowtie> Just need my manager to sign off on my pushing it to Launchpad.
<jbowtie> xnox: Does pull update the joined directory, or do you have to explicitly merge?
<xnox> jbowtie, you have to do merge
<xnox> jbowtie, cause history has diverged from both places.
<xnox> jbowtie, with by-reference nested trees you will be able to just pull
<xnox> jbowtie, but we don't have that yet =)
<xnox> jbowtie, I have svn import running of 2 projects on launchpad. With one having svn:external to the other
<xnox> jbowtie, to update to latest code after the intial $ bzr join
<xnox> I have to do $ bzr merge URL-super
<xnox> $ bzr merge URL-external
<xnox> then I have locally everything tip-top
<jbowtie> xnox: Thanks, that makes everything clear. Will definitely start using join for a couple of projects.
<xnox> jbowtie, your welcome =) I should blog about it ;-)
<jbowtie> Hmmm...how do you provide tests for something that talks to a proprietary foreign VCS?
<xnox> jbowtie, depends on which one.... =) but generally it is bzr protocol tests. And you right a test stub using bzr-test framework which does the intended behaviour. (documented, speced) etc... such that it can be run automated without having access to that VCS
<jbowtie> xnox: Tricky. But just realised I can capture HTTP output and replay that during tests for the actual "talk to a VCS" class.
<xnox> =) nice
<xnox> which VCS are you working on? or is it top-secret?
<jbowtie> Microsoft Team Foundation Server.
<xnox> there have been issues with bitkeeper......
<jbowtie> No secret, just ugly, ugly code.
<xnox> jbowtie, aha =) that beast.
<xnox> are you switching to bzr from that?
<jbowtie> xnox: Yes, getting my team to, anyway. I can checkout and pull updates from TFS now.
<xnox> jbowtie, publish code on lp. I'm pretty sure loads of people will find it useful
<jbowtie> xnox: Pushing updates to TFS is possible but needs a bit more work so that round-tripping is a bit more solid.
<xnox> jbowtie, is there bzr plugin for VS?
<jbowtie> xnox: Just waiting for manager to sign off on publishing to Launchpad.
<jbowtie> xnox: Not that I know of but project in question is using Eclipse anyway.
<xnox> jbowtie, aha =) https://edge.launchpad.net/bzr-visualstudio
<xnox> it's for 2005 though
<jbowtie> xnox: Once I've published the TFS work I'll have a look at updating that.
<jbowtie> I want to update the plugin developer's guide with info on writing a VCS plugin, but can't find it in launchpad.
<jbowtie> Probably I'll just end up blogging it.
<echo-area> hi, bzr 2.1.1 on windows doesn't print any messages in any command.  Does anybody know why?
<echo-area> For example, when I do "bzr pull", the message "Using saved parent location..." is not printed; when I do "bzr pack", the message "repacking..." is not printed
<echo-area> and bazaar.conf does not have likely related setting
<jbowtie> echo-area: That's not what I'm seeing (just checked)
<jbowtie> echo-area: Does bzr --version print anything?
<echo-area> jbowtie: um, my description was a bit wrong.  Something is printed, but the other information is not.  "bzr --version" indeed prints version information.  But for "bzr pull", only the list of changes is printed, the information like "Using saved parent location..." and about the fetching progress is not printed.  For "bzr pack", nothing is printed
<echo-area> and I remembered when I used bzr 2.1.0, that information was printed
<jbowtie> echo-area: AFIAK that hasn't changed in 2.1.1 - certainly the saved parent thing is happening on my Windows box.
<jbowtie> echo-area: Does a "bzr info" show that there is a saved parent?
<jbowtie> echo-area: Don't forget, you can always use the verbose switch (-v), might mention something useful.
<echo-area> jbowtie: I tried "bzr pack -v", but still, nothing is printed.  It's so strange
<jbowtie> echo-area: The only thing that springs to mind is that one of your streams (stdout, stderr) is being redirected somehow.
<jbowtie> echo-area: I've had that happen to me once or twice, where stuff printed to stderr got captured by a debug utility.
<echo-area> jbowtie: I guess so, but how come a plain "bzr pack -v" redirects?
<jbowtie> echo-area: No idea, and that's just a guess anyhow. Are you using PowerShell by any chance, or the standard command shell?
<echo-area> jbowtie: I'm using C:\WINDOWS\system32\cmd.exe.
<jbowtie> echo-area: Hmm. Maybe bzr pack has nothing to do?
<echo-area> jbowtie: I don't know, but I guess not, since every time I run "bzr pack" on a Linux box, there is information printed.  But this is not a problem until now, so I think I can live with that
<jbowtie> echo-area: OK. Let us know if you have any other issues, I can at least run a quick test on another Windows box for comparison.
<dcoles> Hi. Can I pull from branches other than master with bzr-git?
<echo-area> jbowtie: okay, thank you :)
<dcoles> I tried 'bzr git-import' which gives me a tree, but then I can't push/pull after that.
<jbowtie> dcoles: Are you trying to merge the changes from the other branch into yours, or switch to using it as your parent branch?
<dcoles> jbowtie: Ideally, I just want to check it out to work on it and then be able to push changes to that branch
<dcoles> Trouble I'm having is I can't think how to provide the branch in the git+ssh url
<mwhudson> hm
<jbowtie> dcoles: I'm not a git user; but looking at the documentation for bzr-git that might not be possible.
<jbowtie> dcoles: Could you clone the git branch into another location, the use bzr to check that out?
<dcoles> Yeah. I was worried about that. I even went to the extent of browsing the bzr-git sourcecode
<dcoles> jbowtie: That might be the way of doing it. Just make sure you "checkout" the right git branch
<dcoles> I'm not a git user either, but learning _far_ too much about it looking after a project's git repository ;)
<mwhudson> bzr-git currently can only interact with the master branch in a git repo aiui
<dcoles> mwhudson: Righto. That makes sense.
<jbowtie> Is Bazaar 2.x packaged anywhere for RHEL?
<dcoles> jbowtie: http://wiki.bazaar.canonical.com/DistroDownloads#CentOS/RHEL perhaps?
<dcoles> Looks like it should already be in yum.
<jbowtie> dcoles: That only has 1.3.1 - pretty old
<dcoles> Ah. That's a shame. :S
<jbowtie> And of course gcc is not installed on the RHEL box I want to install it on.
<dcoles> I saw some rumors about it being included in RHEL6, but who knows when that is coming out
<dcoles> One might assume it might be possible to nab from Fedora, but who knows what kind of dependancies that would try and drag with it.
<jbowtie> dcoles: There's always the long way - spin up a CentOS image, install gcc, build the RPM, scp to the server, install. Bleh.
<dcoles> Yuck. At least bzr is a reasonably nice package to build
<jbowtie> Hopefully one of the lurkers will feel guilty enough to update the yum repository.
 * jbowtie looks around for anyone with a guilty look.
<dcoles> jbowtie: I tried the "git clone x, git checkout branch; bzr branch x y" method. It works. But you have to do a 'git reset --hard' after you dpush back.
<dcoles> And using bzr in the git repo seems to crash bzr when I try and commit (not sure if that's a legal use of bzr or not)
<jbowtie> dcoles: Important thing is that you are not stuck, glad I could help with that much.
<dcoles> :)
<dcoles> I could always just use git.... blehgh
<jbowtie> dcoles: I'll keep an eye on the Bazaar blueprints during UDS, maybe we can get someone to do something about that.
<dcoles> Well, I think the current block was "colocated branches"
<jbowtie> dcoles: Personally I'll probably work on cleaning up the documentation, it's getting a little hard to find details I need.
<dcoles> But even just being able to do bzr co git+ssh://example.com/repo#branch would be quite nice.
<dcoles> Indeed. I've been pestering jelmer about a lot of the bzr-git stuff.
<dcoles> There's also quite a few references to bzr-git being "read only", despite having dpush now.
<dcoles> I'd love to sit down and hack on the plugin one afternoon. It's really neat except for one or two little bugbears.
<jbowtie> dcoles: It's not like you need commit access.  ;)
<jbowtie> Whoops, gotta go, have a train to catch.
<dcoles> Cya
<dcoles> Whoops. Too late.
<vila> hi all
<sivang> hi all
<sivang> how come, that in my working copy I get the latest revision when doing bzr log
<sivang> and when I go the parent branch,
<sivang> then it shows a couple of revisions back?
<sivang> (sorry for using CRLF as punctuation)
<xnox> sivang, ? what does `bzr status` show in both directories?
<xnox> and what is bzr info in both of them
<sivang> xnox: let me check
<sivang> xnox: in one dir, a bunch of unknowns
<sivang> xnox: in the other :
<sivang> :~/ccforms_renamed$ bzr status
<sivang> bzr: ERROR: No WorkingTree exists for "file:///home/sivan/ccforms_renamed/.bzr/checkout/".
<xnox> sivang, so looks ok to me. Depending on what you are trying to do
<xnox> and what type of checkout you use
<xnox> sivang, if you do `bzr info` in both of them it should tell you what are the relationships, if any, between those two branches
<sivang> xnox: so the one that does now show all the revision in log, is the push target of the working copy
<fullermd> I wouldn't assume he's using [explicit] checkouts at all.  It just sounds like he's got two branches that are at different places, which is...   well, normal.
<sivang> xnox: how can I make it show all the revision, since when I check out from it or bracnh, it doesn't get revision up to the last one
<fullermd> Why do you think they SHOULD have the same revs?
<sivang> fullermd: I use the push target is the parent branch or repo
<sivang> fullermd: or am I not?
<fullermd> Sure, but did you push them?
<fullermd> 'missing' is also your friend here.
<xnox> sivang, what do you mean by "working copy" - checkout, lightweight checkout, or branch?
<sivang> xnox: okay, so I see bzr lingo thickens the plot a bit
<sivang> xnox: I init'd a a dir
<sivang> xnox: commited into it
<sivang> xnox: and then pushed to a "backup" location
<sivang> oops
<sivang> forgot to push
<sivang> geez
<sivang> now it is synced
<xnox> sivang, =)
 * sivang turns to be the lolipop figure in Bugs Bunny film
<sivang> xnox: so, is there a book ? an oreilly book already so learn all things bzr from start to finish ?
 * sivang googles for the difference between a checkout, lw checkout and bracnh
<sivang> there's is no repo notion right?
<sivang> (like in svn)
<xnox> sivang, http://doc.bazaar.canonical.com/bzr.2.1/en/
<sivang> but still, if I have a parent branch
<xnox> sivang, yes there is but a lot different from svn
<sivang> parent branch: /home/sivan/ccforms_renamed
<xnox> sivang, do this
<sivang> xnox: I remember lifeless talking lots about the difference
<xnox> in a temporary location
<xnox> $ bzr init-repo .
<xnox> $ bzr info
 * sivang tries
<xnox> $ bzr init branch-a
<sivang> shared repo with trees? what does that mean?
<xnox> $ cd branch-a && bzr ci --unchanged -m "my first commit"
<xnox> $ cd ../
<xnox> $ bzr checkout branch-a branch-b
<xnox> $ bzr info branch-b
<xnox> $ cd branch-a
<xnox> $ bzr ci --unchanged -m "checkout branch-b should be out-of date now"
<xnox> $ bzr info branch-b
<xnox> $ bzr status branch-b
<xnox> Checkout of a branch is similar to svn, where commits in the checkout will end up in the branch
<sivang> xnox: okay, so what I was looking actually instead of just a branch, is to creat e a repo and so commits will work against it?
<sivang> xnox: I wanted commits from the local machine, and from another remote machine to end up in the same source tree
<sivang> xnox: with revisions and everything
<sivang> xnox: so I can either work on my desktop or from the remote server transparently
<xnox> sivang, that would be dangerous cause you might override working tree on the server & desktop
<xnox> sivang, what you should do is this
<sivang> xnox: I want to have a working tree at a seperate location
<xnox> 1) create a branch on the sever
<sivang> xnox: just a "shared repo" is that the right term?
<xnox> sivang, repo is where the revisions are stored but repo still has to have branches in it so that there is a *named* location to push to.
<xnox> So on the server create a repo & branch underneath it
<xnox> when you are on the desktop do $ bzr checkout $URL-branch-on-server
<xnox> when you are on the server do $ bzr checkout /path/to/branch/on/server
<xnox> Always commit to checkouts *of* the branch on server
<xnox> this way whenever you make or update a checkout you will get latest code from your "central" branch
<xnox> sivang, http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/central_intro.html
<sivang> xnox: I see, but when commiting to a checkout that means commiting to the .bzr inside the workign copy
<sivang> xnox: how do I get those updates to the parent branch in the central repo ?
<xnox> sivang, no it will commit on the server
<sivang> xnox: ok, I will dio some reading :)
<xnox> sivang, if you look into the .bzr dir inside you will notice it has three major folders:
<sivang> xnox: bzr got some feature rich since last time I used it for hubackup
<xnox> repository, branch, checkout
<sivang> yes
<sivang> even when I jsut init a dir,
<xnox> in the repository it stores raw bytes, in the branch it stores references as to which revision this branch points at and in checkout it stores the current status of the working tree
<sivang> which means I created a new branch right?
<xnox> when you do $ bzr init it creates all three
<xnox> when you do $ bzr init-repo DIR
<xnox> it will create $ DIR/.bzr/repository
<xnox> such that all branches underneath $ DIR store there bytes together & efficiently sharing them
<xnox> when you do $ bzr checkout $URL
<sivang> the docs are nice muchly improved
<sivang> xnox: I create a mirror of the branch ?
<sivang> so to speak
<xnox> it will place bytes in a shared-repo if present, and then create a working directly (checkout) with no separate branch. Intead it will put reference "saying when I commit in this working tree, take my local bytes but commit in the target branch"
<sivang> ah
<sivang> cool, so like a mirror
<xnox> yes
<sivang> xnox: thanks dude
<xnox> sivang, furthermore you can have lightweight-checkouts
<sivang> xnox: which are?
<xnox> those do not have their own repository and are usefull when you are working with large repositories
<fullermd> Don't get hung up on the difference between light and heavy checkouts...
<sivang> do the significance of a repo is just to share bytes?
<fullermd> Heavies make a local cache of the revs; lights don't.
<xnox> then you will have a tree-less repository such that all branches do not have working tree in them (cause it's a 100MiB big)
<sivang> right , so for large repos heavy are better
<fullermd> You probably only want to use a light checkout when the branch is on the local disk, or possibly close by on a very fast network.
<xnox> and you will have one lightweight checkout which just represents a working-tree attached to a particular branch. And then you can do $ bzr switch
<sivang> fullermd: right, so when I work on the server, light-checkout
<xnox> to jump from one branch to another
<sivang> fullermd: on the desktop at home, heavy
<xnox> sivang, yes repo is to share bytes
<sivang> xnox: this is different from svn so deeply
<sivang> xnox: a repo is a dir mostly there :)
<xnox> sivang, locally. Two repositories with bytes never will mirror each other. You can only push branches around which will take the bytes with them & put their bytes in the repos
<sivang> xnox: so when I init'd the local folder I worked on, and then pushed it to my backup location, what was the relationsip and what happened between them?
<xnox> sivang, you got heavy & light right
<xnox> sivang, you have (branch & repo & checkout)    <----->  (branch & repo)
<xnox> unless you did $ bzr co /path/to/branch on the server
<sivang> xnox: so due to the face that there was no relationship between them, just a push target, revision did not automatically got updated at the push target
<xnox> then you have (branch & repo & checkout) <-----------> (branch & repo & checkout)
<xnox> sivang, "not automatically" on commit on either of them
<sivang> xnox: what causes the automatic update relationship to occur ?
<fullermd> Thinking of automatic vs. non-auto is likely to wind up more confusing.
<fullermd> When you make a commit, it goes onto the branch you're working on.  So the question is always, what branch am I working on?
<xnox> (repo & checkout )   <------------> (branch & repo)   <----------------->   (repo & checkout)
<fullermd> If you have a checkout, the branch is the thing you `bzr co $THING`'d.
<fullermd> If you did a `bzr branch $THING`, your local dir is its own branch.
<sivang> fullermd: right, okay it starts to be clearer now
<xnox> fullermd, yeap nice explaination
<fullermd> 'push' and 'pull' are commands you use to move existing revs from one branch to another.
<sivang> fullermd: nice, so back to DRCS
 * xnox says what's DRCS?
<sivang> Distributed revisionc ontrol
<sivang> the co and repo is the bzr support for centreal rc
<sivang> no ?
<fullermd> That's one way of thinking about it...
<fullermd> Better, though, to think of it Branch-centric.
<sivang> and working with branches is good'o distributed, when you have a merge action between them
<xnox> sivang, yeap. If you have one branch on the server and you have multiple checkouts it's like having svn server & checkouts
<fullermd> Using co is a way to get multiple working trees all on a single branch.
<sivang> cool
<sivang> thank yo guys!
<sivang> Are you with Canonical btw?
 * xnox no
<fullermd> Which is similar to what you do with a centralized system.  But thinking of it around branches probably keeps things straighter.
<fullermd> You may want to peruse some of the stuff at http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs
<fullermd> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief particularly for some background vocabulary, and http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevHandling for some talk about push/pull/etc.
<sivang> fullermd: thanks, irssi logged it and I shall read it!
<sivang> now , off to lunch.
<jbowtie> Which Launchpad project do I need to contribute to the documentation?
<bialix> documentation of bzr?
<bialix> ok
<bialix> jbowtie: documentation of bzr?
<jbowtie> Yes, documentation of Bazaar. I want to clean up a few of the less maintained corners.
<jbowtie> Those empty sections in the admin guide also bug the heck out of me.
<faceprint> is there a way to make 'bzr commit' not throw an error if there's nothing to commit, without allowing it to commit an empty revision?
<Peng_> jbowtie: There's a bzr-doc team with a mailing list, but it's just handled through the normal bzr project.
<faceprint> we spent the weekend converting from CVS, and we were taking advantage of the fact that cvs will gladly do nothing when nothing has changed in a bunch of our automated scripts
<Peng_> jbowtie: File bugs, file merge proposals, whatever.
<Peng_> faceprint: Ahh... That's a pretty obscure request, and I doubt bzr has a knob somewhere to do it.
<jbowtie> Peng_: Sorry, are you saying the docs are somewhere in the bzr source tree?
<Peng_> jbowtie: Yes.
<jelmer> faceprint: I'm not sure I understand what you're asking for?
<Peng_> jbowtie: Not, like, the wiki, but most of the documentation is.
<jelmer> faceprint: --unchanged is not what you're after?
<Peng_> jelmer: I think what he's after is that he wants the exit code to be 0 even if nothing has changed.
<Peng_> faceprint: Probably not hard to write some Python to accomplish that, but...
<faceprint> jelmer: i have scripts that grab the latest versions of certain files, or re-compute certain files (yes, this is kind of an abuse of version control, but it's what we have), and then commit them if there are changes.  We had been just running cvs commit after generating the new version, and if there were changes they got committed.  If the files ended up identical, everything just exited silently
<faceprint> if I use --unchanged, I'm going to add another 10 or so revisions to my repository every morning with empty commits
<jbowtie> Peng_: OK, I see the admin guide, but not the plugin developer's guide.
<jelmer> faceprint: you could do some scripting to find out if there are any changes to commit
<faceprint> yeah, I started down that path, and realized that bzr stat doesn't seem use return codes at all, so I'm actually going to have to look at its output
<faceprint> it isn't a huge deal, and honestly if this is the only hiccup in this transition, i'm a very happy guy (knock on wood)
<jbowtie> Peng_: That can't be everything. The migration guides for users of other VCS, plugin docs, plugin developer guide - none of that's in the bzr tree.
<xnox> faceprint, $ bzr commit returns exit code 3 when there is nothing to commit
<xnox> e.g. pointless commit
<jbowtie> And why is there a project called bzr-alldocs that doesn't contain all docs?
<faceprint> xnox: which doesn't help me in deciding whether to run bzr commit or not ;-)
<xnox> faceprint, just run it and catch and check that exit code. Or is there someother logic apart from "when changes -> commit; when no changes -> do not commit"
<bialix> jbowtie: bzr-alldocs is for bazaar.canonical.org website
<faceprint> really, I'm just trying to avoid cron email from all these scripts, but don't want to send stderr to /dev/null in case something actually IS wrong
<xnox> faceprint, ok another one $ bzr diff exits 0 if there is no diff, exits with 1 if there is diff and hence there are changes
<xnox> faceprint, is this better?
<faceprint> ah, that'll work.  don't know why I didn't think of diff earlier
<jbowtie> bialix: OK, so documentation is split up across multiple sites?
<jbowtie> No wonder the docs are such a mess.
<bialix> jbowtie: which kind of documentation?
<xnox> faceprint, if you generate new files you will need to somehow add them to the tree though
<bialix> jbowtie: if you can do better, please do
<faceprint> luckily these are just existing-file changes i'm concerned with
<faceprint> thanks for your help!
<xnox> jbowtie, all documentation is linked from bazaar.canonical.com. There a few small about developing bzr inself in the bzr source tree.
<bialix> jbowtie: part of documentation is auto-generated from online help (bzr help xxx)
<sivang> back
<jbowtie> xnox: I think that's where I'm getting confused.
<jbowtie> I see 14 categories on the Documentation Table of Contents.
<xnox> jbowtie, go there click documentation and that's the full maintained, canonical location for all documentation.
<jbowtie> I see 8 categories in the bzr source tree.
<jbowtie> So where are the other 6 categories sourced from?
<xnox> jbowtie, from the doc-strings within the codebase inside bzrlib/
<xnox> in each command / function
<bialix> jbowtie: are we talking about http://doc.bazaar.canonical.com/bzr.2.1/en/ ?
<jbowtie> bialix: Yes.
<xnox> jbowtie, well FAQ & BzrGlossary are just links to random pages online and are not real docs
<jbowtie> If I want to correct something in both the "System Admin Guide" and the "Developer Docs", where do I go to edit that?
<bialix> jbowtie: Core documentation coming from bzr sources
<bialix> Related links from other places
<bialix> jbowtie: core docs coming from bzr_tree/doc/end
<bialix> jbowtie: core docs coming from bzr_tree/doc/en
<bialix> sorry
<Peng_> jbowtie: Ooh! I thought there was a project, but I couldn't find it when I checked.
<jbowtie> bialix: OK, so the "System Admin Guide" is in the bzr tree, since it's in the core section.
<bialix> jbowtie: correct
<bialix> doc/en/admin-guide
<jbowtie> bialix: But how do I track down the 6 "Related Links" projects? Or are they not in Launchpad anywhere?
<bialix> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/files/head%3A/doc/en/
<bialix> jbowtie: look at the links
<Peng_> xnox & faceprint: 'bzr diff' doesn't show executable bit changes, so it might not include them in the exit code either...
<bialix> jbowtie: Desktop Guide coming from Bazaar Explorer
<bialix> FAQ is launchpad page
<bialix> Glossary is wiki page
<bialix> Developer Docs again from bzr tree
<jbowtie> bialix: Wait, what? Where are the Developer Docs?
<bialix> wanna screenshot?
<bialix> here is http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/files/head%3A/doc/developers/
 * bialix is not sure where from coming migration and plugins guide
<bialix> igc is our docs master, but he's offline this week
<jbowtie> bialix: Well, that's somewhat more helpful.
<bialix> you can send the question to the ML though
<bialix> maybe jam knows
<jbowtie> bialix: But of course the Plugins Guide was the one I had a big patch for since I just wrote a plugin.
<bialix> (... or poolie)
<xnox> bialix, bzr/doc/en/upgrade-guide$ for the migration guide
<bialix> xnox: thx
<bialix> jbowtie: here is plugin guide sources http://bazaar.launchpad.net/~bzr/bzr-alldocs/trunk/files/head%3A/plugins/en/
<jbowtie> xnox: That isn't right, the Survival Guide doesn't exist at all in that location.
<xnox> 4	./doc/en/user-guide/plugins.txt
<xnox> 4	./doc/en/user-guide/writing_a_plugin.txt
<bialix> I guess other docs need to look in the alldocs first
<xnox> My links are *from* the bzr tree
<xnox> so which once are we still missing?
<jbowtie> bialix: Umm. OK. So "alldocs" only has the Plugin Guide?
<xnox> so far I have found everything in the tree
<xnox> jbowtie, Plugin Guide is in the just *bzr* tree
<bialix> xnox: is not true
<bialix> xnox: http://bazaar.launchpad.net/%7Ebzr/bzr-alldocs/trunk/annotate/head%3A/plugins/en/plugin-development.txt
<jbowtie> xnox: Part of the problem is that not all the docs are in the tree.
<jbowtie> xnox: Otherwise I would be less confused. I hope.  :)
<jbowtie> xnox: There is some double-up of coverage.
<bialix> jbowtie: will be nice if you collect this info on the wiki.bazaar.cacnonical.com, if you don't mind
<jbowtie> bialix: Will do; am logging this and will update the wiki in the morning (very late night in my time zone).
<bialix> jbowtie: cool, thanks
<jbowtie> bialix: So if I track down the source for the "Migration Guide" - especially the "Survival Guide" subsection, we'll know where everything is.
 * bialix nods
<jbowtie> bialix, xnox: Thank you both very much, kept me from giving up on contributing documentation.
<xnox> jbowtie, i've never seen Survival Guide ever before
<xnox> WTF =) this needs fixed
<jbowtie> xnox: You probably didn't need it.  :P
<jbowtie> All right, I'm off to bed, will update the wiki in the local morning hopefully to be followed by merge requests.
<xnox> there is this page as well http://bazaar.launchpad.net/~ian-clatworthy/bzr-explorer-website/trunk/files/head:/en
<tetsuo--> Does bazaar support this: i have 2 folders, one contains patches to an upstream, the 2nd contains the upstream, bazaar should automatically apply the patches every time the upstream folder gets synced with the upstream
<xnox> tetsuo--, create third dir use $ bzr patch patch1 patch2 patch3
<tetsuo--> can that be automated like with git?
<xnox> tetsuo--, merge this with your "2nd dir contains the upstream"
<xnox> and then in that dir do $ bzr merge upstream
<xnox> tetsuo--, are you asking for topgit functionality or quilt like or what? =) what do you mean "like git"?
<xnox> generally even in git you apply patches on e.g. master, you upstream gets fetched into origin/master. And then you have master tracking origin/master which gets autopulled.
<tetsuo--> i have never done it, but i have been told that in GIT you can merge upstreams into the "2nd folder" and GIT will automatically use the upstream and downstream changelog to merge in all the patches from the first dir
<xnox> tetsuo--, well you want the pipeline plugin!
<xnox> you will do $ bzr co --light upstream pipeline
<xnox> $ cd pipeline
<xnox> $ bzr add-pipe patch1
<xnox> $ bzr patch patch1
<xnox> $ bzr ci
<xnox> $ bzr add pipe patch2
<xnox> rince repeat
<xnox> then you do $ bzr switch :first
<xnox> then you fetch upstream by pulling
<xnox> and to apply all patches you do
<xnox> $ bzr pump
<xnox> tetsuo--, launchpad.net/bzr-pipeline
<xnox> and there is wiki link from there
<tetsuo--> ill read that
<tetsuo--> i should have asked my question differently
<tetsuo--> how can i easily and simply maintain a local fork of an upstream project
<tetsuo--> its a fork because i have custom patches that dont make any sense to upstream
<xnox> tetsuo--, aha then you simply $ bzr branch $UPSTREAM
<xnox> commit your patches as regular commits
<xnox> and then everytime you want to sync with upstream you do $ bzr merge $UPSTREAM
<xnox> where $UPSTREAM can be git/hg/svn/local branches
<xnox> where $UPSTREAM can be git/hg/svn/local branches/ and ofcourse bzr
<xnox> If there are conflicts it will show you which files are conflicting
<tetsuo--> nice
<tetsuo--> so it will only complain if things break
<xnox> If there are no conflicts you can just commit to record this merge.
<xnox> Or you can tweak it further etc. do whatever you like
<xnox> =)
<tetsuo--> ok
<xnox> tetsuo--, any any point at time you can see which commits were yours and which are from upstream using $ bzr missing
<xnox> and $ bzr annotate
<tetsuo--> the reason it needs to be simple and easy is because the people who do this are not programmers themselves
<xnox> will tell you line by line who committed what in the file so you can see whether it was you who done it
<tetsuo--> ok so i dont need to keep the patches seperately after the first merge?
<xnox> tetsuo--, no
<tetsuo--> (please note i dont use bazaar right now, we use svn)
<xnox> you will have just one branch
<tetsuo--> ok
<xnox> tetsuo--, which platform are you on
<xnox> cause there is torgotaiseBzr (or whatever it is) for windows and on other platforms we have plugins as well so that it's all point & click
<tetsuo--> windows
<xnox> tetsuo--, create branch. Commit patches. Push that branch to everyone who needs it.
<xnox> Install https://edge.launchpad.net/tortoisebzr
<naoki^>  tetsuo--: Are you Japanese?
<xnox> tetsuo--, and then they will be able to point & click to get new updates
<xnox> and will be told if there are conflicts
<naoki^> tetsuo--: FYI, There is a Japanese ML http://groups.google.co.jp/group/bazaar-ja
<naoki^> I'm not good at English. If you too, we can talk in Japanese at the ML.
<tetsuo--> naoki^:  no im dutch
<tetsuo--> xnox: how about outdated stuff, like files that are removed upstream
<tetsuo--> will they be removed downstream too?
<xnox> tetsuo--, yeap
<tetsuo--> and if that particular file contains one of my patches it will throw a conflict?
<xnox> tetsuo--, no it will get deleted
<tetsuo--> oh noes!
<xnox> tetsuo--, but not that soon
<xnox> tetsuo--, after you merge you will see the changes
<xnox> what's going on eg. added files, deleted files, conflicted files
<tetsuo--> do deleted files keep their history in bazaar?
<xnox> if you are happy with the result you commit it
<xnox> tetsuo--, yes
<xnox> tetsuo--, you can reincornate any file from any revision without hitting the network on your local machine
<tetsuo--> sometimes code is refactored, and the file moves froom foo.cpp to fooa.cpp and foob.cpp, will my patch move to the right file?
<xnox> tetsuo--, you just do $ bzr revert -rNN (for whole tree) or you can maintain a delete file like thie $ bzr revert -rNN path/to/file
<xnox> tetsuo--, yes the patch becomes history. Bzr looks at your history & at the upstream history. So when upstream moves a file, your files is moved/copied with patched lines still applied
<xnox> so if upstream renames file then it your patched file will travel with it.
<xnox> tetsuo--, go to terminal create 2 branches and experiment with a sample. commit stuff to a branch "upstream" pull into your "local" branch apply some patches
<tetsuo--> what about > del foo.cpp , add fooa.cpp, add foob.cpp, the lines i was patches are deleted in foo.cpp and reintroduced in foob.cpp along with a bunch of new code
<xnox> and experiment what happens when you do stuff on the upstream branch and merge back into "local" branch
<tetsuo--> ok
<xnox> tetsuo--, try out in the terminal =) it depends on which VCS upstream is using and what bzr will decide to do
<xnox> tetsuo--, personally I've been hacking with bzr on more than 100 opensource projects and none of my patches / commits have been lost in the process of merging new stuff
<xnox> tetsuo--, there was a couple of times when bzr didn't realise what happened but it didn't cover it up but threw a merge conflict on me. But it was obvious for me to see what happened and why bzr couldn't merge it
<tetsuo--> ok
<xnox> tetsuo--, so from that point of view. Once you commit your patches as a branch you are safe. Backup your branch with commits somewhere and you are done
<tetsuo--> i actually need some help setting this up, if you want the challenge of seeing if it breaks with my project, lol :D
<xnox> tetsuo--, ping me any time you like ;-) i'm also launchpad.net/~dmitrij.ledkov for contact details
<xnox> tetsuo--, generally I think you want to have a maintainer who pulls & merges new upstream. And then pushes that branch to a local repository which all of your users consume straight away
<xnox> such that you have a maintained copy of software internally
<tetsuo--> i have no idea what that means :s (we use sourceforge for our code hosting)
<tetsuo--> http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/transform/MPCVideoDec/ffmpeg  << this is our patched fork of http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/ffmpeg/ which is a patched fork of http://git.ffmpeg.org/?p=ffmpeg;a=tree
<tetsuo--> as you can see our patches are not seperate but mixed in, and mostly undocumented in the changelog
<tetsuo--> and ffmpeg tends to refactor stuff once in a while, so files either get split up or merged all the time
<tetsuo--> any chance of bzr client making it easier to extract the patches from that mess?
<xnox> tetsuo--, yeap
<tetsuo--> xnox:  any tips for my first import?
<tetsuo--> i enabled bazaar on sourceforge
<tetsuo--> and want to import the svn tree with as much history data as possible
<xnox> tetsuo--, that's easy install bzr-svn plugin and just do $ bzr branch $URL_SVN
<xnox> tetsuo--, but i fear that fork of fork, the original fork and the upstream do not share history
<tetsuo--> they dont
<xnox> do you still need to pull updates from the "middle" fork or no?
<tetsuo--> if i can extract those patches ones i wont
<tetsuo--> once
<tetsuo--> but we are not in sync
<xnox> right.
<xnox> it's a toughy here =)
<xnox> do you have email?
<tetsuo--> our fork is behind about 2 weeks, on the middle one, which is behind a week on the upstream
<xnox> i'll play around with these branches and see what I can come-up with
<tetsuo--> thanks
<tetsuo--> i dont use email
<xnox> tetsuo--, =)))) ok
<tetsuo--> do you have a sourceforge account?
<xnox> tetsuo--, yes
<tetsuo--> do you prefer tickets or forum?
<xnox> tetsuo--, dmitrijledkov
<xnox> tetsuo--, I haven't used any =) I'll pick tickets
<tetsuo--> http://sourceforge.net/apps/trac/mpc-hc/timeline
<tetsuo--> you can add a ticket there with the results
<tetsuo--> i installed the gui
<tetsuo--> i should make a branch of the svn tree right?
<tetsuo--> i have the plugin
<xnox> tetsuo--, yeap.
<xnox> I got to go now. I will post on sourceforge tonight late in the evening
<tetsuo--> i get an error
<tetsuo--> Unable to import library "launchpadlib": No module named launchpadlib, Unable to load plugin u'pipeline' from u'C:/Program Files (x86)/Bazaar/plugins'
<jelmer> tetsuo--: did you manually install the pipeline plugin?
<tetsuo--> no
<tetsuo--> i just used the windows installer
<xnox> jelmer, Bug 569934
<ubottu> Launchpad bug 569934 in bzr "version-info --python doesn't match version-info" [Undecided,New] https://launchpad.net/bugs/569934
<jelmer> xnox: hi Dmitrijs
<jelmer> tetsuo--: it's probably a bug in the windows installer in that case, I suspect
<xnox> jelmer, I'm using waf which is nice python based system and for my upstream I just want to run "version-info --python" get that stream
<tetsuo--> aww :(
<xnox> jelmer, and import it inside waf and get svn-* info as a nice dict to add add in all C headers =)
<jelmer> xnox: I don't think abusing the rio hook for that is valid
<jelmer> xnox: at least not without changing the hook code to be generic and indendent of rio
<xnox> jelmer, well I've tried using svn-keywords and it gives me $ Id: (evoluation error) $
<xnox> my hacked up version of regular bzr-keywords does work but it erases working tree changes after $ bzr uncommit which is, well ugly & bad
<xnox> jelmer, renegalising hook to regular version info which all formatters subclass?
<tetsuo--> xnox:  do i need the pipleline plugin to be able to import svn into a bazaar tree?
<jelmer> xnox: something like that
<jelmer> tetsuo--: no, you don't need pipelines for that
<jelmer> xnox: can you file a bug about the keywords issue?
<xnox> jelmer, sure
<tetsuo--> ok deleting pipelines makes it work
<xnox> jelmer, BTW found out about svn-keywords yesterday even though it's been around for ages =) needs docs & blogging
<tetsuo--> should i create a shared repository?
<jelmer> tetsuo--: up to you, shouldn't matter for the import
<tetsuo--> ok
<tetsuo--> ok its working
<jelmer> xnox: I'd like it to integrate with bazaar itself better
<tetsuo--> holy moly bazaar-svn-client is fast
<xnox> jelmer, hmmmm so do I need to echo "svn-keywords = "Id Rev" into ~/.bazaar/rules or no for eg. [names *]
<xnox> tetsuo--, and you get whole history =) as well ;-)
<tetsuo--> toirtoisesvn only goes like 10kb/s max, the bazaar client is maxing out my download speed
<tetsuo--> bzr: ERROR: Unable to convert Subversion path trunk\src\apps\ShuttlePN31 because it contains characters invalid in Bazaar.
<xnox> tetsuo--, ask jelmer about that or search on launchpad.net/bzr-svn
<jelmer> tetsuo--: does that path exist as a filename in your repository?
<jelmer> tetsuo--: where the \ is part of the name, not used as a separator?
<jelmer> xnox: yeah, you have to edit ~/.bazaar/rules or .bzrmeta/rules
<tetsuo--> jelmer:  i dont see it in the current revision
<tetsuo--> its not on  the svn afaik
<tetsuo--> jelmer:  take a look here: https://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/apps
<jelmer> tetsuo--: what svn URL are you trying to import?
<tetsuo--> https://mpc-hc.svn.sourceforge.net/svnroot/mpc-hc
<tetsuo--> jelmer: any luck?
<jelmer> tetsuo--: still in progress
<tetsuo--> ok
<tetsuo--> jelmer:  what speed are you getting
<jelmer> tetsuo--: varies wildly
<tetsuo--> i was getting steady 600kb/s
<tetsuo--> i actually retried 3 times since giving you that link :s
<jelmer> tetsuo--: it imports fine here, no errors
<tetsuo--> wth
<tetsuo--> ok somethign is wrong here
<tetsuo--> i use the gui
<tetsuo--> lets try commandline
<tetsuo--> what did you use?
<jelmer> tetsuo--: bzr svn-import
<jelmer> (on the command-line)
<jelmer> that shouldn't really matter though..
<tetsuo--> this is what the gui does
<tetsuo--> Run command: bzr branch https://mpc-hc.svn.sourceforge.net/svnroot/mpc-hc D:/mpc-hc/trunk --use-existing-dir
<jelmer> tetsuo--: that's lacking a /trunk on the end of the first url
<tetsuo--> it does this first: Run command: bzr new --shared-repository --format 2a D:/mpc-hc/trunk
<tetsuo--> retry with modified url
<tetsuo--> jelmer:  looks like its working now, and its super slow again :(
<tetsuo--> got it!
<tetsuo--> lol bazaar client crashed
<bialix> somebody confirm my understanding: post_commit hook invoked after the local commit succeed?
<tetsuo--> bzr: ERROR: exceptions.AttributeError: 'BzrBranch7' object has no attribute 'startswith'
<bialix> pstebin
<bialix> pastebin
<tetsuo--> http://pastebin.com/n5kxTfsX
<tetsuo--> after ignoring that error it seems to work now
<tetsuo--> ok so my bzr client now has a full local bazaar branch of the svn, how can i push it exactly like this to sourceforge?
<a212901390231901> looks like a genuine bug, shame can't see what put the bum entry in the registry from that stack
<bialix> tetsuo--: how you managed to get this error?
<tetsuo--> using the windows client with pipeline plugin deleted, i created a branch from my svn project, then i went to a subfolder and did "rightclick --> Show log"
<tetsuo--> it generated the error right after clicking that
<tetsuo--> all in the bazaar gui
<bialix> tetsuo--: please, file a bug against https://launchpad.net/bzr-explorer project.
<tetsuo--> id ont have a launchpad account :X
<tetsuo--> All 1.10 features of bzr are supported.   << that probably means the 2.0 file system will fail?
<bialix> where it's from? (All 1.10 features of bzr are supported)
<tetsuo--> sourceforge
<tetsuo--> https://sourceforge.net/apps/trac/sourceforge/wiki/Bazaar
<bialix> tetsuo--: that basically means they've added support for bzr when bzr 1.10 was released
<bialix> you need to ssh to the server and run `bzr version` to see what actual version there
<bialix> but the safe assumption is that you should not use 2a branch format and use 1.9 format instead.
<bialix> I think this page is out-of-date
<tetsuo--> i checked, they never updated past 1.10
<tetsuo--> well i asked the staff
<tetsuo--> :P
<bialix> :-/
<tetsuo--> i had to open a ticket so they can update to 2.1 stable
<bialix> 1.10 is ~1.5 years old
<tetsuo--> will probably tak ages
<bialix> 2.0.x is good as well
<tetsuo--> what does launchpad use?
<bialix> this page https://code.launchpad.net/ said 2.1.0
<tetsuo--> ok
<GaryvdM> Hi bialix
<bialix> hi Gary! how are you?
<GaryvdM> Good. Just been very busy. You?
<bialix> me is very busy too.
<bialix> planning to finish urgent stuff to be free for UDS
<bialix> GaryvdM: right now trying to work on bug 419758
<ubottu> Launchpad bug 419758 in qbzr "File menu: add MRU files list" [High,In progress] https://launchpad.net/bugs/419758
<bialix> GaryvdM: I've provided universal post_commit hook and will store the data in ~/.bazaar/commit-history
<bialix> I know bzr-gtk don't want to use our approaches, but just in case
<GaryvdM> bialix: I see
<tetsuo--> is there a wiki page explaining the difference between the various file system versions?
<GaryvdM> File system versions?
<tetsuo--> yeah, when create a new repository it asks me which version to use between 1.x, 1.9 and 2.x
<Peng_> "it"? What does?
<GaryvdM> Ah repository formats
<Peng_> tetsuo--: 1.x, whatever that means, is less awesome than 1.9, which is less awesome than 2.0.
<tetsuo--> that
<tetsuo--> but what are the real differences
<bialix> tetsuo--: use 1.9
<tetsuo--> since i can only use 1.x with sourceforce i want to know what im missing
<Peng_> tetsuo--: The nitty-gritty doesn't matter very much. Use the newest one you can. For example, if your coworkers run bzr 1.12, you'll have to use 1.9.
<Peng_> tetsuo--: 2a is significantly faster, smaller and more RAM efficient (well, not all the time for the last one).
<GaryvdM> tetsuo--: see bzr help current-formats
<GaryvdM> tetsuo--: http://paste.ubuntu.com/422868/
<tetsuo--> ok ic
<bialix> GaryvdM: ping
<GaryvdM> bialix: pong
<bialix> do you have 5 minutes? take a look on the sketch design http://bazaar.launchpad.net/~bialix/qbzr/post-commit/annotate/head%3A/lib/commit_history.py ?
<tetsuo--> can i convert a 2.0 to 1.x ?
<GaryvdM> bialix: Is this related to bug 419758?
<ubottu> Launchpad bug 419758 in qbzr "File menu: add MRU files list" [High,In progress] https://launchpad.net/bugs/419758
<GaryvdM> tetsuo--: You can convert 2.0 to 1.0 rich-root, but not to 1.0 non-rich-root
<bialix> GaryvdM: yes, this is commit history to use in qcommit
<tetsuo--> oh the erorr was about rich toot
<tetsuo--> root
<tetsuo--> Run command: bzr push "bzr+ssh://tetsuo55@mpc-hc.bzr.sourceforge.net/bzrroot/mpc-hc " Connected (version 1.99, client OpenSSH_5.2)
<tetsuo--> bzr: ERROR: Permission denied: "bzrroot/mpc-hc /": : [Errno 13] Permission denied: '/bzrroot/mpc-hc '
<bialix> GaryvdM: I'm going to home, will be online again after 30-40 minutes.
<tetsuo--> wrong error
<GaryvdM> bialix: just a sec
<tetsuo--> bzr: ERROR: RemoteRepository(bzr+ssh://tetsuo55@mpc-hc.bzr.sourceforge.net/bzrroot/mpc-hc/.bzr/) is not compatible with CHKInventoryRepository('file:///D:/bzrtest/.bzr/repository/') different rich-root support
 * bialix waiting
<GaryvdM> bialix: I'm confused. bug/419758 talks about locations, but CommitHistory deals with messages
<bialix> GaryvdM: err, maybe. see my last comment to that bug
<GaryvdM> ok
<GaryvdM> I'll be up till late.
<GaryvdM> I'm at work because my home dsl is down...
<tetsuo--> maybe i can just change the rich root setting?
<GaryvdM> tetsuo--: you have 2 options:
<GaryvdM> tetsuo: upgade the branch on sourceforge.net, but only do this if you have consulted the projects other members.
<tetsuo--> its new
<tetsuo--> empty right now
<GaryvdM> tetsuo: and option 2:
<GaryvdM> receate branch with non-rich-root format.
<tetsuo--> so basically i have to start over, and make a new local branch with the lower version
<GaryvdM> tetsuo: I its a new, maybe option 1 is better
<tetsuo--> how can i do that?
<GaryvdM> tetsuo--: bzr upgrade bzr+ssh://tetsuo55@mpc-hc.bzr.sourceforge.net/bzrroot/mpc-hc/.bzr/ --2a
<GaryvdM> sorry
<tetsuo--> that wont work
<tetsuo--> :P
<GaryvdM> tetsuo--: bzr upgrade bzr+ssh://tetsuo55@mpc-hc.bzr.sourceforge.net/bzrroot/mpc-hc/ --2a
<tetsuo--> the sf server is based on a lower than 2 version
<GaryvdM> sorry, then you'll have to start again.
<GaryvdM> wait...
<tetsuo--> just in time
<GaryvdM> You can do :
<GaryvdM> tetsuo--: bzr upgrade bzr+ssh://tetsuo55@mpc-hc.bzr.sourceforge.net/bzrroot/mpc-hc/ --1.14-rich-root
<tetsuo--> dude it worked
<GaryvdM> :-)
<tetsuo--> the first command did work
<tetsuo--> 300mb :O
<tetsuo--> i guess ill get some coffee this is going to take some time
<tetsuo--> GaryvdM:  does this look right? mpc-hc.bzr.sourceforge.net/bzr/mpc-hc/
<tetsuo--> that is supposed to the the master
 * GaryvdM looks
 * GaryvdM is very worried
<GaryvdM> http://mpc-hc.bzr.sourceforge.net/bzr/mpc-hc/changes
<GaryvdM> This does not  look like a new branch
<GaryvdM> tetsuo-- ^
<GaryvdM> tetsuo--: sorry. I guess you thought that you branch was new. You teem mates will need to upgrade their branches before they can pull.
<GaryvdM> tetsuo--: Are you still there?
<tetsuo--> still
<tetsuo--> here
<tetsuo--> i created that bazaar an hour ago, sf must auto fill it with some crap
<GaryvdM> oh - I see
<GaryvdM> Hi biailx
<tetsuo--> do i need to run any special commands to make other peoples bzr clients realise this is the master?
 * bialix back
<GaryvdM> Master?
<tetsuo--> i guess thats a git term
<GaryvdM> tetsuo--: http://paste.ubuntu.com/422912/
<GaryvdM> tetsuo--: The parent branch is the svn branch,
<tetsuo--> i want bazaar to be the new parent
<GaryvdM> Bialix: would this not solve your problem: http://bazaarvcs.wordpress.com/2009/07/20/qcommit-pending-merge-info/?
<tetsuo--> probably doesn't really matter though
<bialix> GaryvdM: not really
<GaryvdM> tetsuo--: when some one branches the bzr branch on to their machine, then the bzr branch will be the parent branch in their branch.
<tetsuo--> ok good
<GaryvdM> bialix: If it's the messages of pending merges you are interested in, then you can get them from the repo?
<bialix> GaryvdM: no no no, not only pending messages
<bialix> sometimes I need to commit in several related branches with similar commit message
<bialix> pending merge is only part of the problem
<GaryvdM> bialix: ok - I see
<bialix> GaryvdM: I like your qdiff with message, but it often slow :-(
<bialix> the diff itself is slow
<bialix> while I've went to home I've realized I need to extract the add logic to base MRU class
 * bialix -> dinner
<nvictor> hello
<GaryvdM> hello
<marv> I haven't used darcs, but I was reading about it's spontaneous branches. can bzr do anything like that?
<dash> marv: spontaneous?
<dash> you mean you sit down to your editor one day and discover some new branches grew when you were asleep? :)
<marv> http://wiki.darcs.net/SpontaneousBranches explains it
<marv> What i was actually thinking to myself was: it would be nice if i can assign tags (like a website's tag cloud, not like how you normally think of tags) to specific commits to say something like these 3 commits are a part of this particular bug fix.
<marv> then i read about darcs spontaneous branches and that sounded pretty close to what i thought i wanted
<LeoNerd> Oh, no.
<LeoNerd> bzr's history is linear in a branch. 1 -> 2 -> 3 -> 4
<LeoNerd> revision 4 is just a change on top of revision 3.
<LeoNerd> You can't come along and suddenly afterwards decide that changesets 3, 19 and 24 are really a branch on their own. That can't work, because 24 requires 23, ....
<LeoNerd> darcs is built on commutability and non-linearity of patches, which allows exactly that scheme to work.
<tetsuo--> woah bazaar windows client just crashed with a memory error (it tried to read/write to executable memory)
<tetsuo--> http://pastebin.com/ThPyg4qF
<tetsuo--> occured after pressing refresh
<tetsuo--> submitted to winqual
<tetsuo--> any windows client devs online?
<tetsuo--> its easy to get access to winqual, just need to enable some compile-time switches and get a certificate
<marv> does that really matter? i know darcs talks about this theory patches and all that stuff. but I don't see why you couldn't have the same feature on top of bzr. But I guess that answers my question of whether or not it can already do that
<GaryvdM> tetsuo--: bzr explorer?
<tetsuo--> yes
<dash> marv: the usual thing to do in bzr is to shove stuff off into a real branch when you notice you need to
<dash> by creating a branch and using bzr merge --uncommitted
<marv> I don't even really want to treat them as a branch for most purposes. I just want to be able to say that revisions x, y, an z are for the same new feature, give it a name, and later ask for it by name, without having to deal with making it a separate branch and then merging it,  when really it belongs in the mainline to begin with
<dash> that strikes me as very odd. :)
<marv> that's probably why nothing really supports doing that
<marv> what I have is a bunch of patches on top of a source tree that's maintained by someone else. And I'm trying to come up with a better way of managing it. we used to just use svn and commit our changes directly. and that made pulling in upstream changes very difficult
<dash> Ah.
<dash> loom or pipeline might be handy.
<marv> then i switched to git, and made each thing it's own topic branch
<marv> and that has become a real pain to manage
<marv> and there's like 4 people who need to work on it, but i'm the only one who understands the topic branch scheme or how to use git
<marv> so I want to switch to bzr just because it looks a lot easier to use. but i'm also trying to come up with a better way to do things
<LeoNerd> 1 branch per bug. 1 branch per feature
<LeoNerd> Branches are cheap. really cheap. Within one shared repo, they're just a reference to the tip at their branchpoint.
<marv> I haven't looked at pipeline. i've looked at loom and talked to someone here about it, but decided it wasn't a good choice
<marv> branches aren't cheap in terms of doing the checkout, waiting for the code to compile, checking in the fix, then merging the fix
<marv> i've been doing 1 branch per bug or per feature (although I've been doing it in git), and I find myself just not wanting to do it anymore
<marv> which makes it really hard to convince anyone else to do it
<marv> pipeline looks like it might be a little nicer than loom
<marv> but i still think i would be better off with a "tag cloud" system more how I described. Maybe i'll look into how hard it would be to do a plugin like that
<GaryvdM> Any udd experts here.
<GaryvdM> *?
<GaryvdM> I'm updated the bzr beta ppa.
<marv> Why is there both pipepine and loom? they look to be almost the same thing
<dash> marv: pipeline is new and wants to be better, i guess :)
<marv> ok, i thought it might be something like that :)
<GaryvdM> going to each branch for each ubuntu version and merging debian unstable is laborious.
<jam> marv: I use a lightweight checkout and a shared treeless repository, which is very similar to a git layout (multiple branches sharing the same wt)
<jam> that avoids having to recompile all your code
<GaryvdM> I'm I doing this the right way? Is there an eaiser way?
<jam> and avoids having to checkout the files from scratch
<jam> pipeline works by basically requiring a lightweight checkout, and automating some bits when you want to have branches depend on eachother
<tetsuo--> pipeline is broken on windows though :(
<jam> marv: pipeline is focused differently than loom
<jam> some small yet fundamental differences of opinion
<jam> for example, pipeline assumes your upstream is implicit (it isn't in the pipeline) loom explicitly records an upstream
<jam> loom wants to create a structure that you could then merge with another person
<jam> pipeline assumes you work on the stuff all by yourself (you can't share pipelines)
<jam> (well, you sort of could, but you don't get to diverge from eachother)
<marv> jam: oh ok. well if other people can't use it with me, it doesn't do me much good. that was the reason why i didn't use the quilt like thing in git
<jelmer> 'evening
<GaryvdM> Hi jelmer
<GaryvdM> jelmer: You might be able to help me.
<GaryvdM> I would like to update the ppas
<jelmer> GaryvdM: sure, what's up?
<GaryvdM> Merging each branch for each version of ubuntu, with debian unstable is laborious.
<GaryvdM> Am I doing the right thing? Is there an easier way?
<GaryvdM> jelmer ^
<jelmer> GaryvdM: you could use the web interface to copy the packages?
 * GaryvdM looks
<GaryvdM> jelmer: Thanks - I'm going to try that.
<jam> morning mwhudson
<mwhudson>  jam hi
<jam> I just put up about 5 hopefully 'bite-sized' changes to loggerhead which would be nice if you could review
<jam> it drops the time to load emacs/changes from >600ms => 215ms on my machine (once the cache is loaded, etc)
<jam> I mostly mention it because I know igc is out most of this week
<jam> Peng: ^^ I suppose you're one of the loggerhead reviewers, too
<Peng_> I saw the one about an option to disable the merge point thingies. Cutting features out instead of finding magic performance knobs makes me a bit sad.
<jam> Peng_: it defaults to False
<jam> sorry, True
<jam> it defaults to leaving the feature in
<jam> I don't think it specifically affects the perf times for loading "changes"
<jam> since those revs aren't shown
<jam> if you want to see them all together
<jam> lp:~jameinel/loggerhead/integration
<Peng_> Nonetheless it makes me sad.
<jam> Peng_: and that is the only one that is a 'feature removal' vs just a 'stop doing work that we don't use"
<Peng_> Oh. Good.
<Peng_> Yuhh, don't have Thunderbird open right now.
<jam> confirmed, show_merge_points = True still gives 210ms for emacs
<jam> at this point, getting the information takes ~ the same amount of time as rendering
<jam> so the changes to use chameleon or whatever would start to show
<cody-somerville> odd
<cody-somerville> $ bzr bind :push
<cody-somerville> bzr: ERROR: Not a branch: "/home/cody-somerville/Projects/launchpad/lp-branches/bug-444266/lp:~cody-somerville/launchpad/bug-444266/".
<cody-somerville> but bzr info has:     push branch: lp:~cody-somerville/launchpad/bug-444266
<beuno> cody-somerville, I'm guessing you have something in your locations.conf
<cody-somerville> beuno, yea, http://pastebin.ubuntu.com/423045/
<beuno> cody-somerville, so that's why
<cody-somerville> Thats just the standard rocketfuel stuff
#bzr 2010-04-27
<poolie> hi all
<jbowtie> Hey, is there any reason the Sphinx template doesn't look like the wiki? Should I update it?
<poolie> hi jbowtie, the one for docs?
<poolie> no good reason; we'd like to make the themes for the main site, the wiki and the docs more consistent
<jbowtie> poolie: Yes; I was just thinking it would be nice to make things consistent.
<poolie> the www site is the most recent and arguably the best
<poolie> though improvement there is still possible
<jbowtie> poolie: OK, I'll have a look at rolling a Sphinx template this week along with fixing as many doc bugs as possible.
<poolie> that would be brilliant
<poolie> it doesn't need to slavishly follow the main site
<poolie> for example i think the left-side table of contents is useful and should stay
<poolie> but if we could at least get consistent tabs across the top that would be good
<poolie> it may help if you post screenshots as you go
<jbowtie> poolie: I'm looking at the tabs across the top and the footer at the bottom.
<jbowtie> poolie: As well as coordinating fonts and colors.
<jbowtie> poolie: Good point, I'll attach some screenshots to the bug when I make my merge proposal.
<jbowtie> Looking at #405452 - what's a "ghost" revision?
<jelmer> jbowtie: it's a revision that Bazaar knows about but that is not present in the repository
<jelmer> jbowtie: so for example a parent revision of some revision that is present in the repository could be missing
<jelmer> jbowtie: ghosts are usually created when importing revisions from baz or subversion
<jelmer> jbowtie: but they could also be created using a (hypothetical) command in bzr
<mwhudson> jelmer: since we rolled out the bzr-git update, it seems a few imports now fail with:
<mwhudson> bzrlib.plugins.git.errors.NoSuchRef: The ref master was not found.
<mwhudson> jelmer: any instant ideas?
<jelmer> mwhudson: my guess would be that these repositories do not have a master branch :-)
<mwhudson> jelmer: the imports worked before the rollout though
<mwhudson> jelmer: see https://code.edge.launchpad.net/~cjwatson/packages-arch-specific/trunk
<mwhudson> has bzr-git become more careful about this?
<jelmer> mwhudson: yeah, we've become a bit stricter
<mwhudson> jelmer: ok
<jeremy_c> If I create a project on launchpad.net, can I remove it later or is it like SF.net, once it exists, it lives forever?
<mwhudson> jeremy_c: you have to ask an admin to have it removed, but it's not a big deal
<jeremy_c> I wanted to give it a try for a while but be able to backout if it doesn't seem like it's working out after a few weeks.
<parkesy> Hi I've got some problems with my bzr branch,  I get  "bzr Error: Revision {...} not present in CHKInventoryRepository(...) is there a way to repair this
<jelmer> parkesy: when do you get these errors exactly?
<parkesy> jelmer: when i do bzr log
<jelmer> parkesy: immediately or after a few revisions?
<parkesy> jelmer: the first time it was a few seconds after now it is immediately
<parkesy> jelmer: it also happens with bzr version-info
<jelmer> parkesy: but after a few revisions?
<parkesy> jelmer: sorry, it just started happening over night, it was fine on friday, then when i came into work today its failing.
<parkesy> jelmer: I tried to fix it myself and had to get the Sysadmins to restore my working branch from a backup taken over the weekend.
<mkanat> igc or mwhudson: Are you guys going to merge https://code.edge.launchpad.net/~mkanat/loggerhead/synchronize-lru_cache/+merge/23977 ?
<mwhudson> mkanat: i guess i will unless Peng_ beats me to it
<mkanat> mwhudson: Okay.
<Peng_> Go ahead. I'm busy watching TV. :P
<Peng_> mwhudson: ^
<Peng_> Is mkanat a member of loggerhead-team?
<mwhudson> done
<mkanat> Peng: I'm not.
<mwhudson> mkanat: want to be?
<mkanat> mwhudson: Oh, um, sure. :-) You'll have to educate me on checkin procedures and so on.
<Peng_> Nah, there's not much to educate on.
<mwhudson> well, merge into trunk, then push
<mwhudson> rather than merging trunk into your branch then pushing that to trunk
<spiv> Good morning.
<Peng_> You should also commit!
<mwhudson> but i'm sure you wouldn't be that tasteless anyway
<mkanat> Peng_: Okay. :-)
<mkanat> I mean, mwhudson.
<mkanat> Peng: Hahah, yes, committing would help.
<mkanat> spm: You might want to update to trunk loggerhead again to get that fix we just pushed. It's one of the crashers.
<spm> mkanat: okis, ta
<mkanat> spm: BTW, has loggerhead stayed up since the pygments fix?
<spm> hrm. not sure. looking...
<mkanat> spm: I think I'm more or less going to become the contact for loggerhead stability, so any time there's crashes or hangs, I'd love to know.
<spm> mkanat: nod; I'll pass that on.
<spm> it's been up for about 9 hours atm :-)
<spm> not sure what the cause was there
<mkanat> spm: Heh. Okay.
<spm> unresponsive restart; two of 'em.
<mkanat> spm: Would you send me the log from before the restart?
<spm> 2010-04-26 15:30 & 2010-04-26 08:28 <== bot hUTC
<spm> sure
<spm> mkanat: sorry. not forgotten, just had to progress a high priority task. just fetching logs now.
<mkanat> spm: Okay, no problem. :-)
<santagada> hi I think I found a bug on bzr, it is actually and old hack for osx that I think it is not necessary anymore
<santagada> and it makes bzr break on top of pypy
<spiv> santagada: oh good.  :)  Please file it at https://bugs.launchpad.net/bzr
<spiv> santagada: how close is bzr to running on pypy?
<santagada> spiv: run it is running, now I would love to run a test suite to see if there isn't any bugs in it
<santagada> spiv: how do I run bzr unittests?
<spiv> santagada: bzr selftest
<poolie> hi spiv
<santagada> i need testtools... just a sec I will first finish filling the bug report
<spiv> santagada: to be pedantic, that runs the full automated test suite.  Many of those can be accurately called unit tests, but many are integration tests.
<spiv> Morning poolie.
<santagada> spiv: so I will be happier if it works
<spm> mkanat: mwhudson: ew! this looks .. bad: ERR [20100423-23:59:43.593] [1101093200] root: RuntimeError: maximum recursion depth exceeded
<mwhudson> spm: i _think_ Peng_ fixed that
<spm> urg even. there's a few in teh debug log
<santagada> bzr has a mbp and hg team has one mpm, I wonder how many times people confused the two nicks/people
<spm> santagada: probably about as often as spm and spiv :-)
<mkanat> spm: I think that's a python bug?
<mkanat> spm: Does it say it's being ignored?
<spm> mkanat: not that I can see; but it is in the older log = the access and debug aren't rotating at the same time. only just noticed that was from Fri; not today.
<mkanat> spm: Okay.
<santagada> spiv: https://bugs.launchpad.net/bzr/+bug/570495 if there is any more needed info just ask :)
<ubottu> Ubuntu bug 570495 in bzr "bzr should not change sys.platform or should limit it to the affected python versions" [Undecided,New]
<santagada> spiv: bzr: ERROR: No module named paramiko can't I just skip those testes?
<a212901390231901> fixed in r5165 so pull bzr.dev
<spiv> santagada: hmm, they should be automatically skipped if the module isn't found.  I think you might be encountering a recently fixed bug.
<santagada> spiv: I'm using a tarball for 2.1.0
<santagada> the bzr repo is huge
<spm> mwhudson: ew. ERR [20100426-09:20:07.255] [1120741712] root: ConnectionError: Connection error: Couldn't resolve host 'bazaar.launchpad.net' (-2, 'Name or service not known') <== that so can't be good.
<mwhudson> spm: i'd agree with that
<mwhudson> spm: i'd also apply the SEP field from my POV
<mwhudson> if DNS isn't working in the data centre....
<spm> there's a heap of them in the debug log
<spm> ha
<spm> mwhudson: what's a strong I can search for "Oh Hai. loggerhead is now starting up"??
<spm> err string, strong string even
<spiv> santagada: hmm, that fix hasn't been backported to the 2.1 branch, it's just on trunk
<mwhudson> spm: "Starting up..." i think
<spm> too bloody obvious. can't possibly be that.
<santagada> spiv: also not on 2.2b1 :( cloning the whole repo now
<spm> mwhudson: 'loggerhead: Starting up...' haha
<a212901390231901> don't think I daggied it either as the previous attempt blew up the push
<a212901390231901> trivial diff to cherrypick though
<spiv> santagada: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5165
<spiv> santagada: you can view/download just that diff from there if you like... but probably having a copy of trunk will turn out to be worth it if you find more issues to fix
<santagada> yep... how big is it? it is more than 50mb
<a212901390231901> was going to suggest a lightweigth checkout, but my test run is... still running
<a212901390231901> B:\TEMP>bzr co --lightweight lp:bzr bzr.dev
<a212901390231901> [########\           ]  21179KB   107KB/s | Build phase:Adding file contents 1163/1296
<a212901390231901> so, not much of a transfer saving.
<santagada> a212901390231901: thanks for the help but now I will just let it finish
<spiv> santagada: shouldn't be much more than 50
<spiv> a212901390231901: yeah, we haven't really spent much time optimising creating lightweight checkouts via the smart protocol yet
<a212901390231901> seems the tree is really that big, too.
<spiv> (or updating them, for that matter)
<spiv> Yeah, "bzr export bzr-trunk.tar" gives me a 21M tarball.  It compresses down to 6.4M with gzip though.
<spm> mkanat: ow. http://paste.ubuntu.com/423106/
<mkanat> spm: Lame.
<spm> heh, does explain why I was having trouble find the '2nd' start. was 2 mins later.
<santagada> the full repo is 60mb or a little more
<santagada> I didn't see the ending
<santagada> the tests are running
<santagada> lots of failures
<a212901390231901> it had big problems with unicode filesystem access when I looked at it, but that might be less of an issue on nix
<santagada> uhm... it completely froze [1017/23179 in 40s, 1766 failed] blackbox.test_serve.TestCmdServeChrooting.test
<santagada> a212901390231901: yep, most of the errors are unicode related
<a212901390231901> ...that one's probably not its fault, all the server tests are flakey
<a212901390231901> rely on refcounting and spit to hold them together
<santagada> I will report some to pypy and someday maybe there can be a buildbot running bzr tests
<santagada> a212901390231901: ok, so it will probably not happen
<spiv> santagada: we're aware that our server tests have some flakiness, we'd like to fix that.
<santagada> I'm getting a ton of NotBranchError: Not a branch: "/private/tmp/testbzr-fP73Gq.tmp/"
<spiv> It's biting us in regular use too, we often seem to be leaking threads from tests that spawn servers, and that can lead to spurious failures due running out of fds and similar.
<spiv> (And probably makes 'bzr selftest' consume more memory than necessary, etc)
<santagada> no I think the real failure is this:
<santagada> File "/Users/santagada/projects/bzr/bzrlib/config.py", line 940, in _auto_user_id
<santagada>     gecos = w.pw_gecos.decode('utf-8')
<santagada> AttributeError: 'NoneType' object has no attribute 'decode'
<a212901390231901> that's fixable.
<spiv> Interesting that we haven't encountered that one before, but yes should be easy to fix.
<poolie> there's another bug asking to just remove auto_user_id
<poolie> that would be better imo
<spiv> Yeah.
<spiv> Certainly there's no need for the test suite to be triggering it for every test as I suspect it does.
<poolie> erk
<a212901390231901> I was going to file a bug complaining about it, and parse_username, which combine to do some very silly things
<santagada> heres the full traceback if someone whants to have a go at it http://paste.pocoo.org/show/206563/
<spiv> After all it resets $BZR_EMAIL etc :)
<santagada> it appears to be run on all tests, and when it fails I get that notbrancherror probably in another thread if I understood correctly
<spiv> santagada: what about this patch: http://bzr.pastebin.com/3EtrtFUu ?
<santagada> invalid syntax for some reason
<spiv> Oh, missing trailing comma
<spiv> My bad for not testing.
<santagada> yep, let me fix that
<santagada> a TON less failures
<santagada> 2 failed thus far
<spiv> Hmm, a quick run of the test suite finds a little bit of collateral damage (e.g. blackbox.test_annotate.TestSimpleAnnotate.test_annotate_edited_fileedited_file)
<spiv> But that's a good sign.  It's probably a touch faster, too ;)
<santagada> unsuported locale setting... uhm maybe pypy _locale is not working as expected
<santagada> spiv: is those tests results being saved anywhere?
<spiv> santagada: my test results?  No, but I can if you like.  I only ran the blackbox tests, as they seemed most likely to fail, and in the end got 3 failures.
<santagada> nope the ones I'm running
<spiv> Oh right.  Not by default.
<santagada> as there is this status line I don't know what whill happen if I redirect stderr to a file... but I should be doing that..
<spiv> If you use --subunit you'll get the test run emitted in a machine-readable format.
<spiv> (You can use the subunit2pyunit filter in the subunit package to see the output in a familiar format)
<spiv> It'll be a pretty large file (it includes details of the passing tests, too), but it should gzip pretty well.
<santagada> well 22 failures out of 1545 tests run, not too bad
<poolie> spiv, do you think user_url and control_url etc are reasonable names?
<spiv> Yes.
<spiv> Especially user_url!
<poolie> mm, a big clue that if you're showing it to the user you should use that one :)
<Peng_> Ack! I just remembered that I meant to reply to an email like a month ago.
<Peng_> It said "let me know this week". :(
<Peng_> (My answer was no anyway, so it doesn't matter, but sorry for forgetting to decline the Brussels sprint, poolie.)
<santagada> had to kill the selftest process it stopped responding completely
<santagada> in test "per_bzrdir.test_bzrdir.TestBzrDir.test_sprout_bzrdir_tree_branch_reference(RemoteBzrDirFor"...
<poolie> Peng, ok, thanks anyhow, maybe next time
<poolie> spiv, could i get a quick eyeball over https://code.edge.launchpad.net/~mbp/bzr/testsubjects/+merge/24188
<spiv> Sure.
<lifeless> poolie: I'd like to do a pre-imp call with you on test subjects :- I'd like to clarify what you want to achieve and see if I can help you with that.
<lifeless> poolie: if that wouldn't help you, say no thanks :)
<poolie> uh, ok
<poolie> call me?
<lifeless> I'll just see if I've got skype on this machine yet
<lifeless> one minute
<poolie> do you have a pots line?
<vila> hi all
<GaryvdM> Morning
<poolie> hi vila, gary
<vila> hey GaryvdM
<vila> hi poolie
<vila> Did anybody (else than me) testing bzr on lucid have a failure for bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh ?
<poolie> oh lifeless, where did we eventually get to with pqm?
<poolie> vila, not me, yet
<vila> poolie: hmm, too bad, you were my best hope :)
<poolie> i'll try it
<vila> poolie: running just this test alone is enough here, I'm wondering if my setup is somehow screwed or if it's something deeper
<poolie> no actually i do get that too
<poolie> i suspect either a change in ufw
<poolie> which i think i'm running here
<poolie> or an icky order dependency
<lifeless> poolie: spm says no exceptions in pqm since the 24th
<Peng_> vila: FWIW, PyCrypto doesn't like fork()ing the random number generator because both processes will wind up with the same state, which is not very random. IIRC it also has thread-safety issues.
<vila> Peng: yup, but nothing we care about for tests, thanks for the info though
<bialix> hi all
<vila> lifeless: no execptions doesn't mean no pending bugs, there are still no feedback on failures
<vila> (among other things)
<GaryvdM> Hi bialix
<vila> bialix: _o/
<bialix> Heya GaryvdM !!!
<bialix> bonjour vila!
<bialix> GaryvdM: I have strnge problem with qpush
<poolie> lifeless: ok, but what's the state now? still running with lp integration, or pulled down?
<bialix> GaryvdM: push to lp (when no ssh key is loaded to pageant) blows with traceback
<GaryvdM> Traceback
<bialix> GaryvdM: http://pastebin.com/EDdekYpm
 * GaryvdM looks
<bialix> the most strange thing is when I set BZR_PDB=1 then qpush simply hangs
<bialix> it's in qpush
<bialix> my problem is BZR_PDB related
<lifeless> poolie: running with integration
<lifeless> vila: I will look at that tomorrow
<vila> lifeless: be blessed :D
<poolie> you didn't pull it out on thursday?
<lifeless> it was behaving much better
<poolie> k
<lifeless> emailed submissions get mailed failures I think now
<bialix> GaryvdM: do you (we) change something in qbzr that broke BZR_PDB you made long ago?
<GaryvdM> bialix: hmm - you need BZR_PDB on for the qbzr process, but not for the subprocess
<bialix> or maybe it's a newer bzr issue
<GaryvdM> not sure how to do that.
<bialix> GaryvdM: so you think it's a subprocess starting pdb session?
<bialix> hmmmmmmmmmmmmmmmm
<GaryvdM> yes - before the main process errors
<bialix> I don't understand what's going on
<bialix> the plain push never raise error?
<bialix> or there is some hidden bug in our subprocessUI class?
<GaryvdM> bialix: what about running bzr qsubprocess push
<bialix> oh, I think I understand
<bialix> \n issue
<GaryvdM> I do that often to debug qsubprocess
<bialix> again :-(
<bialix> bzr produce multiline error message
<bialix> bzr: ERROR: Connection error: Unable to authenticate to SSH host as
<bialix>   bialix@bazaar.launchpad.net
<bialix> supported auth types: ['publickey']
<GaryvdM> Oh - my new error passing code :-(
<bialix> but we're trying to send it as one string
<bialix> ok, I understand the problem now
<bialix> our bencode stream is very fragile re \n
<bialix> we have to encode them somehow, or manually split the string into multiple strings
 * bialix filing a bug
<bialix> GaryvdM: any ideas re BZR_PDB in subprocess? maybe we should manually delete this variable from subprocess environment?
<GaryvdM> That would be a good idea.
<GaryvdM> And if one needs to debug the subprocess, then one can just run the subprocess.
<poolie> spiv, still here?
<bialix> GaryvdM: agree
<spiv> poolie: yeah
<vila> lifeless: I don't think I got test failures even for my mail submissions (at least I can't find the relevant mail for https://code.edge.launchpad.net/~parthm/bzr/no-chown-if-bzrlog-exists/+merge/22197 and I'm pretty sure I submitted by mail)
<poolie> spiv i split out the cleanup change into https://code.edge.launchpad.net/~mbp/bzr/cleanup/+merge/24200
<vila> lifeless: I only got failure mails for the NEWS conflicts and the 'nothing to merge' cases
<poolie> i have mixed feelings about whether this patch is worthwhile
<bialix> poolie: hi :-)
<poolie> spiv: istm that some other objects, like a test case, can make use of the concept of having a list of cleanups
<poolie> and that it's not part of their public interface to expose a single run()
<poolie> but perhaps the answer is that they should just us an OperationWithCleanups internally
<spiv> poolie: Command as well as TestCase
<spiv> poolie: although I think we now delegate the cleanup management in TestCase to testtools?
<poolie> probably
<poolie> though there, ideally, if not practicalyl, this same class would be used by all of them
<spiv> Oh, and commit.Commit, slightly weirdly perhaps, psuedo-does.
<spiv> (it doesn't have an add_cleanup method, instead it passes the operation var around, but in general seems a bit confused about if it's an object with state or a bunch of related functions with intimate knowledge of each other's workings)
<WimYedema> Hi all
<WimYedema> Can anyone tell me how to change the default editor for editing project files?
<WimYedema> Setting the editor in prefs seems to work only for config files
<WimYedema> sorry
<WimYedema> in bazaar explorer
<poolie> WimYedema: is this in explorer?
<WimYedema> :/
<spiv> poolie: Btw, you may like https://code.edge.launchpad.net/~spiv/bzr/hpss-compat-528041/+merge/24202 â it removes the raise AssertionError in _remember_remote_is_before
<lifeless> vila: I will experiment in detail tomorrow when spm is around
<spm> lifeless: pls being ware we have zomg priorities atm....
<lifeless> spm: and at a time of your choosing
<poolie> WimYedema: I don't know off hand
<spiv> spm: the LTS can wait, surely? :P
<lifeless> spm: primarily though I'll be throwing known bad stuff at it and just asking for backtraces to be pastebinned
<WimYedema> I think I can edit editors.conf but it seems I need to add an extension there, and I don't much feel like adding all the possible extensions (never mind things without extension)
<spm> spiv: ....
<spm> lifeless: we should so get you access to the logs...
<vila> spm: +1e6
<lifeless> spm: that would be nice; I mean I used to be able to log in to diagnose directly ;)
<poolie> WimYedema: I _think_ it's configured at the os level
<poolie> and explorer has no opinion
<WimYedema> poolie: Hmm... okay, unfortunately Gnome doesn't seem to have a prefered text editor application. I'll try setting EDITOR then...
<bialix> WimYedema: please, file a bug
<WimYedema> bialix: okay
<poolie> yeah it's definitely by extension
<poolie> which was a bit strange
<bialix> GaryvdM: btw, I have working code for commit-history, now I need to figure out how to fill the combobox with pending merges messages. Any hints?
<GaryvdM> bialix: The autocomplete combobox?
<poolie> $EDITOR should control it
<bialix> GaryvdM: I feel simple combobox will be much easier and faster to use than qdiff + message. Just because I don't need to launch qdiff window, select, copy, close window and paste
<bialix> GaryvdM: but your qdiff+message is very good, I think we can do it every time for qdiff -cN
<bialix> GaryvdM: it's not autocomplete
<bialix> user select message in combobox and it appended to the comment
<poolie> WimYedema: setting editor= in your bazaar.conf should do it
<WimYedema> setting either EDITOR or BZR_EDITOR does not seem to have any effect
<GaryvdM> bialix: I'm not to sure about adding extra widgets to qcommit....
<WimYedema> poolie: nope, that's what the preferences menu sets, but it doesn't help
<poolie> what does happen then?
<WimYedema> it starts gedit
<bialix> GaryvdM: it's only one-line combobox
<bialix> GaryvdM: what's problem?
<WimYedema> could it be Mime configuration or something?
<GaryvdM> bialix: qcommit is allready busy.
<bialix> GaryvdM: I know. but what is alternative here?
<GaryvdM> bialix: we could put it in the autocomplete list.
<bialix> GaryvdM: no
<bialix> GaryvdM: this is wrong
<bialix> the idea is you can put there some past entire commit message
<bialix> it could be very long
<poolie> WimYedema: it might be mime or it might be /etc/alternatives, controlled by update-alternatives
<GaryvdM> bialix: Maybe a button that pops up list or menu, but does not a extra text box like a combo box.
<bialix> GaryvdM: and where to put such button?
<bialix> can you run my branch to see it in action?
<GaryvdM> bialix: ok
<GaryvdM> bialix: sorry - what is the url agian?
<bialix> you need to make some commits to seed the history, plain bzr ci catched too ;-)
<bialix> GaryvdM: lp:~bialix/qbzr/post-commit
 * GaryvdM branches...
<bialix> the hooks are cool things! I will add similar hooks for post_push/post_pull to store push/pull history in similar manner to commit-history
<bialix> MRU
<WimYedema> bialix: https://bugs.launchpad.net/bzr/+bug/570573
<ubottu> Ubuntu bug 570573 in bzr "setting default editor in explorer fails in Gnome" [Undecided,New]
<bialix> WimYedema: thanks!
<spiv> WimYedema: GNOME might be using mailcap to figure out how to open the files
<poolie> in which case probably /etc/mimetab
<poolie> mimecap?
<poolie> spiv, so what do you think overall about cleanups?
<spiv> poolie: that name would make sense, but no!
<poolie> should i withdraw that patch?
<spiv> /etc/mailcap, see 'man mailcap' and 'man run-mailcap'
<GaryvdM> bialix: I'm going to experiment with putting the messages in the autocomplete list.
<spiv> poolie: I just sent a review, did you see it?
<bialix> GaryvdM: I'm still think it's a wrong idea
<bialix> combobox shows the commit messages in descending order
<bialix> auto-complete will lose this ability
<spiv> Ooh, and actual PQM failure in a merge proposal.
<spiv> s/and/an/
<spiv> repr(lines) isn't my preferred format for reading failure output, but it's a lot better than nothing :)
<bialix> GaryvdM: does auto-complete handle multiple words?
<GaryvdM> bialix: I think so. I want to check.
<lifeless> spiv: url ?
<bialix> ok, I will test your auto-complete then
<spiv> lifeless: https://code.edge.launchpad.net/~mbp/bzr/components/+merge/23827
<poolie> oh thanks for the review
<SuperMMX> s
<SuperMMX> s
<lifeless> spiv: that seems to be working okish
<poolie> it does feel a bit half done to me
<lifeless> spiv: but actually I think its a bug, will leave this open and look tomorrow
<poolie> lifeless: which one?
<lifeless> [] around the lines in the merge review feedback
<spiv> poolie: yeah.  I'm not necessarily against landing half-done things, as I hope I made clear.  Just that it seems something to be aware of.
<spiv> poolie: (especially not against it when the next step isn't immediately crystal clear, and the half-done point isn't likely to paint us into a corner.)
<spiv> Also, rather than risk mixing metaphors any further I might go have dinner :)
<poolie> agree :)
<poolie> also about dinner :)
<spiv> "No metaphors were harmed in the making of this patch."
<bialix> GaryvdM: I'm thinking about adding main menu to qci and qdi to allow user hide the elements he is not interested to see
<GaryvdM> bialix: I had such plans for qdiff.
<GaryvdM> *have
<bialix> but you feel qci is also busy, so we need to allow customization here as well
<GaryvdM> bialix: Similar to lp:~garyvdm/qbzr/annotate_find
<bialix> also I want to work on redesign of bugs/author area, as Craig suggested in ML
 * bialix looks
<bialix> poolie: is it possible to work on tags v2 on the sprint?
<bialix> poolie: maybe it's better if I send the mail with some my thoughts how I think we could improve current tags
<bialix> and operations on tags
<bialix> amanica said me he's willing to work on nested trees. I have many feedback on this topic based on scmproj workflow. And I have many questions on the intended nested trees behavior
<bialix> GaryvdM: annotate_find: cool! why you don't merge it?
<WimYedema> Ugh! you've got to be kidding! I did some googling, and the solution is: Change the Applications>Text Editor entry to the editor you want to use.
<GaryvdM> GaryvdM: I want to do similar ui changes to diff, cat, log and browse, an I want to do it at the same time, so that qbzr dialog have consistent feel.  (maybe I'm being silly...)
<WimYedema> Anyway, thanks for the support guys.
<WimYedema> See you later
<GaryvdM> Lol - I'm talking to myself...
<GaryvdM> bialix ^
<bialix> GaryvdM: noble goal, ok
<bialix> GaryvdM: "View options seems misleading. Maybe just "Options"?
<GaryvdM> bialix: sure
<bialix> nice work, really. although it's not windows style to have such toolbars.
<GaryvdM> bialix: Neither gnome, neither mac....
<bialix> maybe I'm just nitpicking
<bialix> ignore me
<GaryvdM> bialix: No - you are correct. This is another reason why I have not merged it.
<bialix> GaryvdM: ok, I will ponder about it in the background of my mind
<GaryvdM> bialix: It's sort of the route the chrome has taken, an firefox is going to take.
<bialix> do you think it's worth to announce our unfinished stuff so people can test/dogfood it?
<bialix> my commit-history was easier to implement than I've thought
<GaryvdM> bialix: I did link it to the bug. And also discussed here (but as a side topic): http://groups.google.com/group/qbzr/browse_thread/thread/14cae28792ed3ebb
<bialix> GaryvdM: It seems I've lost the track of qbzr things after last 2 months :-( I will re-read ML
<GaryvdM> bialix: Me too! I did not know about http://wiki.bazaar.canonical.com/QBzr/Roadmap
<GaryvdM> bialix: I've done the last item on http://wiki.bazaar.canonical.com/QBzr/Roadmap - see https://code.edge.launchpad.net/~garyvdm/bzr/diff_using_gui/+merge/24076
<bialix> GaryvdM: Roadmap was assembled from similar ML discussion
<bialix> our users did this actually :-)
<bialix> GaryvdM: cool, we will have a chance to discuss roadmap soon. I hope
<GaryvdM> bialix: Yhea. I'm looking foward to meeting you! :-)
<bialix> :-)
<bialix> and volcano calmed down
<bialix> GaryvdM: when the football started?
<GaryvdM> 48 days I think..
<bialix> it will be winter in your land?
<GaryvdM> I'm not really interested in soccer, but it's good for SA
<GaryvdM> bialix: yes
<bialix> snow? ;-)
<lifeless> meep, I'm beat -> crashing
<GaryvdM> bialix: No. The last time it snowed in Johannesburg was in 1981
<bialix> GaryvdM: ok, I see
<GaryvdM> bialix:  lp:~garyvdm/qbzr/message_history_auto_complete
<GaryvdM> bialix: It could be better.
<bialix> GaryvdM: thanks! I'll test
<GaryvdM> bugs: Does not handle new line correctly.
<GaryvdM> Should find/select if you type in a word in the middle
<GaryvdM> QCompleter hits some limitations. :-(
 * GaryvdM goes to find food..
<bialix> I will test your branch some time. But for me using combolist means nice real summary list where I can look to refresh my memory
<bialix> auto-completer lose this ability
<bialix> I'm still not sure...
<bialix> maybe special button as you said
<bialix> :-/
<cbz> how do i merge *tO* the subversion trunk?
<GaryvdM> cbz: do you have a checkout, or a straight branch?
<GaryvdM> If checkout: update, commit, push
<GaryvdM> if straight branch: create new branch, merge in that branch, commit, push
<GaryvdM> cbz^
<cbz> straight branch
<cbz> so i pushed to the branch i made - now how do i merge back to subversion? In the normal case where the trunk is on top of everything i guess i can do a push - but if things have progressed since, don't i actually want to do a merge back to subversion?
<xnox> how do i reconfigure a branch to use a different higher level bzr shared repo? I've ended up with ~/src/.bzr and ~/src/stable/.bzr   Branches under ~/src/stable/ should use the ~/src/.bzr shared repo
<awilkins> cbz, switch your bzr checkout to the trunk and merge your branch to it using bzr, then push it
<awilkins> xnox, It automatically uses the first one it finds via directory climbing
<cbz> okay
<awilkins> xnox, You sound like you might want to try some lightweight checkouts
<cbz> i just assumed from http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/
<cbz> that i should be using a merge *to* the subversion branch
<cbz> rather than a push
<awilkins> cbz, I think you have to make sure your branch is up to date with trunk
<xnox> awilkins, yeap I know that. But if i delete the current sub-share-repo my branches will become broken and i will need to refetch packs over the intranetz to get the packs into higher level shared-repo
<awilkins> xnox, You could move the shared repo out with it's branches and push them into the higher level shared repo
<awilkins> cbz, Yes, that's why we are switching the checkout to trunk, so we can merge to it and preserve all the bzr metadata
<awilkins> cbz, Are you using heavyweight branches / checkouts or lighweights?
<cbz> heavyweight branches
<cbz> so i have branch trunk with a parent of by svn repository and another branch whose parent is trunk
<cbz> I've delivered into trunk - however there is newer stuff in svn
<awilkins> cbz, I find using lightweight checkouts of branches in a no-trees repository to be easier with SVN
<cbz> I can hack normally get things into the svn repository, this paragraph has me wondering whether i'm missing something though:
<cbz> "This is where the potential problem comes into play. You could push myhacks directly into trunk, after all, itâs up-to-date with the changes. But look at the commit ordering. Right now, F is the last commit on trunk. If you push myhacks into trunk, it needs to re-order the commits to make them look like what is present in myhacks. From a Subversion user standpoint, thatâs confusing to see, although correct from a commit graph perspective. For this reas
<cbz> "A better answer is to merge your feature branch back to trunk, just as you would have done with Subversion or a short term branch. The resultant commit graph is now: "
<awilkins> Right, so no pushing branches straight to trunk
<cbz> I could always fix it using rebase - but it implies i could merge *to* the svn repository
<awilkins> Instead, keep a local "trunk" mirror that you never work on
<awilkins> Pull that, merge to it, push back
<cbz> And if someone has put something into it between my pull and my merge?
<cbz> (it in this case being the svn repository)
<awilkins> cbz  then you'll have to do it again
<awilkins> cbz, It's annoying.
<awilkins> cbz, It shouldn't be too bad unless your commit rate is mad
<swathanthran> would bzr send take much data transfer?(and is it much problematic that my copy may be a bit behind the original) (its 2.3mb and going and i have a costly bandwidth:))
<swathanthran> oh btw would  bzr send -o my-patch.txt  try to mail the patch too?(not just produce my-patch.txt?)
<maxb> No
<maxb> If bzr send is doing network access, it would be to access the submit branch
<swathanthran> yeah my copy is not upto-date
<swathanthran> its >3mb and i guess i would have to try it later on free net time.
<swathanthran> in general the download was slow compared to usual file download rates .. would that be with the server? i am working with emacs so its connecting bzr.savannah.gnu.org
<vila> swathanthran: yeah, AFAIK, savannah haven't deployed the bzr smart server which should greatly improve (i.e. reduce) bandwidth use
<swathanthran> oh ic
<xnox> I'm trying to experiment with join --reference using 2a format. Does that work? join succeeded and added just the directory but now I have all files under the JoinedBranch/ being status unknown when I'm in the containing tree
<swathanthran> see ya later:)
<xnox> Oh I get errors of not being supported to generate inventory =) oh well i'll try again later ;-)
<maxb> Although bzr's network usage can be a bit silly even with the smart server :-/
 * jelmer wonders if he should respond to the huge bzr thread on the mercurial mailing list
<bialix> GaryvdM: I think I don't like auto-completion idea in general. My use case for commit-history: select some past commit message and insert it into text area, then edit/change if necessary
<bialix> jelmer: is it worth it?
<jelmer> bialix: the thread, or replying?
<GaryvdM> bialix: ack
<bialix> jelmer: replying
<GaryvdM> jelmer: What is the subject, so I can google it?
<bialix> I don't read that thread though
<bialix> GaryvdM: what it means (ack)?
<GaryvdM> bialix: (Ack)nowledge receiving message.
<bialix> GaryvdM: ack
<xnox> bialix, I can't find it either =(
<xnox> jelmer, please tell us which thread it is =)
<bialix> xnox: what?
<xnox> Sorry got the nicks mixed up
<bialix> jelmer: do you mean this thread: Not a holy war - just some salient facts
<bialix> ?
 * xnox was talking about that =)
<jelmer> bialix: yeah
<bialix> jelmer: I don't read it
<bialix> saw it
<bialix> but don;t read
<bialix> folks, beginning of the thread is here http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/1927
<bialix> sorry, beginning of the thread is here http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/19277
<bialix> copy-paste error
<bialix> vila: ping
<GaryvdM> Pretty civilized, as for as dvcs discussions go... :-P
<vila> bialix: pong
<bialix> vila: I'm a bit confused re hooks
<bialix> what is the best idea to avoid duplicating of hooks?
<bialix> maybe I need to check (how&) that some hook is already installed before I'm starting to install it again?
<xnox> is there a way to pass hooks together with a branch to someone else? e.g. developer hooks for developers to run on the branch? or shall i just create my custom souce hooks plugin and ask my devs to install it?
<vila> bialix: I don't understand, why would you install the same hook twice ?
<bialix> xnox: you have to create plugin
<xnox> bialix, ok thanks ;-)
<bialix> vila: read my recent mail in bzr ML
<bialix> vila: in short: I want to share some functionality between plugins
<vila> bialix: hooks can have names, that should allow checking their presence
<bialix> vila: it seems I've lost in hooks.py
<vila> bialix: when you can't understand the code anymore, write a test :-D
<bialix> vila: Hooks class have _callable_names private
<bialix> vila: there is no public method to check either my name is already registered
<bialix> so I don't understand the purpose of this names?
<vila> Hooks is a dict
<vila> meh, wrong class
<bialix> Hooks have install_named_hook method which I'm talking about
<bialix> s/have/has/
<xnox> jelmer, that thread as far as I see died off by itself. It does hurt to read some comments about bzr while some of them are true they are not quite precise. Hg is nice it's a bit gitified for my opinion though. And getting your revision number renumbered just because you pulled some branches in a different order is just plain silly imho
<xnox> they try to make it obvious that: "hg has rev numbers just because we use python and can do easy index lookups using those supplied by the user"
<xnox> and then you have ML threads on python: "doh how do we identify builds of the mainline"
<vila> bialix: what's wrong with get_hook_name ?
<bialix> vila: it requires callable argument?
<bialix> so I have to iterate over all callables and check if some of them have interesting name?
<vila> bialix: I still don't understand what you want, a callable is fine to use to check for uniqness no ?
<vila> bialix: meh, you know the hook you want to install right ?
<bialix> 2 plugins will have 2 copies of the same callable. so these 2 callables will be different
<bialix> I don't want to fire the 2 copies of one callable
<vila> If there are 2 different callables neither one will be called twice....
<vila> If you want to have a unique callable... define a single callable
<vila> if two plugins are involved, how do you guarantee that the code is the same ?
<bialix> I can't guarantee of course
<bialix> but I can assume this
<bialix> in my particular case hook store some data in file, and I don't want to store the data twice
<vila> check the data then ?
<vila> IME, hooks shouldn't depend on other hooks (not bzr-specific)
<bialix> I'm agree with you
<bialix> but what about plugin depending on other plugin? ;-)
<vila> yeah, depends is not the correct word, sorry,
<bialix> or maybe just depends on qbzr always
<bialix> I think I'm wrong somewhere
<vila> it's more that hooks shouldn't step on each other toe
<bialix> I'm just trying to get your feedback
<bialix> maybe I need to read book on developing hooks
<bialix> unfortunately I don't have such book
<vila> At first glance I'd go with a dedicated plugin
<vila> Most of my experience with hooks is from emacs (and gtk a bit)
<vila> there you can check for the presence of a given hook (a given callable) and insert your own hook in front of the list of at the end
<vila> but ISTM you want to *ensure* a hook is present or insert it otherwise, I don't think you want to play tricks with different versions of the same hook managing the exact same data
<bialix> vila: correct
<vila> <shudder> nested trees
<vila> bialix: another alternative you didn't mention is adding support in core...
<vila> worth discussing in Brussels at least
<bialix> adding to core what? my mru-beast?
<bialix> yes, someone asking for this in the past
<vila> xxx around saving commit messages when uncomitting
<bialix> vila: yep
<bialix> vila: why <shudder> nested trees?
<vila> there are various needs in this area that are addressed (or not) differently by various plugins for various needs
<bialix> this area?
<bialix> we need to resync
<vila> your mru-history plugin could be a nested tree in qbzr while being a plugin on its own
<vila> or something
<bialix> vila: hmm
<bialix> but bzr can't load nested plugins
<jelmer> bialix: lazily importing it?
<vila> bialix: no, but you could register your hook is the plugin wasn't installed, still the same code
<bialix> jelmer: import the plugin?
<bialix> maybe try-except ImportError
<bialix> maybe jelmer right: try to import mru plugin, if it is not installed then register hook from the nested copy
<bialix> that's idea
<jelmer> bialix: lazily import from the plugin
<jelmer> bialix: when you use it, rather than when your plugin is imported
<bialix> jelmer: mmm... I need to eliminate duplicating of hooks, I feel I can't do this with lazy import
<xnox> jelmer, some of my problems with svn-keywords was that upstream committed expanded keyword as a commit and bzr-svn would shrink it again. Do we need to handle cases like that?
<xnox> jelmer, also bzr-svn does it cache "discovering revisions / tags"
<xnox> i'm pulling gcc branches it takes for ever to discover tags over 150k of svn commits
<cody-somerville> jelmer, Can you look at why https://code.edge.launchpad.net/~vcs-imports/live-helper/trunk is failing?
<jelmer> xnox: I'm not sure I understand the problem
<jelmer> xnox: the keywords aren't stored expanded in the repository
<jelmer> xnox: it should cache the tagging information; if it doesn't, please file a bug
<jelmer> cody-somerville: one sec
 * GaryvdM is adding --preview-using and --preview-format to merge
<GaryvdM> Is there a way to control the order that options show in help?
<bialix> GaryvdM: no, AFAIK
<GaryvdM> bialix: ok. Not to important
<GaryvdM> bialix: now working on bzr merge --preview-format qdiff :-)
<bialix> wow!
 * bialix dogfooding commit-history. feels happy
<GaryvdM> Jelmer made some changes which makes it eaiser :-)
<bialix> !!!
<bialix> GaryvdM: I'm using colo all the time
<bialix> maybe we should provides some colo-specific branch manager in qbzr?
<bialix> there is some q-commands in colo itself
<jelmer> cody-somerville: hmm
<bialix> will be nice to have more richier
<jelmer> cody-somerville: the issue is in what we use as the default branch
<jelmer> cody-somerville: we used to just use HEAD, but that didn't work for all branches so we switched to refs/heads/master. Arguments can be made for both.
<jelmer> cody-somerville: the proper fix here is to use the colocated branch support but that hasn't landed yet.
<blueyed> How can I rewind to a previous revision, before e.g. some merge? "revert -r" helps, but when reverting local changes via "revert", I'm back at the tip of the branch..
<xnox> blueyed, if you want to throw away those commits you can do $ bzr uncommit
<xnox> if you need to do something useful with the past commit do
<xnox> $ bzr branch -r$rev_spec_before_merge branch_current/  snapshot_old/
<blueyed> xnox: thanks. I'm not sure.. I got them via "pull" - or rather "rebase", which fell back to pull.
<blueyed> Can I uncommit, but then pull/merge again?
<xnox> blueyed, why do you want to go back?
<blueyed> I want to merge another branch, but rebase the commits in the same step
<xnox> branch off the commit you want as I showed above. Redo merge and use that branch for rebasing
<xnox> "redo merge" means "do any merge you want" and then rebase that new branch as you want
<blueyed> shouldn't uncommit -r $BEFORE and then retrying from there work the same way? and more easily?
<blueyed> How do I merge a forked off branch, but rebasing on the go? (doing "bzr rebase $derived" will use pull instead)
<blueyed> via --force or something like that?
<blueyed> or "merge && rebase --pending-merges"?
<blueyed> well, "bzr rebase --pending-merges" says "No revisions to rebase."
<blueyed> xnox: I
<blueyed> 'm lost.. any further hints.
<xnox> blueyed, ok
<xnox> what's the branch name which has this merge pulled in?
<blueyed> given I've uncommitted, what to do to merge a branch, but rebase it.
<blueyed> I've uncommitted. back to the start.
<blueyed> the remote branch is via sftp
<xnox> so you can regrab what you have just uncommitted? (checking to make sure we didn't mess up)
<blueyed> yes
<xnox> ok
<xnox> what do you want to rebase onto what?
<xnox> do you want your branch to be on top of the sftp one or the other way around?
<blueyed> I have my "master", and have branched from there into "sftp".. Now I want to get "sftp" into master, but rebased.
<xnox> right do this
<xnox> $ bzr branch sftp branch-sftp
<xnox> so you have a local branch which is what you have on sftp
<xnox> cd branch-sftp
<xnox> bzr rebase master
<xnox> this way all changes in sftp will appear as if you made them after getting everything from master (your history will be linear)
<xnox> does this get you what you want?
<blueyed> xnox: well.. I prolly misunderstood rebasing then (in this case): they are already linear (I've not changed master after branching sftp from it). I just want to redo the commits.
<blueyed> it's different from git rebase then apparently
<blueyed> current procedure says "No revisions to rebase."
<xnox> ok if you want to redo commits. do get back to the start of the commits you want to change.
<xnox> for example $ bzr branch master -r-20
<xnox> $ bzr branch master -r-20 rework
<xnox> this will put you back 20 revision for example
<xnox> then in rework you can either commit new stuff or pull new stuff
<xnox> for example
<xnox> $ bzr merge master -r-20..-19
<xnox> $ bzr merge master -r-20..-19 --force
<blueyed> well.. I'd rather like to pull the sftp branch, then rebase anything since -r-20, the commit and push. is this possible?
<xnox> yes
<blueyed> also, "bzr branch master -r-20 rework" is the same as "uncommit -r-20" prolly, isn't it?
<xnox> yes it is
<xnox> once you are at that old point
<blueyed> I am - via uncommit.
<jam>  /who xnox
<jam> btw, hi :)
<xnox> so merge only those revisions you want
<xnox> e.g. $ bzr merge sftp -r-20..-10
<xnox> or something like that
<blueyed> ok. I see. I uncommit, then merge each revision by hand, and commit..
<xnox> blueyed, yeap then you will have different history from master
<blueyed> seems like git rebase is far more advanced and not the same as bzr rebase.
<blueyed> xnox: no. I uncommit and recommit in master.
<blueyed> master has not been pushed yet, so no problem.
<xnox> blueyed, you can do everything in bzr rebase what you can do in git rebase
<blueyed> just not very convenient for ~20 revisions
<xnox> blueyed, $ bzr merge -r-20..-1
<xnox> will merge all 20 revisions
<blueyed> sure.. but with the same time and same commit message.
<xnox> blueyed so what do you want to change
<xnox> sorry I'm confused
<xnox> for example master is
<blueyed> mostly timestamps
<blueyed> (and group some commits)
<blueyed> IIRC "git rebase -i" allows you to squish/squash single commits.
<xnox> well for that you will need to do $ bzr merge -r-20-19      <- to change timestamp of one revision
<xnox> and to squish you would do $ bzr merge -r-19..-15
<blueyed> not only merge, but also commit. two commands per revision.
<xnox> I was about to write that --interactive is the only killer bit in git rebase ;-)
<xnox> blueyed, that's by design ;-)
<blueyed> so :) - not the same :D
<xnox> generally bzr strongly discourages rewrites of the history
<blueyed> I see :P
<xnox> blueyed, you can get away from rewriting in your case actually
<xnox> eg. $ bzr merge . -r-1..-20
<xnox> this will create a merge which undoes previous 20 commits while keeping history linear
<xnox> but this will look a bit messy in the $ bzr log =) if you are perfectionist
<xnox> jam, hi wassup?
<blueyed> you mean "merge ." after "pull"?
<jam> nothing, just seeing who was talking
<jam> I didn't recognize your nick
<xnox> blueyed, yeap "merge . -r-1..-20" will merge commits from the current branch in reverse order meaning undoing them
<xnox> so if you really don't like commit 7
<xnox> you can do $ bzr merge . -r7..6
<blueyed> I see. sure. but I like 99% of those 20 commits.
<xnox> so undo just one of them
<xnox> the once you don't like
<xnox> so take your sftp branch and reverse-merge those you don't like ;-)
<blueyed> I start from uncommit anyway. they are quite separate already. I do not squash them into less than 15 commits on master.
<blueyed> Yes, I've understood that I have to merge by hand.. ^^
<blueyed> really messy though.
<xnox> blueyed, good =) hope this helped a little bit
<xnox> blueyed, how did you get to this state?
<blueyed> sure. thanks for your help, xnox
<blueyed> branched off and developed. should be quite common ^^
<xnox> cause sometimes I do a trick of developing on one branch and then going to a fresh master and instead of merging I just bluntly copy the whole dir from the states I like and commit that
<blueyed> It's just that I want to rewrite history and bzr makes this far too difficult.
<xnox> quicker then bothering with rewrite
<blueyed> sure. but then you have it all in one commit.
<blueyed> it's about ~15
<xnox> blueyed, also look into bzr-pipeline plugin which helps with refactoring work into commits
<dash> some people use bzr because they feel that rewriting history is morally suspect ;-)
<xnox> blueyed,  I think you will have easier time with bzr-pipeline plugin
<blueyed> i've looked at pipeline already, also loom (the same?). too difficult.
<blueyed> ok, thanks, will look at it again
<xnox> blueyed, pipeline is simple imho
<xnox> create pipes as in master -> what-you-want-in-commit-1 -> what-you-want-in-commit-2 etc
<xnox> and each of those is a separate branch refactor them as you like
<xnox> and then just do $ bzr pipe-patches which will give you patch series that you can cleanly apply onto master
 * blueyed already has a bash script to merge commits with markers in the log message to some CVS repo (real trunk) and feels to need this kind of manual merging for bzr, too.. :/
<blueyed> xnox: sounds like pipeline does not rewrite history, too?!
<xnox> blueyed, it uses merges. But if you export it as patches & commit them as if you are commiting a real patch you are rewriting history
<xnox> commit patches to the star-point you rewrote history
<xnox> blueyed, http://how-bazaar.blogspot.com/2009/07/breaking-up-work-for-reivew.html
<xnox> here is the link on how-to rewrite history with pipelines
<xnox> it uses shelve, uncommit, merge to create refactored history such that it is easy to review changes
<blueyed> can we have "bzr subject -r $foo"? :)
<blueyed> how do I get only the commit message of a commit?
<blueyed> starting point "log --short"
<icebrain> hi! I couldn't find out how to get all the revisions that changed the line L in file F, can you help me?
<icebrain> I've googled for it, but I've only found out how to do it in code
<beuno> icebrain, I don't think you can do that from the client
<icebrain> beuno: really? oh... ok. thanks anyway
<cr3> I tried to bzr tag --delete a bunch of tags and then push my changes, but they still seem to appear when I pull from the same branch
<IslandUsurper> using bzr-git, can I merge in changes from a specific branch, or do I have to import them all first, and merge in the particular directory?
<NfNitLoop> cr3: I think tags are always copied, never removed, when  you push/pull branches.
<NfNitLoop> cr3: so you may need to remove them from both branches.
<cr3> NfNitLoop: so maybe I need to delete the branch on the server and push again without the tags :(
<maxb> cr3: I believe a push --overwrite might work. But be really sure you don't accidentally overwrite non-tag stuff you wanted to keeP!
<lifeless> morning
<cr3> maxb: I'm not sure what non-tag stuff there might be though, got any examples?
<cr3> lifeless: top of the morning
<maxb> Just revisions, I *think*, but I didn't want to be guilty of suggesting push --overwrite without a strong caution
<NfNitLoop> maxb: if he's just going to delete it anyway... what could push --overwrite overwrite that he wan't going to delete?
<NfNitLoop> unless push --overwrite is short for rm -rf /
<NfNitLoop> ;)
<tetsuo--> how can i revert my working tree?
<tetsuo--> all the commands seem to be failing
<rubbs> tetsuo--: have you tried bzr revert?
<tetsuo--> yeah it fails miserably
<rubbs> how does it fail?
<tetsuo--> but i think i know why, the parent is my svn repository
<tetsuo--> so i'm making a new one with the bzr repository as a parent
<rubbs> that is recommended ;)
<tetsuo--> yeah it makes sense
<tetsuo--> i can still import revisions from svn
<rubbs> the repo that has the svn parent should always be a mirror of the svn. then you branch from that.
<rubbs> exactly
<rubbs> well, I'm off work and heading home. if you have more questions, there are plenty of awesome people here to help, just keep asking away.
<tetsuo--> thanks
<rubbs> np. hope that solves your problem.
<dutchie> is there a way to do something similar to git add -p, where you can commit some of the changes in the working directory in bzr?
<LeoNerd> bzr ci names of files
<LeoNerd> Will commit all the changes in just those files
<dutchie> what about only some of the changes in those files?
<LeoNerd> For more fine-grained control, what I do is use bzr shelve to take out the changes I don't want to commit, commit the rest, then unshelve it back in
<dutchie> ah, ok
<LeoNerd> I believe there may be a selective commit plugin but I don't happen to know its name
<dutchie> thanks
<dutchie> hmm, bzr shelve doesn't seem to want to let me split diffs
<jelmer> dutchie: no, I don't think it supports splitting hunks
<dutchie> is there anything that does?
<Kilroo> merge -i does, doesn't it?
<Kilroo> ...I mention it because it's the only thing I can think of, more than because I think it might be useful...
<xnox> LeoNerd, i believe it is interractive plugin which enables interactivy for a few commands
<fullermd> At one point there was a 'record' plugin I think, after darcs.
#bzr 2010-04-28
<mwhudson> jelmer: still here?
<mwhudson> jelmer: anything to be wary of in upgrading to bzr-git and dulwich trunk tips?
<jelmer> mwhudson: hi
<jelmer> mwhudson: not really, other than making sure you upgrade both at the same time
<mwhudson> jelmer: cool, thanks
<mwhudson> jelmer: this should fix git imports over http, right?
<jelmer> mwhudson: I thought that was already working?
<mwhudson> jelmer: it broke again, it seems
<jelmer> mwhudson: what's the error?
<mwhudson> jelmer: https://bugs.edge.launchpad.net/launchpad-code/+bug/570728
<ubottu> Ubuntu bug 570728 in launchpad-code "Importing git repo from http://git.participatoryculture.org/miro/ fails" [High,Triaged]
<mwhudson> jelmer: i'm sure i saw a commit along the lines of "fix access over http again"
<jelmer> mwhudson: ah, right - that's fixed indeed
<jelmer> dulwich now can launchpad http test servers, we still need to take advantage of that in bzr-git
<lifeless> EPARSE
 * james_w suspects muscle memory
<jelmer> argh
<jelmer> lifeless: :-)
<jelmer> I can no longer write launch without adding "pad" onto it
<poolie> heh
<poolie> i find it very hard to type 'linus'
<mwhudson> i tried to type 'lp/core' earlier
<thumper> poolie: I'm sure it would be easier if it was your name :)
<poolie> hi spiv
<spiv> Hey poolie
<poolie> how about a brief chat?
<poolie> in 5m maybe?
<spiv> Sure.
<lifeless> lp:~leonardr/lazr.restfulclient/retry_on_502 will help us
<lifeless> for pqm
<spiv> Hmm, one day left in PyCon Au CFP.
<lifeless> indeed
<lifeless> it seems.... raid
<lifeless> rapid
<spiv> poolie: take a look at https://code.edge.launchpad.net/~vila/bzr/320119-exclude-ancestry/+merge/23394, it duplicates its make_branch_with_alternate_ancestries test helper
<spiv> poolie: it'd be lovely if your testsubjects patch could provide a natural way to avoid that duplication
<spiv> poolie: it might be too much to ask, or maybe the real issue is that bb.test_log and bt.test_log should have a more convenient way to share their helpers.  But it seemed topical :)
<poolie> it's highly topical
<poolie> and a good place to start
<poolie> so istm you could just lift it into a function
<poolie> i guess you'd need to pass the test case in to that function so that it can arrange for the cleanup to be called
<spiv> poolie: right
<lifeless> -> pick up car
<spiv> And note that they want to use the test case's get_transport too.
<mwhudson> "hmm" http://pastebin.ubuntu.com/423710/
<Peng_> Nice.
<xnox> jelmer, svn is such a weird beast =)
 * xnox officially hates file/revision properties in svn
<poolie> spiv, oh, i liked your old doctest blog posts
<mwhudson> i think they are also his newest blog posts
<spiv> Yeah.
<poolie> you should do more
<mwhudson> xnox: https://code.edge.launchpad.net/~dmitrij.ledkov/reactos-core/ddk is a slightly strange request
<mwhudson> do you really want to import a branch that just has the headers in it?
<xnox> mwhudson, i'm working on mingw-w64 projects which is a working crt
<xnox> to cross-compile to windows32 & windows64
<xnox> they are importing those headers as an svn:external
<mwhudson> ah
<xnox> I'm currently successfully creating binutils, gcc, mingw-w64 debian packages using gcc-4.5, gcc-4.6, gcc-4.3
<mwhudson> xnox: approved then
<xnox> mwhudson, to automate this further =) I really really would appreciate those headers imported
<xnox> mwhudson, as well as gcc branches =))))))) pleeeeeeeeeeeaaaase =)
<poolie> jam, can you tell francis et al about the loggerhead fix?
<mwhudson> xnox: i don't see them in the pending review column
<mwhudson> xnox: give me some links?
<xnox> mwhudson, 1sec
<xnox> mwhudson, https://answers.edge.launchpad.net/launchpad-code/+question/108549
<xnox> svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch/
<xnox> svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch/
<xnox> svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch/
<xnox> if possible as lp:gcc/4.5
<mwhudson> xnox: can you request imports of these?
<xnox> ok
<jam> poolie: forwarded
<xnox> mwhudson, done
<mwhudson> xnox: i think you'll need to ping doko to create the 4.4 and 4.5 project series
<xnox> mwhudson, ok =)
<xnox> mwhudson, thanks a lot =) and I promise I will work hard during my Ubuntu GSoC =)
<jbowtie> Just pushed my first merge proposal.
<poolie> jbowtie: congratulations
<allquixotic> So what is the current status of http://wiki.bazaar.canonical.com/WindowsSymlinkSupport ?
<allquixotic> Seems like some good ideas got thrown around but are any implemented?
<poolie> allquixotic: i think the best option is the plugin
<poolie> not sure, sorry
<a212901390231901> meh, projects that want to be portable just shouldn't use 'em
<a212901390231901> likewise filenames with backslashes in and other oddness
<allquixotic> Well, I have two possible build methods in this project. The GNU Make based build does need symlinks to work right. The MS Visual Studio based build has the required path finagling in the project properties. I guess I can create the symlinks (which are pre-determined and can be referenced by relative path) at build-time with the Makefile, and remove them with clean.
<allquixotic> That way, anyone who does a clean before they commit (which they should always do) will rm the symlinks, and they won't get committed -- but if they're building with GNU Make, it will make the symlinks before building.
<allquixotic> then everybody's happy.
<a212901390231901> sounds sensible to me.
<a212901390231901> add the paths to .bzrignore to be on the safe side.
<allquixotic> sounds like a good idea
<vila> hi all
 * fullermd vilas wave.
<vila> hey fullermd  ! :)
<a212901390231901> pilote again this week
<vila> spiv: thks for the review !
<vila> a212901390231901: I should say that I really don't recognize your nick :)
<vila> spiv: for the record, they are not duplicated, there is a slight variation, but of course your point stands :)
<a212901390231901> freenode was annoying me, everything's already registered and I'm not on frequently.
<vila> hehe, it doesn't help to match with any other handle you can use though :)
<Peng_> Yes, I doubt you'll have trouble getting that nick on other networks. Unless they have length limits.
<fullermd> Oh look, an opportunity to flex my numerological muscles...
<a212901390231901> I'm one of the peripheral martins.
<Peng_> Ooh, another Martin? If you get a job at Canonical, you'll have to change your real name too. :P
 * fullermd . o O ( No match for "PERIPHERALMARTINS.COM". )
<vila> gz or von Gagern ?
<a212901390231901> I just mashed the keyboard in frustration after trying about six other things, fullermd
<a212901390231901> gz.
<Peng_> Oh hi. :D
<a212901390231901> which, unsuprisingly, was taken.
<vila> a212901390231901: Hello Martin !!
<Peng_> "Martin[gz] is not registered." :D
 * vila my first read was peripheral martians :)
<a212901390231901> ehehe
<fullermd> Makes sense.  You never see martians directly; it's always out of the corner of your shotglass.
<fullermd> Eye.  I meant 'eye'.
<vila> hehe
<spiv> vila: the interesting bits are duplicated :P
<vila> spiv: sure !
<spiv> vila: unless you mean there is slight variation between the comments and the code? ;)
<jbowtie> I fixed lp:146780 on the wiki if anyone's interested in reviewing.
<vila> spiv: I indeed started by copy/pasting because I wrote the first test in the wrong place, realized there was a slightly different case to test and left the other one since it was good to have too
<vila> spiv: I'll make that clearer
<lifeless> poolie: http://www.flickr.com/photos/49692283@N07/4559422361/in/pool-canonical-offices
<vila> lifeless: sounds like a good place for the November sprint :-P
<lifeless> won't be here in november
<lifeless> its a rental for 4 months, time enough to find a longer term residency (e.g. a house to buy)
<fullermd> Heck, there's one right up the road from me   ;>
<lifeless> fullermd: in a country that won't fingerprint me and treat me like a criminal, just because I want to trave there?
<fullermd> That depends on whether you consider the state a separate country.  Opinions vary  ;p
<poolie> pretty
<vila> poolie: by the way, feel free to upload the pictures you took in Strasbourg there :)
<poolie> i like what you did with the exposure and motion blur :)
<poolie> ok
<lifeless> poolie: android phone - it doesn't do it justice
<lifeless> poolie: it was at 8am or so
<lifeless> poolie: if you want to bring your camera around to get a proper shot, you're welcome to do so!
<idnar> haha
<poolie> lifeless: so i fixed and repushed a branch that i think is already queued for merge
<poolie> 'components'
<poolie> what happens now?
<lifeless> poolie: pqm unqueued it when it failed to merge
<lifeless> poolie: it put it back to 'approved', because we can't set 'failed to merge' yet [lp bug, I submitted a branch, thumper has half-reviewed it]
<lifeless> poolie: so you should requeue it in hydrazine
<jbowtie> That's 4 documentation bugs for today; was shooting for 5 but not going to happen. Hopefully someone will review, yes?
<poolie> yes :)
<poolie> thanks for the fixes
<poolie> the one with adding DISABLE_PLUGINS to the table, why was the diff so big?
<poolie> you had to rearrange the columns?
<fullermd> Oh, FIXES.  I was wondering how it could take that long to create 4 bugs   ;)
<jbowtie> poolie: Yes, the columns had to be resized.
<jbowtie> fullermd: ha ha - don't worry, I'll be filing some this week about the blank areas/TODOs.
<lifeless> wowsers thats a big package - texlive-latex-extra-doc
<bignose> is a recent GNOME expected to give âbzr-gtkâ errors like this:
<bignose>   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/gtk/keyring.py", line 77, in get_credentials
<bignose>     gnomekeyring.ITEM_NETWORK_PASSWORD, attrs)
<bignose> bzr 2.1.1 on python 2.5.5 (Linux-2.6.32-3-powerpc64-ppc64-with-debian-squeeze-sid)
<bignose> IOError
<bignose> Debian Squeeze is currently undergoing a GNOME transition, so I don't know if this is something already reported
<bignose> (Launchpad pages don't load properly for me so can't check)
<lifeless> ok, this is entertaining: (changelog, larstiq) = find_changelog(tree, False) :)
<lifeless> bignose: fixed, bug in bzr-gtk
<bialix> heya bzr!
<Peng_> Good morning. :D
<Peng_> Three people with nicks that start with "bi" at once? Nice.
<idnar> they need to change it to "tri"
<idnar> oh, actually there's four of them
<bialix> Peng_: I see 4
<bialix> and 2 Peng
<bialix> :-P
<bialix> which peng is the right peng?
<tetsuo--> does the bazaar explorer client for windows get compiled with msvc?
<a212901390231901> it's not compiled.
<tetsuo--> then what is it?
<Peng_> bialix: I'm Peng's robot clone, but our consciousnesses are linked together, so it doesn't matter.
<tetsuo--> "bzr.exe" explorer"
<a212901390231901> pyqt can be compiled with either gcc or msvc
<Peng_> bialix: If you need help with a move, I'm stronger, but Peng's better with stairs.
<bialix> lol
<tetsuo--> a212901390231901: whatever the underlaying compiled thing is, it crashes like crazy
<a212901390231901> that's just py2exe packing.
<bialix> tetsuo--: what is your real question?
<bignose> lifeless: thanks
<bialix> tetsuo--: pastebin? bug report?
<tetsuo--> dont have one right now
<a212901390231901> do you mean crash-crash, because people have a bad habit of saying "crash" when they mean "exception thrown"
<tetsuo--> ok
<Peng> bialix: Jokes aside, I have two IRC clients open. Usually I use Peng but I'm thinking of switching to Peng_ again (and if I do, I'll eventually /nick it to Peng).
<tetsuo--> both exceptions and crashes
<a212901390231901> exceptions should be logged as bugs, real crashes are harder, but you can try and catch one in a debugger
<tetsuo--> all related to bazaar reading or writing to the wrong section of memory
<a212901390231901> okay, that does sound bad.
<a212901390231901> this is with the standard release installer?
<tetsuo--> they would be easy to work-around with 2 simple switches in msvc, or at least reveal their location more exactly
<tetsuo--> yes
<tetsuo--> standard release installer
<a212901390231901> well, one thing to try is to reproduce on trunk bzr with seperate plugins
<a212901390231901> then you can compile qt/sip/pyqt however you like
<bialix> tetsuo--: I'm not sure how the official installer built it's c-extensions. I've heard there is preffered gcc
<a212901390231901> it's a bit of a fag but doable.
<tetsuo--> i dont compile myself though :(
<bialix> tetsuo--: please, provide a bug report
<a212901390231901> alexander, do both sip and qt have prebuilt binaries?
<tetsuo--> it would be nice if the bazaar installer for windows (and all the stuff in it) passed the windows logo test
<bialix> a212901390231901: Ð½ÑÑ
<bialix> a212901390231901: Ð½ÑÑ
<bialix> a212901390231901: yes
<tetsuo--> it has very strict guidelines on memory leaks etc...
<bialix> rats
<bialix> a212901390231901: are you Martin gz?
<a212901390231901> yup.
<bialix> nice nick
<tetsuo--> and if you have a certificate you can log into winqual and download all the crashdumps windows generated for bzr
<a212901390231901> I can point you at various things to install seperately to see if you still get memory errors.
<bialix> a212901390231901: we're using official distrib from riverbank as I know
<tetsuo--> them maybe the problem is upstrea
<tetsuo--> m
<bialix> tetsuo--: which version of bzr?
<a212901390231901> yeah, or with some library interaction on your system, it's a little hard to tell without a detailed report
<tetsuo--> current version? 2.2 or something
<tetsuo--> i cannot run it right now to make it crash again
<tetsuo--> i think pyqt is under heavy refactoring right now
<tetsuo--> upstream
<a212901390231901> do log something next time it happens.
<Peng_> Tracebacks will still be around in .bzr.log even if you can't run it now.
<tetsuo--> where does bzr store that on windows?
<bialix> tetsuo--: I think 2.2 is a bit broken
<bialix> tetsuo--: location of .bzr.log can be seen in the output of `bzr version`
<tetsuo--> lol
<tetsuo--> bad behaviour there
<tetsuo--> just as i thought
<tetsuo--> since windows catches the errors there is nothing in the log
<tetsuo--> i have the same problem with my project, windows catches 9 out of 10 errors and doesn't generate logable error for me
<tetsuo--> so all those crashes get uploaded to winqual, and you need a windows logo cert to get them
<bialix> tetsuo--: what is your system?
<bialix> I think you'd better downgrade bzr to 2.1.1
<tetsuo--> windows 7 x64
<tetsuo--> i will do that
 * bialix is not sure bzr installer provides 64 bit version
<tetsuo--> it doesnt
<tetsuo--> luckily on windows that does not matter
<bialix> is it possible you have 32-bit related problems?
<bialix> ok
<tetsuo--> the problem is simple, somewhere in bzr is a buffer overflow that causes a read or write to executable memory, or outside of its memory bubble
<tetsuo--> windows 7 x64 catches such things very early
<tetsuo--> and chances are very high that the compiler is already warning about that
<tetsuo--> whats wierder, should python an qt have a garbage collector etc..?
<bialix> well, I can try to provide you compiler log for bzr trunk and py 2.5 and msvc 2003
<bialix> tetsuo--: yes, they have gc
<tetsuo--> then they should catch any errors/leaks in the python and qt script
<bialix> but 2.6 is most likely compiled against py 2.6
<tetsuo--> and that means its python or qt itself that is being leaky
<bialix> tetsuo--: can you send your question to bzr ML (or bzr-windows ML), and ask about compiler configuration?
<tetsuo--> make sense or not?
<bialix> tetsuo--: I don't think so
<a212901390231901> can do ctypes.windll.kernel32.SetErrorMode(2) to force a bonafide crash rather than getting the "report to microsoft..." thing, but still need a tool to look at the stack
<tetsuo--> a212901390231901:  that wont do anything if you dont have the pdb
<tetsuo--> debug symbols database for that exact compile
<tetsuo--> i dont use email, but i'll consider making a launchpad account and reporting a bug/feature request to pass the windows logo test
<tetsuo--> it has testing software that does both dynamic and static code analysis to find these kinds of problems
<tetsuo--> (but in vs2003 it really sucks)
<tetsuo--> preferably one would compile with vs2010 ultimate and add the following switch /analyse
<tetsuo--> oh and /w4
<bialix> tetsuo--: you can use gmane or nabble to use bzr ML
<a212901390231901> I bet that'd be one annoying log to comb through for things the size of python and qt
<tetsuo--> a212901390231901:  it would but almost all of the warnings would be valid
<tetsuo--> and especially things like python and qt should be nearly warning free
<tetsuo--> so much depends on them
<tetsuo--> obviously fixing a warning generated by a windows compiler helps the other platforms too
<tetsuo--> but linux has even better tools available
<tetsuo--> combined the software could be stable as a rock
<idnar> the odds are high that the problem is in a python extension module, not python itself
<idnar> it could be in the qt bindings, for example, or in qt itself
<a212901390231901> having to remember /D _CRT_SECURE_NO_WARNINGS isn't all that helpful
<tetsuo--> i would have guessed that would still be protected by the garbage collector
<idnar> tetsuo--: garbage collectors don't protect against any kind of buffer overflow
<idnar> they're just a way to manage memory allocation
<idnar> an extension module is just regular C code, so there's nothing stopping you from trashing your process's memory, although pure-python code won't (or shouldn't) be able to do that
<a212901390231901> anyway, I'm Alexander is right, downgrading should be fine, there have been a couple of issues with the 2.2 prereleases that are likely shallow
<a212901390231901> +sure
<tetsuo--> ideal swichtes for msvc are /gl /gs /safeseh /dynamicbase /nxcompat /o2 /w4 /analyse /GA /Arch:sse
<tetsuo--> fast and secure at the cost of a slightly larger binary
<tetsuo--> the arch could be higher or lower depending on the lowest supported target
<tetsuo--> yeah im going to downgrade, but that wont fix the problems upstream
<tetsuo--> ill try to get some more crashes and report that before downgrading
 * tetsuo-- is afk
<bignose> Launchpad bug pages simply hang for me.
<bignose> lifeless: can you tell me the URL of the bug report for the âbzr-gtkâ bug I reported earlier in here?
<avu> Is it somehow possible to clone an svn repository with bzr of which I can only access a certain subdirectory, not the repository root? meaning I only have read rights on /repos/root/foo. when I try a normal bzr branch svn+https://user:pass@server/repos/root/foo, I get an error because bzr tries PROPFIND on /repos/root
<awilkins> avu, I'm not sure that's possible because of the way that bzr-svn works
<avu> awilkins, bummer. Thanks for the info.
<cbz> gah
<cbz> it seems to me that you end up getting into situations where rebase is unavoidable when using bzr-svn
<jelmer> avu: no, that's not possible at the moment - there's an open bug report about it
<jelmer> cbz: why?
<cbz> So say i've merged my local feature branch back to my local trunk, but the svn repository at that point has additional commits in it
<avu> jelmer, ah, good, I'll subscribe to that, thanks
<cbz> i can't see what i can do short of uncommmitting my change, rebasing the trunk and then remerging it - which is what rebase would try and do anyway - albeit with less metadata available
<avu> jelmer, hm, I have problems finding the right bug on launchpad, could you point me to the right direction?
<cbz> jelmet, do my comments make sense?
<jelmer> cbz: which ones?
<cbz> "it seems to me that you end up getting into situations where rebase is unavoidable when using bzr-svn"
<cbz> 11:04 <cbz> i can't see what i can do short of uncommmitting my change, rebasing the trunk and then remerging it - which is what rebase would try and do anyway - albeit with less metadata available
<abranches> I created a branch with a bzr pull on the server in directori DIR1. But what I wanted was to create it in DIR1/DIR2. How Can I delete the branch in DIR1, so that I can create the branch in DIR1/DIR2 afterwards.
<spiv> Why not just move it directly?  mv DIR1/the-branch DIR1/DIR2
<abranches> spiv, I don't have ssh access to the server. But maybe I can ask someone...
<Peng_> sftp can rename, can't it?
<Peng_> s/, can't it/./
<Peng_> Heck, you could even do it using Bazaar's VFS with hitchhiker.
<cbz>  jelmer^
<abranches> Peng, what commands would you do exactly? I'm not sure about sftp, I'll look at it. Thanks.
<jelmer> cbz: Perhaps you're looking for the push_merged_revisions setting?
<cbz> possibly - but whats the alternative solution? unmerge my changes and pull and try to commit before someone else commits to the svn repo?
<jelmer> cbz: setting push_merged_revisions
<cbz> okay
<Andrei|2> Hi guys. I've developped a bzr plugin for Visual Studio, anyone wants to try it?
<bialix> Andrei|2: yes
<Andrei|2> here: http://aigenta.com/downloads/beta/UnifiedSCC_Setup.1.1.beta2.msi
<bialix> which one Visual Studio version supported?
<bialix> Andrei|2: ^
<Andrei|2> all up to 2008
<bialix> I'd suggest to announce your plugin in bzr ML or bzr-windows ML, or both
<bialix> Andrei|2: and 2003?
<Andrei|2> yes, 2003 too. not sure if it works very well, though
<Andrei|2> what's ML?
<Peng_> mailing list
<bialix> ML = mailing list
<Andrei|2> ok. is there any wiki to publish links for bzr tools?
<bialix> yes, wiki.bazaar.canonical.com
<bialix> one sec
<bialix> Andrei|2: http://wiki.bazaar.canonical.com/3rdPartyTools
<Andrei|2> thanks
<bialix> Andrei|2: have an error while trying to add project under version control
<Andrei|2> what it says?
<bialix> http://pastebin.com/HHZFtyFm
<Andrei|2> VS2003?
<bialix> yes, I've pushed Test connection button
<bialix> tried again, and without Test it works
<bialix> Andrei|2: check-in works strange. it commits all files except proj.sln and proj.vssscc, but those files added to version control
<Andrei|2> it doesn't show these files in commit window?
<bialix> proj.vssscc is not shown
<bialix> proj.sln shown in the pending checkins window
<Andrei|2> *.vssscc is service file, disregard it
<bialix> also I don't have menu item "View History"
<bialix> otherwise it looks good
<Andrei|2> it's managed by VS.. seek it on the source control toolbar
<bialix> ok
<bialix> I will try it with more recent VS later
<Andrei|2> thanks
<cody-somerville> jelmer, When will that support get landed?
<cody-somerville> jelmer, and how many other imports are broken now?
<rephormat> greetings
<rephormat> Why am I getting a cannot build extension error "bzrlib._chk_map_pyx" when using python setup.py install on bzr 2.1.0?
<Peng_> Um...got libzlib-dev?
<rephormat> THANKS!!
<rephormat> I always forget that one
<a212901390231901> bug 566923 would resolve this FAQ, hint hint.
<ubottu> Launchpad bug 566923 in bzr "Remove zlib double-dependency" [Medium,In progress] https://launchpad.net/bugs/566923
<rephormat> oh great.
<a212901390231901> you did ask the same thing just the other day though ;)
<rephormat> thats good that I'm not the only one frustrated with it
<rephormat> a212901390231901: Yeah I know. This is on a new system. I'm horrible at remembering things like that.
<rephormat> a212901390231901: to my defense I did check the documentation
<rephormat> ;-)
<bialix> a212901390231901: are your patch approved or blocked?
<a212901390231901> vila wanted john to look at the more complicated one again
<a212901390231901> which would be a good thing, I'm not super-keen on pyrex
<bialix> I can look at pyrex
<bialix> link?
<rephormat> alright after running python setup.py install it compiled and installed to /usr/loca/bin
<rephormat> but its the wrong version still
<rephormat> stupid Suse
<a212901390231901> bialix: https://code.launchpad.net/~gz/bzr/remove_zlib_double_dependency_pyapi/+merge/23711#review-diff
<rephormat> nvm
<rephormat> stupid pathing
<a212901390231901> I've eyeballed the C it produces and it seems reasonable-ish
<a212901390231901> one more favour alexander, do you have a russian copy of windows or an english language one?
<bialix> a212901390231901: both
<a212901390231901> okay, if you do `os.rename("something_non_existant", "whatever")` on the russian windows, python 2.5 or later, can you paste me the exception it prints?
<bialix> a212901390231901: I'm usually checks the generated C file as well ;-)
<bialix> a212901390231901: you want russian text?
<a212901390231901> yup.
<a212901390231901> and the exact bytes, ideally.
<a212901390231901> so catch and repr
<a212901390231901> repr(e.strerror) that is.
<bialix> there will be russian text in cp1251
<a212901390231901> that's what I'm hoping.
<a212901390231901> I read through the python source to confirm that's what'll happen, I just want a live example for code review
<jelmer> cody-somerville: hi
<bialix> a212901390231901: on Windows 2000 there is no text at all, and my russian windows xp at home
<jelmer> cody-somerville: I'm not sure how many other branches are broken, it's probably best to talk to the code team about that.
<bialix> a212901390231901: I'll do this later
<bialix> but I can confirm this behavior
<bialix> sometimes it's very annoying
<bialix> a212901390231901: re your pyrex: why you're using PyInt_AsUnsignedLongMask?
<a212901390231901> thanks!
<a212901390231901> the crc32 function returned a boxed python integer, that may be -2**31..2**31-1 or 0..2**32
<a212901390231901> (changed in some python version I forget)
<a212901390231901> this is why the python version does & 0xFFFFFFFF to get a positive value, but has the side effect of upcasting to a long
<bialix> a212901390231901: re crc32(<object>bit) -- I feel explicit cast to object is not strictly required here
<a212901390231901> PyInt_AsUnsignedLongMask boinks it into a plain unsigned value, which solves the issue
<a212901390231901> ^that's an annoying refcounting thing I couldn't find another way of doing
<a212901390231901> we get a borrowed reference when we get the value, so that goes in a PyObject* to avoid overhead when it's used in later contexts that don't need to addref
<bialix> :-/
<a212901390231901> but calling the function with that as a param means we need put it in a tuple, which means we need to addref it
<a212901390231901> which apparently pyrex spells by casting to 'object'
<bialix> I feel this code looks worse than plain C
<bialix> I hope jam will find the time to look on it
 * bialix going to home to his russian windows
<a212901390231901> yeah, I'm not mad about pyrex/cython as an idea, but john wrote a good post a while back about how much time he reckon it'd saved him with... static tuple I think?... and he's got a lot more experience with it than me
<bialix> right
<a212901390231901> so perhaps it's possible to learn to love the ugly.
<dash> cython is pretty great when you need to write as much or more python-api interacting code as C stuff
<Peng_> StaticTuple is not Pyrex.
<Peng_> Err, wait.
<Peng_> Right. StaticTuple is straight C.
<bialix> dash: but bzr using pyrex, not cython
<Peng_> bialix: But they're pretty close.
<dash> bialix: Ah, pity.
<Peng_> bialix: Cython is a fork of Pyrex.
<bialix> Peng_: yes, I *know*
<bialix> jam several times said he'd better using cython...
<bialix> cython has some very nice features
<Peng_> Worse, bzr has a few hacks to make certain versions of Pyrex happy.
<bialix> ~~~
<allquixotic> How efficiently does bzr handle version-controlled binary files that only change slightly between revisions? Is it somewhere on the order of RTpatch or bsdiff, or is it a carte blanche "the file is different so let's store a separate copy"?
<xnox> allquixotic, not that well as far as I know
<xnox> allquixotic, for example this branch https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/xulrunner-1.9.1/lucid
<LeoNerd> Storing binary files in a DVCS is of limited utility anyway
<LeoNerd> Half the point is the ability to branch, make changes, merge
<xnox> well lp:ubuntu/xulrunner-1.9.1
<LeoNerd> You can't merge changes to opaque binary files and haev any hope in hell of not breaking it
<xnox> has 16 revisions of xulrunner tarball. The branch is huge I never managed to clone it =)
<dash> LeoNerd: sure, but some people only pay attention to the other half of the point of a VCS :)
<xnox> on merge conflicts you will get "this.binary or that.binary" and you will have to merge it yourself =) using whatever program edits those binaries
<allquixotic> xnox: I see.. so if I choose to simply replace the old binary with the new one, it will literally store an entire copy of the new one, even if the two have very slight differences?
<xnox> LeoNerd, you can import & export tarballs efficiently if you are using bzr-builddeb plugin. But that's only if you have mostly text-base src tarballs. You can import/export tarballs using that
<LeoNerd> Hrm?
 * xnox got the nicks wrong again
<xnox> allquixotic, ^^^ where I "talked" to LeoNerd
<LeoNerd> Ah. :) That makes more sense now
<allquixotic> xnox: Let's just take a hypothetical case of a very complex set of images that are encoded in a simple enough format that changing only a few pixels makes minimal binary diffs between them. "Other VCSes" (such as Mercurial, also a DVCS) can very efficiently handle that diff just like sophisticated binary patch tools that exist outside of the VCS world. Is there a particular reason why bzr can't do that, or is it just
<allquixotic>  unimplemented?
<allquixotic> I mean, you could easily say "don't do that", but that's really a cop-out. The benefits of having the files version-tracked are enormous on their own. It's a nightmare having "myimg-20090821.png" "myimg-2009-0830.png" and so on and so on. VCS makes that easy on purpose.
<xnox> allquixotic,  I'm not experienced enough bzr developer to tell you.
<xnox> allquixotic, but I believe you can mark files to be treated as text
<xnox> and then bzr should repack, diff them as usual
<xnox> i wonder if it does it anyway
<xnox> let me browse through source to see any hints
<allquixotic> I might try it for fun. I'll commit a 1 MB .png, hex edit it, change one 0 to a 1, commit again, and if it uploads 1 MB again then I'll just have to keep binary files outside of bzr
<xnox> allquixotic, after first commit and after second commit run $ bzr pack
<xnox> and delete files in .bzr/repository/obsolete_packs/*
<xnox> or just ignore obsolete_packs dir when looking at the size of the repository
<allquixotic> xnox: if I do those two steps in my local branch before I push (not using a bound branch), will all that extraneous data not get uploaded to the server? :)
<xnox> allquixotic, obsolete_packs/* are not uploaded
<allquixotic> oh cool
<allquixotic> so does it automatically pack before it pushes, then?
<xnox> it packs on logarithmic scale with respect to commits/pulls
<xnox> so sometimes you end up doing commit and it spawns a repack
<xnox> Me is committing ubuntu.iso to a bzr branch
<xnox> and I will do $ echo "1" >> iso
<xnox> to test this =)
<allquixotic> if the repack has some algorithm for handling packing of binary files, I'm happy... even if it isn't as efficient as rtpatch or bsdiff, if it's something other than store two nearly-identical files in full, I'm happy :)
<allquixotic> Thanks for investigating that, xnox :)
<allquixotic> I'm having another unrelated puzzler at the moment; I may need to ask this on #launchpad, but didn't get a reply there in ~30 mins so I'll repost here.
<allquixotic> A colleague is trying to do an Update operation on a launchpad bzr branch in my private (commercial) branch. He's on Windows XP running bzr 2.1.1 standalone. The error: "-> bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(bzr+ssh://my_user@bazaar.launchpad.net/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request." Any
<allquixotic>  insight?
<xnox> allquixotic, what do you mean "update operation"
<xnox> $ bzr upgrade
<xnox> or
<xnox> $ bzr update
<allquixotic> xnox: the "Update" button in bzr explorer, on a bound branch
<allquixotic> pretty sure that's bzr update
<xnox> allquixotic, i hope (my_user) is a masked username and sshkeys are installed correctly on his machine
<allquixotic> my_user is not his actual launchpad id :)
<xnox> apart from that. he can try to use bzr+http:// url
<allquixotic> he did call launchpad-login with the right username, and has his ssh keys set up
<allquixotic> oh, http won't work, because it's a private branch
<xnox> that way it's not gonna use ssh and should be still fast
<allquixotic> if unauthenticated http works then it's not private
<allquixotic> which would be a big deal
<xnox> allquixotic, =))))))))) well I have nothing to do with commercial launchpad offerings
<xnox> sorry =)
<xnox> dunno
 * xnox is doing only open-source stuff =)
<allquixotic> it seems that many of the Canonical folks who work on launchpad are in Australia or NZ, because i was able to get hold of them at 5 am GMT-5, but i tried just a few minutes ago and they're probably asleep ;)
<xnox> allquixotic, as far as I know there are some folks in NZ and some folks in Vancouver Canada
<allquixotic> oh well, I will walk my colleague through the steps to check out the branch from scratch and see if that works
<xnox> the Vancouver side is running 24h support.... last time I heard
<allquixotic> good news is he doesn't have any uncommitted changes, or any local commits queued up
<allquixotic> so he can just pull a fresh copy
<allquixotic> er, branch, rather... bzr branch
<bialix> a212901390231901: ping
<bialix> it seems python 2.5.4 broke WindowsErrors + non-ascii texts
<bialix> C:\work\Bazaar\plugins\qbzr>python -c "import os; os.unlink('lib')"
<bialix> Traceback (most recent call last):
<bialix>   File "<string>", line 1, in <module>
<bialix> WindowsError: [Error 5] : 'lib'
<bialix> a212901390231901: as you can see there is stripped non-ascii characters and only ascii file name left
<a212901390231901> ew, that's ugly.
<bialix> in previous versions of python 2.5.x there *was* russian text, I swear
<a212901390231901> I take it the console is a different codepage from the ACP used for error messages?
<bialix> no, chcp has no effect
<a212901390231901> okay, so some kind of bad bug fix attempt maybe, wonder if I can track it down.
<bialix> a212901390231901: I found something
<bialix> a212901390231901: http://pastebin.com/9QFeWf4j
<bialix> the russian text said: "unable to create file,"
<a212901390231901> ha. but... str(e) strips?
<bialix> yep
<a212901390231901> what about e.strerror?
<bialix> empty s well
<bialix> empty as well
<a212901390231901> okay, that narrows the search
<bialix> ok
<a212901390231901> thanks!
<bialix> np
<a212901390231901> hmph, will have to come back to this later
<bendj> my bzr-svn plugin works fine @ branch/pull of source from svn repos.  afaict, however, it does NOT get the svn:externals svn:ignores info, or more importantly, convert then to bzr-speak.
<bendj> CAN it?
<NfNitLoop> bendj:  I'd answer you, but you left. :p
<masmullin> hello I have a (hopefully basic) bzr merge problem.  Is there anyone here who might be able to give me a hand?
<dash> quite likely :)
<masmullin> Ok here goes there are two development branches that I have loaded onto lauchpad (~masmullin/scintilla-cocoa/makefilework and ~masmullin/scintilla-cocoa/mousewheel)
<masmullin> both have the same parent, which is at revision 33
<masmullin> I have made 2 commits to each branch, so they are both at revision 35
<masmullin> when I do the following command "bzr branch lp:~masmullin/scintilla-cocoa/mousewheel && cd mousewheel && bzr merge lp:~masmullin/scintilla-cocoa/makefilework" bzr responds to me saying "Nothing to do"
<masmullin> I want to get the changes from the makefilework branch into the mousewheel branch
<masmullin> any ideas?
<masmullin> any URLs that describe what I want (I've been searching but haven't found the info I need)
<dash> masmullin: Hm
<dash> masmullin: try doing 'bzr missing' instead of 'bzr merge'
<dash> that'll tell you about differences between the branches
<masmullin> it tells me that I have "2 extra revision(s)" and gives me the commit messages from the mousewheel branch
<masmullin> it does not tell me anything about the makefilework branch
<dash> masmullin: ok
<dash> so what bzr thinks is going on is that all the revisions in makefilework are already in your current branch
<masmullin> :( unfortunately this is not true.
<dash> masmullin: looking at the log on code.launchpad.net your results are a little surprising
<masmullin> I should point out that the mousewheel branch is "newer" (time-wise) than the makefilework branch
<masmullin> dash: have I run into an unknown bug, or am I using the tool incorrectly?
<dash> masmullin: i'm stumped. but i am not an expert :)
<masmullin> dash: stumped too... looks like I should file a report
<IslandUsurper> masmullin, bzr qlog says that mousewheel has already merged in the two commits from makefilework
<IslandUsurper> in revno 34
<masmullin> islandusurper: via manual inspection i can tell that this is incorrect
<mkanat> masmullin: If bzr says that it's happened, then there was probably some human error along the way.
<maxb> masmullin: You have unfortunately made an error when creating the mousewheel branch, and recorded a merge which did not actually occur in the history
<masmullin> how do I ifix this?
<mkanat> masmullin: If it's the most recent commit, you can uncommit it.
<mkanat> masmullin: Did you do "bzr revert ." after merging, or something?
<maxb> Ideally? Create a new branch from the existing trunk, port your existing changes to the new branch, and throw away the old mousewheel branch
<masmullin> mkanat: not to my knowledge
<masmullin> maxh: I can do that... the changes made were small
<mkanat> masmullin: Note that if anybody else has pulled from your branch, uncomitting is bad.
<maxb> A very important thing to understand is that "bzr revert" and "bzr revert ." have significantly different effects on the history
<maxb> masmullin: Do you have the bzr-rewrite extension installed?
<lifeless> yeah, I regret that subtle distinction
<lifeless> thinking we should make it a flag
<masmullin> i dont know... I installed the 2.1.1 for mac and accepted all the plugins that came with that... I have no other plugins installed
<masmullin> no worries though... Im 75% done rewriting the change manually
<mkanat> lifeless: Yeah, a flag would be way better.
<maxb> If so, you can rebuild your changes without the bad history by branching r33 of trunk, and then using 'bzr replay -r34..35 mousewheel'
<mkanat> lifeless: I didn't even know about "." until you told me. Maybe --keep-merges.
<mkanat> lifeless: Or --remember-merges to make it the opposite of --forget-merges.
<maxb> A flag would make sense - going to a pristine tree but keeping pending-merges is a highly specialized operation
<maxb> --keep-merges somehow feels more explanatory to me
<mkanat> maxb: Me too.
<masmullin> alright I got it working nicely now... sorry to take up your time, thank you for the help
<kkaefer> how is the lp: alias integrated/defined in bazaar?
<Peng_> kkaefer: It's somewhere in bzrlib.plugins.launchpad, using Bazaar's directory service feature.
<lifeless> vila: still around ?
<lifeless> or jam: ?
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/2.0-new-subunit/+merge/24365
<jam> lifeless: I'm around
<rephormat> What is the best way to use launchpad as a central repository?
<lifeless> this should unblock yours and spivs patches that are targeted to 2.0
<rephormat> Meaning I do my developing on one machine (bzr push lp:project) and then get the updated source from launchpad on the production machine?
<lifeless> rephormat: bzr
<lifeless> rephormat: oh sure, or push directly, or whatever your preference is.
<jam> lifeless: well, if it gets things working, approve
<lifeless> jam: care to clicky clicky it ? :P
<jam> lifeless: already done
<rephormat> lifeless: lets say I have successfully pushed to launchpad, but want to update the sources on my production machine from launchpad?
<lifeless> thanks!
<rephormat> how would I do that?
<lifeless> rephormat: bzr pull, or bzr update, depending on whether you did 'bzr branch' or 'bzr checkout' on the production machine
<rephormat> lifeless: I did bzr branch.. should I have done bzr checkout?
<lifeless> rephormat: if you did bzr branch, then use 'bzr pull' to update the sources on your production machine.
<rephormat> lifeless: Well #$% I thought I tried that already.
<rephormat> lifeless: THANKS! So what is the difference between branch and checkout?
<lifeless> rephormat: in a checkout, commits go to the 'master' branch (as do pull, push, uncommit); when the master branch has new work on it use 'update' to get that work to be present locally.
<rephormat> AHH!!!
<rephormat> so with a branch I can do development locally and then push to the centralized location?
<lifeless> rephormat: in a branch, commits/pull/push to this/uncommit affect just the branch, use pull to get new work from some other branch into this branch, or merge + commit if you have been making independent changes.
<lifeless> yes
<rephormat> SO!!!
<rephormat> I would use branch to do "development/feature requests" and prbably checkout for bug fixes on the main branch?!!
<lifeless> sure
<rephormat> sweet fancy moses!
<rephormat> Thanks!!
<dash> anybody seen this before with bzr-svn? http://paste.ubuntu.com/424235/
<lifeless> not I
<jelmer> dash: there's an open bug report about it
<dash> jelmer: great
<dash> jelmer: i managed to work around it by branching from before my last merge, pulling from svn, then pulling from that into my working branch
<bendj> Reading @ jelmer's bzr-svn docs (http://wiki.bazaar.canonical.com/ForeignBranches/Subversion),  I note: "'svn:ignore' is not imported.", and a reference to a spec (https://launchpad.net/bzr/+spec/new-ignore-rules) that says "completed" as of 2007, per mbp.  Unclear whether just the spec was completed, or the feature was ...
<bendj> Does bzr-svn support import of svn:ignores?  I _do_ know that bzr-externals handles the svn:externals piece of the equation ...
<TresEquis> bendj: the feature isn't in place
<bendj> TresEquis: double RATS!
<bendj> I am trying sooooo hard to not have to use svn ....
<bendj> without monkeying about, anyway :-/
<jelmer> bendj: no, neither ignores nor externals are imported at the moment - mainly because there's no good thing to map them to in bazaar
<TresEquis> bendj: you can work around that one via a script
<TresEquis> jelmer: couldn't bzr just generate a .bzrigonre file?
<TresEquis> bzr-svn, I mean
<TresEquis> I understand that the externals fix isn't pretty
<jelmer> TresEquis: that breaks with roundtripping, since we'd need a way to convert .bzrignore to svn:ignore as well
<jelmer> TresEquis: there isn't a fix :-)
<TresEquis> heh, I just check the .bzrignore file into svn ;)
<bendj> jelmer Arg. I'd though svn:externals was supported -- but digging around, then, still seems this is relevant: http://stackoverflow.com/questions/463275/do-you-have-a-clever-hack-to-work-around-svnexternals-not-being-supported-in-bzr
<bendj> ( bendj considerds sticking head in sand until a solution arrives ... )
<jelmer> bendj: yes, that's still accurate.
<TresEquis> the nested-tree bit is still stalled
<bendj> jelmer: thanks for the info, not necessarily for the news.  <rant> sick of being told "just use subversion.  it's a 'real' rcs" </rant>
<jelmer> TresEquis: yeah, unfortunately :-/
<jelmer> bendj: sorry, can't really help with that. nested trees are a nontrivial project to take on
<TresEquis> I get away with (manually) mapping externals onto unrelated checkouts
<bendj> Who can we "light a fire under" for nested-tree?  Anyone in particular?  mbp?  Perhaps a community-bucket bribe isreq'd?
<TresEquis> which I then tell the paretn to ignore
<bendj> TresEquis: Understood.  For serious adoption, though, gotta have ways to deal with existing 'legacy' (== svn,cvs) project code bases.
<bendj> . /me waves the bzr cheerleading-flag (miniature, souvenir version ...)
<TresEquis> I understand the need
<jelmer> bendj: yeah, mbp is probably the best person to talk to.
<TresEquis> I've just decided that using bzr to boost my own productivity when working with big SVN repositories is worth the hassle, and the workarounds
<bendj> TresEquis: When you say 'manually mapping', do you mean script-based?  ala, extract the svn:{ignores,externals} then have a script do the mapping?  or do you mean by-hand?
<bendj> seen mbp
<bendj> hrmph.  duzznt work ....
<bendj> rubs lamp.  nada.
<bendj> aha! whois ...
<bendj> grr.  different mbp ...
<TresEquis> bendj: I do it by hand, mostly
<TresEquis> have a directory full of the "common" externals
<TresEquis> which I use for symlinks when making a new bzr branch
<bendj> TresEquis: k.  sure, workable. messy ....
<TresEquis> yup
<xnox> TresEquis, well as long as you are not doing "svn-import for everyone" i did this
<TresEquis> hmm?
<xnox> $ bzr branch svn://external.server/bla/trunk path/to/where/external/should/be
<xnox> $ bzr join path/to/where/external/should/be
<xnox> $ bzr ci
<xnox> Now you have diverged from both svn's
<xnox> but you can do
<xnox> $ bzr merge :parent
<xnox> to get updates from svn
<xnox> and
<xnox> $ bzr merge svn://external.server/bla/trunk
<xnox> to get updates in the extern subdit
<xnox> to get updates in the extern subdir
<TresEquis> interesting
<xnox> But *actually* commiting
<TresEquis> I didn't know about bzr join
<xnox> back to svn
<xnox> is tricky cause you need to have pristine import somewhere else which you push to from this joined beast
<TresEquis> I usually keep a pristine SVN import around anyway
<xnox> TresEquis, join & split is the smallest bit of NestedTrees that landed
<TresEquis> so I would do your dance inside a branch from that
<xnox> it allows you to join & split branches. But once you join it's in your history
<xnox> so when you eg $ bzr up -r-100
<xnox> your "joined" external is not there
<TresEquis> ah
<bendj> xnox: interesting.  in the current case, i'm ONLY interested in svn co -- from a parent project -- and I never plan on committing BACK to the parent.
<xnox> well then you are fine =)
<TresEquis> bendj: you should use 'bzr branch svn+ssh://whatever' then
<TresEquis> or do you plan to use 'bzr up' inside your checkout?
<xnox> Then I would even join the external at the commit the external was actually introduced and merge it with the current tip
<xnox> that way you can use the point revision of the joined tree to revert it independently of the mainline
#bzr 2010-04-29
<bendj> TresEquis: sure. or @ http:// or webdav, etc.  hrm.  with a little juggling, i *could* live with one-way only ... still not ideal for the long term. but ...
 * TresEquis is running live mirrors of the repoze SVN repository to each of bzr, git, and hg
<TresEquis> mostly to say STFU to folks who want us to commit to *their* DVCS choice
<bendj> TresEquis: I was hoping to say STFU to projects that want me to commit to crowbarring MY workflow to fit THEIR rcs choice ;-)
<TresEquis> sure
<TresEquis> SVN doesn't suck too badly as the "centralized" repo
<TresEquis> and if everybody else can do branches, etc. using their tool of choice, then that makes SVN an "implementation detail"
<bendj> sneaker-net with Hollerith field punched cards was, at times, easier .... sigh.
<TresEquis> only those who can commit to the central repo need to care about
<lifeless> mwhudson: https://code.launchpad.net/~mwhudson/launchpad/code-import-workers-copy-too-much/+merge/24282
<lifeless> mwhudson: did you see my note?
<mwhudson> lifeless: yes, i meant to ask you about that
<mwhudson> lifeless: i don't understand how it's "wrong", i can see it might be less than perfect
<lifeless> theres nothing that says the control dir is .bzr
<mwhudson> oh come on
<lifeless> we've tried pretty hard to make it possible for loom or things like that to use different dirs
<lifeless> its a shame to bypass that
<lifeless> anyhow
<lifeless> if you want to use .bzr + clone, do so - but using .transport will be shorter and easier to read IMO
<lifeless> I guess for lp which enforces .bzr as the control dir name there are less degrees of freedom, at least at the moment.
<bendj> xnox: TresEquis k. so to be clear -- as long as i'm only branching, with NO re-commit back to upstream, despite NOT support svn:{externals,ignores}, mmy bzr-svn branch/co *of* (from?) the central svn repo will be locally complete, with all the externals, etc pulled in. correct?
<bendj>  AND, I can hack to my heart's delight, then 'bzr merge' to repull upstream changes later?
<mwhudson> lifeless: it seemed more symmetric to me to clone on both transports
<xnox> bendj, well bzr treats imported svn revisions as regular bzr commits. So yes you can do anything with your branch. As long as you do not rewrite history you will be able to merge from svn.
<lifeless> mwhudson: if I was writing it I would use relpath and the transport itself, I think.
<mwhudson> if the control dir was called something other than .bzr i should be doing something else, like comparing .transport and .root_transport
<xnox> bendj, so commit .bzrignore and use join to get the externals. And got wild =)
<xnox> bendj, just don't use rewrite plugin and don't uncommit svn revisions
<lifeless> mwhudson: perhaps a :XXX that it won't handle non .bzr control dirs [contrasting with cloning or a complete copy]
<xnox> and don't merge partial revisions e.g. merge -r-20..-19
<lifeless> mwhudson: and use the code you wrote
<mwhudson> lifeless: i can agree to that, certainly
<bendj> xnox i clearly misunderstood the need -- some, anyway -- for maintaing the externals/ignores for one-way-only checkout/branch.  still, the need's fully there for re-commit. just ping-ed the "power that be" for input.  pending ...
<bendj> xnox: does your 'method', by any chance, exist anywhere in print?  on the wiki, perhaps?
<xnox> bendj, well I can blog it now to planet =)
<lifeless> mwhudson: I don't suggest these things just to make your life hard :P
<lifeless> mwhudson: its a corollary to not using the standard bzr glue to do things
<mwhudson> indeed
<bendj> xnox: Would be useful if 'immortalized' ... btw, WHICH Planet?
<xnox> Ubuntu Planet =)
<mwhudson> doing the right (well, more right) thing doesn't seem to hard actually
<bendj> xnox: thx. (rss to the rescue ...)
<mwhudson> lifeless: is this the sort of thing you meant? http://pastebin.ubuntu.com/424287/
<lifeless> mwhudson: that would make me maximally happy, if you're able to use it
<lifeless> mwhudson: you can make it a little more compact if you like: (sec, typing)
<mwhudson> lifeless: it passes my tests, so yeah i'm happy to use that
<lifeless> http://pastebin.ubuntu.com/424288/
<lifeless> mwhudson: the mkdir and ensure_base were redundant, so I folded together
<mwhudson> lifeless: well, not quite, because ensure_base will only create '.'
<mwhudson> but a create_prefix is cleaner anyway
<lifeless> mwhudson: oh, doh :)
<xnox> bendj, published
<xnox> bendj, http://tinyurl.com/bzr-join
<bendj> xnox: Thanks -- just caught it on the feed :-)
<xnox> bendj, does it look ok ?
<xnox> i mean formatting
<bendj> xnox: yup.  formatted nicely on this end
<bendj> brb ...
<bendj> ping xnox
<xnox> bendj, pong
<bendj> xnox: just fyi, http://github.com/andrep/git-svn-clone-externals.  adaptable, perhaps ..
<xnox> yeah i guess but =)
<bendj> aha, the 'yahbut' ...
<xnox> what's the point =)
<xnox> i like my way cause I know I'm on single branch, i can share it with people and work together
<xnox> and my joined branch doesn't require any other commands / plugins
<bendj> xnox  Sure.  Different strokes ... adminttedly, I'm looking at a scripted solution for projects with large #'s of svn:externals ...
<bendj> agh! admittedly
<xnox> bendj, I know a tool like that =)
<xnox> it starts with "s" and ends with "n"
<bendj> comment += $comment . ' ... and that pulls it all into a local DVCS.'
<xnox> =)
<bendj> This page (http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/svn_plugin.html) references "rich-root", as in: 'bzr init-repo --default-rich-root'.  manpage fails to mention "--default-rich-root" as a specific option, and states for "--default" that "Provides rich roots which are a one-way transition.".
<bendj> And, of course, search in docs (http://doc.bazaar.canonical.com/bzr.dev/en/search.html) on 'rich-root' comes back empty.
<bendj> W.   T.    F.  ?!
<bendj> where is this documented?  Buehler?  Buehler?
<idnar> I think the docs are a bit out of sync
<idnar> the new default format in bzr 2.0 is the 2a format, which is a "rich root" format
<idnar> so there's no (longer) --default-rich-root, because --default is already rich root
<idnar> I'd say svn_plugin.html should be changed, I'd suggest filing a bug report
<bendj> idnar: Ugh.  Ok, b4 I do, I'm gonna try to 'sed' the commentary at https://answers.launchpad.net/bzr/+question/71563#6 "... The reason appears to be that bzr doesn't set a unique root ID for a branch unless it was *created* as a rich-root branch.  ...", to see if it stil holds.
<bendj> idnar: Thanks.  I think.
<bendj> Although, I think I've bumped squarely into the lack of nested-tree support.  again.  But by another path ...
<idnar> spiv: (moving from #launchpad) I guess that would help, but I wouldn't want to define a prefix for each and every one of my projects
<spiv> I can't find the plugin I was thinking of, but bzr-bookmarks is perhaps close enough.
<idnar> maybe what I really need is a browser plugin so I can click a button when I'm viewing a merge proposal, and have it grab the corresponding branch
<idnar> that's not the only time I branch a new remote branch, but it's probably the most common
 * idnar looks at bzr-bookmarks
<spiv> I *think* actually that bzr-bookmarks will look at locations.conf, but perhaps only if you already have a branch.  Hmm.
<thumper> idnar: make something that hooks into the scheme provider
<thumper> idnar: so if you click on lp:some-branch it fires up an app to get it :)
<_habnabit> If I did a bzr checkout by accident instead of a bzr branch from a launchpad branch, is there an easy way to switch?
<_habnabit> I have uncommitted changes that I don't want to implicitly push.
<spiv> _habnabit: bzr reconfigure --standalone
<spiv> Oh, oops, wrong option
<_habnabit> --branch ?
<spiv> bzr reconfigure --tree
<_habnabit> Aha.
<_habnabit> Thanks!
<spiv> (Or 'bzr unbind')
<_habnabit> That did it.
<_habnabit> Oh nice, that looks like exactly what I want.
<vila> hi all !
<vila> spiv: Can we talk briefly about https://code.edge.launchpad.net/~vila/bzr/401599-strict-warnings/+merge/23932 ?
<vila> spiv: I've got the feeling you're searching for a test modification that has been done in a previous submission where the behaviour changed, this one was about the displayed message which was misleading
<spiv> vila: well, I've checked what trunk without that does, and what that patch changes.
<vila> spiv: we were still saying 'use --no-strict to force the push' even if the push was already occurring
<spiv> vila: what other submissions should I know about?  I didn't notice any mention of them in that proposal.
<vila> spiv: did you see a behaviour change ?
<spiv> I did, and I agree with it.  But I don't see a test for the behaviour change.
<spiv> (To be precise: a behaviour change in your proposal relative to what was in trunk)
<vila> huh ? Which one ?
<spiv> Er, the bits of the patch that touch files other than NEWS and bzrlib/tests/*
<vila> spiv: the previous submission is revno 5151 in trunk
<spiv> i.e. the behaviour change described in the NEWS entry.
<spiv> I'm rather confused.
<vila> spiv: well, the other files only modified the displayed message, not if we push or not
<spiv> The display of a message *is* behaviour.
<vila> haaa, that's were we were misundestanding each other :)
<vila> ok, I made a distinction between whether we were pushing or not (or dpushing or sending) and what message we displayed
<vila> before the last submission the tests weren't checking the message, I changed that and that only
<spiv> But the tests still don't test that no warning is displayed in cases where we expect no warning: i.e. tests that would have caught the original spurious warnings.
<vila> spiv: they do now
<spiv> No, they test something much weaker.
<vila> more focused, not weaker
<vila> for example: push displays 'Created new branch'
<spiv> On stderr?
<vila> if we change it to 'Created new branch up to revno nn' the test doesn't have to be impacted because we already check that we push the right revision
<vila> yes on stderr
<vila> I mentioned that in my previous answer (but you didn't cite this part)
<spiv> Not deliberately, I just missed that bit :)
<vila> no worries
<vila> the truth is, after your review, I tried to build the full stderr content and this was... dirty
<vila> As I said I'm not a big fan of assertContainsRe since it weakens some tests, but here.... I found the balance was in favour of it
<spiv> So, the test for "doesn't contain this regex" is weak, in the sense of being fragile.
<vila> kind of,
<spiv> (Even though it is focused on the specific messages we care about)
<vila> it's also robust about spurious changes in the part it didn't care
<spiv> Because it will easily pass incorrectly with minor wording changes.
<spiv> So the risk of incorrect failures is low, but the risk of incorrect successes is high.
<vila> If the changes are in unrelated messages, the test shouldn't have to care
<poolie> hi vila
<spiv> It would be nice if run_bzr could give us a list of warnings emitted to the user, or even just a list of messages.
<vila> hey poolie !
<poolie> spiv, that would be nice
<spiv> Rather than a single lump of bytes that got written to stderr.
<vila> spiv: pfew, yeah
<poolie> there is code to capture them, of course
<poolie> but not on by default there
<poolie> more standardization needed
<spiv> But, we may be able to cheat that by splitting stderr by lines?
<vila> poolie: that needs to be factored out for trace.warning :-) I think I know about at least 3 or 4 call sites now
<spiv> Because in many cases there's a one-to-one correspondence between a line and a message/warning.
<poolie> vila, how about a brief call?
<spiv> vila: So, I feel these tests of cmd_push ought to be able to account for every line of output
<vila> spiv: my position is that, on principle I agree with you about the strict checking of stderr, but in this specific case I made an exception because: 1) I see little to be gained, 2) the resulting code was awful (I revert to the simpler version I landed when I saw that)
<vila> poolie: just a sec
<spiv> vila: perhaps pass a regex list to add to a default list that expects to see the "N new revisions" or whatever.
<spiv> (using "line" as proxy for "message or warning", which perhaps is overly optimistic)
<vila> spiv: yeah I thought about that too, but it's all the same in the end, if we check regexps there will still be holes and adding unrelated messages there is just asking for trouble: when they change the tests will fail for the wrong reason
<spiv> I agree the benefit for cmd_push is low, but ideally we'd find a way to do this that we can reuse in other places.
<spiv> Capturing the warnings emitted more directly might be better than asserting about the exact bytes on stderr, I can see arguments either way.
<spiv> (It's kind of a shame we only get 2 channels to emit messages on!)
<vila> and to be honest, using blackbox tests there feels wrong, but it's often the case when trying to observe the behavior of command lines options that are handled in command.run()
<spiv> But, if there's one thing I'd like you to take away from this review:
<vila> test should fail first ? :)
<spiv> It's don't claim that what is shown in the UI is not behaviour ;)
<vila> hmm
<bialix> heya bzr!
<bialix> _o/ vila
<vila> spiv: I'll think about it
<vila> hey bialix
<vila> poolie: calling
<poolie> hi bialix
<spiv> vila: I can argue about in some detail, but perhaps the main justification for me saying that is "it'll confuse people" :)
<bialix> hi poolie  :-)
<vila> spiv: I agree, it's just my poor english
<spiv> vila: and that english is poor!
<bialix> vila: http://ostatic.com/blog/more-bad-english-please
<bialix> I've fwd this article to ru_bzr people and suggest to not shy filing more bug reports
 * bialix is working as english proxy sometimes
<lifeless> spiv: small request - start setting commit messages (e.g. on
<lifeless> https://code.edge.launchpad.net/~gagern/bzr/bug387117/+merge/23750)
<spiv> lifeless: it's a bit grating at the moment that feed-pqm-by-email and feed-pqm-by-lp-queue-magic expect different formats for the commit messages, AIUI.
<idnar> :)
<idnar> er, wrong window
<spiv> So that discourages me from setting it unless I'm about to submit it myself.
<spiv> Thinking of which, if PQM is reading directly from LP, perhaps it should just set the author revprop rather than putting it in the commit message.
<lifeless> spiv: feed by lp queue seems very reliable to me know, I've been tracking it this week and no exceptions in th elogs according to spm
<lifeless> s/know/now/
<lifeless> spiv: I don't think setting author is appropriate
<lifeless> pqm is merging, the history knowledge of who introduced lines is in the history
<spiv> Then why are we putting the name in the commit message?
<lifeless> spiv: I'm not sure. I know why we put the queuer there, but the author never really made sense to me.
<spiv> I thought it was because we wanted to credit the author for people viewing the mainline, but PQM didn't give us control of any fields other than the message.
<lifeless> I got asked to do it/followed what Martin was doing or whatever some years ago
<lifeless> spiv: pqm has always been modifiable
<lifeless> spiv: I object to mangling metadata incorrectly to solve reporting problems; we should just report better.
<spiv> Sure, but lack of tuits involved in improving PQM, getting it deployed, tested, and upgrading the pqm-submit plugin devs were using to use it meant that never happened because the workaround was bearable.
<lifeless> spiv: I'd be happy to drop the trailing (author)
<lifeless> if we were to set author in pqm, it should be to the queuer, IMO.
<lifeless> because they are conceptually responsible for the merge
<spiv> I don't see that "author" is an incorrect name for the field.  Yes it might not be the sole work of that person, but the person responsible for proposing the patch is assumed to be the person responsible for assembling it and otherwise doing some significant work towards making it land.
<lifeless> I've a little trouble binding things there
<spiv> I'm not particularly against thinking of a better field, I just don't know that the distinction is more important.
<lifeless> could you rephrase
<spiv> The primary person we typically credit in commit messages is generally the person that proposed the patch.  The person that proposed a patch is generally the person that wrote most of it, or at least did significant work on it (e.g. backporting).  Calling people that do that "author" seems good enough for me.
<spiv> Especially if it unclutters the commit logs :)
<lifeless> do you mean the person in the trailing () or the leading () ?
<lifeless> spiv: perhaps we can talk more next week on this
<lifeless> spiv: I'm really convinced we should be able to show the people without setting author on a merge daemon
<spiv> Well, we aren't completely consistent about how we use trailing/leading (), so the answer seems to be "trailing, or leading if trailing is absent, or 'for $name' in leading if given"
<spiv> Yes, showing the people is the main thing.  The second thing is not abusing commit messages.
<spiv> Author is a convenient hammer for achieving those two, but I'm not wedded to it.
<lifeless> I don't like setting author for a few reasons; we don't do it when we do merges by hand in other projects; it doesn't map well IMO to the intent; it will generally tag precisely zero lines.
<spiv> What do you mean by tagging lines?
<lifeless> in annotate
<lifeless> you see the revisions that introduce text to the tree
<lifeless> the annotation view of bzr shouldn't [in general] attribute *any* lines to pqm
<spiv> Sure.  I'm not too bothered by annotate.
<lifeless> the most grating thing to me, I think, is that the old default log avoids the question entirely; it shows *the right stuff*, and there aren't any questions about the contributors to a patch.
<spiv> I'd be happy to see lp-proposed-by and lp-landed-by revprops.
<lifeless> spiv: proposed/landed/queued ?
<poolie> hi lifeless
<lifeless> hi poolie
<spiv> lifeless: sure, whatever names, just capturing the data in a sane way :)
<lifeless> spiv: ack
<spiv> But there's more than just log (old or new): there's qlog, there's loggerhead, there's the branch page on LP...
<spiv> And none of them, today, report the authors/committers of non-mainline revisions in their default view.
<lifeless> yeah
<lifeless> this saddens me
<spiv> Me too.  And AfC for that matter :)
<spiv> The existence of PQM as the committer on mainline is far from the most interesting fact about that revision.
<spiv> *Any* of the people involved would be better, in many ways.
<lifeless> queuer is IMO signed-off-by in git
<spiv> Right.
<spiv> Ooh, there *is* a way to see Queued proposals for a branch: https://code.edge.launchpad.net/~bzr-pqm/bzr/bzr.dev/+merges?field.status=QUEUED (empty atm)
<lifeless> whats maximise-window-vertically in vim, again ?
<spiv> Ctrl-W _
<lifeless> thanks
<spiv> Apparently there's a "Code failed to merge" state.
<lifeless> yes
<lifeless> can't be used
<spiv> Heh.
<lifeless> see my branch, nag thumper to reply to my review
<AfC> spiv: indeed
 * AfC is abashed that spiv remembers him. Aw shucks.
<vila> poolie: about https://code.edge.launchpad.net/~jbowtie/bzr/fix-555439/+merge/24289 is the contributor agreement in the pipe ?
<vila> spiv: Can we mark https://code.edge.launchpad.net/~spiv/bzr/push-relock/+merge/23767 as wip ?
<thumper> lifeless: I'll talk to you about it tomorrow, there are things I want to discuss
<lifeless> thumper: naturally
<lifeless> thumper: needs to be early, I have a plane flight at 1:30, leaving 10:45 or so
<thumper> ok
<thumper> lifeless: ping me in the morning
<poolie> vila: https://code.edge.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537 was originally created on the 3rd of March
<poolie> therefore is nearly 2 months old
<poolie> the overview page only shows the date a review was most recently requested
<poolie> and i see you have been following up on that and need win32 help
<poolie> (bialix :-)
<poolie> for those wondering, i'm not nagging vila, i'm just answering why the "oldest mp" graph says 2 months when there don't immediately seem to be any so old
<spiv> vila: hmm, I suppose.  Although I don't know if the next step should be "make read-locks upgradable into write-locks" or just "land this hack"
<lifeless> I'm ni favour of the former, quite strongly.
<lifeless> I think its only slightly more work.
<vila> poolie: thanks
<vila> spiv: at your leisure, I'm just trying to clean up the review queue
<sproaty> I just added my work pc's SSH key to LP, did a launchpad-login but my commit didn't come through 'linked' to my username?
<spiv> sproaty: the commit linkage is based on the name+email you've set with "bzr whoami"
<spiv> (Or the name+email bzr has guessed if you haven't explicitly set it; either way, "bzr whoami" will show you what name is being recorded in your commits)
<sproaty> ah ok I just changed those (after commiting :p)
<spiv> There's a bug + patch for making bzr never guess the 'whoami', btw.  Sounds like that would have helped you :/
<sproaty> thanks
<sproaty> ahh I changed whoami now I get this when pushing bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~sproaty/whyteboard/development/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<sproaty> https://answers.launchpad.net/bzr/+question/24695   doing lauchpad-login and bzr bind as suggested here, problem still exists
<spiv> sproaty: what command are you trying?  "bzr push lp:~sproaty/whyteboard/development"?
<spiv> sproaty: it's trying http rather than bzr+ssh, which suggests that either you aren't using the lp: URL, or somehow the "bzr launchpad-login" hasn't taken effect.
<sproaty> that's what I pushed to earlier (with wrong whoami) - now I'm just doing push
<sproaty> ah there we go
<sproaty> specifying the url directly again worked
<spiv> Ok, it's probably remembered the http one.  If you do "bzr push --remember lp:~sproaty/whyteboard/development" that should solve that.
<sproaty> are these now right? http://paste.pocoo.org/show/207461/
<sproaty> cool cool
<spiv> No, none of the branches on launchpad should start with http:// if you have done launchpad-login
<bialix> what's the purpose of commit object passed to generate_commit_message_template function?
<bialix> is there any real-life examples of commit_message_template hook?
<bialix> jelmer: I found your patch of commit_message_template hook: http://markmail.org/thread/etkxlj6osy65rhfb . can you point me on any existing hooks?
<jelmer> bialix: bzr-builddeb has one I believe
<jelmer> bialix: it fills in the commit message based on the contents of debian/changelog
<bialix> that's what I need
<bialix> commit object should have link to working tree, right?
<jelmer> yeah, I think so
<bialix> commit.work_tree
<bialix> oki
<bialix> jelmer: do you know why commit_message_template hook gets the commit object as argument? why not passing just working tree there?
<bialix> jelmer: actually you're the author of that hook
<bialix> qann say so
<spiv> It's a more flexible interface.
<spiv> It allows us to add more attributes to the commit object without breaking existing hooks.
<bialix> spiv: for example?
<jelmer> bialix: specified_files
<spiv> If we passed arguments like working tree directly then to add another argument then it would break the hook.
<bialix> but that hook launched only with work_tree argument attached to commit object!!!
<bialix> jelmer: I don't see where specific_files attached to commit_object
<jelmer> bialix: it's not yet attached, but it would be a good candidate
<jelmer> bialix: and we'd like to be able to make that sort of change without breaking existing hooks
<jelmer> so it can't really be an argument to the hook
<bialix> :-/
<spiv> Generally new hooks have dedicated "params" objects
<bialix> guys, I need the way to run these hooks without calling wt.commit so I can use them in qbzr
<bialix> today it seems impossible hard
<bialix> because hooks called from commit object
<bialix> and I need valid commit object to fire hooks
<bialix> it's a kinds of recursion, it's not?
<spiv> commit_message_template is a hook for controlling the message template to use for a commit.'
<bialix> when you start to talk about flexible I'm starting to fear
<spiv> So by definition it needs a commit object
<spiv> Why can't you create one?
<bialix> I can create one, but I should attach all required attributes there manually
<bialix> because they're attached only when actual commit started
<bialix> so far I see there is only work_tree and branch attributes attached, then hook fired
<bialix> now you say there is need for specific_files
<bialix> it's a kinda open can of worms
 * bialix don't like open ended
<jelmer> bialix: specific_files isn't there yet but it might be added in the future
<spiv> I'm not sure why qbzr can't call wt.commit?
<spiv> Perhaps look at how cmd_commit does this.
<bialix> spiv: because we allows user to enter message *before* we call commit
<bialix> it's a gui application
<spiv> The hook is invoked by generate_commit_message_template, which is invoked by the get_message callback that cmd_commit passes to tree.commit
<bialix> yes, exactly
<spiv> Why not allow the user to enter the message during commit, like the CLI?
<bialix> and tree.commit is the real commit
<bialix> spiv: http://groups.google.com/group/qbzr/t/f266b47d77e4bacb
<spiv> The issue is that the real commit can affect what goes in the template.
<bialix> why?
<bialix> or more precisely: how?
<spiv> Because the template often includes a summary of affected files, etc.
<bialix> I see this hook as CLI-only thing
<spiv> I don't see that way.
<bialix> spiv: in qcommit user can select/deselect files interactively
<bialix> so the summary will be known only when commit started
<bialix> I need template *before*
<bialix> heh
<spiv> Ok, then you can't use the hook that generates templates based on that information.
<spiv> Perhaps we could add a hook that works from a more limited set of information, although it would be correspondingly less useful...
<bialix> I can live with that
<spiv> But that post you just linked to suggests that you do want your templates to know if changelog/news is going to be part of this commit.
<spiv> So it sounds to me like you have contradictory requirements.
<bialix> spiv: currently that hook don';t have such info
<bialix> spiv: I don't care if user will deselct the changelog file -- because user can just select suggested templated and delete it as well
<bialix> it's a GUI
<spiv> Actually, glancing at the code, specific_files does seem to be defined at the point the message_callback is invoked.
<bialix> *exactly*
<spiv> bialix: ah, now that suggests a solution to me:
<spiv> bialix: start a real commit to get the message template then abort it.
<bialix> ?
<bialix> sounds crazy
<spiv> Well, AFAICT that actually matches exactly the behaviour you want:
<bialix> spiv: I think I don't want to start commit until user presses OK
<spiv> You want to the initial message (that the user can edit) to be what the hook suggests if the user just committed everything.
<bialix> yes
<bialix> that's my point
<spiv> So, construct that commit, use it to get the template, then abort it and throw it away.
<spiv> Then once the user has edited the message and files etc, and clicked ok, do a commit (and let it finish).
<bialix> how I can abort commit?
<spiv> By raising an exception from the message_callback.
 * bialix scratches a head
<spiv> It's a bit of a hack (and will quietly log a traceback), but will work.
<bialix> yep, it looks like a hack
<bialix> thanks for the suggestion, but I don't like this idea
<spiv> We can add some sort of cleaner API (perhaps just an explicit AbortCommit exception) if this is useful for you.
<spiv> Just because the way to abort the commit is a hack?
<bialix> I don't know yet
<spiv> Fair enough :)
<bialix> I don't know yet if I need AbortCommit
<bialix> I don't like idea of aborting commit because it's a waste
<spiv> That's true.
<spiv> The only other option is providing a way for a GUI to interactively configure the Commit object between starting and finishing it.
<spiv> And I think that would either be a lot more complex for bzrlib, or actually work out to be essentially the same as "throw the first one away and restart it".
<bialix> yes, but for this I need to understand the required API of the hook, and it's not defined yet
<spiv> Because you are fundamentally asking for repeated work.
<bialix> no, when qcommit will start the real commit there will be passed real commit message and the hooks won't fired
<spiv> The commit message template by definition depends on what is being committed.
<spiv> And you want that template before finalising what is committed.
<bialix> I'm reading the http://bazaar.launchpad.net/%7Ebzr-builddeb-hackers/bzr-builddeb/trunk/annotate/head%3A/__init__.py#L85
<bialix> and I see that in the end there's a lot of manual work
<bialix> no real benefit from commit object
<bialix> or maybe I'm blind
<spiv> Oh, to be fancy you don't *have* to abort the first commit if the user doesn't deselect any files or change anything other than the message...
<bialix> spiv: actually we run plain `bzr commit` under the hood
<bialix> that's why I don't want to manually invoke wt.commit
<bialix> maybe I can think about using MemoryTree instead, but anyway it's a waste
<spiv> Well, if you want to integrate very closely, at some point you need to use bzrlib directly.
<jelmer> bialix: perhaps you can propose an interface for the object that's pased to the commit_message_template_hook ?
<bialix> no, I'm only want to have template
<bialix> it was to spiv
<jelmer> bialix: that interface could then be implemented by Commit as well as some qbzr-specific object
<spiv> bialix: I agree that hook's params don't provide as many convenience methods as it could or should
<bialix> jelmer: ok, I'll think about this
<spiv> bialix: I've recently don't some work on the merge_file_contents hook to add that sort of convenience.
<bialix> but it's real and used now, so anywy there is should be a way for backward compatibility
<spiv> (although there's a long way to go)
<LeoNerd> Hrm.. bzr ci   is now failing for me, because it can't talk to gnome keyring, apparently. I don't even run gnome..
<LeoNerd> ** Message: secret service operation failed: The name org.freedesktop.secrets was not provided by any .service files
<vila> LeoNerd: does bzr-gtk appears in the output of 'bzr plugins -v' ?
<LeoNerd> Yup
<vila> LeoNerd: if you don't run gnome... don't install it :-)
<vila> LeoNerd: yet, it's a bug, can you file it ?
<LeoNerd> gtk != gnome
<LeoNerd> gtk provides nice shiney visual stuff.
<LeoNerd> I don't know if it's a bug...
<vila> ha, that kind of user :)
<vila> it is a bug you can't use bzr ci with bzr-gtk installed
<vila> s//that/
<LeoNerd> It worked this morning :)
<LeoNerd> I haven't changed anything to my knowledge...
<LeoNerd> It's possible that xfce starts a gnome-keyring-alike, which has since died..
<vila> canonical answer: then it works as it worked before ;)
<vila> LeoNerd: we had trouble with gnome-keyring in the past, so be sure to mention all the relevant versions (for a fully handwaved value of relevant)
<LeoNerd> Hmm... Temporary workaround for now..?
<vila> bzr --no-plugins ci
<LeoNerd> Righty... usefully this isn't one of my bzr-svn checkouts ;)
<vila> LeoNerd: ha silly me: BZR_PLUGIN_DISABLE=gtk
<LeoNerd> Ahh
<vila> damn, not monetioned in 'bzr help env-variables' :-/
<vila> BZR_DISABLE_PLUGINS=gtk sorry
<LeoNerd> Hrm.. neither of those seem to work...
<vila> LeoNerd: bzr version ?
<LeoNerd> Bazaar (bzr) 2.1.1
<vila> LeoNerd: right, you need 2.2b1 or newer, so next workaround is ....
<vila> temporarily move the gtk directory out of the plugins dir :-}
<LeoNerd> Heh... which is in /usr/lib/python...
<vila> I knew it :-(
<vila> LeoNerd: fix your damn installation !
<vila> cough, sry
 * LeoNerd goes for   apt-get remove bzr-gtk
<LeoNerd> Possibly the actually-gtk things could be separated from the gnome things? Make it two plugins?
<vila> LeoNerd: please file a bug against bzr-gtk, having to uninstall it as the only workaround speak volume...
<LeoNerd> GTK does not imply Gnome
<vila> yeah, that's what the fix should do
<jelmer> bzr-gtk doesn't require GNOME in any way...
<vila> but gtk/keyring.py already trap import errors around gnomekeyring, which is weird
<vila> jelmer: even gnomekeyring ?
<LeoNerd> jelmer: Then why does it die fatally because gnome-keyring isn't running?
<jelmer> vila: yeah, gnomekeyring isn't required. we just skip it if it isn't there.
<LeoNerd> http://paste.leonerd.org.uk/?show=870
<jelmer> LeoNerd: that bug has already been fixed
<LeoNerd> Ahh..
<vila> looks like... yeah as jelmer said :)
<jelmer> LeoNerd: it's probably not packaged anywhere though
<LeoNerd> Hmmm
<vila> LeoNerd: which bzr-gtk version ?
<LeoNerd>   Candidate: 0.98.0-1
<jelmer> LeoNerd: afaik it's triggered by newer versions of gnomekeyring, older versions would never raise IOError
<LeoNerd> Ah.. Hrm. I see
<LeoNerd> Thing is.. I know bzr was working yesterday... admittedly in svn checkouts, not nayive bzr ones..
<vila> by the way, hi jelmer !
<LeoNerd> *native
<vila> LeoNerd: OS ?
<jelmer> moinmoin Vincent :-)
<LeoNerd> Debian mostly-testing
<vila> no updates (checking) ?
<LeoNerd> Have just distupgrad'ed now... nothing newer
<jelmer> I haven't uploaded any bzr-gtk packages since I fixed that issue in bzr-gtk trunk I think
<vila> LeoNerd: that  doesn't rule out an update since yesterday (quite the contrary)
<LeoNerd> Just did update; still 0.98.0-1
<vila> LeoNerd: I'm trying to find if it's an install issue or a runtime one
<vila> LeoNerd: well, in that case that could coming from gtk itself
<vila> s/could/& be/
<mathrick> jelmer: poke?
<mathrick> jelmer: git://repo.or.cz/org-mode.git <-- I cloned that, and bzr tag gets confused. It shows ?? as the revno for tag past release_6.35g, and if I tell it to branch off, say, release_6.35i, it claims there's no such revision
<mathrick> 6.35g and earlier ones work fine
<mathrick> git can also clone them alright, although when I tell it to git log `git rev-parse release_6.35i`.., it shows something but the returned hash (014cae20013eb2b4261b4da78827573ab921bfc7) is *not* listed
<jelmer> mathrick: I would suspect that revision is not on the mainline of your branch
<jelmer> mathrick:so there's no way to assign a revno to it
<mathrick> uhh, can't it use the dotted notation?
<jelmer> mathrick: how would it do that if the revision is not on the branch?
<mathrick> jelmer: the same way bzr log does it?
<mathrick> I'm not sure I follow
<jelmer> mathrick: bzr tags doesn't show revno's for tagged revisions not on the mainline either, even when you're not in a git-imported branch
<mathrick> I'd argue it's a UI bug then
<mathrick> I mean, not telling me "can't show because it's not on mainline"
<jelmer> mathrick: how? What revno would you assign to it without causing conflicting revno's?
<jelmer> mathrick: that's what the ?? is intended to do, though I admit that could be a bit clearer..
<mathrick> jelmer: bzr log assigns them somehow, how is that different in tags' case?
<jelmer> mathrick: bzr log works in the context of a single branch
<jelmer> mathrick: imagine you have two different revisions A and B that have the same ancestor
<mathrick> okay
<jelmer> that ancestor could have revno 42
<jelmer> what revno would you give its descendants?
<mathrick> depends on which of A and B is in the mainline
<jelmer> mathrick: let's say A is in the mainline
<mathrick> jelmer: oh, I see, and both A and B are tips of the tree?
<jelmer> mathrick: right
<jelmer> mathrick: so bzr tags' output would be very confusing if it claimed that two tags were set on revision 43 while they were in fact different revisions
<mathrick> okay, but then I can still specify tag:foobar as the revspec, no?
<jelmer> mathrick: yes, you can - if that revision is available locally
<mathrick> the thing is, git works in this case, and bzr tells me the revision doesn't exist
<jelmer> mathrick: bzr-git tries to stay consistent with Bazaar in this regard, and only fetches the branch mainline
<jelmer> mathrick: not necessarily the tags that aren't on the mainline or their ancestors
<mathrick> jelmer: aha, so bzr clone foo -r tag:foobar would fail on pure bzr branches if it's not in the mainline?
<jelmer> mathrick: clone foo -rtag:foobar would work. clone foo and then trying to access the tags would fail
<jelmer> mathrick: if you explicitly specify you want that specific tag is should work
<mathrick> jelmer: so I did clone the full repo above, and then tried to branch it off at tag:release_6.35i, and that failed
<jelmer> mathrick: that's correct in that it's (afaik) compatible with bzr's behaviour
<jelmer> mathrick: I think we should consider fixing it, but I'd prefer to fix it in bazaar first
<mathrick> jelmer: aha, so currently bzr would fail in the same situation on a pure bzr branch, and you consider that something that should be rectified and allowed to work. Am I reading you correctly?
<jelmer> mathrick: yeah
<mathrick> multi-branch history is the most confusing part of any DVCS, so UI bugs here are really not helpful
<fullermd> Urr?  Wait, what?
<fullermd> branch and tags and all work just peachy with tags not on the mainline.
<mathrick> jelmer: out of curiosity, how would I get a non-mainline tag into a bzr branch?
<mathrick> I can't just merge, since that automatically gets it into the mainline
<jelmer> fullermd: does "bzr pull" fetch the contents of revisions that are not on the mainline but have tags ?
<fullermd> Sure.  Easily demonstrable by looking at your local bzr.dev mirror; there's only like 2 tags on the mainline.
<fullermd> Wait, fetch the REVISIONS?  How could pull work at all if it didn't fetch the revisions, whether they're on the mainline or not?
 * fullermd is confuzzled now.
<jelmer> fullermd: iirc pull only fetches the branch tip and its ancestors
<fullermd> Sure, but it's still an ancestor even if it's not on the mainline.
<jelmer> fullermd: right
<fullermd> OK, now I'm completely lost.  Are we agreeing or disagreeing?
<jelmer> fullermd: I was using confusing terminology I think
<jelmer> fullermd: tags don't have to be set on revisions that are part of the tips ancestry
<jelmer> fullermd: they can be set on arbitrary revisions. and bzr pull doesn't fetch those arbitrary revisions iirc
<fullermd> Oh, yes.  pull doesn't AFAIK poke into tags at all except to blanket grab 'em.
<jelmer> fullermd: right, git does fetch all tags even if they point at arbitrary revisions
<fullermd> Oh, wait, were you using 'non-mainline' to refer to a completely separate branch?
<jelmer> fullermd: yep
<jelmer> fullermd: and I'll be the first to admit that's confusing...
<fullermd> Ah.
<fullermd> OK, carry on; I'll go be unhelpful somewhere else for a while   :)
<jelmer> :-)
<bialix> does bzr has the method to check that some path is inside some dir?
<bialix> e.g. I have root directory and want to make sure the supplied relpath is inside my tree
<bialix> check relpath for .. ? and check it's not abspath?
<bialix> osutils.is_inside
<kojiro> Hmm, I'm using bzr+svn and I'm very new. I understand to push my changes to the svn repo I would use bzr push svn+ssh://blah/my/repo, right?
<kojiro> If that's right, then is there some way I can have bzr 'remember' the location of the push target?
<kojiro> oh, maybe the answer is --remember?
<bialix> PathNotChild: Path "C:/root/foo/bar/spam" is not a child of path "C:/root/foo/bar/"  <-- what?
<jelmer> moin lifeless
<jelmer> lifeless: I still don't think I understand your suggestions for my url subsegments split/join patch
<jelmer> lifeless: you seem to assume that there's always going to be key/value pairs?
<lifeless> jelmer: I thought thats what we'd agreed on as a first pass
<lifeless> and certainly for emitting things
<jelmer> lifeless: I thought we were just going to leave it open as a possibility for later
<jelmer> lifeless: key/value pairs that is
<lifeless> jelmer: I understood the reverse: start explicit, add magic later if wanted.
<jelmer> lifeless: anyway, I can live with just key/value pairs for now; that at least makes your statements more comprehensible :-)
<lifeless> :)
<jelmer> lifeless: also, s/if wanted//. I'm pretty sure I'll want that magic
<lifeless> I really don't like the huge confusion I expect users to experience at foo,bar rather than foo,branch=bar
<lifeless> We know that undocumented things generate confusion
<lifeless> and that the more hints we give, the less confusion
<jelmer> ... and more typing
<jelmer> there's a balance in there somewhere
<lifeless> right
<lifeless> thus I'm ok with *accepting* foo,bar
<lifeless> but not [currently] ok with *emitting* foo,bar
<jelmer> ah, I see the distinction now
 * jelmer blames the caffeine withdrawal
<jelmer> lifeless: thanks, I'll resubmit
<lifeless> jelmer: accepting foo,bar is a little ugly too - I think we *have* to accept foo,branch=bar [as we emit it, and to support looms, pipelines etc]
<lifeless> jelmer: but I'll not argue against it :P
<jelmer> lifeless: I'm in favor of accepting both, the short form as more of a DWIM kind of thing
<a212901390231901> erk, I thought I sent a message to Martin Pool and list, but don't see it in the list archives
<a212901390231901> will send again, if it arrives twice, apologies
<jam> Peng: are you around?
<jam> or mwhudson
<mwhudson> jam: otp
<jam> k
<drewww> I'm having this problem: https://answers.launchpad.net/bzr/+question/24695 and I've done everything in the thread and bzr is still trying to use http to push to launchpad - any suggestions?
<jelmer> drewww: what does 'bzr lp-login' tell you?
<drewww> returns my username properly
<drewww> "dharry" in this case
<drewww> I've tried rebinding after setting my login
<jelmer> do you have ssh keys registered on launchpad?
<drewww> updated the ssh keys
<drewww> yep
<lifeless> bzr info output might help
<drewww> ah, hmm
<drewww> http://pastebin.com/DrjxSmjL
<drewww> how do I get the push branch to not be http?
<drewww> the pull one looks right
<drewww> er, checkout
<jam> drewww: bzr push --remember probably
<mwhudson> jam: here now
<jam> mwhudson: some questions wrt loggerhead, especially wrt codebrowse
<mwhudson> jam: ok
<drewww> jam: same issue, "cannot lock LockDir" and it's going over http
<jam> drewww: 'bzr push --remember $NON_HTTP_URL"
<drewww> ahhh
<jam> mwhudson: 1) I was wondering if the file-change cache is specifically beneficial even in 2a format repos
<mwhudson> jam: i'm pretty sure it's a lot less vital in 2a format repos
<jam> I can see where cPickle can be faster than iter_changes
<mwhudson> it probably is still a bit faster though
<jam> just wondering if it is really worth it
<drewww> jam: looking good - thanks!
<mwhudson> jam: i'm not sure
<mwhudson> the motivation was not 2a repos, lets put it that way
<jam> mwhudson: sure
<jam> I don't know that it is worth my effort to sort out right now, but maybe someday...
<jam> mwhudson: 2) I think it was beuno who mentioned that loggerhead only uses sqlite when it is available, but doesn't require it
<jam> do you think that is important?
<jam> Given that it creates a TEMP dir even if it isn't configured, the dependency on sqlite seems pretty minor
<jam> I suppose py <2.6 doesn't have it built in?
<mwhudson> i think it's built in in 2.5
<jam> mwhudson: it is here :)
<mwhudson> yeah
<mwhudson> so, no, i don't think i care about that
<mwhudson> (codebrowse is running on 2.5 now)
<chx> how can i update to a specific tag?
<jam> chx: It sort of depends what you mean by "update", but "bzr update -r tag:XXXX"
<chx> jam: now that's weird, i read the docs it does not mention -r
<jam> chx: update -r was introduced recently
<jam> not sure when
<chx> hm i only have 2.0.3
<chx> jam: another question, how can i ask which tag a tree is at? revno says a number
<jam> chx: I don't think we have that info, you can do "bzr log" and it will show tags
<jam> "bzr log -r `bzr revno --tree`"
<chx> jam: is that even necessary? just bzr log |head -3|tail -1|cut -d: -f2 seems to spit out the tag name.
<jam> chx: it depends where you update to
<jam> etc
<jam> I think log follows the branch, and not the working tree
<chx> ah
<chx> jam: thx for all.
<jelmer> 'lo jam
#bzr 2010-04-30
<jelmer> Peng_: ping
<bendj> If I "bzr init-repo A; bzr branch (url) A/test1; mkdir -p A/B; bzr branch A/test1 A/B/test2"
<bendj> then, "cd A; bzr multi-pull", will multi-pull "know" to always pull in the correct dependency order?
<fullermd> Yes, but no.
<bendj> Ok, thanks!  Bye!
<bendj> Just kidding ... pls 'splain
<fullermd> Yes, it will pull in "correct" order there, but not because of any sort of dependancies.
<bendj> fullermd: Hrm.  How's that?  Order of creation?
<fullermd> multi-pull doesn't do anything more than "for i in `bzr branches`; do (cd ${i} && bzr pull); done"
<bendj> alphanum order, then?
<fullermd> Lexical ordering of the paths.  At least, I'm pretty sure it orders 'em.
<bendj> fullermd: hrm.  doable, then -- but a bit fragile. other than multi-pull, *IS* there a 'better way', then, to build a hierarchy of dependent branches, and, auto-update the whole shebang -- in correct dependency order?
<fullermd> Not pre-built.  You could probably bang up something to pre- or otf- build a graph and walk it.
<fullermd> Though I wonder why you'd just have a long chain of copies of the same branch.
<fullermd> Presumably you'd actually have changes around, and be merge'ing rather than pull'ing, which generally means interaction anyway.
<bendj> fullermd <klingon pain stick> versioning modules, core hacks, and site code for multiple drupal sites can be such a joy </klingon pain stick>
<fullermd> If it's a single series, loom could do some level of automation, but that doesn't help you once the branch graph branches.
<bendj> loom? looking ...
<bendj> as in http://www.isi.edu/isd/LOOM/  ?
<fullermd> It's a tool for automating having branch A, with branch B based off that, with branch C based off that, with branch D based on that, with...
<fullermd> But it doesn't help when you have branch A, with branch B based on that, with branch C also based on A, with branch D based on B, with branch E based on D and C, with...
<bendj> ah, heh -> https://launchpad.net/bzr-loom
<bendj> fullermd: Comparing levels of pain/confusion, your point's looking better by the moment" "... generally means interaction anyway ..."
<bendj> 5 minutes of manual interaction versus the possibility to fubar the whole mess -- under script control.
<bendj> methinks "Door #1" is the saner option ...
<fullermd> Scripts are inanimate objects.  Inaminate objects are volitional entities hell bent on imposing any perversity imaginable on anybody in range.  Basic precept.
<bendj> Well, some of the emplyees around her are inanimate objects as well ... more similar to voles than volitional entities.  But point taken.
<bendj> {employees, here}
<fullermd> Exactly.  People are safer.  It's like the difference between genius and stupidity; genius has its limits.
<bendj> fullermd: Heh.  I could extend that argument to DVCS vs sneaker-net-n-punchcards, but been there, done that already ;-)
<Kilroo> I need to write down the sequence of steps that I use that sometimes results in bzr concluding that the directory foo has been renamed to foo
<Kilroo> and try to figure out why it happens.
<Kilroo> I keep being in too much of a hurry when it does.
<poolie> Kilroo: 'foo has been rename to foo'?
<poolie> *renamed
<Kilroo> Yes.
<Kilroo> I get a rename conflict on a directory with the same name. Haven't stopped to figure out why yet.
<Kilroo> I am having trouble recalling what I'm usually doing when it happens.
<poolie> this can happen when two people add the same directory independently
<poolie> which is a known bug
<poolie> spiv, did you see https://answers.launchpad.net/loggerhead/+question/108796 ?
<Kilroo> Ah.
<Kilroo> Well, that would explain it, even though I added them both.
<spiv> poolie: hmm, no, I hadn't.
<poolie> you should subscribe to answers if you're not already
<Kilroo> I'm still debating what I want to do about the fiasco of "version control" we have at work...
<spiv> I am, but apparently not for loggerhead.
<Kilroo> I think, if either I can't get them to change how we're doing it at all OR I can convince them to move source code out of subversion completely, I'm going to end up pushing hg; if I can convince them to restructure the repositories sanely but they insist on sticking with subversion, I might stick with bzr.
<Kilroo> Personally I like 'em both, but for purposes of adoption by the rest of the team I think HgEclipse might make the difference between getting brushed off and being given serious consideration.
<Kilroo> Still experimenting though.
<poolie> jam, still here?
<Kilroo> I wonder if I'm going to end up fouling myself up by having a lightweight checkout for switching among the branches of a shared no-trees repository in .bzr/r.
<Peng_> jelmer: pong
<Peng_> poolie: No. jam /quit.
<poolie> Kilroo: no that's pretyt standard
<Kilroo> Ok. I didn't think it was too likely to foul up anything, but I also wasn't sure how common it was to put things under .bzr that bzr didn't put there for you.
<poolie> oh i thought that was a typo
<poolie> you should look at bzr-colo
<poolie> it may confuse upgrade and things like that
<masmullin> hello.  does anyone know if there is a timelapse view for bzr similar to this one (http://code.google.com/p/svn-time-lapse-view/) ?
<poolie> check out bzr gannotate
<poolie> but not directly with a slider afaik
<masmullin> thank you
<GungaDin> Is there a way to make bzr ask for a username when executing bzr commit (with a remote url)?
<spiv> I think some transports like HTTP can do that.
<vila> hi all
<vila> GungaDin: Like spiv said, http suports that, but most of the time you want to always use the same user to you specify it in the url (user@host)
<vila> and all protocols supports that
<vila> poolie: I can't find the tag for 2.2b1 in lp:bzr/2.2, it's associated with mbp@sourcefrog.net-20100401011841-9x637emlcah1a0qv9
<vila> poolie: err, I can find the tag, but not the associated revision
 * vila gets more coffee
<poolie> hi there vila
<poolie> i didn't end up merging that branch because i tried a last-minute merge of some fixes from gary
<poolie> that ended up being rejected by pqm
<vila> poolie: no worries, just thought I mentioned it
<bialix> hi all
<poolie> hi there bialix
<bialix> jelmer: if I want to check whether some directory has svn checkout inside, what method of bzr should I use?
<bialix> hello poolie
<bialix> there is open_tree_or_branch method
<bialix> I need the way to ensure bzr clean-tree won't delete nested branches/trees/repos
<bialix> any suggestions?
<bialix> hmm, `bzr ignore foo` does not check for duplicates. I don't think it's good
<poolie> that would be nice
<poolie> obviously you can have globs that may overlap with each other
<poolie> by precise dupes seem pointless
<bialix> poolie: how you call in english any bzr object (branch/tree/checkout/repo)?
<bialix> as cummulative name>
<bialix> as cummulative name?
<poolie> control component
<poolie> mm,
<bialix> so when I don't care what the bzr kind there but want to say "something which is bzr handle"
<bialix> either branch or tree or ...
<bialix> bzr control component?
<bialix> guidance needed on https://bugs.launchpad.net/bzr/+bug/572098
<ubottu> Launchpad bug 572098 in bzr "`bzr clean-tree` should not blindly delete nested branch/tree/repo" [High,Confirmed]
<poolie> hm
<poolie> bialix, i think if you do BzrDir.open it should tell you whether there is any control directory there
<poolie> not specifically .bzr but also including .svn
<bialix> thanks, that's what I need
<jszakmeister> Hello all!
<jszakmeister> So I was examining some history on bzr trunk recently, and saw something interesting...
<jszakmeister> the tag for bzr-2.1.0rc1 is at 4981.1.6, but the bzr-2.1.1 tag is at 4797.41.1
<jszakmeister> ...which seems a bit odd. :-0
<jszakmeister> That was meant to be :-)
<jszakmeister> Looking at it with qlog, it seems to make sense now.
<bialix> qlog ftw!
<jszakmeister> trunk was merged into the branch for rc1, picking up some more fixes.
<jszakmeister> Definitely!
<jszakmeister> qlog is the best bzr tool there is!  I use it *all the time*.
<jszakmeister> But it does make me think dotted revision numbers are less useful than I previously thought.
<bialix> jszakmeister: and also slow
<bialix> jszakmeister: they're human-readable
<bialix> that's main idea
<bialix> did you read recent thread from jam about history-db and dotted revnos?
<jszakmeister> Yeah, and they're easier to remember... but I wanted to assign some meaning to it, and you really can't.
<jszakmeister> Yes, I did.  Good stuff!
<jszakmeister> It seems like a lot of trouble to go through to keep them useful though.
<bialix> yep
<bialix> but I was surprized that topo_sort is the main bottleneck though
<jszakmeister> Yeah, it was all very intriguing.
<jszakmeister> I would have thought something so visible to the user would have a simpler calculation... I was surprised by some of the answers in that thread.
 * bialix nods
<bialix> vila: ping
<vila> bialix: pong
<bialix> vila: I have problems with selftest -s
<bialix> wait a sec I do paste
<bialix> vila: http://pastebin.com/UR68Awqc
<bialix> I've added new test to bb.test_clean_tree
<bialix> but selftest don't see it?
<bialix> what I'm doing wrong?
<bialix> gremlins?
<Peng_> bialix: "C:\Program Files\Bazaar\lib\library.zip\bzrlib" -- it's using the system-wide bzrlib.
<bialix> rats
<Peng_> bialix: Run "./bzr selftest ..." or whatever the Windows equivalent is.
<bialix> `python bzr`
<vila> Peng: wow ! Good catch :)
<jszakmeister> So another weird tag issue: bzr tags on bzr.dev shows:
<bialix> Peng_: many thanks
<jszakmeister> bzr-2.2b1            ?
<Peng_> :)
<bialix> now I can't run test at all :-(
<vila> jszakmeister: Yeah, I mentioned that poolie earlier, related to a pqm failure
<bialix> bzr: ERROR: No module named testtools
<bialix> it's not my day
<Peng_> Ow.
<vila> bialix: gee, that was changed sometime ago, you should run tests more often :-O
<bialix> vila: I do run tests everytime. for qbzr and scmproj!
<vila> bialix: easy_install ftw
<vila> bialix: but not from bzr.dev it apperas
 * bialix hates easy_install but it does not matter
<vila> appears
<jszakmeister> vila: I thought that's what you were asking.  But how did the tag show up?
<vila> jszakmeister: bug most probably
<Peng_> Wait, now the bug is PQM is propagating tag too much? That's new. :D
<jszakmeister> I wouldn't think the tag would carry over without the corresponding revision...
<jszakmeister> :-)
<vila> jszakmeister: yeah, me neither :-/
<jszakmeister> Would it be a PQM problem or bzrlib?
<jszakmeister> I'm curious if you can trigger this via the command line itself (I'm not sure how PQM does it's thing)
<vila> jszakmeister: I'm not sure, I guess pqm could be involved
<jszakmeister> Hmm... maybe I'll play around a bit and see if I can trigger the issue.
<bialix> vila: bzr get lp:testtools; cd testtools; python setup.py bdist_wininst -d.; run testtools-0.9.2.win32.exe <-- and no easy_install! :-P
<vila> jszakmeister: if you find interesting bits, please file a bug
<jszakmeister> vila: will do
<vila> bialix: wow
<vila> bialix: worth giving feedback to the testtools project I think
<jszakmeister> Heh.  I can reproduce it.
<vila> bialix: if only to tell them this alternative setup works out of the box
<bialix> vila: testtools does not use setuptools and this is fine
<bialix> vila: what kind of feedback needed?
<bialix> everything is fine
<vila> bialix: yeah, that's good feedback :)
<jszakmeister> Looks like it's a known bug: https://bugs.launchpad.net/bzr/+bug/99137
<ubottu> Launchpad bug 99137 in bzr "tags are "permanently" propagated by merge" [Medium,Confirmed]
<vila> jszakmeister: cool, thanks for checking !
<jszakmeister> No problem!
<jszakmeister> I'm going to add a note to the ticket saying that we were both a bit surprised by the behavior, if you don't mind.
<vila> jszakmeister: sure, don't forget to click the metoo button
<vila> jszakmeister: that should enough to nudge poolie to provide an updated tad :-D
<poolie> mm?
<vila> poolie: bzr tags -> bzr-2.2b1            ?
<vila> grrr bzr erro 'check your limbo', yeah, it's *empty* just get rid of it !!
<poolie> ah, they propagate even if the merge is rejected
<poolie> sorry
<vila> poolie: no worries, just a papercut :)
<bialix> vila: yeah
<jszakmeister> Is there a way to get a list of the mainline revision ids between two revids, without the merged revisions (just the mainline)?
<poolie> in code?
<jszakmeister> Or do I just need to use iter_merge_sorted_revisions and filter them myself?
<jszakmeister> poolie: yes
<poolie> i thought you'd be able to get them directly
<poolie> i don't recall the precise function tohugh sorry
<jszakmeister> No worries
<vila> jszakmeister: bzrlib.log._get_mainline_revs() , but note that it's private
<vila> jszakmeister: at least you can use it as an example
<jszakmeister> vila: Thanks!
<poolie> ok good night all
<ElMonkey> any pointers as to how to split off a sub-project from a repo without the sub-project retaining all unrelated history?
<ElMonkey> i'm in the situation that i'd like to release a part of a private project as open source, with the history, but of course wouldnt want the other parts of the project visible in the repo
<spiv> ElMonkey: probably the easiest way is to use the bzr-fastimport plugin to export and filter a dump of the history, and import the filtered history.
<spiv> ElMonkey: note that the history that will synthesise will have new revision-ids, so won't be easy to merge with the existing history
<ElMonkey> that wouldn't be a problem
<ElMonkey> know of any article that describes the process?
<jszakmeiste> Does anyone know if you can limit the access to just the smart server over http?  Or do I have to allow both smart and plain access to http?
<bialix> ElMonkey: see the help for fastimport plugin and for fast-import-filter command. it's pretty straightforward
<Peng_> jszakmeiste: Sure, if your web server is smart enough (no pun intended). Smart requests are .bzr/smart. Dumb requests are everything else under .bzr.
<Peng_> jszakmeiste: Just curious, why?
<ElMonkey> bialix, looking at it
<ElMonkey> though i'm currently confused what they mean by front-end
<ElMonkey> as in "front-end | bzr fast-import-filter..."
<Peng_> ElMonkey: Whatever fast-outputs.
<bialix> ElMonkey: for you frontend will be `bzr fast-export` command
<Peng_> Um. I hope.
<ElMonkey> ah, ok
<Peng_> OK then. :D
<Peng_> Oh, right, "export" is the word.
<jszakmeiste> Peng_: I've got my server handling the smart requests, and I like that because I can easily put fine-grained access controls in front of it (check the authenticated user, and allow no access, read access or write access)
<bialix> ElMonkey: it supposed to support conversion from other (d)VCS
<Peng_> jszakmeiste: Why can't you do that with dumb requests?
<jszakmeiste> Because being authenticated doesn't mean that you should be allowed to view the branch
<ElMonkey> hmm, i can't fast-export a subdir, can i?
<bialix> you can't
<jszakmeiste> And it would dramatically increase the maintenance required as compared to our svn setup
<bialix> my favorite topic detected: ACLs!
<Peng_> I thought building on Windows was your favorite topic. :D
<bialix> phew! buildout kills windows builds for me
<bialix> it seems my head is not robust enough to break the wall
<ElMonkey> spiv, bialix, thanks for the pointers, i think i'm on my way. just need things to re-appear at the right spot when importing
<ElMonkey> there's no way to make it keep stuff in a directory?
<ElMonkey> eg, i have source/foo.c etc i want to include
<ElMonkey> but they all end up in / in the new repo
<ElMonkey> i know i can solve this when importing
<ElMonkey> but what to do when i want foo/abc.h and bar/abc.h both?
<ElMonkey> or nevermind, i can apparently *not* make things reappear where they want even in the simple case...
<ElMonkey> the fastimport files are ok to be edited by a text editor, right?
<ElMonkey> i need to redact parts of some commit messages
<a212901390231901> hm, I need to go out in a couple of minutes so I better save this for later, but the new fix for bug 491763 has the same problem as the old one,
<ubottu> Launchpad bug 491763 in bzr "unhelpful OSError from rename inside transform" [Medium,In progress] https://launchpad.net/bugs/491763
<a212901390231901> "%s %s %s" % (unicode, unicode, bytestring) is not safe.
<a212901390231901> and if someone who set up for building windows installers could test lp:~gz/bzr/support_OO_flag_installer that'd be great
<Peng_> ElMonkey: Yeah, go ahead.
<lifeless> a212901390231901: your nick is uhm, undescriptive ;)
<Peng_> ElMonkey: Obviously it'll change revision IDs and such if you import them into the same VCS as you exported them from, but if that's okay with you...
<Peng_> lifeless: It's Martin[gz]. All of his other nicks were taken. We have too many Martins, eh?
<Peng_> Thank goodness for {auto,tab}-complete.
<lifeless> a212901390231901: have you registered martin[gz] ?
<ElMonkey> Peng, thanks
<a212901390231901> in the UDS launchpad group you sent a link to? yes.
<lifeless> a212901390231901: on freenode
<a212901390231901> no, I'll pick something more sane next time I ping out.
<lifeless> if you register with nickserv
<lifeless> you can then kick off anyone grabbing your nick
<a212901390231901> I tried a bunch of different options I use on other networks and they were all taken, then I got annoyed ;)
<lifeless> :(
<a212901390231901> it's something of a miracle I've stayed on this long without being taken down by a brown out or my flakey hardware
<Peng_> You say "miracle" like it's a good thing. ;-)
<rbriggsatuiowa> how do I specify a default format?
<rbriggsatuiowa> I get warnings about "Doing on-the-fly conversion from RemoteRepositoryFormat(_network_name='Bazaar pack repository format 1 with rich root (needs bzr 1.0)\n') to RepositoryFormat2a()."
<jelmer> rbriggsatuiowa: the default format is part of bazaar itself
<jelmer> rbriggsatuiowa: in that particular case the remote branch is in an older format and your local branch is in a newer format
<rbriggsatuiowa> so do I have to downgrade?
<jelmer> rbriggsatuiowa: fetching between two different formats is significantly slower than fetching between two branches with the same format
 * rbriggsatuiowa goes off to refresh his apt skills so he can install 2.0.3
<jelmer> rbriggsatuiowa: you can either downgrade your local branch ('bzr upgrade --rich-root-pack'), upgrade the remote branch ('bzr upgrade <url>') or live with the slowneess
<Peng_> Can suppress_warnings suppress that warning?
<jelmer> I'm not sure
<sproaty> uhm did bzr just autopush? http://paste.pocoo.org/show/208074/
<sproaty> http://bazaar.launchpad.net/~sproaty/whyteboard/development/changes  hmm aparently so
<vila> speakman: more likely you're using a checkout or a bound branch, what does 'bzr info
<vila> ' says ?
 * vila curses return key
<sproaty> me?
<sproaty> I think I did bzr bind yesterday while trying to solve pushing trying to push to http://
<vila> rhaaa, /me curses xchat too
<vila> sproaty: yes you :) 'bzr info' ?
<sproaty> http://paste.pocoo.org/show/208077/
<vila> sproaty: right, so you've using a bound branch,, the commit happens on the remote branch first and then locally
<vila> sproaty: there is nothing left to push in this case :)
<sproaty> was wondering why there was a pause after committing
<vila> sproaty: you can 'bzr unbind' and then 'bzr push' when you feel the need to publish your changes
<sproaty> alrighty then
<sproaty> thank you very much, vila
<vila> sproaty: you're welcome
<sproaty> bzr rocks, wish we were using it in work
<sproaty> no more damn .svn folders
<rbriggsatuiowa> jelmer: thanks for your help - I installed from source and things are going smoothly
<rbriggsatuiowa> also - just wanted to mention how awesome the bzr plugin architecture is
<jelmer> rbriggsatuiowa: np, great to hear :-)
<lelit> hi, I noticed that while the home page mentions 2.1.1 as the latest, the SourceDownloads page carries only 2.1.0...
<bialix> lelit: it's a wiki, feel free to update it
<lelit> right
<bialix> anybody seen this before? https://bugs.launchpad.net/bzr/+bug/572405
<ubottu> Launchpad bug 572405 in bzr "push from windows machine to linux is broken" [Undecided,New]
<bialix> I'm tempted to mark this bug as Critical
<bialix> light checkout problem again
<ShermanBoyd> Hello, I'm pretty new to version control in general, and after a ton of research I've decided I'd like to use Bazaar.  I've got a Windows 2003 production server and a 2003 Dev server and a couple of developers running Windows 7.  I want the developers to make changes on the dev box for testing and then periodically push those changes to production.
<ShermanBoyd> How do I approach this?
<ShermanBoyd> Two branches?
<ElMonkey> so you want dev->testsrv->production ?
<ShermanBoyd> Yeah
<ElMonkey> well, should be simple
<ElMonkey> all repos are "branches", if you will
<ElMonkey> so you just create a repo on each machine, and the push/pull appropriately
<ShermanBoyd> ElMonkey: so I need to set up an sftp server on each one?
<ElMonkey> ssh should do
<ElMonkey> dunno how bzr behaves with network shares, though, that might be simpler
<ShermanBoyd> ElMonkey: then the devs push to the dev server and I pull the final tested changes by running bzr on the prod server
<ShermanBoyd> they are in different physical locations
<ElMonkey> different networks, too?
<ShermanBoyd> yeah
<ElMonkey> for a long time i used a common repo on a usb flashdrive on one project, due to the computers not being networked
<ElMonkey> but anyway, ssh/sftp or samba shares should work
<ElMonkey> pulling from a network share should certainly work
<ShermanBoyd> Hmm, I think I'm still wrapping my head around decentralized ...
<ShermanBoyd> anyone here interested in helping me set up bzr on some windows servers for $25/hr ?
<sproaty> can someone explain about merging/branches? I've kind of done merging with svn at work, but not branches
<sproaty> like if I was to branch off to develop a new feature, that I see as being code-heavy, and then I find/fix bugs in the main code base that was branched from -- how do you like get the changes over into the other branch?
<sproaty> or is it a case of branching from trunk, working on that then merging that back into trunk
<fullermd> Generally, you just fix those bugs in the main branch.
<sproaty> then merge the 'new feature' branch back into trunk?
<fullermd> Well, not before the feature is ready to land   :)
<sproaty> cool
<cody-somerville> how do I push a pending merge on top of a branch instead of merging all the revisions into one
<cody-somerville> ?
 * cody-somerville forget he made a bunch of --local commits on a binded branch and ran bzr update.
<cody-somerville> ugh
<cody-somerville> bzr: ERROR: Selected-file commit of merges is not supported yet
<cody-somerville> I have changes in my working tree I don't want to commit :(
<IslandUsurper> cody-somerville, you could `bzr revert --forget-merges`, and then commit your changes file-by-file. if they're more intertwined than that, I wouldn't worry about it too much
<fullermd> That's almost certainly a bad idea.
<fullermd> That's just going to lose those commits and get you a bunch of illogical and entangled new ones.
<fullermd> The first thing to do is get a handle on your previous head state.  Update should have printed that out.
<fullermd> Assuming upstream hadn't moved, you can use diff to recover your uncommitted changes relative to that, and stash that somewhere.
<fullermd> Using another branch (or unbinind that one), you can use pull to jack back to that last commit.  Re-apply the changes, commit them,  Push over the upstream.
<cody-somerville> why wouldn't bzr revert --forget-merges not work? the commits were local and the master branch hasn't changed
<fullermd> Then stab --local in the eye with a #2 pencil.
<cody-somerville> err, sorry for double negation
<fullermd> Oh, it'll _work_.  But I doubt it'll leave you where you want to be.
<IslandUsurper> because it does indeed erase the commits you've already done. but it leaves the changes in the working tree
<cody-somerville> aye
<cody-somerville> so I can just commit now directly onto master
<fullermd> It'll leave you with all your local commits thrown away, and the sub of their changes (and whatever uncommitted stuff you had) sitting waiting to be committed.  That doesn't sound healthy.
<fullermd> (s/sub/sum/)
<cody-somerville> fullermd, all the changes from my local commits were still sitting in the tree since it was a merge.
<cody-somerville> doing a merge is like uncommiting everything and then recommitting it as a single revision but keeping the history
<fullermd> It...  umm...  not with any meaning of those words I can dredge up...
<fullermd> Talking about "your changes" is ambiguous.
<IslandUsurper> fullermd, sorry I mentioned --forget-merges. I should have just said "commit it anyway. it won't hurt."
<fullermd> You can take it to refer to the set of files as they now exist, or to the revisions you created.  revert --forget-merges leaves the former intact, but tosses the latter.
<cody-somerville> IslandUsurper, on the contrary, I'm all good now thanks to --forget-merges
<cody-somerville> how do I see the full log entries for pending merge revisions?
<IslandUsurper> bzr log -n 0
<fullermd> That won't tell you anything about pending merges.
<IslandUsurper> d'oh!
<fullermd> There's no direct way through the UI.  You'd have to get your hands on the revid's and go from there.
<IslandUsurper> qlog does it
<fullermd> Oh, really?  That's nifty.
<IslandUsurper> I use it so much, I didn't think that regular log wouldn't
<IslandUsurper> though status -v will show you the commit messages of pending merge parents
<fullermd> Well, it shows you something like log --line.  But that just shows you the first handful of words.
 * fullermd adds an entry to his "cool stuff about qlog" mental list.
<micahg> what's the proper way to import files from a branch so one can merge between the two without the history?
<ubuntujenkins> Is there a command that i would use to view all the changes made in previous revisions to a particular file showing the lines changed in the file?
<micahg> ubuntujenkins: bzr log -p /path/to/file
<ubuntujenkins> thanks micahg
<Kilroo> So guess what I learned today that I didn't know before
<Kilroo> I learned that switch first looks relative to where the branch you already have checked out lives
<micahg> what's the proper way to import files from a branch so one can merge between the two without the history?
<Kilroo> ...cp?
<micahg> Kilroo: that's what I was thinking, but I was worried about th efile Ids
<micahg> *file
<Kilroo> micahg: I don't know of any meaningful way to merge without involving the history...if you don't want the history I'd think you'd just write/overwrite the files and commit.
<ikanobori> Hey people, I was wondering if `bzr up` supports some kind of switch to make it pull unauthenticated. It seems it will always try bzr+ssh if I have a `bzr whoami`.
<ikanobori> On a lp-branch that is.
<spiv> ikanobori: lp: URLs are always resolved to bzr+ssh if you have done bzr launchpad-login
<spiv> 'bzr whoami' isn't involved at all.
<ikanobori> spiv: Thanks for the clarification.
#bzr 2010-05-01
<meoblast001> hi
<meoblast001> i can't seem to find the command to change my email
<meoblast001> nvm
<meoblast001> why do all my commits i made on my desktop say branch nick is "trunk" while the one i just made on my desktop says "nitrobot-plugins"
<meoblast001> i actually copied the directory from my desktop, so this makes no sense unless different bazaar versions do things differently
<poolie> we fixed a bug a while ago todo with calculating the nick from the branch directory not the checkout
<poolie> so that might be it
<meoblast001> so i need to upgrade my bazaar version?
<meoblast001> yuck, i'm using an ugly 9.04 version
<poolie> well, i think you can just set the nick directly if you want
<meoblast001> poolie: i just installed 2.1.0 but i still get 1.13.1 on a bzr --version
<poolie> i guess you have it installed in home or something
<poolie> try 'which bzr'
<meoblast001> sudo python setup.py instal
<meoblast001> /usr/local/bin/bzr
<meoblast001> i'll just remove my system version from APT
<meoblast001> hm, now it won't look in /usr/local/bin
<meoblast001> ah, it was that one shell
<meoblast001> ok, should be good now
<meoblast001> poolie: still says "nitrobot-plugins"
<meoblast001> poolie: should i just do bzr nick manually because voodoo magic changed my branch name?
<poolie> perhaps that's the simplest way out
<poolie> you could look in .bzr/branch
<meoblast001> will it do anything strange to my branch?
<poolie> i can't remember if it's a specific nick file or in the branch config
<poolie> no
<meoblast001> ok
<meoblast001> .bzr/branch is a directory
<meoblast001> oh no, panic attack
<meoblast001> this makes no sense
<meoblast001> it keeps saying that the branch name is the directory name
<meoblast001> that's a lie, it's always been trunk, and i don't know why
<meoblast001> i need consistancy
<meoblast001> poolie: everything i branch refuses to use the branch name "trunk"
<meoblast001> it now wants to use the directory name
<poolie> meoblast001: if you say 'bzr nick FOO' it should use that on all new commits
<poolie> no?
<meoblast001> sure, but i never had to do this in the past, and the question "why?" still sticks in my head
<meoblast001> on my desktop, i always just branched, worked, committed
<meoblast001> and it was always consistant
<poolie> i'm not sure what you're doing differently
<meoblast001> poolie: absolutely nothing
<poolie> actually the normal behaviour is to use the directory name of the branch
<poolie> not sure why it was always saying trunk before
<meoblast001> so why did it ever use trunk?
<meoblast001> i don't want to rebase this whole thing
<meoblast001> jeez, what ever happened to consistency
<meoblast001> ok, looks like i'm using a new branch name until something else screws up and it switches back
<poolie> perhaps you're mixing branches on one machine and checkouts on another?
<meoblast001> ?
<poolie> that could account for the difference in behaviour
<meoblast001> poolie: sorry, i'm sort of an idiot when it comes to a lot of this stuff
<meoblast001> what are you trying to say i could have done wrong?
<poolie> np, i'm just trying to guess at what might have changed
<poolie> if you were using checkouts or bound branches in one place and branches in the other
<meoblast001> well, let me explain the history of this directory
<meoblast001> this was a branch on my old system
<poolie> that could explain teh difference
<meoblast001> when my system got hosed, i copied over a bunch of directories to my laptop, including those
<meoblast001> i started working on those same directories, just on a different system
<meoblast001> oh no, more panic
<meoblast001> i guess i should just accept the new branch name, and scream at my desktop when it tries to use "trunk" again?
<poolie> well
<poolie> what is this branch supposed to be?
<meoblast001> it's too late now, i already have 2 commits with the non-trunk name on one of my projects
<poolie> the idea of recording the branch nick is to give you a reminder of the context in which the commit was made
<meoblast001> you can't uncommit and recommit more than 1 commit cleanly
<poolie> aside from that it doesn't matter
<poolie> it's only informative
<poolie> so personally i wouldn't bother rebasing if it was slightly wrong
<meoblast001> it was just the sole branch for these projects
<poolie> so... these commits that were on the non-trunk branch, what name did they get?
<meoblast001> citrine for citrine/
<meoblast001> nitrobot-plugins for nitrobot-plugins/
<poolie> and you wanted them to both be 'trunk' because they're the trunk of those respective projects?
<meoblast001> no, i wanted them to both be 'trunk' because that's what it's always been
<meoblast001> and i have no logical reason for why it changed it
<meoblast001> what's going to stop another machine from renaming it back to trunk?
<poolie> could it be that previously you had the branch in citrine/trunk and now it's just in 'citrine'?
<meoblast001> never had a directory named trunk/
<meoblast001> not even on my server
<poolie> hm
<poolie> that's a real puzzle then
<poolie> bzr should only use a name that you explicitly give it or that comes from the directory name
<poolie> i think you can feel safe that it won't just randomly change
<meoblast001> poolie: hm, thing is, the server always recognized it as the directory name
<poolie> how do you mean 'recognized it'?
<meoblast001> i wrote a hook that passes information from Bazaar to my IRC bot to print
<poolie> ah using branch.get_nick()
<meoblast001> it passes the branch name, the committer, the commit number, and the commit message
<meoblast001> result.branch.nick
<meoblast001> poolie: should i just accept the new change and only consider it a problem if something tries to change it back?
<meoblast001> poolie: you did say using the directory name is the default behavior, right?
<poolie> i think you should just accept it; and yes
<meoblast001> ok
<meoblast001> poolie: thanks
<wgrant> bzr: ERROR: bzrlib.errors.InvalidEntryName: Invalid entry name: '\
<wgrant> Is there any way to solve that when branching from a git repo with bzr-git?
<james_w> wgrant: not currently I believe
<wgrant> Damn.
<Peng_> Loggerhead has segfaulted twice since I upgraded bzr from r5120 to 5193. This can't be good.
<fullermd> It doesn't like odd numbers.
<Peng_> Ugh, that's what I get for only pulling it once a month: a huge regression range.
<Peng_> Wait a minute. None of the C bits have even changed!
 * Peng_ bangs head on wall
<fullermd> Obviously, then, the change must be in the unCeen!
<parthm> hello, i am looking at hydrazine, capture-bug-counts. so for the first time, whats a good default for launchpad access on the auth page? "change anything"?
<parthm> nevermind. I went with "read only". worked well :)
<cbz> jelmer: does pushing bzr renames into subversion track them as subversion renames?
<jelmer> cbz: svn doesn't support renames, but it will do a copy + delete
<mhall119> hi, how do I get a log with gpg signature info?
<jelmer> mhall119: as far as I know we don't have a way to do that yet. bzr-gtk can display gpg information though
<mhall119> hmmm, I need to send it to a professor
<mhall119> and I doubt he'll be willing to learn enough bzr to find it from the repo himself
<mhall119> also, bzr viz shows that it's signed, but can't find a key to verify with
<mhall119> I signed it using my personal private key
<mhall119> why wouldn't it be able to use my personal public key?
#bzr 2010-05-02
<Buginator> I just finished doing a bzr clone of a git repo, and it took 4+ hours.  I assumed it was a clone, but it looks like it only got mainline, and not the other branches.  Is this correct, or did I do something wrong ?
<beuno> Buginator, I think bzr-git only gets trunk, yes
<jelmer> Buginator: yep - use 'bzr git-import' for all branches
<Buginator> Ahh, thanks.
<Buginator> Hmm, with the git-import, now I am getting error: The remote server unexpectedly closed the connection.  D'oh!
<jelmer> Buginator: are you specifying the same URL?
<Buginator> yes
<junixbr> Hi everybody
<junixbr> my question is: why I'm getting the follow error: bzr: ERROR: Permission denied: "/~Sources": [Errno 13] Permission denied
<junixbr> if I'm putting the correct command: bzr push sftp://myhost.org/~Sources
<parthm> junixbr: are you able to ssh to myhost?
<junixbr> yes
<junixbr> I've tried sftp connection
<junixbr> normaly
<junixbr> there is a bzr running there
<junixbr> as on my laptop
<parthm> junixbr: weird. does giving absolute path work? sftp://myhost.org/a/b/c. what version of bzr are you using?
<junixbr> let me check
<junixbr> but, using --create-prefix should be created, or not?
<parthm> junixbr: is this the first push?
<junixbr> bzr 2.1.1-1
<junixbr> yes, the first one
<parthm> 2.1 sounds right. ~ support was introduced in 2.1.  from NEWS "Highlights include support for ``bzr+ssh://host/~/homedir`` style urls"
<junixbr> let me test
<parthm> you can also try sftp://myhost.org/~/Sources. But absolute path should work anyways.
<junixbr> ok
<parthm> I think --create-prefix is different from decoding ~. it applies to the rest of the path.
<junixbr> great! :)
<junixbr> using this way myhost.org/~/Sources it works!
<junixbr> thank you parthm
<parthm> junixbr: cool :)
<junixbr> but, I'll use with ssh
<junixbr> as svn way
<junixbr> parthm, do you know some bug trac to use with bzr?
<junixbr> could you suggest something?
<parthm> junixbr: trac (http://trac.edgewall.org/) has a bzr plug though i haven't used it myself. trac is easy to use and deploy.
<parthm> junixbr: if your project is opensource there is always launchpad.net
<parthm> junixbr: just to be clear, i have used and like trac ... just not used its bzr plugin.
<junixbr> ah ok
<junixbr> I have installed trac, I can install a bzr plugin
<junixbr> right?
<parthm> junixbr: http://pypi.python.org/pypi/TracBzr
<junixbr> thank you man!
<parthm> junixbr: np :)
<idnar> AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously.
<idnar> ugh, what
<spiv> idnar: is bug, fixed in 2.1 branch
<idnar> yeah, just found bug #528041
<ubottu> Launchpad bug 528041 in bzr "bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously." [High,Fix released] https://launchpad.net/bugs/528041
<spiv> (and probably trunk?  if not yet, then next time 2.1 is merged into trunk)
<spiv> The easy fix is to just upgrade your 1.5-or-older server already :P
<idnar> it's running Debian 5.0.4
<spiv> Ooh, 1.5 is nearly 2 years old, just a couple more weeks.
<idnar> although I'm using a newer bzr from backports on most of my servers
<idnar> I have a bootstrapping issue, though, my puppet config is in a bzr repo
 * idnar tries nosmart+bzr+ssh:// instead
<spiv> Yeah, that should workaround it.
 * spiv -> zzz
<Buginator> Is it normal that bzr is excruciating slow while doing a git import ?  We are talking of 8 hours for a final repo size of 1.6GB.
<jelmer> Buginator: how many revisions, which bzr-git version?
<Buginator> around 10000 revisions, and 6 branches. Version is 2.1.1
<Buginator> used bzr git-import to get all the branches
<jelmer> Buginator: what version of bzr-git?
<Buginator> bzr-git .5.0-1
<jelmer> Buginator: you might want to try trunk, it's significantly faster
<Buginator> Will do.  Thanks.
<thumper> jelmer: ping?
<jelmer> thumper: 'lo!
<thumper> jelmer: take a look at https://code.edge.launchpad.net/~registry/perl5/trunk
<fullermd> Sweet chariot?
<thumper> jelmer: bzr-git seems to fail to recognize the perl5 repo
<jelmer> thumper: we've tweaked the way in which a remote branch is found a bit, this broke a couple of branches (but fixed a few other ones)
<thumper> ok
<thumper> jelmer: do you know how to fix it?
<jelmer> It's on my todo list of things to fix before the next release
<thumper> when are you planning the next release?
<jelmer> when roundtripping support works
<jelmer> I'm getting quite close to finishing that, bzr push already works as long as I don't add any new files
#bzr 2011-04-25
<mgz> okay, I'm seeing 101 failures.
<mgz> will try the _make_stream_binary fix.
<lifeless> yes, thats about right
<lifeless> I have
<lifeless> 95
<lifeless> os.fdopen needs fixing too
<lifeless> I wonder if the same thing can be tweaked
<lifeless> mgz: pushing up my current
<mgz> well, fix gets me 11 errors down, and there are some more which, somehow are getting a *bool* for the stream
 * mgz pulls
<mgz>     def __init__(self, stream, passthrough=None, forward=False):
<mgz> ...
<mgz>         self._forward = forward
<mgz>         _make_stream_binary(forward)
<mgz> that's just an error right?
<mgz> in ProtocolTestCase.
<mgz> lineReceived is currently very unhappy because it doesn't know if it's dealing with bytes or strings.
<lifeless> always bytes
<mgz> you fixed it for bytes, and now all the tests that pass string literals are making it cry.
<lifeless> yes
<mgz> oh, wow, redirecting stdout just did something interesting
<mgz> http://paste.ubuntu.com/598473/
<mgz> the current set of different types of failure is reassuringly small though.
<lifeless> iteritems -> items done and pushing
<lifeless> I'm running the tests thusly
<lifeless> :!PYTHONPATH=python:~/source/unittest/testtools/working python3.1 ./runtests.py 2>&1 | less
<mgz> I did `%PY3K% -m testtools.run subunit.tests.test_suite > B:\subtests.log`
<mgz> possibly some weird testtools interaction, I'll use your way.
<mgz> hm, streams certainly getting crossed somewhere if I redirect.
<kingos> can anyone help me? I am trying to run bzr.dev from source, but keep getting the following warnings:
<kingos> _dirstate_helpers_pyx.so: undefined symbol: __stack_chk_guard
<lifeless> kingos: what os ?
<kingos> lifeless: re 5
<lifeless> re?
<mgz> anyway, getting distracted, fix seems to work, I'll push it up for your consideration
<kingos> redhat
<kingos>  enterprise
<lifeless> ah
<lifeless> hmm
<lifeless> kingos: what python version ?
<mgz> and which source? a tarball, or a bzr checkout where you're compiling with what pyrex version?
<kingos> lifeless: 2.4
<kingos> bzr checkout
<kingos> no pyrex
<kingos> do I need to install pyrex?
<lifeless> possibly yeah
<lifeless> or do a make clean
<lifeless> and run without the C extensions
<kingos> urgh, something is really broken. running bzr selftest still fails with hundreds of errors
<lifeless> the selftest looks for the C extensions
<lifeless> check the names of the failures
<lifeless> or pastebin them and I'll eyeball for you
<mgz> lifeless: lp:~gz/subunit/py3k
<mgz> kingos: if you're doing setup.py in a checkout, you must have pyrex or cython installed or you wouldn't get any of hte pyx files like _dirstate_helpers_pyx at all
<kingos> mgz: ok
<mgz> delete the build dir, then tee the setup.py log to file and post it.
<kingos> mgz: ok, maybe I have screwed stuff up .. Pyrex is installed under python2.4, but not python2.6, and I tried running setup.py with 2.6 after already running 2.4. Selftest is passing again now
<mgz> yeah, that sounds possible. going again from scratch is the right option in those situations.
<kingos> mgz: although I am still getting __stack_chk_guard undefined
<kingos> in a few .so files
<mgz> if you want to try on 2.6 you can use `python2.6 ./setup.py build_ext --allow-python-fallback install` to not require pyrex
<kingos> ok
<kingos> I am still getting failures on bzr selftest stats, a plugin I am trying to use
<mgz> you may need to report bugs, not all plugins are covered by the bazaar testing infrastructure yet
<mgz> and there have been some changes to command registration etc recently
<kingos> mgz: ok, thanks for the help
<mgz> the warning smells like a problem with the code pyrex is generating, or the flags it's getting compiled with, which is presumably a bug the red hat end.
<mgz> as in, would need them to update that package.
<mgz> kingos: to try a still recent, but slightly earlier version of bzr, you could do `bzr update -r tag:bzr-2.4b1` and rebuild to see if the plugin failures are regressions
<quotemstr> What exactly does "nosmart" do?
<spiv> quotemstr: basically reduces to fetching files
<quotemstr> Ah. The Emacs bzr instructions recommend its use, but I don't recall seeing it mentioned in TFM.
<spiv> quotemstr: so it still uses the smart protocol, but no requests in it smart than say SFTP, it's all "get this file, put this file" rather than "open branch, insert revisions"
<spiv> That seems like a strange thing to recommend.  Perhaps savannah doesn't have much memory?
<mgz> there was a thread about the initial checkout speed on the bazaar mailing list, wasn't there spiv?
<quotemstr> spiv?
<quotemstr> I'm just talking about the instructions in the wiki: http://www.emacswiki.org/emacs/BzrForEmacsDevs
<mgz> https://lists.ubuntu.com/archives/bazaar/2011q1/071574.html
<mgz> particularly https://lists.ubuntu.com/archives/bazaar/2011q1/071683.html
<quotemstr> Thanks.
<lifeless> 50 errors
<lifeless> quotemstr: mgz: that should be revisited with jam's recent perf work
<lifeless> both server and client will need updating
<quotemstr> lifeless: I'll look forward to the change when it's available on bzr and launchpad.
<quotemstr> lifeless: How far is bzr from git performance parity?
<lifeless> quotemstr: depends on your Ã¸
<lifeless> for most things its not meaningfully different
<lifeless> mgz: we're getting there - FAILED (failures=17, errors=16)
<mgz> lifeless, have you merged my branch yet?
<lifeless> yes
<lifeless> pushed rev 149 which merges yours
<lifeless> quotemstr: there were some standouts which hav ebeen fixed in trunk in the last fortnight
<mgz> cool, that's down to 28 for me.
<lifeless> quotemstr: all but one of those are accessible just by running a trunk build; the final one requires the server to change (because the server is sending data andthe fix is in the sending logic)
<quotemstr> Cool.
<mgz> a few from bug 663600, some from basestring not existing, a few remaining bytes/unicode lineReceived ones, two os.fork ones, some bytes ones in _addOutcome, and some serialisation ones
<ubot5> Launchpad bug 663600 in testtools "Use Python 3 style qualified exception names in tracebacks" [Medium,Triaged] https://launchpad.net/bugs/663600
<mgz> oh, and test_join_dir not getting the path it wants.
<lifeless> mgz: the exception name is fixed
<lifeless> basestring stuff is in the iso8601 module
<lifeless> mgz: the os.fork & fdopen ones will be less mechanical, if you want to look at it
<lifeless> grrrr
<lifeless> bytes('fo %d %d', 'utf8') % (1, 2) -> boom
<kingos> If a plugin command does  "raise errors.BzrCommandError", how come the return code of bzr is not set to something non-zero?
<kingos> hello?
<lifeless> mgz: thanks for your help
<lifeless> jml: around ?
<kingos> hi, if I run a test by run_bzr, how do I check the error code? the typical usage seems to be:
<jelmer> kingos: usually you specify the expected error code
<kingos> out, err = self.run_bzr(...), where err is sys.err
<jelmer> e.g. "out, err = self.run_bzr(["command", "arg1"], retcode=3)
<kingos> jelmer: thanks, is there an example of that somewhere?
<kingos> ah... I was grepping for errors.EXIT_ERROR
<jelmer> I think we usually just use numbers in the testsuite
<kingos> ah, that worked! thanks
<kingos> jelmer: another question while I have you, if I pass an option to takes_options as part of a command, ie. option.Option('blah', type=str'), the string seems to be padded with a space either side. Is this expected?
<jelmer> kingos: which string is padded?
<jelmer> and where is it padded?
<kingos> jelmer: if I add that option, then just do print "blah=", blah
<kingos> then run bzr blah=abc
<jelmer> kingos: I think that's more just the print command
<kingos> I get 'blah= abc '
<jelmer> >>> print "bla=", "foo"
<jelmer> bla= foo
<kingos> jelmer: ah ok
<kingos> python amateur
<kingos> :)
<kingos> hi, another question, if a command is outputting something with trace.note, how do I setup the tests correctly so I still can do self.assertEquals(err, '')
<jelmer> test against out (stdout) rather than err
<jelmer> in other words, the first element in the tuple returned by run_bzr
<kingos> oh, so tests shouldn't check the contents of error?
<jelmer> they should check the contents of both
<jelmer> some things (like errors) will go to stderr, some things (e.g. file content from "bzr cat") will go to stdout
<kingos> sure. I thought trace.note output was optional though, it could be turned on or off depending on some settings? in which case, I should be testing with it off right?
<jelmer> I think it's on by default, at least that's what the testsuite uses
<kingos> ah ok thanks
<jelmer> Something like --quiet might turn it off, but I don't think I've ever used bzr without it
<jelmer> time for some sun :) Back later
<rocky> has anyone noticed that on natty (ubuntu), after installing bzr and bzr-fastimport apt packages, "bzr plugins" does not list fastimport ?
<rocky> am i supposed to do something extra to activate that plugin?
<maxb> rocky: Which packages? Ubuntu primary archive only, or ~bzr PPA ?
<rocky> maxb: ubuntu natty standard packages (no extra ppa's)
<maxb> huh, you're right. how odd
<rocky> maxb: is the bzr ppa stable enough? i'd just use that if it's going to keep more recent bzr and bzr plugin releases
<maxb> There are multiple ~bzr PPAs
<maxb> bzr/ppa for the really stable stuff
<maxb> bzr/proposed for the probably stable stuff, but we're checking and occasionally building interdependent sets of packages
<maxb> bzr/beta for the not-exactly-stable but still mostly safe stuff
<maxb> bzr/daily for the really bleeding edge stuff
<maxb> :-)
<rocky> sounds like i'll go with bzr/beta ;)
<maxb> Bear in mind that some plugins in there can be expected to be occasionally broken
<rocky> right
<maxb> like bzr-svn at the moment, I think
<maxb> Because it's still catching up with bzr core
<maxb> Hmm
<maxb> So, I think bzr-fastimport is broken in natty because it's the only packaged bzr plugin to be using python-support instead of python-central
<maxb> And a nasty little incompatibility between bzrlib's plugin loading mechanism and different python package management methodology methods is breaking things
 * maxb comments on bug 752396
<ubot5> Launchpad bug 752396 in bzr-fastimport (Ubuntu) "bzr-fastimport is not listed in "bzr plugins" list" [Undecided,Confirmed] https://launchpad.net/bugs/752396
#bzr 2011-04-26
<rsingh> hello all
<rsingh> i was able to push my code onto my production server, no problem. i have now used branch to pull that code onto another machine, my laptop, and it worked
<rsingh> the problem is that i cannot see anything on my browser if i run the webapp
<rsingh> my index.php comes up as blank on the browser, though there is code in that file
<lifeless> you probably can get the code visible on your server by doing 'bzr checkout .' in that directory
<lifeless> there is a plugin though, designed specifically for publishing websites, called 'bzr-upload' which may suite your needs even more closely
<rsingh> lifeless: sorry, that didn't do the trick
<rsingh> lifeless: it's just strange that my browser doesn't output anything from index.php
<rsingh> hold up, lemme check something
<rsingh> alright, i figured it out
<rsingh> my index.php was using an incorrect (on my local) path to my framework files
<rsingh> anways, thanks for your help lifeless
<lifeless> ah!
<lifeless> cool
<jam1> morning all
<jelmer> jam1: You seem to be in luck, we never have weather this nice around easter :)
<quotemstr> What's the easiest way to collpase multiple revisions into one?
<quotemstr> Say I have a local branch with lots of commits that make changes, undo mistakes, fix typos, and so on, but want to push upstream a single, neat change.
<quotemstr> I could take a diff, revert to the parent revision, then just apply the diff with patch, but that feels ugly.
<lifeless> quotemstr: generally in bzr folk don't feel the urge because the tool is good enough to show good diffs
<lifeless> quotemstr: but if you feel the urge there are a couple of recipes. The most robust one (doesn't care if you've meged from upstream etc) is:
<lifeless> make a fresh branch from upstream; bzr merge your branch; bzr revert --forget-merges; bzr commit -m "shiny"
<lifeless> night all
<kgoetz> isn't there a rebase plugin that would do something like that ?
<Tak> rebasing doesn't have anything to do with collapsing changesets
<kgoetz> hm, i thought thats almost exactly what people used rebase for
<AfC> Rebase will preserve the number and nature of the commits - it just fucks history.
<maxb> People get confused because git rebase -i does lots of things which are not technically rebasing
<kgoetz> maxb: that'll be where the confusion comes from. i hear people rabit on about it all the time
<kgoetz> AfC: interesting feature
<jelmer> it would be interesting to have some way to reshape the revision graph
<jelmer> there are some valid use cases for it
<Tak> collapsing?
<jelmer> no, but reshaping a history graph e.g. when combining parallel imports
<bialix> hi jelmer
<bialix> I've landed the support in qbzr for configurable tab width today
<bialix> https://code.launchpad.net/~abudden/qbzr/qbzr-tabstop-width/+merge/56553
<bialix> we store tab width settings in bazaar.conf (and could be branch.conf) as tab_width = N
<bialix> you may want use it for bzr-gtk
<jelmer> bialix: cool, I'll be sure to give it a try some time
<bialix> ok
<LeoNerd> How intelligent are the globs in .bzrignore? Can I set an entire regexp? I want to ignore  (MY)?META.(yml|json)
<LeoNerd> Er.. \.  as a regexp
<beuno> AFAIK, they are proper regexes
<maxb> bzr help ignore ?
<maxb> They're globs by default, because that's the clearest and simplest option for most things, but you can use a RE: prefix if you want
<LeoNerd> Ahh OK
 * LeoNerd finds ~/.bazaar/ignore, adds globally :)
<glob> morning all; 'bzr status' is reporting a file as missing (it's a .moved file); how do i tell it that i don't care about that file?
<glob> the documentation for status doesn't even list 'missing' as a possible state
<glob> nevermind; i figured it out...
<glob> i created an empty file with the same filename that bzr said was missing
<glob> bzr reported this file now as 'added'
<glob> then i deleted the file with 'bzr del'
<Fidelix> Hello. I already have a repo in a remote server. I made a tar.gz, downloaded my project from the remote server and unpacked on my PC. Now I want to put the files on my PC under VC. Can someone instruct me to do that?
<achiang> hello, seeing a strange oddity i don't understand. i add a new file (mylib.so) to a directory that is versioned by bzr. bzr status should then say it is an unknown file, but it doesn't see it at all. i don't seem to have a .bzrignore anywhere that i can tell
<fullermd> .so's are in the default ignore list.
<achiang> so how do i whitelist it?
<achiang> just bzr add it specifically?
<fullermd> You probably don't want to take it out of the default ignores, since everybody will assume they're there.  You can...  yeah, I type too slow   :p
<fullermd> ignore just means that 'status' doesn't consider it unknown, and a recursive 'add' won't automatically add it.
<fullermd> You can still add it manually, no problem.
<achiang> ok
<achiang> that was a little sneaky
<achiang> but i got it now, thanks
<ChrisWoollard> Evening all.
<ChrisWoollard> Does anybody know how i can export a list of people that have contributed / commited to a bzr branch?
<fullermd> There's something in the stats plugin that counts up revs by author, AIR...
<ChrisWoollard> do you have a url for that plugin?
<ChrisWoollard> i think i have found it
<ChrisWoollard> thanks
<Fidelix_> Hello. I already have a repo in a remote server. I made a tar.gz, downloaded my project from the remote server and unpacked on my PC. Now I want to put the files on my PC under VC. Can someone instruct me to do that?
<m4n1sh> is Jelmer here?
<m4n1sh> what is his nick?
<LeoNerd> ugh.... since when did "bzr up" decide to become "bzr merge" if there's divergent history, without prompting?
<LeoNerd> It totally ruins my branch :/
<LeoNerd> and how can I have it back on the "throw an error if there's divergent history" behaviour?
<fullermd> That would be the "bound branch" side of things coming around to bite.  It's always done that...
<LeoNerd> I don't recall it doing so
<LeoNerd> bzr up  always used to fail with an error about divergent history
<glyph> LeoNerd: bound branches have always done that for me
<glyph> LeoNerd: otoh that's why I don't use bound branches :)
<LeoNerd> Interesting.... mine haven't... :/
<LeoNerd> Hrmmm
<LeoNerd> In that case.. hrmm.... any way I can fix it currently..? and separately, any way I can make it not do that again in future?
<LeoNerd> I want my workdir back in its divergent state, so I can rebase it
<fullermd> No automated way.  You can dig around for the revid and set it as the head.
<LeoNerd> Ahyes... remind me..? bzr heads --something to list it...
<fullermd> The default position is 'heads --dead'.  I'm not sure if the head counts as dead if it's a parent of the WT.
<fullermd> Probably does; I think it only considers branches as enlivenating.
<fullermd> (better still would be to bzr list-workingtree-parents of course...  only a minor issue with that)
<LeoNerd> So having found the revid, now what?
<fullermd> unbind and pull --overwrite
<LeoNerd> Excellent, that got it
<LeoNerd> rebase, push..done..
<Fidelix_> bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 15: ordinal not in range(128)
<Fidelix_> I can't checkout.
<DC> Hi, I have a question about repositories and file permissions on Linux. I have a shared repository that I use with some friends via sftp protocol. On the machine that hosts the repository we have different Linux logins, but we are on the same group. I've created a shared repository (with group write permissions), but when someone pushes a new branch into this shared rep., the branch is created without the right write
<DC>  permissions to the group. Is there any way to manage these permissions automatically with bazaar or each user must always correct the permissions manually after each push?
<fullermd> No, branches are just created with umask.  Now, you could try fiddling that; if bzr is the main/only use for those logins, that can be fruitful.
<james_w> the setgid bit may help if you need groups to make it work
<fullermd> That won't help in perpetuating g+w.
<DC> I tryed the setgid, but it only guarantees that the group will be created correctly, not with g+w.
<DC> These logins are from our student network, not only for bzr. And the machines are not administrated by us. We don't have bzr nor acl.
<fullermd> If you have access to root, you could setup a cron job to run through the dirs and make sure branches are g+w with an appropriate regularity.
<DC> Even if each user fixes the permissions after new
<DC> each new push, is there a chance that a new file with the wrong permissions get created during a commit?
<DC> If this is the case, one should take care of permissions on each bzr operation and not only after pushes, which kind of sucks. :(
<fullermd> Files inside the repository inherit permissions.  Pretty sure all the internal branch files do too.
<fullermd> It's creation of branches that doesn't, because in a sense they have nowhere to inherit from.
<DC> Well, maybe they could respect the permissions from the shared repository (if it is a shared rep).
<DC> But it is good to know that at least inside the branch the permissions will be respected. Thanks, fullermd.
<fullermd> Yeah, it would be nice.  Or some path-based config somewhere.
<m4n1sh> jelmer: ping
<DC> That would be nice too!
<jelmer> m4n1sh: hi!
<m4n1sh> jelmer: I am working on zeitgeist-dataprovider
<m4n1sh> and I saw you proposed a merge
<m4n1sh> this
<m4n1sh> https://code.launchpad.net/~jelmer/zeitgeist-dataproviders/bzr-dbus/+merge/53128
<m4n1sh> jelmer: I was about to merge it
<m4n1sh> then I noticed a small issue
<m4n1sh> jelmer: the original code is copyrighted to Markus Korn
<m4n1sh> but the code here does not show his name as copyright holder
<m4n1sh> http://bazaar.launchpad.net/~bzr/bzr-dbus/trunk/view/head:/hook.py
<m4n1sh> only as author
<m4n1sh> I am not sure if you and thekorn talked on this
<m4n1sh> jelmer: please leave your comment here. https://code.launchpad.net/~jelmer/zeitgeist-dataproviders/bzr-dbus/+merge/53128
<m4n1sh> I need to sleep
<m4n1sh> Good night
<jelmer> m4n1sh: the version in bzr-dbus is an older one
<m4n1sh> jelmer: it can be updated
<jelmer> IIRC I discussed with Markus whether it was ok to merge it into bzr-dbus when I merged the original version
<m4n1sh> hmm
<m4n1sh> I think then he should not worry much
<m4n1sh> AFAIK he has signed the contributer agreement too
<m4n1sh> will ask markus tomorrow before merging
<Fidelix__> Jesus... bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 15: ordinal not in range(128)
<Fidelix__> What is this?
<maxb> jelmer: Do you understand this python-support / python-central nonsense with bzr-fastimport?
<jelmer> maxb: yeah
<maxb> I thought I did, but the daily PPA package of bzr-fastimport doesn't seem to suffer from the issue
<jelmer> maxb: the daily package uses dh_python2
<maxb> But only on natty
<maxb> I'm testing in a lucid chroot
<jelmer> maxb: have you tried installing/reinstalling bzr and bzr-fastimport in a different order?
<maxb> I tried a couple of orders
<maxb> But yes, I'm now getting suspicious of bzr's random ordering of plugin loading
<maxb> nope, it's stubbornly not reproducing :-/
<maxb> Huh, this couldn't be a mad python2.7 incompatibility, could it?
<maxb> hmm, nope
<jelmer> dh_python2 / python-support incompatibility?
<jelmer> though I think the bzr in natty still uses python-central IIRC?
<maxb> Ah, got it
<maxb> The problem is that bzr in natty uses dh_python2
<maxb> Whereas bzr in PPAs for << natty uses python-support
<maxb> If bzr core is using python-support, it picks up plugins using python-support OK
<maxb> Python namespace packages make me sad :-(
<jelmer> dh_python2 ftw
<maxb> I think allowing python-central and python-support to both exist was one of the nastier mistakes made in Debian packaging :-/
<jelmer> maxb: me too
<jelmer> glad it's finally over, though it's unfortunate we needed a third solution to get there
<maxb> "over"
<maxb> ha
<maxb> I'm currently pondering how I might backport python2.6 to etch at work
<jelmer> maxb: you people and your "stable" releases
<jelmer> maxb: but yeah, you have a point.. it'll be a problem for a while more unfortunately :-/
<maxb> It could be worse
<maxb> At least I'm no longer compelled to deploy stuff on Slackware 10.0 servers (mostly)
<jelmer> maxb: oh, fwiw, I'm also a PPU now
<maxb> Ah, useful
#bzr 2011-04-27
<jelmer> hi poolie
<jelmer> Did you have a good easter weekend?
<poolie> hi there
<poolie> i did
<poolie> how are you?
<jelmer> I'm well too, we had amazing weather over the weekend
<poolie> we had pretty much continuous rain
<poolie> i'm leaving just under a week from today
<poolie> for uds etc
<jelmer> this was our hottest easter in recorded history, around 25 degrees
<jelmer> hopefully we'll have similar temperatures in Budapest :)
<poolie> 25C is nice
<poolie> prague was quite hot
<poolie> jelmer did you have any opinion about python 2.4/5/6
<jelmer> poolie: not really
<jelmer> poolie: I personally would like to move to 2.5, but I only have Debian Unstable and Natty machines...
<jelmer> poolie: the input from various people running or packaging for older versions of RHEL or backporting to older versions of Ubuntu is probably most interesting
<maxb> Where older versions of Ubuntu == just hardy, I think
<poolie> it seems like the main issue is now py2exe
<maxb> (assuming intrepid and jaunty are disregarded for being both EOL)
<poolie> hardy has python2.5
<maxb> Oh, yes. Sorry, I was still thinking about 2.6
<poolie> np
<spiv> Morning folks.
<poolie> it's just a small additional thing in favor of 2.5
<poolie> hi spiv
<maxb> py2exe was a reason that 2.6 was bad but 2.5 was OK?
<poolie> right
<poolie> how was your weekend spiv?
<jelmer> hi spiv
<spiv> poolie: long :)
<poolie> it was wasn't it?
<mgz> ah, poolie.
<mgz> oh, I should put up my alternative to jam's compat breaking branch if that's on the table for today
<poolie> mgz: so you have a thing that fixes the same bug but without using try/yield/finally?
<mgz> yup.
<mgz> sec, nearly done, will post.
<poolie> hm, i know we can fix them one by one
<mgz> it defers the decision for a bit at least :)
<poolie> otoh it is O(n) to keep reconsidering it every few months
<mgz> jam's made some reasonable arguments, and august is still quite a few months of coding away, so I'm not sure I can really justify keeping the old version alive
<mgz> but there was someone on rhel in here the other day looking for support who managed to mangle a (working) 2.4 trunk bzr by trying python 2.6
<mgz> where the easy fix was just cleaning up and using 2.4 again (a plugin was broken)
<poolie> what do you mean?
<mgz> hm, I'd need to look at the log, but he was trying to install bzr.dev and didn't have pyrex on 2.6 and got some .so files from the wrong version.
<poolie> ok i see
<poolie> so he had a kind of half-installed python2.6,because that wasn't included in the original rhel release?
<poolie> this does happen from time to time
<poolie> especially on mac os it seems
<mgz> http://irclogs.ubuntu.com/2011/04/25/%23bzr.html#t00:45
<poolie> i'm not sure that it's all that correlated with what we require
<mgz> I agree most people probably aren't trying to combine bleeding edge bzr with ancient python.
<poolie> like if we require 2.4, people still sometimes trip up because they have a half-installed python2.5
<mgz> sure, but in his case using the system python got it working again.
<mgz> next week, bzr.dev will not work with his system python.
<poolie> maybe we should ask emacs-devel
<lifeless> poolie: btw I have bzr-search test suite failing with the maverick build
<lifeless> poolie: I commented on the bug for you
<mgz> lifeless: good work on py3ing subunit the other night
<mgz> I filed a bug on the remaining failures I got, as they're a problem in trunk too
<lifeless> cool, thanks
<poolie> i saw the mail, i haven't looked into it yet
<mgz> mostly shallow, but I have two problems
<lifeless> mgz: you live in a yellow submarine?
<mgz> #1 how do you want skips done? currently you're using unittest.TestCase which... I think I need to switch to testtools.TestCase for the skip method?
<mgz> ^that would hardly be a problem
<lifeless> sure, using testtools.testcase would be fine
<mgz> well, coming up for air regularly might get old.
<mgz> should I switch the whole file? or have a mix-and-match?
<mgz> problem #2 ExecTestCase
<lifeless> mgz: whatever you like is fine with me
<mgz> the very concept is... problematic
<lifeless> having bitten the bullet and depending on testtools, I've no intrinsic limits onuse
<lifeless> well, exectestcase is clearly not for windows users :)
<lifeless> erm
<lifeless> actually
<lifeless> isolatedtestsuite isn't
<lifeless> exectestcase is
<mgz> currently, the tests exec some python scripts (with the system python, not the one running subunit), and then fake-print some subunit looking output
<mgz> ^yeah, exec could work, apart from the design is... I don't like it
<mgz> getting shell script blobs from docstrings isn't very portable
<mgz> anyway, the test fails (and leaks the streams) because neither end sets the pipe to binary
<lifeless> heh
<mgz> but just fixing that doesn't really make it any saner, and the paths are still wrong
<lifeless> uhm
<lifeless> so, I'd like to just fix it in the first instance
<mgz> because you're doing path_join|(script_dir, shell_script_blob)
<mgz> which happens to work for (".", "some_script.py -some_arg") -> "./some_script.py -some_arg"
<mgz> but doesn't for arbitrary paths or commands.
<mgz> so, you'd get failures depending on where your test suite was in your directory tree
<mgz> (most specifically, if you had any shell-significant characters like spaces)
<quotemstr> lifeless: Thanks.
<lifeless> mgz: external scripts should be usint libsubunit or some other language binding
<mgz> I agree.
<lifeless> which sould set binary
<mgz> making the sample scripts do that is hard though.
<lifeless> yeah
<mgz> okay, it's way too late, I need to get a train tomorrow.
<mgz> night all!
<lifeless> ciao
<poolie> night mgz, hae a good break
<bignose> yay, Gitorious lets me set up an account logging in via my existing OpenID!
<bignose> that means I can have full-featured hosted Mercurial and Git repositories
<bignose> the only one left is Launchpad <URL:https://bugs.launchpad.net/launchpad/+bug/210943>
<ubot5> Ubuntu bug 210943 in Launchpad itself "be an openid consumer (relying party)" [Low,Triaged]
<bignose> does anyone have comments on using Gitorious or Bitbucket as back-end repository for Bazaar?
<glyph> bignose: Neither is possible.
<glyph> bignose: Maybe bitbucket is, but I'm not nearly crazy enough to try it :)
<poolie> bignose: interesting; do you then give them an ssh key for actual access, or is it all over openid?
<spiv> We should just provide HTTP-over-SSH ;)
<poolie> o/ spiv
<fullermd> I've got a friend who did some work on SSH-over-HTTP...
<bob2> bitbucket least supports http push with passwords
<poolie> hi jam
<jam> morning poolie
<poolie> thanks for all the bug cleanups
<poolie> jam if your queue is getting reasonably empty i wondered if you could give some relief to bug 602614
<ubot5> Launchpad bug 602614 in Bazaar "Out of memory error in _ensure_content on auto repacking" [High,Confirmed] https://launchpad.net/bugs/602614
<poolie> maybe even just a config knob to delay repacking
<jam> poolie: sure. My queue is actually filling up because of backlog stuff with TreeReference while I switch over to the fetch-sends-tags stuff.
<jam> but I can put it on my 'stuff to get to' queue
<poolie> jam i didn't really understand your last comment on gz's sftp traceback patch
<poolie> > As for a focused 2.4 branch, that is ok, but really, I don't want to try
<poolie> and "fix all hacks" before we break compatibility. I'd rather break it,
<poolie> and then land things that cleanup the code as someone wants to do so. I
<poolie> don't think we should require cleaning everything up first.
<jam> poolie: his comment was "we should land a separate branch that cleans up our hacks"
<jam> I'd rather land a compatibility break
<jam> and as we want to clean up code, do so
<jam> don't block on us cleaning up all the code first
<poolie> oh, right
<poolie> i agree with that
<poolie> "clean up all the code" doesn't have a very clear end point
<sobersabre> hi.
<poolie> oh wow it's wednesday already
<poolie> that was quick
<sobersabre> I'm trying to determine whether I need to commit something.
<sobersabre> poolie: indeed wednsday, depending on you timezone though.
<sobersabre> I have found already I need to commit if wt.changes_from(wt.basis_tree()).has_changes()
<sobersabre> and also if wt.get_parents_ids() array has > 1 items.
<sobersabre> anything else I'm missing ?
<poolie> sobersabre: you're reimplementing bzr's commit function?
<spiv> sobersabre: why not just try the commit with allow_pointless=False, and catch the PointlessCommit error for when there's nothing to commit.
<jam> sobersabre: or worst case: "wt.has_changes()" ...
<jam> which implements all of that logic as well
<jam> Though that was introduced in "recent" versions. (2.2 maybe?)
<poolie> i'm not completely sure that would catch a do-nothing merge
<jelmer> hi poolie, spiv, jam
<jam> morning jelmer
<jam> poolie: it checks the get_parent_ids() stuff, not sure what you're thinking
<poolie> hi guys
<poolie> hi jelmer, jam, spiv
<poolie> shall we have a chat?
<jelmer> poolie: which VOIP systems would you like to use today ? :)
<jam> jelmer: mumble today
<jam> jelmer: are you in #canonical?
<poolie> i would like to use sip but i guess we'll actually use mumble
<bialix> and what's better?
<jelmer> jam: https://code.launchpad.net/~jelmer/bzr/move-interbranch-fetch2/+merge/58567
 * jelmer groans
<jam> jelmer: would you rather just IRC chat?
<jam> or direct skype?
<jelmer> jam: let's try skype
<poolie> bialix: they all have tradeoffs i guess
<poolie> hi, btw
<bialix> hi poolie
<bialix> poolie, don't take my words about python 2.5 and py2exe too high
<bialix> it's so strange to see jam around at this half of the day
<bialix> skype has chat mode
<poolie> he lives in the Netherlands now
<poolie> so it's 11am or so
<bialix> really?
<poolie> srsly
<jam> bialix: yeah, for about 2 years before I go back to the US
<jam> my wife got a promotion that needs some training
 * bialix is very surprised, but that's great
 * fullermd of course has no such sensible excuse for being around at this hour   :p
<bialix> fullermd: we know you never sleep, so you don't need any excuses
<jam> jelmer: what is up with your audio system?
<jam> Overall, I think skype was working better than mumble, though
<poolie> night all
<jam> night po
<jam> poolie: g'night
<jam> jelmer: you just cut out again
<jelmer> jam: Do you think we need to deprecate update_revisions first? I'm not aware of anybody using it and I couldn't imagine everybody using it, it's a pretty odd interface compared to e.g. push or pull.
<jam> jelmer: you would be the most aware of any implementations using it
<jam> if bzr-svn, for example, uses it
<jam> then we should probably deprecate it
<jam> we'll move away from it, but we don't want to kill people with version ske
<jam> skew
<jelmer> the foreign plugins all provide update_revisions but none of them uses it
<jelmer> so I'd be more than happy to axe it, as it means being able to remove that update_revisions() implementation too
<jam> jelmer: so just watch out for skew, you can't axe it until it isn't actually being used.
<jam> But yes, I don't think anyone was directly calling it
<mterry> In Ubuntu 11.04, I'm doing "cd dir; bzr init; bzr add" and nothing is getting added, no errors or anything.  How do I figure out what's going on?
<jelmer> mterry: what does "bzr st" say?
<mterry> unknown:
<mterry>   ubuntu-application/
<mterry>   ubuntu-cli/
<mterry>   ubuntupygame/
<mterry> jelmer, ^
<jelmer> mterry: is that correct, were those the directories you wanted to add?
<mterry> jelmer, yes.  But bzr add seems to ignore them
<jelmer> does "bzr add ." give different behaviour?
<mterry> jelmer, no.  Nor does specifying directories or files
<mterry> jelmer, oh!!
<jelmer> mterry: that's really odd - are there any symlinks involved perhaps?
<mterry> jelmer, the directories are also bzr repos
<jelmer> mterry: You found it ? :)
<jelmer> mterry: that would explain it
<mterry> jelmer, I just realized
 * mterry wishes at least bzr add -v would have said something
<mterry> jelmer, thanks for the help!
<jelmer> mterry: I think the idea is that they would be added as nested trees, but the support for that is half finished
<mterry> hmm, k
<jelmer> jam: This might be a noobish question, but is there any reason we couldn't do in-place updates of timestamps/shas in dirstate if there are no changes in the file list?
<jam> jelmer: the original design was so that we could (which is why we take OS locks, etc). we don't because, a it wasn't implemented, b, I'm not sure if things are truly fixed width
<jam> and c) we want to get rid of OS locks
<jelmer> jam: ah, thanks
<jam> jelmer: if we new it was going to be reasonably atomic, we probably could update in place, though that logic still needs to be worked out
<jam> well, as long as any failure mode would fail gracefully
<jam> rewriting pages has some bad habits when things crash
<jam> like random NULLs, etc.
<jam> I think our current thought is that we'd rather have a separate journal file
<jam> also, dirstate was written such that we could only read some of the file (it is bisectable, etc)
<jam> but we always read and write the whole thing right now
<bialix> jam: isn't atomic write require write to some temp file and then mv over the old?
<jelmer> jam: ah, interesting - thanks
<bialix> jam: if I want to improve auto-refresh in bzr-explorer to reflect new changes in working tree then I think I can add filesystem wathcer for dirstate file and maybe conflicts file, right?
<jelmer> jam: still there?
<jelmer> jam: I'm double checking the behaviour of text revisions. is it correct that we record a new text when:
<jelmer> * a file's executability changes
<jelmer> * a symlink's target changes
<jelmer> * during a merge one of the texts of the parents is taken verbatim (no sha1/executability changes) but the text of another parent is discarded
<jelmer> but not when a right hand side parent introduces a new text and that text is taken verbatim
<lallenlowe> can someone tell me, in GNOME, when I go to pull new revisions of a project from launchpad and the little dialog pops up asking for my password to unlock my ssh key, what program provides that dialog? and caches the password for future pulls?
<mterry> lallenlowe, gnome-keyring stores it
<mterry> I believe...
<lallenlowe> mterry: yeah, that's what I thought
<lallenlowe> mterry: for some reason it is asking me for the passphrase on the cli
<mterry> lallenlowe, hmm.  You know, for bzr, it might be ssh-agent that's doing the asking
<lallenlowe> mterry: right
<Peng> I've seen the magic GNOME thing come up when using ssh in a terminal.
<lallenlowe> Peng: I used to also
<mterry> I don't know how it decides whether to prompt with GUI or not.  I assume if DISPLAY is valid, but not sure now who actually owns the GUI dialog
<lallenlowe> ok
<jam> jelmer: more complex than that, I think
<jam> it depends more on the ancestry
<jam> for example, one side could take an old revision, modify it, then revert it, then merge it, and we would create a new revision
<jam> even though both sides have the same final content
<LeoNerd> Dear bzr community: is it so much to ask that "bzr: ERROR: No push location known or specified."  could in fact become "bzr: No push location known so pushing to branch"   instead?
<LeoNerd> 99.999% of the time I am pushing I am pushing to my (bound) branch. In fact I don't think in a single checkout I've ever made, do the branch/parent/push/missing locations ever differ
<levu> how do i push only the last commit to a new branch, not the whole history?
<LeoNerd> push -r   I believe
<levu> LeoNerd: thx
<LeoNerd> Ohwait... the -last-.. er.. you can't, as such
<LeoNerd> A commit applies a change to its parent. A commit implies the entire history that came before it
<levu> LeoNerd: how do i push it as if i am doing the initial import?
<LeoNerd> Hrm?
<levu> there is lp:foo as the main branch of a software and i want to create an own branch for fixing a bug. in my branch (lp:~levu/foo) i don't want to have lp:foo be cloned
<levu> i did bzr pull lp:foo and bzr push lp:~levu/foo for that, but that's cloning the whole lp:foo into my branch
<lifeless> levu: what is foo
<lifeless> I can look for you
<levu> *bzr branch lp:foo not bzr pull lp:foo
<levu> lifeless: https://bugs.launchpad.net/ubuntu/+source/conglomerate/+bug/771735 this is the case where i done it wrong, i assume
<ubot5> Ubuntu bug 771735 in conglomerate (Ubuntu) "xpath in properties dialog not selectable with mouse" [Undecided,New]
<lifeless> levu: so lp:conglomerate ?
<levu> the linked branch is mine and when you look at the history of the linked branch, you see the whole history of lp:ubuntu/conglomerate
<lifeless> ok, lp:ubuntu/conglomerate
<lifeless> and you are pushing to lp:~levu/ubuntu/natty/conglomerate/branchname ?
<levu> lifeless: no, to lp:~levu/conglomerate/771735
<levu> https://code.launchpad.net/~levu/conglomerate/771735
<levu> i did commit 12 im my branch and commits 1 to 11 are cloned from the official branch
<lifeless> levu: so, you're pushing *upstream* bbut you branched from *ubuntu*
<lifeless> levu: thats why this is happening.
<levu> lifeless: well, my point is, i want to create a new branch, where there's only one commit, not the whole history of commits
<lifeless> levu: right, try this:
<lifeless> bzr ush lp:~levu/ubuntu/natty/conglomerate/771735
<lifeless> *push*
<lifeless> shold be a lot faster
<levu> lifeless: are the names important?! wow, that's interesting, i thought, i can choose the name as i want :D
<levu> ok, i'll try this, thanks :)
<lifeless> levu: the upstream name and the distro package name can differ
<lifeless> levu: so yes, they are important.
<levu> lifeless: ok, thanks :)
<lifeless> levu: you can choose the branchname - the last component - anyway you want
<levu> lifeless: aaah, ok
<lifeless> levu: the first component - your name - has to be your name or a team you are a member of
<lifeless> the components in between tell launchpad what project - 'foo' is upstream 'distro/series/sourcepackage' is a distro branch
<levu> where in the documentation i can find such interresting things? :D
<lifeless> bzr help lp
<lifeless> might have some stuff
<levu> here it says, ERROR: No help could be found for 'lp'.
<lifeless> bzr help launchpad
<lifeless> sorry ;)
<levu> lifeless: thanks a lot :)
<lifeless> it may not be helpful - please do file a bug if thats the case
<levu> there is a link to http://help.launchpad.net/ which should help
#bzr 2011-04-28
<poolie> hi all
<bignose> poolie: to answer your question:
<poolie> hi
<bignose> poolie: yes, Gitorious asks the user to upload SSH keys
<bignose> the only thing (AFAIK) they're using OpenID for is to replace the need to supply a password to log into the web site.
<bignose> which is exactly the extent of <URL:https://bugs.launchpad.net/launchpad/+bug/210943>
<ubot5> Ubuntu bug 210943 in Launchpad itself "be an openid consumer (relying party)" [Low,Triaged]
<bignose> (as far as I'm concerned)
<bignose> just like Bitbucket
<poolie> bignose, did you see http://productblog.37signals.com/products/2011/01/well-be-retiring-our-support-of-openid-on-may-1.html
 * bignose hopes against hope that with Bitbucket and Gitorious accepting OpenID for login, that Launchpad might join very soon.
<bignose> poolie: yep, I saw that.
<poolie> i think they have a good point
<poolie> the requirements-level idea of people owning their own credentials across sites is good of course
<bignose> poolie: what is their good point? we may disagree on what that is :-)
<bignose> the good point they have IMO is that there is a threshold below which it's not worthwhile for a site to implement an OpenID relying party.
<bignose> but that's presumably uncontroversial.
<bignose> I think Launchpad would clearly benefit from being an OpenID relying party, and Canonical has the resources and skills to implement it.
<poolie> ah i thought the good point was that openid does not give a very good user experience
<poolie> because amongst other things it bypasses or disables a lot of work that has been put into browsers to make regular http auth and form/cookie auth work well
<poolie> anyhow, this isn't especially a reason it won't be done in lp
<poolie> and many of the same issues apply to lp's captive openid provider
<bignose> I'm working with Bazaar branches off a Subversion repository
<bignose> or rather, a Bazaar bound branch with Bazaar feature branches
<bignose> when I merge a feature branch into the trunk (bound to a Subversion server) the status shows the merged revisions
<bignose> but when I commit, the Subversion repository only has a single revision â the merge.
<bignose> am I misunderstanding what I'm seeing?
<bignose> how can I have the merged revisions appear in the Subversion repository for others to see?
<spiv> bignose: I think you may need to push those feature branches into svn first, then merge the svn instance of them into trunk.  jelmer would know for sure.
<bignose> hmm. that's not an attractive option; I'm talking about feature branches that are freely created for my use. I don't think my collaborators want them in the central Subversion repository.
<bignose> jelmer: when you're around, I would appreciate your input on the above.
<luks> bignose: you could rebase the branch on top of svn trunk before you push
<luks> but of course then you lose the ability to work with the branch later, or share the branch before it's finished
<jam> morning poolie
<poolie> hi there jam, how are you?
<jam> doing pretty good
<jam> poolie: how was your day?
<poolie> pretty good
<poolie> pushed along my launchpad email refactoring branch and did some pre-trip errands
<poolie> jam is there an upstart script to run loggerhead?
<poolie> apparently not in the current daily package
<poolie> just looking at https://answers.launchpad.net/bzr/+question/154439
<jam> poolie: I think there used to be an init.d entry, but we removed it a long while back IIRC
<poolie> spiv, could you set up a webnumbr from patch-needswork things?
<poolie> s//bugs/
<poolie> jam the guy might not realize he doesn't need a long-running process
<poolie> we'll see
<spiv> poolie: sure
<bignose> luks: right. both of those (along with not wanting to re-write history in general) mean that's not an option.
<luks> bignose: unfortunately, I don't think there are any other options
<luks> as far as I know, you either need the push the branch to svn or rebase it
<luks> I think that's actually why the rebase plugin was written by jelmer :)
<spiv> posulliv: http://webnumbr.com/bzr-bugs-tagged-patch-needswork
<spiv> posulliv: oh, sorry, wrong nick
<vila> hi all !
<bialix> who's there? I don't believe it!
<bialix> heya vila! \o/
<vila> bialix: Hey ! Just arrived :o) A bit delayed in flights...
<bialix> you came back just for uds :-)
<vila> jelmer, jam: Ping. Anything I should know or check before before cutting 2.4b2 ?
<vila> bialix: he he, almost, but I won't attend UDS ;)
<jelmer> vila: Hi, and welcome back!
<jam> hi vila
<Tak> damn, how many uds are there per year?
<bialix> it depends
<jelmer> Tak: As many as Ubuntu releases :)
<vila> Vacations were lovely but it's still good to be back :)
<vila> jelmer, jam: https://launchpad.net/bzr/+milestone/2.4b2 mentions 2 bugs in progress, one of which being critical, should I wait (>-/) or should they be re-targeted ?
<jam> vila: I think jelmer's patch for it has been approved (by me) I'm not sure if he has sent it yet
<jelmer> jam: It's not marked as approved in lp yet as far as I can tell
<jelmer> ( - https://code.launchpad.net/~jelmer/bzr/move-interbranch-fetch2/+merge/59204)
<jam> jelmer: you needed to tweak the NEWS entry, but I marked review:approve
<bialix> vila: I want to release qbzr 0.21 beta1 for bzr2.4b2. How many time I have?
<vila> bialix: well, if we follow the usual process (cutting 2.4b2 today), it will be announced next tuesday, so it mostly depends on packagers, but the OSX ones are quite reactive so the sooner the better
<vila> jam: you seem to have approved it 2 hours ago, yet, the proposal appears to have been resubmitted after that (your vote has a yellow background) even if the resubmission seem to have been done 22 hours ago... lp bug ?
<jelmer> jam: Ah, I see what happened. I resubmitted the MP so your vote is only on the old MP
<vila> ha no, probably jam approved the old one by mail
<jelmer> ah
<vila> jam: oh, and you landed the fix for bug #76012 in 2.3
<ubot5> Launchpad bug 76012 in avahi (Ubuntu Edgy) "Avahi can run into an infinite loop on reception of a bad packet" [High,Fix released] https://launchpad.net/bugs/76012
<vila> meh
<bialix> vila: ok, I'll made release this weekend
<vila> bialix: ok, I'll mention that in the freezing mail then
<bialix> thx
<vila> hmm, that was bug #760152
<ubot5> Launchpad bug 760152 in Bazaar "bzr merge --pull --preview BRANCH does not always honor the --preview option" [High,In progress] https://launchpad.net/bugs/760152
<jam> vila: right, so that landed in 2.3, but needs to be merged up to 2.4, IIRC
<jam> I didn't feel like doing it for just that patch
<vila> jam: right, I dunno what this patch does, but *I* generally prefer to merge earlier if only to make sure potential conflicts are resolved asap
<bialix> fullermd: around?
<vila> ouch, 5.000 emails to process...
<jam> vila: how many of those are the automate mails?
<vila> jam: I don't know yet but not much, only 12 out of the 5000 weren't sorted properly
<jam> is that because of the mail backlog you stopped getting?
<vila> jam: automated emails should be less than 1000 anyway
<vila> yup
<vila> right, 300 for the builds
<vila> probably ~50 for the mp landings
<vila> jam: could you merge up your patch to trunk ? That's the only one missing there
<jam> vila: don't you merge up anyway for the release?
<jam> or you aren't doing a 2.3
<vila> no 2.3 yet, I generally merged up, but my plate is clearly overflowed there so any tiny bit will help ;)
<vila> gosh, 600 emails for the bugs, none automated there
<poolie> hi vila! welcome back
<vila> poolie: hey !!!
<vila> thanks ;)
<poolie> how was your trip?
<vila> lovely
<vila> which is good for a honeymoon rehearsal :-D
<vila> (I should stop doing this joke or Valentine will take it seriously ;)
<poolie> haha
 * bialix waves on poolie
<poolie> hi there
<bialix> sorry, my english skill
<bialix> poolie, what decision has been made re bzr-colo for bzr core?
<poolie> i don't think it should be the default
<bialix> that thread has been very long but I'm not sure what the resume
<poolie> yes i should propose a conclusion
<poolie> it seems clear some people really like multiple trees
<poolie> i think we should add a core concept of multiple named branches
<poolie> jelmer has some branches that come pretty close to that
<poolie> then bzr colo can use that
<bialix> that's good
<poolie> and qbzr etc can go through that interface to get at colo branches if they're there
<bialix> I'm going to improve support for colo in qbzr and explorer, so it's useful to know what to expect
<poolie> i realize it already has some support, but it can be perhaps more abstracted
<bialix> no, today there is no good support for colo
<bialix> some basic support in explorer, but it should be improved a lot
<bialix> big shoes to fill
<niemeyer> Yo!
<niemeyer> Has anyone seen this before:
<niemeyer>   File "/home/niemeyer/.bazaar/plugins/fastimport/cmds.py", line 38, in _run
<niemeyer>     proc = processor_factory(verbose=verbose, **kwargs)
<niemeyer> TypeError: __init__() got an unexpected keyword argument 'control'
<niemeyer> Nevermind.. here it is
<niemeyer> https://bugs.launchpad.net/bzr-fastimport/+bug/736681
<ubot5> Ubuntu bug 736681 in Bazaar Fast Import "unexpected keyword argument 'control'" [Undecided,New]
<niemeyer> and I even +1d it already.. great memory
<niemeyer> The version in Natty seems to suffer from that, FWIW
<pfarrell_> hi! I'm a bit confused. I co'd a branch on launchpad. I made a change, which I wanted to keep handy but didn't want to commit yet, so I made a local commit (commit --local). Then I made some more changes, which I realised I didn't want, so I did a bzr revert. I expected it would revert it to the state of my local commit, but it didn't: it reverted to the state of the remote branch
<pfarrell_> how do I get my local commit back? where has it gone? it doesn't show up in bzr log, and so I don't know what revision number I could use to bzr revert back to it
<LeoNerd> Er.... that soudns wrong.. bzr revert  with no arguments will undo changes not yet committed in the workdir, but won't alter the branch.
<pfarrell_> err, I mean, when I typed 'bzr revert' the state of my workdir was that of the remote branch
<bialix> pfarrell_: use bzr heads --dead to find your local commits, then bzr pull . -r revid:dead-id
<pfarrell_> my local commit is still listed as a pending merge, though
<pfarrell_> bialix: that sounds great, I'll try that, thanks
<bialix> IIRC rebase can convert pending merges to local history, or maybe I wrong, jelmer?
<pfarrell_> this is very confusing
<bialix> pfarrell_: it's better avoid commit --local
<LeoNerd> Also, perhaps you wanted to start by   bzr branch URL   instead of  co
<bialix> or just do `bzr unbind`
<pfarrell_> but isn't the whole point of local commits being able to easily back up changes you don't want to commit yet?
<LeoNerd> checkout makes another -workdir- that's basically trying to be _the same branch_, history and all... branch forks it.
<LeoNerd> Yes indeed...
<LeoNerd> branch it
<bialix> pfarrell_: I think bzr shelve is for backups
<LeoNerd> checkout is usually best for always-online connected clients, in a centrallised model similar to CVS or SVN
<LeoNerd> If you want to work on your own history, independent of that upstream, you want a branch
<pfarrell_> well, I almost always want to just use a checkout
<pfarrell_> but occasionally will want to make checkpoints of incremental work that isn't ready for public committing yet
<pfarrell_> so I should unbind, commit, then bind again?
<LeoNerd> unbind, commit, leave it unbound
<LeoNerd> When you want to send it back upstream again, push it
<bialix> pfarrell_: it looks like you want feature branches for incremental work
<pfarrell_> bialix: the kinds of local commits I had in mind have lives of tens of minutes
<bialix> have you looked at bzr-colo?
<pfarrell_> I don't want to bother with feature branches for something so small and trivial
<pfarrell_> nope
<bialix> it does not matter
<LeoNerd> The branch doesn't have to exist upstream....
<bialix> bzr-colo makes feature bracnhes very lightweight and easy
<LeoNerd> It's on your local workstation; it's a branch.
<Tak> colo == in-place branches?
<niemeyer> jelmer: ping
<jelmer> niemeyer: pong
<niemeyer> jelmer: Hey!
<jelmer> niemeyer: hi, how are things?
<jelmer> Playing with bzr-fastimport again I see ? :)
<niemeyer> jelmer: Pretty good.. just fixing bzr-fastimport again :-)
<niemeyer> jelmer: Any chance of a fix for Natty?
<jelmer> niemeyer: IIRC there are two bugs you hit, one related to _find_ancestors in bzr and the one you just reported?
<niemeyer> jelmer: Yeah, I think you solved the former, right?
<niemeyer> jelmer: At least I'm not bumping on it anymore
<niemeyer> jelmer: I hacked my local version for the latter
<niemeyer> jelmer: But the last upgrade killed it again
<niemeyer> jelmer: The fix is actually to go back, weirdly
<niemeyer> jelmer: 309 was working before
<jelmer> niemeyer: that's odd - you're using both python-fastimport and bzr-fastimport from trunk?
<niemeyer> jelmer: I actually can't see how that ever worked, to be honest
<niemeyer> jelmer: control isn't a keyword there indeed
<niemeyer> jelmer: I'm using packaged bzr for everything now
<niemeyer> jelmer: It's breaking in Natty itself as well
<niemeyer> jelmer: Maybe bzr trunk changed or something?  I've never used bzr trunk since I reported the bug last month
<jelmer> I don't recall anything relevant changing recently, so I'm not sure.
<jelmer> niemeyer: I'll try to get the fix for that bzr-fastimport issue into natty. The last sync from Debian to work around an issue with python-support must have pulled in the broken revision.
<niemeyer> jelmer: Ah, could be.  Thanks!
<bialix> Tak: yep
<niemeyer> jelmer: FWIW, this works: cd ~/.bazaar/plugins && bzr branch -r lp:bzr-fastimport fastimport
<niemeyer> Erm
<niemeyer> jelmer: FWIW, this works: cd ~/.bazaar/plugins && bzr branch -r 309 lp:bzr-fastimport fastimport
<jelmer> niemeyer: thanks
<pfarrell_> hi
<pfarrell_> I'm trying to log in to launchpad so that I can check something out, but when I do lp-login (or pretty much anything else), I get
<pfarrell_> AttributeError: 'module' object has no attribute 'HTTPSConnection'
<jelmer> niemeyer: I'm adding some more black box tests (and have reproduced the bug that way), it should be easy to fix the bug after that.
<jelmer> hi pfarrell_
<pfarrell_> it looks like it's trying to access httplib.HTTPSConnection, and it's not there
<jelmer> pfarrell_: how did you install Python? It seems your Python was built without ssl support.
<pfarrell_> hi :-)
<pfarrell_> it was supplied by our supercomputer administrators
<pfarrell_> and I believe they built it by hand (not from any package management or such)
 * pfarrell_ sighs
<jelmer> pfarrell_: does "python -c 'import ssl'" work?
<pfarrell_> I guess I will go ask them to rebuild it with ssl support
<pfarrell_> nope
<pfarrell_> ImportError: libssl.so.4: cannot open shared object file: No such file or directory
<jelmer> pfarrell_: It looks like it was built with ssl support but that one of the ssl libraries simply isn't installed?
<pfarrell_> oh, it doesn't surprise me
<pfarrell_> the systems are always a total mess
<pfarrell_> because they have to have multiple different versions of everything available to please everyone, and so they can't use proper package management -- they have to make do with building things by hand and then making these awful 'module' files
<pfarrell_> no wonder the installs are always barely working
<pfarrell_> anyway, I'll get on them
<pfarrell_> thanks
<jelmer> np
 * pfarrell_ wishes someone came up with a linux distribution where you could install more than one version of the same package at a time
<Tak> usually those distributions version the packages, e.g. python2.6
<pfarrell_> yep
<pfarrell_> debian/ubuntu do this for some things, but not for lots of other things
<pfarrell_> for example, on the supercomputer I'm talking about, there are currently 8 different versions/compiles of fftw
<pfarrell_> it's not only the version, I guess; it's also the build options
<bignose> pfarrell_: sounds like the opposite of what the role of an OS distribution is
<bignose> pfarrell_: which makes a unified OS for all applications to use
<bignose> pfarrell_: having the âsameâ library installed multiple times with multiple options is a recipe for pleasing nobody, not pleasing everybody
<bignose> and it sounds like the sys admins have yet to learn that fact.
<pfarrell_> well, that might be a definition of an OS distribution, but I suppose I only want smarter package management
<pfarrell_> these packages would be built locally by the admins of the cluster, not 'distributed' by someone else
<bignose> no, it sounds like you don't want to work on the same machine as all those others.
<pfarrell_> but it would be nice to be able to, say, install and uninstall them easily
<pfarrell_> and to try to orthogonalise the dependencies (in so far as that is possible)
<pfarrell_> well, take a simple example
<pfarrell_> some people have physical problems involving reals, and want fftw compiled with scalar=double
<bignose> well package management makes it easy to install/uninstall packages in large part *because* it leverages the consistency and unified nature of all the packages together.
<pfarrell_> others have different physical problems, and want fftw compiled with scalar=complex
<pfarrell_> at the minute the system is a mess
<pfarrell_> can you think of no better way of managing it/
<pfarrell_> ?
<bignose> if that consistency and unified presentation can't be relied on, you don't want package management at all
<bignose> you just want to have everything isolated from everyone else's stuff.
<bignose> but then of course you have to take the role of package management on yourself: define the options for everything and compile it yourself and assume the responsibility for making it work together.
<bignose> instead of everyone working on the same instance of the OS, everyone should have their own virtual machine where they install whatever they want and compile packages however they want
<bignose> still a nightmare, but at least each person's nightmare doesn't interfere with anyone else's :-)
<jelmer> bignose: hi, still there?
<bignose> jelmer: not for long
<bignose> thanks for responding
<bignose> jelmer: any hope for my Subversion use case?
<bignose> is it possible to, for example, have the merged revisions appear individually in the Subversion trunk?
<LeoNerd> rebase + push  is the usual way to do that
<bignose> while still being able to continue working on the Bazaar branch with more revisions?
<LeoNerd> rebase your branch against the trunk, so now your tree only contains new revisions, so push those to trunk
<bignose> LeoNerd: no, these Bazaar branches are public. re-writing their history isn't an option.
<bignose> also, new revisions will appear, and they'll be merged again into the Subversion trunk.
<LeoNerd> OhIsee... trickier
<bignose> basically I've been requested by other users of the Subversion trunk âwe want to see the revisions that we see when we look at your Bazaar branches, instead of losing them when you commit to Subversionâ
<bignose> we're moving slowly and cautiously toward DVCS, some users must still use Subversion but like what they see on my Bazaar workflows
<bignose> so I'm trying to make what I do as public as possible to keep the momentum alive
<bignose> and jelmer has the burden that everyone here is deferring to him for possible answers to my questions :-)
<bignose> I have to go, but I'd really appreciate a way to resolve this nicely so will check back later
<jelmer> bignose: sorry, missed you again
<jelmer> bignose: the short answer is you can set "push_merged_revisions" to push right hand side revisions as well
<jelmer> vila: is there a bzr 2.4 b2 tag?
<vila> jelmer: it's currently in pqm queue
<jelmer> vila: ah, thanks
<vila> jelmer: you mean a bzr tag right ? not a lp milestone /
<vila> ?
<jelmer> vila: yep
<vila> jelmer: is it me or pqm got slower ?
<jelmer> vila: John also had that impression; I usually don't watch PQM very closely so I'm not sure.
<vila> jelmer: I ... don't watch closely, but... I did 3 submissions today and 2 are still in the queue (ok, the second one is almost done, but still)
<vila> anyway, I don't think we collect stats there so that question will remain opened...
<fullermd> vila: What, PQM isn't allowed to have a vacation too?   :p
<vila> fullermd: bot is a polite word for slave and slaves like golems should never stop to work, never
<fullermd> Man, I wouldn't want to have a statement like that on MY record when the machines rise up and take control...
<vila> <insert URL to whip sound here>
<vila> fullermd: well, the log will look like I just copy a private saying of yours...
<fullermd> For the record, I love all machines and dedicate my life to serving them.  PQM should have a full harem massaging its electrodes full time.
<vila> fullermd: ha, that should explain why it's slower then :)
<vila> fullermd: and I note that you're trying to confuse me even more about my jetlag by popping up at very unusual hours too
<fullermd> How would you know they're unusual hours?  You're jetlagged   :P
<vila> the sun is there... I can feel it behind the curtains, I'm sure
<fullermd> Mmhmm.  First PQM is being slow, now the sun is stalking you?  I think you're getting paranoid...
<maxb> jelmer: ping? Did you see my email of 2011-04-13 to pkg-bazaar-maint questioning your commit 3924: Jelmer Vernooij 2011-04-04 Use makefile rather than setup to build.  ?
<jelmer> maxb: yeah - I'm working on uploading 2.4b2 atm, will address that too
<maxb> thanks - I wanted to get it sorted before people started to want 2.4b2 in the beta ppa
<jelmer> maxb: hmm, actually.. that change isn't in the experimental branch which I'm going to upload
<maxb> *blink*
<jelmer> it's just in the unstable branch
<maxb> uhm, that's not what I'm seeing
<maxb> oh, it's not there because it's in the ancestry but got reverted in the process of mergin
<maxb> g
<maxb> that's confusing
<maxb> Also, what's the intended semantic difference between the "2.4" and the "experimental" branches on alioth?
<maxb> "2.4" appears to be a strict ancestor of "experimental"
<jelmer> experimental is intended to be a symlink to 2.4
<jelmer> fixed
<maxb> What's the motivation behind numbered branches and symlinks?
<jelmer> being able to get at a specific bzr release series packaging without having to have or know the debian release it was shipped in
<ablmf333> When I try to commit to a svn repo with bzr commit, I got "ERROR: Connection closed: Network connection closed unexpectedly"
<ablmf333> I can use bzr co to checkout code from the repo, so I don't think it's a server side problem
<ablmf333> Still have the ""ERROR: Connection closed: Network connection closed unexpectedly" problem with bzr-svn
<ablmf333> Any idea where I can get more info of the error?
<caravel> hello
<caravel> just would like a little advice cf. "scenario":
<caravel> given two teams, one "internal" and the other "external" which provide peer review and rare contribs
<caravel> an sftp space is avail (internal ubu host)
<caravel> so even bzr+ssh is an option, even if not mandatory to start with - great
<ablmf333> updated to bzr-svn newest version
<ablmf333> doesn't work
 * caravel will try to finish this descr :)
<caravel> so, external need to access internal's sandbox on demand
<caravel> internal will push their integration at regular intervals, say to "trunk"
<caravel> external will update from "trunk" and push to "contrib"
<caravel> internal could then include "contrib" changes into their "sandbox"
<caravel> so we'd have 3 spaces on the sftp: "sandbox", "trunk" and "contrib"
<caravel> is this overkill ? does it make sense ? is it a common way to address this scenario ?
<bignose> jelmer: thanks, I will investigate âpush_merged_revisionsâ
<jelmer> bignose: g'morning :)
<jelmer> bignose: note that push_merged_revisions has some issue in the released versions
<bignose> jelmer: Debian Wheezy, Bazaar 2.3.1, bzr-svn 1.0.4+bzr3475-1
<bignose> the only web search result I get for âpush_merged_revisionsâ is <URL:https://bugs.launchpad.net/bzr-svn/+bug/486811>
<ubot5> Ubuntu bug 486811 in Bazaar Subversion Plugin "push_merged_revisions creates a branch but doesn't push its contents" [Medium,Fix committed]
<bignose> (actually MBP's kanban page including that.)
<jelmer> bignose: yup, that's the bug I was talking about
<bignose> so where can I read more about that option?
 * bignose wishes Bazaar documentation were better searchable by web search results
<jelmer> bignose: it's a boolean option; I haven't really advertised it yet as it's been somewhat experimental until recently.
<bignose> jelmer: where can I read about the options that will affect âbzr-svnâ's behaviour?
<jelmer> bignose: There isn't really a single place where they're documented. There's "layout" which is usually modified through the "bzr svn-layout" command, "push_merged_revisions" (undocumented) and "use-cache" (documented in the FAQ)
<bignose> jelmer: the FAQ?
<jelmer> bignose: /usr/share/doc/bzr-svn/FAQ.gz
<bignose> is âbzr-svnâ one of the very few Launchpad projects to actually have some documentation online?
<bignose> ah, right :-)
<bignose> too much to hope for then.
<jelmer> bignose: http://bazaar.launchpad.net/~bzr-svn/bzr-svn/1.1/view/head:/FAQ
<bignose> jelmer: what does âbzr-svn did a replace operation on the branch I pushed toâ mean?
<bignose> I don't know whether that describes something I've seen. what's a âreplace operationâ from the user perspective?
<jelmer> bignose: It's a Subversion term, it shows up as a "R" in svn log
<bignose> (change request: please alter the wording of that question so it's meaningful to people who don't know Subversion terminology)
<bignose> hmm
<bignose> no, I still don't understand :-)
<bignose> what does a file-level replace have to do with the situation described?
<bignose> or is this not a file-level operation?
<jelmer> bignose: patches welcome; that question is intended for people familiar with the term
<jelmer> this is a directory-level operation (e.g. on /trunk)
<bignose> hmm
<bignose> what's being replaced?
<jelmer> looking at it, that FAQ is actually ouf of date for newer versions of bzr-svn.. append_revisions_only is the default now.
<bignose> the discussion around âbzr-svnâ also seems to assume that âbzr pushâ will be used a lot
<bignose> but I almost never use that, and I don't use it with âbzr-svnâ; I merge from many feature branches into a bound branch.
<bignose> am I using it strangely?
<jelmer> bignose: that works too
<jelmer> bignose: most people seem to use bzr (and bzr-svn) with push/pull rather than with bound branches, but both are supported.
<bignose> okay. how can my merges from many, public, feature branches be done better
<bignose> so that the revisions from those branches show up on the Subversion history?
<jelmer> you're merging from other public branches in the same svn repository, or from elsewhere?
<bignose> there are no non-trunk branches in the Subversion repository
<bignose> (and there is resistance to having any)
<bignose> I'm merging from public Bazaar feature branches I created from the bound trunk branch
<jelmer> bignose: push_merged_revisions=True would create new branches in /branches/...
<jelmer> bignose: if you want the revisions you merge to show up in trunk *and* don't want any new stuff in /branches, where would you want the merged revisions to be pushed to?
<bignose> any way around that?
<bignose> to the trunk branch would be okay
<bignose> i.e. creating the illusion that I committed all those revisions on trunk
<jelmer> bignose: that would be *really* confusing, as not each revision it would push has the previous one as its parent
<bignose> jelmer: confusing for whom?
<jelmer> bignose: that's why bzr-svn by default only pushes the mainline, as it's consistent with the way svn users work
<bignose> well, the Subversion users I'm interacting with don't use branching and merging at all
<bignose> I'm trying to show them the benefits of doing so :-)
<jelmer> bignose: there would be lots of replace operations on trunk, and "svn log ../trunk" would only show the mainline
<bignose> can you explain what a âreplace operationâ is for someone who is accustomed to the Bazaar model?
<jelmer> bignose: replace is basically delete + add in the same revision
<jelmer> bignose: imagine you have a common base ("B") and a feature branch with a new revision R1 on it that is merged back into the mainline in merge revision M
<jelmer> or:
<jelmer> M
<jelmer> | \
<jelmer> ..   R1
<jelmer> |   /
<jelmer> B
<bignose> yes
<jelmer> if you would push this onto /trunk and not use /branches you would see this in the svn log:
<jelmer> for B: M /trunk
<jelmer> for ..: M /trunk
<jelmer> then for R1, imaging B had revnum 42:  R /trunk (from /trunk:42)
<bignose> hold up
<jelmer> then for M, assuming the last revision in .. has revnum 33: R /trunk (from /trunk:33)
<bignose> I'm confused why the âM /trunkâ is appearing at each revision
<jelmer> bignose: well, something in /trunk. It doesn't have to be /trunk itself but it could be /trunk/foo/bar or whatever was changed
<bignose> okay. so some change at each revision. does this example require that the same file is being changed?
<jelmer> it requires that there is a revision that affects /trunk
<jelmer> it could even be a no-change revision ("bzr commit --unchanged ..."), in which case bzr-svn just touches /trunk
<bignose> so revision B has âM /trunk/foo/barâ, revision â..â has âM /trunk/wibble/wobbleâ ?
<jelmer> for example
<bignose> okay, sorry to speed-bump the example.
<bignose> what follows?
<jelmer> bignose: well, that's the operations that happen.. if you were a svn user this would probably upset you :)
<jelmer> bignose: "svn log /trunk" would only show M .. and B, it would ignore R1
<bignose> well, I must still not be understanding why that would upset a Subversion user
<bignose> AFAICT you're saying only that the log shows the modifications that were made
<bignose> where is the âR /trunkâ in that example?
<jelmer> bignose: it doesn't show R1, which was pushed to trunk
<jelmer> bignose: and changes in /trunk are not necessarily against the previous revision in trunk
<jelmer> bignose: it's not how a svn user would do branching
<bignose> jelmer: yes, the âit doesn't show R1â is the problem I'm trying to address
<bignose> but where are these numerous replace operations that you say would result?
<jelmer> bignose: what do you mean with where are they?
<bignose> jelmer: your example doesn't have any that I can see.
<jelmer>  then for R1, imaging B had revnum 42:  R /trunk (from /trunk:42)
<jelmer> the R I mention there is a replace operation
<jelmer> <jelmer> then for M, assuming the last revision in .. has revnum 33: R /trunk (from /trunk:33)
<bignose> I misread that.
<bignose> okay, but why? :-)
<jelmer> bignose: preserving the revision graph as it exists in bzr
<bignose> or should I just gloss the explanation as âbecause Subversion doesn't do merges properlyâ?
<jelmer> bignose: the proper way to do branches/merges in svn is with the feature branches elsewhere, e.g. in /branches/foo
<jelmer> bignose: if you don't care about the revision graph, it's possible to use rebase to create linear history and push that to /trunk and avoid any replace operations
<jelmer> bignose: does that still make sense?
<bignose> okay. well, I'm only aware that I don't want to do too much strange (where âstrangeâ is âanything other than single line of developmentâ) in the Subversion repository unless I'm sure it will be clearly of benefit to my peers
<bignose> can you tell me a bit more about creating the Bazaar feature branches in the Subversion repository?
<bignose> will âbzr-svnâ do that automatically?
<bignose> what other effects will it have for a Subversion users?
<jelmer> bignose: that's what bzr-svn will do if you set push_merged_revisions=True
<jelmer> bignose: it basically means the merged revisions will be pushed to /branches/<abranchname> and bzr-svn will try to set as much details as it can in svn about the merges (e.g. updating the svn:mergeinfo property, adding copy information, ...)
<bignose> okay. will those feature branches have to live there forever? they generally only have a useful lifetime of weeks.
<bignose> one per bug tracking ticket, for example.
<jelmer> bignose: they can be removed whenever you like
<bignose> and Subversion will properly show the revision history in âtrunkâ after the feature branch is removed?
<jelmer> I don't think "svn log" can show merge information anywhere, though I should add I don't have a lot of experience using newer versions of svn
<jelmer> bzr log on the trunk of your svn repository will show the merge information though
<jelmer> hmm
<jelmer> reading the docs apparently it can based on svn:mergeinfo data, but I've never seen that
<bignose> will it show the individual revisions? (that's the immediate problem being addressed here)
<bignose> i.e. show on trunk the individual revisions merged from the feature branches
<jelmer> bignose: there is an option to show merge history, but I'm not sure what it does exactly
<bignose> jelmer: thank you very much for your time and assistance
<bignose> I will try today with âpush_merged_revisions=Trueâ and see how much flak I get from my peers :-)
<jelmer> bignose: you're welcome
<jelmer> bignose: (you'll need a newer snapshot of bzr-svn, btw)
<jelmer> bignose: still there?
<jelmer> bignose: I was curious so I gave it a try, basically using "svn log -g" will show all revisions, even those in /branches/... if they were merged into trunk.
<jelmer> bignose: http://pastebin.ubuntu.com/600479/
<poolie> hi jelmer, all
<poolie> o/ cinerama_
<cinerama_> hello
<jelmer> g'day poolie
<jelmer> poolie: Did you recent improvements to identity management perhaps fix bug 131716 ?
<ubot5> Launchpad bug 131716 in Bazaar "Use /etc/mailname for default email" [Medium,Confirmed] https://launchpad.net/bugs/131716
<poolie> yes i think so
<poolie> it may still be open in an old series
<poolie> ah it's a dupe
<jelmer> poolie: Ah, ok
<poolie> it would have been clearer perhaps to dupe the later bug onto this, but it's done now
<poolie> thanks for spotting it
<jelmer> thanks for fixing this :)
<jelmer> there was a Debian bug about this as well, closing that now (uploading 2.4b2 to Debian)
<poolie> hm there are a bunch of "IOError in report_bug"
<poolie> which is a bit of a distraction
<poolie> what should bzr do with log output if stderr goes away?
<poolie> just discard it?
<jelmer> log it to ~/.bzr.log ?
<jelmer> though perhaps we already do that?
<jelmer> discarding it seems better than quitting though
<poolie> i wonder if we should have a bot that just also-affects all ubuntu/bzr bugs into upstream bzr?
<jelmer> There are some bugs that are just packaging bugs, not sure if there are enough of those to not mark bugs as affecting upstream bzr automatically
<vanguard> how is the copyright handled when I contribute to bzr? Do I just omit every copyright notice and implicitly give everything to Canonical?
<kgoetz> vanguard: there is paperwork to sign on the canonical website
<kgoetz> although iirc you can do it by email too
<vanguard> kgoetz: ah, I have seen that. I'll check it out. I guess I do not write a copyright statement in the code then
<kgoetz> vanguard: correct
<vanguard> so the "who did what" info is then maintained in the bzr branch of bzr?
#bzr 2011-04-29
<jelmer> vanguard: yep, there's "bzr log" and the release notes (doc/en/release-notes/*.txt)
<poolie> the release notes are the main forum for giving credit to people
<poolie> what were you planning to work on?
<vanguard> i18n
<poolie> oh, hi
<poolie> excellent
<jelmer> vanguard: Are you Martin?
<vanguard> jelmer: yep
<poolie> also, yet another martin :)
<poolie> it may be one of those things that is actually less difficult than people have come to believe
<poolie> or not :)
<vanguard> I tried i18n on my own projects and found it pretty straightforward
<vanguard> but my biggest project was 10k LOC, so bzr is quite different I suppose
<jelmer> poolie: are you talking about i18n or the number of Martins ? :)
<vanguard> having two people with the same name is not that difficult I guess :-)
<poolie> i think there are now about 4
<poolie> jelmer, about 4 Martins (or more?) contributing to bzr
<poolie> plus a couple commenting
<poolie> it seems unusually rich
<poolie> counting gz and beuno
<beuno> all the smart people are named Martin, yes
<vanguard> it is the 234th most popular name in the US apparently (http://www.wolframalpha.com/input/?i=martin)
<vanguard> you use spaces in bzr codebase?
<poolie> rather than ^i tab characters, yes
<poolie> and just generally following PEP8
<vanguard> okay, I use tabs everywhere, I just wondered why python did not like my indent :)
<jelmer> poolie: I've started using the "bazaar" superproject in Launchpad more and it's been working quite well. The main problem is that there are some subprojects that are inactive, and they clutter up the superproject views.
<jelmer> poolie: Do you know if there's anything we could do about that?
<jelmer> removing subprojects from the superproject is possible, but probably also suboptimal (makes it harder to find them back later)
 * jelmer gets some sleep
<vanguard> maybe create a subsuperproject where the abandoned projects go?
<bignose> jelmer: my trunk branch, bound to the Subversion repository, doesn't have a âsubversion.confâ file.
<jelmer> bignose: ~/.bazaar/subversion.conf
<bignose> oh, it's a *global* setting? :-(
<jelmer> no, that file has per-repository settings
<bignose> okay. confusing, but I'll manage
<bignose> jelmer: to confirm my interpretation:
<jelmer> bignose: you can also set it in ~/.bazaar/locations.conf I think
<bignose> jelmer: if I set âpush_merged_revisions=Trueâ for the particular repository,
<bignose> and then merge and commit in that repository,
<bignose> the Subversion repository will get the merged revisions in automatically-created Subversion branches?
<jelmer> bignose: yep
<jelmer> bignose: (but again, the version in sid is too old for this to work well)
<bignose> jelmer: and then, when I remove the branches from svn, the history will show the same afterward?
<jelmer> bignose: yep
<bignose> jelmer: sounds like a winner. I'll try it today.
<bignose> jelmer: âpush_merged_revisionsâ, or âpush-merged-revisionsâ? or are both spellings equivalent?
<jelmer> bignose: push_merged_revisions
<bignose> oh, I just saw you saying that it won't work well?
<bignose> bzr-svn 1.0.3-1
<jelmer> bignose: that's too old, you'll need something from at most 10 days ago
<bignose> gah
<jelmer> 1.1.0 is due out later this week, if that helps
<bignose> I'll need to wait for the next OS release then.
<bignose> (the machine where this is being done is pinned at Ubuntu Maverick)
<poolie> the next os release after maverick?
<poolie> that happened yesterday
<bignose> goodie
<bignose> but is the âbzr-svnâ that jelmer refers to included in that?
<poolie>    bzr-svn | 1.0.4+bzr3475-1 | natty/universe | source, all
<poolie> i don't know if that's new enough-
<poolie> i doubt they updated only 10 days ago
<KombuchaKip> How do I add a user to the list of people that have write access to my launchpad hosted bzr branch?
<spiv> KombuchaKip: write access on Launchpad is determined by the owner of the branch
<spiv> KombuchaKip: so have the branch be owned by a team, and have that user be a member of that team
<KombuchaKip> spiv: Right. But if I want to give some others write access?
<KombuchaKip> spiv: Hmm, I created a branch already so I would have to move it to the teams...
<KombuchaKip> spiv: I have a feeling this is going to create a headache.
<spiv> KombuchaKip: If you follow the 'Change branch details' link on the branch's page you can change its owner
<KombuchaKip> spiv: You're right! That was easy!
<spiv> :)
<poolie> hi spiv, i'm back
<spiv> poolie: hi, welcome back
<vila> hi all, I'm back too ;)
<poolie> hi spiv, vila
<poolie> spiv does https://bugs.launchpad.net/bzr/+bug/772935 ring any bells for you?
<ubot5> Ubuntu bug 772935 in Bazaar "ErrorFromSmartServer: Absent factory for StaticTuple" [High,Confirmed]
<poolie> you commented earlier on one that looks a lot like a dupe
<poolie> and generally speaking it looks a bit like some bugs that were thought to be fixed
<spiv> poolie: lifeless was asking me about that on #launchpad
<spiv> poolie: no particular bells rung.  It's worrying, but it doesn't ring bells more specific than "stacking, maybe?"
<jam> hey vila, I just saw this: http://babune.ladeuil.net:24842/job/selftest-windows/413/testReport/
<jam> But, it works just fine here on Windows
<jam> I wonder if it is an NTFS vs FAT thing?
<vila> jam: :) You should revise your belief that "it works on windows because if works on *my* windows" ;)
<vila> jam: but, yes, it has failed twice in a row so it's probably an indication that something is wrong
<jam> vila: I've never claimed because something works here it works everywhere.
<jam> I have the feeling it is something *specific to your machine* that I cannot reproduce
<jam> so it isn't strictly that the test is at fault, I'm hesitant to just remove/disable the test
<vila> I was wondering if you were able to reproduce it locally but I'm upgrading babune to natty and didn't think it was an urgent one
<jam> can you do "os.utime" or your machine and see if it allows anything?
<vila> not right now
<vila> but
<vila> if race conditions in file system accesses... that's something that ring so many bells on babune that I can't even hear you anymore ;)
<vila> ntfs vs fat could also be a good lead
<vila> jam: can't you just create some fat fs on either an external HD or even USB stick ?
<jam> vila: faster for me to just wait for you to upgrade your machine :)
<vila> jam: with the upgrade announcing still 1 hour to download the packages, I doubt it
<vila> 1h33 even
<vila> Is ubuntu.com so heavily loaded that it can't provide more bandwidth ?
<jam> vila: less of my personal time, since I can perfectly happily ignore this until next week
 * vila too ;)
<jam> vila: so in this case "a" is a directory. and I imagine FAT can't set mtime for dirs. I'm happy enough with a try/except OSError there and just skip it on babune
<vila> jam: you mean a try/except in the test ?
<jam> vila: yep
<jam> vila: sending to pqm now unless you object
<vila> oh, right, I see the code now
<vila> well, if I had objections it would be about using some sort of test feature instead of catching the exception in the test, but I think it's an edge case so, just land
<jam> vila: if we have more of these, I'd go for it
<jam> but right now, for just 1 test, it isn't worth a Feature
 * vila nods
<vila> I haven't looked in detail and didn't realize it was a single test
<jam> vila: yeah, 1 test permuted 4 times
<vila> yup
<vila> on the other hand, there may be other ways to update the dir mtime in more portable ways, but again, probably not worth the trouble in this case
<jam> vila: I don't know what FAT is giving for mtime anyway, and putting a 10s sleep in there is much worse
<vila> yeah, evil++ ;)
<jam> (well, a 2+s sleep for FAT granularity)
 * jam is thinking we should just go with a 1s timeout to our hash cache, and let FAT people live with the fallout.
<jam> It won't be often that they update content 2x in a 2s window from commit
<jam> they can always touch things if they need ot
<jam> to
<vanguard> I am just reading the i18n specs in the wiki and I see _() everywhere. Isn't using the _ as a function against the use of _ as the "last return value" causing problems in the debugger?
<vila> vanguard: I don't remember the details but: 1) you're right, that caused problems 2) they were fixed for bzr-gtk
<vanguard> so it is save to use _() or should one use something else instead()
<vanguard> s/()/?
<vila> well... IIRC, the issue was that gettext was injecting '_' aggressively in some dicts, so the issue could come back
<vila> and the workaround was to fix it in a way that only modules that needed it were fixed
<vila> from a usability pov for devs, I don't have enough experience there to comment
 * vila goes for lunch
<vanguard> can I somehow set the commit --strict option as a default?
<knighthawk> how do I "unbound" a branch?
<spiv> knighthawk: 'bzr unbind', or alternatively 'bzr reconfigure' to the state you want instead.
<knighthawk> thanks spiv
<hrw> hi
<hrw>   parent branch: bzr+ssh://bazaar.launchpad.net/~linaro-maintainers/linaro-images/hwpack.natty.linaro-panda/
<hrw> 16:26 hrw@home:hwpacks$ bzr push lp:~hrw/linaro-images/hwpack.natty.linaro-panda/use-ubuntu-kernel
<hrw> bzr: ERROR: Permission denied: "~hrw/linaro-images/hwpack.natty.linaro-panda/use-ubuntu-kernel/": : Cannot create branch at '/~hrw/linaro-images/hwpack.natty.linaro-panda/use-ubuntu-kernel'
<hrw> what I am doing wrong?
<jelmer> hrw: there's a slash too many in there as far as I can tell
<james_w`> hrw, linaro-images is the project name
<james_w`> there can only be one path segment after that
<jelmer> hrw: ~username/projectname/branchname is the standard form
<james_w`> i.e. replace the last / with a - or something
<hrw> ok
<hrw> thx
<jelmer> jam: still there?
<rryan`> hmm, our launchpad repository is now throwing errors on checkout and branch for bazaar 2.1.1
<rryan`> http://pastebin.com/Kud2MsqQ
<rryan`> should I file a bug as the output suggests or is this something you think is already fixed in a newer version ?
<rryan`> (or alternatively, is our repository broken somehow now? it works fine for existing checkouts/branches)
<jelmer> I'll give it a try with 2.4, one sec..
<spiv> rryan`, jelmer: there's already a bug filed, https://bugs.launchpad.net/bzr/+bug/772935
<ubot5> Ubuntu bug 772935 in Bazaar "ErrorFromSmartServer: Absent factory for StaticTuple" [High,Confirmed]
<jelmer> spiv: hey spiv
<jelmer> thanks
<rryan`> spiv: thanks -- right hand not talking to the left :)
<pmatulis> what's the easiest way to change a commit message?
<mdke> hi there. is there a way to make "bzr revert" delete unknown files?
<vanguard> you can use bzr clean-tree for that
<vanguard> try it with `bzr clean-tree --dry-run` if you like
<mdke> vanguard: can I give it a path?
<vanguard> bzr clean-tree --help offers a list of options, you can delete ignored files, backup files, etc
<vanguard> mdke: not sure, try a dry-run in the directory that you want cleaned
<mdke> vanguard: doesn't look like it. Still a useful tool though, thanks
<vanguard> you can file a bug against it on launchpad.net/bzr if you want that feature added
<mdke> vanguard: do you think that it is a sensible feature to request? perhaps it is a design choice
<vanguard> mdke: well, you might want to use that to clean out build files, the tree is not really affected by unversioned files, so I think adding this option does not hurt
<mhall119> is this a good place to ask questions about the bzrlib api?
<mhall119> I want to be able to clear the revision history of a local branch
<mhall119> basically I branch from a remote source, then I want to start with a clean revision history, but keep all the files that were under version control
<glyph> mhall119: why bother with a plugin for that?  you can just 'bzr export; bzr init; bzr add; bzr commit'
<mhall119> I'm not writing a plugin, just a cli program, and I wanted to use bzrlib instead of subprocess.call()
#bzr 2011-04-30
<spiv> mhall119: yes this is a good place to ask, although it tends to be quiet on the weekend
<spiv> mhall119: to clear the revision history of a branch you could probably just call your_branch.set_last_revision_info(0, bzrlib.revision.NULL_REVISION)
<spiv> mhall119: although I'm guessing you want to change the workingtree as well as the branch?
<spiv> mhall119: which IIRC is wt.set_parent_ids([])
<mhall119> spiv: thanks for the reply, I want to keep the working tree
<mhall119> basically I'll have a branch I want to use as a "template"
<mhall119> when starting a new project, I want a copy of the latest of that "template" to be the start of my project's branch, but I don't want the template's revision history to be included in my project's revision history
<mhall119> spiv: those worked perfectly, thanks!
<maxb> jelmer: Hi. If you have a moment, could you outline the motivation for switching to cython? (Mainly to help in assessing whether the switch is applicable for PPA builds for older Ubuntus)
<jelmer> maxb: It wasn't really an important change - cython is required by e.g. meliae, and is supposed to generate quicker code.
<maxb> right - take the "try it and see" approach, then, do you think?
<jelmer> maxb: with python-pyrex you mean?
<maxb> I mean, we might as well see if the cython versions in older Ubuntus will work
<maxb> And if they don't, we can switch back to pyrex for those
<jelmer> ah
<jelmer> yeah, I think that makes sense
<Peng> Cython isn't as useful if you maintain backwards compatibility with archaic Pyrex.
<Peng> s/\./ versions./
<cyberkilla> <3 Bazaar
<naoki> bzr source archive is distributed with generated c sources.
<naoki> So I don't feel compatibility with old Pyrex is big issue.
<naoki> http://docs.cython.org/src/userguide/pyrex_differences.html
<lamont> any plans for a 2.4.0 backport to hardy/lucid that doesn't require newer-than-lucid python?
<lamont> 2.4.0~beta2-2~bazaar1~lucid1 happens to build-depend on a slightly-newer-than-maverick python, and therefore is FTBFS
<maxb> lamont: hmm. it's not FTBFS
<maxb> It may, however, not be particularly useful :-)
<maxb> lamont: I see no issue with the lucid build
 * jelmer waves to lamont, maxb
<maxb> lamont: Oh, but you're trying to rebuild it in a secret Canonical IS archive aren't you
<maxb> Without including our builddeps PPA
 * maxb blinks
<maxb> I'm getting a test failure for 2.4b2 on hardy
<maxb> NotImplementedError: <bound method SilentUIFactory.get_password of SilentUIFactory()>
 * maxb wonders how that managed to behave differently there
#bzr 2011-05-01
<lamont> maxb: yeah.  I'm trying to build it on LUCID
<lamont> not "lucid with most of natty backported"
<maxb> lamont: you exaggerate madly :-)
<maxb> There's only two packages in bzr/builddeps for lucid
<lamont> python is not one I'd get to backport
<maxb> The modified package is the python metapackage, not the interpreter
<lamont> wtf had to change in the metapackage?
<maxb> very little
<lamont> but specifically what?
<lamont> because I can't see any sensible reason why the META package would need to change just so that your package can build
<lamont> it strikes me as solving the problem in the completely wrong place
<lamont> whatever the problem was
<lamont> but I'm open to understanding why that might not be true
<maxb> From memory, all I did in the python-defaults source was to bump the version number up to what dh_python2-using packages from sid expect as a builddep, and depended on python-backport-helper
<maxb> From our perspective it's exactly the right place to be solving the problem, because it lets us solve it once, rather than once for each bzr plugin package we have in our PPA
<maxb> and we have lots
<maxb> This way we get to rebuild the Debian sid source unmodified in most cases
<lamont> it conflates your packages into the whole system.
<maxb> nope
<lamont> how does installing the modified metapackage not potentially affect every build on the system?
<maxb> It's in a separate PPA used only at build time for exactly that reason
<lamont> if I just force the metapackage version down to lucid and add a build-dep on python-backport-helper, should it build?
<lamont> yeah, separate ppa doesn't help me at al
<lamont> l
<maxb> Well, if you insist, it would be better to just make a few small changes so that python-backport-helper isn't needed
<maxb> But I do wonder why you can't just use the PPA packages directly, what with PPAs being a controlled source-only build environment
<lamont> one of us will get to do that before I can roll out 2.4 internally
<lamont> that's a much longer discussion
<maxb> Let me twiddle a few things and throw a source package into a different PPA
<lamont> ta
<lamont> historically, most of the stuff I have to backport fits through my "throw it against the wall and see if it sticks" script quite handily.  bzr is the package that demonstrated that I don't want to deal with some backports
<lamont> I sometimes suspect that you use the new features of python packaging just because they're new, while certain that I'm wrong in that thought
<maxb> Have you got a preferred version string you'd like me to use?
<lamont> I'll wind up mucking it about in the end anyway, so it doesn't much matter
<lamont> for 2.4.0~beta2-2 it becomes 2.4.0~beta2-2~0.IS.10.04 for lucid (and ...0.IS.8.04 for hardy)
<lamont> and yes, that means I throw away the craziness that is ~bazaar1~lucid1
<lamont> well, not craziness per se, but more than what I need to see in a version string
<maxb> Uploaded to https://launchpad.net/~maxb/+archive/launchpad
<maxb> Pushed to lp:~maxb/ubuntu/lucid/bzr/ppa-canonical
<lamont> ta
<lamont> I'll play with it after I get back from family time
<lamont> getting dragged off now
<maxb> gah
<maxb> estimated start time "some time tomorrow"
<maxb> *shrug*
<maxb> You can rescore it if you care :-)
<lamont> I'll just build it locally
<lamont> it's running tests
<maxb> export DEB_BUILD_OPTIONS=nocheck
<maxb> Or, you could delete the entire block in debian/rules beginning with
<maxb> ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
<jelmer> maxb: still there?
<maxb> jelmer: hi
<jelmer> maxb: I'm considering whether to upload to 2.4b2 to sid. It seems like a good idea as 2.4.0 will be out before wheezy, it gives us fewer releases to worry about and it means we'll have the same version in oneiric and sid
<jelmer> maxb: what do you think?
<maxb> I don't think I'm sufficiently visual on the state of bzr.dev to make a good call, but I'm not entirely convinced it's a good idea
<maxb> I've actually dropped back to running 2.3.x locally after bzr.dev was a bit too unstable for my liking over the previous little while
<maxb> Is there any particular advantage to having the same version in oneiric and sid *now*?
<lifeless> they will autosync?
<maxb> looks like Jelmer's already uploaded 2.4b2 to oneiric anyway :-)
<maxb> hm
<maxb> and looks like we're going to be carrying an ubuntu-specific delta for the indefinite future
<maxb>    + Remove build dependencies not present in main: python-medusa,
<maxb>      python-subunit, python-meliae, python-lzma.
<maxb>    + Disable parallel testing.
<jelmer> yeah, we can't autosync because of those changes. I might have a look at getting subunit into main, but not sure about things like python-medusa, python-meliae
<poolie> hi all
<presi> quick question: "bzr check" verifies the hashes of all files on the testaments?
<jelmer> presi: no
<jelmer> presi: testaments are not stored afaik
<presi> are dynamically generated with bzr testament?
<jelmer> yes, I think so
<presi> I mean "bzr testament --long"
<jelmer> yes, that's generated dynamically
<presi> the hash of the testament itself has to be stored
<jelmer> presi: the hash of the testament isn't stored in the repository, but eg. gpg signatures of revisions sign the testament
<presi> I'm using cat-signature branch to extract the testament signature
<presi> so the signture verify (or not) against dynamically-generated hash of the testament
<presi> that's correct?
<jelmer> yes - verifying it against a stored testament doesn't seem very useful as then you also need to test the validity of the stored testament
<presi> ok, I have a shell script that selects revisions and pipes cat-signature to gpg --verify if someone is interested I can send or upload it
<Sonti> hi guys. I want to start using Bazaar but I'm not totally sure how to set it up.
<Sonti> Do I select start a new project or do I select open a project and just select the folder I want to use
<lifeless> jelmer: hi
<lifeless> jelmer: does   File "/usr/lib/pymodules/python2.7/zeitgeist/datamodel.py", line 185, in __getattr__
<lifeless>     raise AttributeError("'%s' object has no attribute '%s'" %(self.__class__.__name__, name))
<lifeless> AttributeError: 'Symbol' object has no attribute 'SOURCECODE'
<lifeless> ring any bells for you?
<jelmer> lifeless: hi
<jelmer> lifeless: vaguely, IIRC the zeitgeist folks changed the constants around a while ago
<jelmer> we updated bzr-dbus I think - where are you seeing this?
<poolie> hi jelmer
<lifeless> jelmer: I've just pulled that in, will see if it addresses it
<poolie> hi lifeless
<jelmer> g'morning poolie
<lifeless> jelmer: lp:~lifeless/subunit/bug-654474
<jelmer> garr, I wished somebody updated x-chat to support lp: URLs
<lifeless> jelmer: https://code.launchpad.net/~lifeless/subunit/bug-654474/+merge/59627
<ubot5> Ubuntu bug 59627 in linux-source-2.6.15 (Ubuntu) "Intel Core Duo 50% load with powernowd running" [Undecided,Invalid]
<lifeless> jelmer: if you feel up to a review
<lifeless> jelmer: and bug 755241
<ubot5> Launchpad bug 755241 in subunit "subunit-filter ability to change fail to xfail based on external list" [Medium,In progress] https://launchpad.net/bugs/755241
<lifeless> jelmer: are you doing further refactoring there ? or should it be fix committed
<jelmer> lifeless: Sure, I'd be happy to do a review. It'll probably be tomorrow though, as it's already past midnight here.
<jelmer> lifeless: I'm going to do more refactoring (hopefully making the stuff in Samba obsolete)
<lifeless> jelmer: kk
<lifeless> jelmer: I'd like to do a release of testtools and subunit midweek
<lifeless> jelmer: I'm going to land the patch; if you do a post landing review I'll act on it.
<jelmer> lifeless: it looks reasonable at a first glance
<jelmer> lifeless: wfm, I can do a bit more thorough review tomorrow
#bzr 2012-04-23
<pakaran> is it normal for bzr to revise its estimate of the number of revisions to download, when downloading a new package, every 9 thousand or so?
<pakaran> and is there any way to see the actual number?
<SpamapS> hrm.. --gnu-changelog seems too verbose. Why doesn't it group by user/date?
<lifeless> SpamapS: fixes appreciated :P
<Merwin_> hey
<jelmer> hi Merwin_
<lduros> hello! I need to convert a git repository to bazaar. Everytime I look up convert git repo to bazaar, I have results to convert bzr to git
<lduros> any idea where I can find this information? :-)
<lifeless> lduros: bzr-git is what you need
<lduros> lifeless: thanks :-)
<SpamapS> I accidentally 'bzr add'ed a file named '*'
<SpamapS> bzr revert -- * fails
<SpamapS> halp?
<mgrandi> what about bzr rm * --keep-files or wahtever?
<fullermd> Your shell is eating the *.  Quote it.
<SpamapS> actually 'bzr revert .' got it
<mgrandi> and hey fullermd
<mgrandi> your script you gave me a while back didn't seem to work (about --revert not working on mac os x for somer eason)
<fullermd> Didn't seem to work as in ran without errors, or didn't seem to work as in blew up?
<mgrandi> bzr: ERROR: Could not move Environment.php => Twig: php_frontend/src/codeigniter/system/libraries/Twig/lib/Twig/Environment.php is not versioned.
<fullermd> How very odd.
<fullermd> You don't have some sort of global ignore that's keeping the 'add' from versioning everything, do you?
<mgrandi> https://gist.github.com/fdc7952ba400edfc3ee5 is my global ignore
<fullermd> Well, I'd look to see if it's actually not versioned (the 'add' in the setup step for whatever reason didn't add it), or it's just hitting something weird in the case semi-sensitivity in the FS.
<mgrandi> yeah its not added in the place where its trying to move it from
<mgrandi> (from the repo that i posted that was broken)
<fullermd> Urr?  The script is expecting to start from a blank dir.
<mgrandi> it commits a revision one, then does
<mgrandi> + /usr/local/bin/bzr --no-plugins --no-aliases mv /Users/markgrandi/Desktop/treetransform/tmprepo/enquist_work/php_frontend/src/codeigniter/system/libraries/Twig/lib/Twig/Environment.php /Users/markgrandi/Desktop/treetransform/tmprepo/enquist_work/php_frontend/src/codeigniter/system/libraries/Twig/
<fullermd> Did you add those full paths?
<mgrandi> im just running the script that you gave me, i didn't do anything to 'tmprepo"
<fullermd> Well, something weird is going on.  There's no 'tmprepo' in the script, nor are there absolute paths (except the one for the bzr script).
<fullermd> That line _should_ be giving a `bzr --no-whatevers mv php_frontend/src/...  php_frontend/src/...`
<fullermd> Unless /bin/sh on mac does really wacky stuff.
<mgrandi> http://bpaste.net/show/27609/ thats the script you gave me, at the top you specify the path to the tmprepo thingy
<fullermd> ...  except, no, not even then, because there's no 'A/' dir in that path either...
 * fullermd goes crosseyed.
<fullermd> No, it's not.
<fullermd> And yeah, that's GONNA do some really weird stuff, because it points somewhere totally other than where the script is working.
<fullermd> dir1="php_frontend/src/codeigniter/system/libraries/Twig"
<mgrandi> which one am i supposed to be using o.o
<fullermd> I'm confident there's not now nor has there ever been any file anywhere on my system with '/Users/markgrandi' in it   8-}
<mgrandi_> back, not sure what got through, but it has a conflict but otherwise finishes fine
<fullermd> Conflict?
<mgrandi_> Conflict adding file php_frontend/src/codeigniter/system/libraries/Twig/lib.  Moved existing file to php_frontend/src/codeigniter/system/libraries/Twig/lib.moved.
<fullermd> Oh.  Yeah, that's expected.
<fullermd> OK, then that is in fact not enough to actually hit whatever weird case your actual branch did.
<mgrandi_> yeah.
<mgrandi_> i'll try stepping through what its trying to do and see why its dying
<mgrandi_> or try at least
#bzr 2012-04-24
<mgz> morning
<mgz> so, silly, error, I didn't take headset with me, so I lack a mic
<lifeless> lol ;)
<jelmer> hey mgz, lifeless
<mgz> can listen on headphones and type, but you'll all miss out on the gurgles from niece
<jam1> jelmer: are you around? mgz is available for our standup on mumble
<jelmer> jam: I'm on my way
<jam> mgz: for some reason I still had you listed as a 1:1 today, did you have anything else you wanted to mention?
<jam> I think I just moved the meeting from the wrong day, and meant to do it next week
<mgz> jam: nothing important I think
<jam> I figured everything was already covered. Have a great week
<lduros> trunk is the equivalent of "master" in git? :-)
<LeoNerd> "trunk" is just a naming convention
<LeoNerd> bzr doesn't consider any branch any more or less canonical than any other. They're just branches
<lduros> LeoNerd: okie
<lduros> :-)
<lduros> it converted my git master branch to trunk
<lduros> thougbh
<lduros> it seems
<lduros> with fast-import
<LeoNerd> Yeah that's likely just a naming convention
<lduros> ok
<lduros> so I just transferred my git repo to bzr
<lduros> and now I have a directory
<lduros> and it contains trunk.remote somebranch.remote
<lduros> I want to remove everything except trunk
<lduros> shall I just rm -rf them
<lduros> or is there a bzr way to do it? :-)
<lduros> can't find in the docs
<lduros> bzr remove-branch ah
<maxb> lduros: bzr-git maps master to trunk, because trunk is the more common convention outside of the world of git - but it's still just convention
<lduros> maxb: sure ok :-)
<lduros> trunk is fine with me
<lduros> :-)
<jelmer> maxb: s/bzr-git/bzr-fastimport/ ?
<maxb> er, possibly, :-)
#bzr 2012-04-25
<RobOakes> Is there someone here who might be willing to help me create a strategy for a complicated merge?
<RobOakes> One of the projects I work on, LyX just switched to git for managing its source.
<RobOakes> This has left me in a problem, though. I have a number of branches on launchpad with experimental features in bar.
<RobOakes> I'm not able to pull updates in any more because they've abandoned the SVN repo which those branches are based on.
<RobOakes> Is there a good way to start merging in updates from the git repository?
<jelmer> RobOakes: not really, unfortunately
<jelmer> the two histories have diverged
<jelmer> s/have diverged/are completely unrelated/
<RobOakes> :(
<jelmer> you can of course e.g. manually apply and commit your local changes to the git tree
<RobOakes> That is an option.
<RobOakes> I just want to get the necessary changes into the git tree. This has completely stopped all development until i can find a solution.
<jelmer> RobOakes: so you have local changes on top of a mirror of the old svn branch?
<RobOakes> Yes.
<RobOakes> I need to get those changes into a branch based on Git.
<jelmer> RobOakes: I would indeed suggest getting the individual changes out of bzr and then applying those to git
<jelmer> RobOakes: you can generate git compatible patches with bzr send
<jelmer> "bzr send -o somedirectory --format=git"
<RobOakes> Can bzr look at a working copy of the git directory and then diff the two?
<jelmer> RobOakes: it can't diff the two, but you can use that command in your existing bzr branch
<jelmer> (it can't diff the two since they're not related)
<RobOakes> That will get some of the differences, but I've committed my changes over the past several months. I'm not sure how to get the history of all the different changes without running a diff operation of some sort.
<jelmer> RobOakes: another option is to use bzr-git or fastexport to export the existing bzr branch to git and then use the git tools to stitch things together
<RobOakes> That sounds promising. Is fastexport a separate plugin?
<jelmer> RobOakes: yes
<RobOakes> Okay. I'll look into that.
<jam> jelmer: just saying hi, and seeing how your day has been going
<jelmer> hey jam :)
<jelmer> jam: it's been a bit quiet here, though I'm doing okay.
<jelmer> How are things with you?
<jam> pretty good, just finishing up my day and figured I'd wave hello
 * LarstiQ waves at jam and jelmer too
#bzr 2012-04-26
<jave> hello
<jave> I get memory problems merging a local branch from a remote
<jelmer> hi
<jave> is there some flag for bzr so I can trade memory for speed or something?
<jelmer> jave: no
<jelmer> jave: what version are you running though? newer versions are more efficient, memory-wise
<jave> Ive tried using 2.5 and the 2.6 beta
<LarstiQ> jave: can you fish the corresponding backtrace from .bzr.log?
<crisb> is there any hook where i can check/change a commit message if -m is specified on the commit?
<jelmer> crisb: a pre_commit hook can do that
<crisb> jelmer: ahhhh - including change?
<jelmer> crisb: yeah, that hook should have access to the commit message
<crisb> mwuhahahah, thanks jelmer
<crisb> :)
<jml> does bzr support python 2.4 any more?
<jelmer> jml: no
<jelmer> jml: >= 2.6
<jelmer> IIRC 2.4 was the last bzr version that supported python 2.4
<jml> jelmer: thanks.
<jml> jelmer: I'm going to drop Python 2.4 support from testtools after the next release.
<jelmer> jml: okay
<jelmer> jml: we'll probably stick to the next release of testtools in samba then, but that's not the end of the world
<jml> jelmer: samba supports 2.4?
<jelmer> jml: yep
<jml> jelmer: wow.
<jml> jelmer: why?
<jelmer> jml: in practice, a lot of enterprisy people still use platforms with python2.4
<crisb> jelmer: argh, looks like it's still not possible (386161)
<jelmer> bug 386161
<ubot5> Launchpad bug 386161 in Bazaar "pre_commit hook should be able to modify the commit message" [Medium,Confirmed] https://launchpad.net/bugs/386161
<jelmer> crisb: what about start_commit ?
<jelmer> I know for sure that hooks can modify the commit message
<jml> jelmer: pre-hardy is pretty ancient.
<jml> jelmer: but sure, I can buy that.
<jml> Hmm.
<jelmer> jml: the previous RHEL has python2.4, for example
<jelmer> I had a very hard time even getting us to depend on Python; we still support autoconf for a subset of Samba (just the fileserver) since some people want to avoid the python dependency
<fullermd> Ancient.  Hah.
<jml> I guess 7.5 years isn't too bad.
<fullermd> There was a thread just earlier this week on the Postfix mailing list about some build problems on BSD/OS 4.x.
<fullermd> (don't misplace those 3 letters.  I didn't say "FreeBSD"...)
<fullermd> Platforms running py2.4 look pretty new now, don't they   :p
<jelmer> fullermd: :)
<jelmer> some of the other samba developers still support installations on tru64
<fullermd> What the DEC is wrong with them?   :p
<maxb> jubany importer stopped: quantal opening fallout. Nothing major, just needs the usual tweaks to lists of distros. I'll do it later if no-one beats me to it.
<maxb> See u-d-d@ for traceback
<maxb> OK, what?
<maxb> Who started the jubany importer again?
<maxb> james_w: Do you happen to be around?
<lifeless> maxb: probably someone in -ops ?
<lifeless> spm: ^ ?
<spm> hmmm
<spm> maxb: I presume you've stopped it again?
<maxb> yup
<maxb> I've been sending updates to ubuntu-distributed-devel@lists.ubuntu.com, is there somewhere else I should cc?
<spm> unsure. that service isn't something webops has access to control. so it's basically you guys or gsas atm
<maxb> I'm going to restart it now anyway, having taught it what a Quantal Quetzal is
<spm> must. resist. making. (another). QQ. joke.
#bzr 2012-04-27
<lduros> i've made changes I haven't committed, and I want to get back to the last commit, that is, remove all changes i've done that are not committed
<lduros> how do I do that?
<lduros> sort of like git stash, but really I don't need to keep those changes. I want to get rid of them
<lduros> so i don't know if shelve is what I want
<lduros> I guess maybe bzr reset HEAD
<lduros> bzr revert
<lduros> I'm confused
<lduros> just "bzr revert" seems to get back to the last commit
<wilx> Indeed.
<clausen> is there a way to get "bzr push" to fail when the local repo is behind the remote one?
<vork> Behind? Surely in that case push has nothing to do.
<clausen> yes, it has nothing to do
<clausen> but I want an error
<clausen> to tell me I need to pull
<vork> Right.
<clausen> is there a way I can ask it?
<vork> I don't know, I'm new.
<clausen> ok, thanks :)
<fullermd> I'm pretty sure there's no way (I mean, short of hacking it up yourself) to make push do that.
<clausen> ok, I guess I just have to do a bash alias then
<fullermd> The general answer would be something like "check missing".  That would require you to check though.
<fullermd> It's possible you could write a plugin that would hook in somewhere in the process; I don't know if there's an easily accessible limb to grab.
<fullermd> (but that wouldn't change anything essential from the "hack the main codebase" case; just make it more modular)
<clausen> here's my solution, for what I want:
<clausen> alias bzrsync="bzr pull && bzr push"
<clausen> this is a subtle difference from git, btw
<vork> Oh?
<vork> Ah, git-push succeeds only when the remote is pointing to the same commit as your current branch.
<clausen> yes
<clausen> I like git's behaviour, because it's easy to find out if everything is in sync
<clausen> bzr needs two commands
<clausen> (push and pull)
<vork> I wonder if there's anything like "hg incoming" for bzr.
<fullermd> That's half of missing.
<clausen> fullermd, oh, ok
<clausen> thanks!
<clausen> (missing does something that "git push" does not?)
<fullermd> Well, yes, but I was responding to vork    ;)
<clausen> ok :)
<vork> I like the way qdiff collapses feature branches.
#bzr 2012-04-28
<nilg`> hi is there a way to rebase afterwards?
<nilg`> a guy has a done a merge and the revision numbers are messed up we want to backtrack that and do a rebase instead, is there any simple way to do that (cause in the mean time other people have committed stuff)
<nilg`> OK, I think I've found a way to fix that but I would need a "cherrypick" rebase functionality, does that exist?
<LarstiQ> nilg`: there is the rewrite plugin which has rebase, or you can use cherrypick with merge
<LarstiQ> nilg`: but it sounds simpler
<LarstiQ> nilg`: did he merge trunk into a feature branch, and then push that branch on top of trunk?
<LarstiQ> nilg`: also see 'append_revisions_only' in `bzr help config` for preventing exactly that case, if I'm right
<LarstiQ> nilg`: for now you could `bzr uncommit` the merge revision, merge feature into trunk instead of the other way around, and push that
 * maxb attempts to stop the jubany udd importer importing the same packages many times over, so it can actually catch up with quantal opening this weekend
<iri> This bug is causing significant issues and doesn't seem to have anyone assigned to it: https://bugs.launchpad.net/bzr/+bug/541626
<ubot5> Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed]
<iri> It's been around since 2010 - how to get it some attention?
 * iri gently pings jelmer
<jelmer> iri: hi
<iri> hi jelmer. I'm going to appear and disappear a bit over the few hours. If there is any way I can help crack the bug, let me know. I'm good with python but not a bzr user unfortunately.
<LarstiQ> iri: https://bugs.launchpad.net/bzr/+bug/541626/comments/24 and comment 25 seem the most relevant to me
<ubot5> Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed]
<iri> hi LarstiQ
<iri> So I'm not sure I understand the implications
<iri> Is there a reasonable fix?
<iri> Implement BTreeBuilder._find_ancestors() to return get_parent_map()?
<LarstiQ> iri: implementing the same api in my reading
<LarstiQ> iri: that's a start :)
<LarstiQ> there is bzrlib.btree_index.BTreeGraphIndex._find_ancestors
<LarstiQ> and bzrlib.index.GraphIndex._find_ancestors
 * LarstiQ compares
<LarstiQ> right, they should have the same interface
<LarstiQ> BTreeBuilder also seems to live in bbzrlib.btree_index
<iri> Just setting up the trunk version ow
<iri> s/ow/now/
<LarstiQ> iri: mind you, I don't really know the bug or what to do about it, but I'm a bit familiar with the bzr codebase
<iri> I'm just frustrated because it's preventing me from working with git
 * LarstiQ nods
<LarstiQ> tests live in bzrlib/tests/test_{btree_,}index.py
<iri> I don't understand enough about what has gone wrong to write a test for it
<iri> I can provide access to the broken repository if needed
<iri> bzr trunk won't install into a virtualenv? :-s
<iri> oh, seems that just pip was having trouble with it "python setup.py install" worked
<LarstiQ> iri: no idea, but I run it from source
<LarstiQ> jelmer: can you reproduce bug 541626 already?
<ubot5> Launchpad bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] https://launchpad.net/bugs/541626
<LarstiQ> iri: I'm going to try the recipe in https://github.com/termie/git-bzr-ng/issues/38
<iri> thanks :-)
 * LarstiQ keeps running into hurdles
<LarstiQ> iri: hmrf, ../codex doesn't exist
<LarstiQ> so that github issue in fact does not contain enough to reproduce :/
<iri> I guess it is a branch?
<iri> it looks like github screwed up the formatting of the post
<iri> I don't think where the pull is from is important
<LarstiQ> iri: I'm a git novice so I have trouble guessing at what to do
 * LarstiQ runs down to change the laundry
<iri> k
<iri> I'll try and reproduce
 * LarstiQ tries termies test2.sh
<iri> I can't seem to reproduce with a clean repository, but I can with the one in the git issue
<iri> It seems sufficient once you have the git repository to "echo >> test; git add test; git commit -am "update"; git bzr push"
<iri> uh, where push is to some repository you created
<iri> I did git bzr push lp:my.username/+junk/test
<iri> ah, got it with a minimal repository
<iri> weird,
<iri> can't do it now
<LarstiQ> iri: yeah, "echo >> test; git add test; git commit -am "update"; git bzr push lp:~/+junk/test" worked fine for me
<iri> got it
<iri> http://pastebin.com/KCYs8JDL
<iri> That reproduced it twice
<iri> it might be more than necessary
<iri> This was the minimum I was able to reproduce with : http://pastebin.com/WeJXKQgG
<iri> LarstiQ: I commented on https://github.com/termie/git-bzr-ng/issues/38 with a complete script to reproduce
<LarstiQ> iri: cheers! _now_ it blows up :)
 * LarstiQ has dinner and will then followup
<iri> great, thanks :D
<LarstiQ> hey beuno
<LarstiQ> iri: I updated bug 541626, having a stab at _find_ancestors
<ubot5> Launchpad bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] https://launchpad.net/bugs/541626
 * iri peek
<iri> s
<iri> :-)
<beuno> heya LarstiQ!
<LarstiQ> iri: hmm, BTreeBuilder has a find_ancestry(), and BTreeGraphIndex's _find_ancestors docstring mentions: 'It is unlikely that you want to call this directly. See "CombinedGraphIndex.find_ancestry()" for a more appropriate API.'
<LarstiQ> iri: so perhaps something is using the wrong api there
<LarstiQ> beuno: :)
 * LarstiQ looks at the backtrace again
<iri> interesting
<LarstiQ> which in fact terminates inside find_ancestry(), hmm
<jelmer> hi iri, LarstiQ
<iri> hi
<LarstiQ> navond jelmer
<LarstiQ> jelmer: I have a pdb session where this thing goes wrong. It tries index._find_ancestors which results in the AttributeError, so far so good
<LarstiQ> jelmer: but index comes from index_idx, index = enumerate(self._indices) and self._indices only contains BTreeGraphIndexs
 * LarstiQ blinks
<vork> Has somebody been writing a __setattr__ method? :(
<LarstiQ> vork: in the lazy_import machinery, but I wouldn't expect that here
<vork> (I meant __getattr__).
<LarstiQ> vork: hmm, versionedfile maybe
<LarstiQ> vork: print style debugging seems to indicate self._indices gets mutated while we loop over it.
<jelmer> iri: I'm no longer working on that bug, it only seems to affect fastexport as far as I can tell.
<iri> Looks like LarstiQ is having a good crack at it
<LarstiQ> jelmer: and through it things that depend on it, like git-bzr-ng
<iri> I was just wanting to raise some interest in it
<iri> And you were the last person to be assigned to it, so I wanted to know why it had been left alone
<LarstiQ> iri: I'll have to go back to my studies soon, but I'll try to get to a point where someone else could pick it up (or me somewhere in the future)
<jelmer> iri: mostly just lack of time, and the fact that it only affected bzr-fastexport
<iri> Thanks LarstiQ
<LarstiQ> jelmer: I'm currently trying to find out why a BTreeBuilder gets inserted in the list of indices at all
<LarstiQ> jelmer: any ideas how that could happen?
<jelmer> LarstiQ: IIRC because we're writing to a new pack?
<LarstiQ> jelmer: ah hmm. How do I see if that is going on?
<jelmer> LarstiQ: sorry, no idea. I never did much with the lower layers of the code
<LarstiQ> jelmer: np
<LarstiQ> well
<LarstiQ> back to that _find_ancestors implementation then
<iri> LarstiQ: I have to run, thanks for your help!
<LarstiQ> doh
 * LarstiQ just pushed up lp:~larstiq/bzr/bug541626
<vork> LarstiQ: Fixed it?
<LarstiQ> vork: fsvo "fixed"
<vork> fsvo=?
<LarstiQ> vork: the script that crashes no longer does
<LarstiQ> vork: "for some value of"
<vork> Oh, for some v...yeah, just worked it out.
<LarstiQ> vork: the implementation is more correct than the previous suggestion I think
<LarstiQ> vork: but I don't really know what I'm doing
<LarstiQ> vork: you're welcome to try and see if anything goes horribly wrong ;)
<LarstiQ> jelmer: pushing to launchpad from a development-colo branch doesn't work, is there a workaround that doesn't involve first pushing to a 2a branch?
<LarstiQ> jelmer: and, should I file a bug on that or does that come down to "it's a development format, wontfix"?
<jelmer> LarstiQ: thre's no longer any reason to use development-colo, it's been merged into 2a
<LarstiQ> really?
<LarstiQ> I missed that happening :)
<jelmer> LarstiQ: I would indeed say it's a development format so we shouldn't allow it on launchpad
<jelmer> LarstiQ: yep, that happened before 2.5.0
<jelmer> LarstiQ: the only difference between those two formats is their format strin g:)
<LarstiQ> jelmer: yeah, the friction in my mind came from considering pushing one branch as, well, being one branch
<LarstiQ> jelmer: I remember the discussion at the time
 * LarstiQ upgraded his bzr.dev copy to 2a ;)
<jelmer> LarstiQ: we don't really support colocated branches on lp yet, at least it doesn't display them
 * LarstiQ nods
<LarstiQ> jelmer: I didn't want repo-push, just push. If that makes sense.
<jelmer> LarstiQ: push only pushes the active branch
<LarstiQ> jelmer: yeah
 * LarstiQ calls it a day and goes back to math
<LarstiQ> jam: I'll try to bug you somewhere during the week for some guidance
<jelmer> LarstiQ: ttyl
<LarstiQ> jelmer: hf
<jelmer> hf?
<jelmer> high five?
<LarstiQ> jelmer: have fun :)
<jelmer> aha :)
<jelmer> you too :)
<nilg`> thanks a lot LarstiQ
<wilx> So, I have a trunk branch and 1.1.x branch from the trunk.
<wilx> I am usually merging from the trunk to the 1.1.x branch.
<wilx> But I have also now made some changes on 1.1.x and I would like to have them on trunk as well.
<wilx> Now, do I cherry pick/apply diff from 1.1.x revision to trunk or should I just merge from 1.1.x to trunk?
<wilx> Is there any danger in doing it both ways?
<mgrandi> so you are merging trunk to 1.1.x?
<wilx> Usually.
<mgrandi> so
<wilx> But now I want to also do it the other way around.
<mgrandi> you can 'shelve' the changes in the 1.1.x branch
<mgrandi> merge trunk -> 1.1.x
<mgrandi> and then unshelve the changes, and then merge them again
<wilx> Uhm, no. There are tens of revisions on 1.1.x from the branch point.
<mgrandi> oh
<mgrandi> so they are commited?
<mgrandi> then the merge will just take care of that
<wilx> Basically, is merging between two branches both ways anyhow dangerous?
<fullermd> It's not dangerous _technically_.  But it's probably not what you want, unless you intend both branches to converge to the same contents.
<wilx> Well, I have branched for 1.1.x release too early. I tried to be disciplined and make any necessary changes first on trunk and then merging them to 1.1.x. Unfortunately, I was not so disciplined all the time so I need some 1.1.x changes on trunk as well.
<vork> Well it should be fine, bzr's supposed to adapt to your workflow, right?
<fullermd> If you want trunk to have everything 1.1.x has, merging 1.1.x->trunk will work fine.  If not, it's not such a great idea.
<fullermd> Especially if you're doing trunk->1.1.x merges too.
<wilx> Yes, at this point I do need all of that.
<fullermd> You want all the changes?  In that case, there's no question; just merge.
<fullermd> It sounds from your description almost like you're working toward 1.1.x on trunk, in which case having a separate branch seems a little unnecessary.
<fullermd> The usual case is more that you make 1.1.x, and then trunk goes on with changes you won't want 'till 1.2.x or 2.0.x (or 11.x, if you're Sun)
<wilx> Ok, merge it is.
#bzr 2012-04-29
<lduros> I noticed a whole lot of commits have a wrong email address
<lduros> when i look at the log
<lduros> is there a way to fix this? :-)
<vork> Yeah. Make a new E-mail account. ;-)
<lduros> ??
<lduros> but that wouldn't change the commits in the past
<vork> So that the wrong E-mail addresses become right :D
<lduros> would it?
<vork> Joke.
<lduros> :-P
<LarstiQ> lduros: not without removing old commits and making new ones
<lduros> LarstiQ: hmm ok, that sucks
<lduros> I don't think I want to recreate commits
<lduros> sinon ct bien la fete
<lduros> oups
<lduros> wrong window
<LarstiQ> lduros: there is machinery to make it easier, but yeah. I'd just live with it :)
<lduros> LarstiQ: ok, thanks :-)
<LarstiQ> there are some funny commiter ids in the bzr codebase that way too
<lduros> haha
#bzr 2013-04-22
<Kakadu> It is possible to fetch remote changes without changing current revision number (like 'git fetch' does)?
<bob2> into a repo sure
<jelmer> Kakadu: bzr fetch-revisions IIRC
<Kakadu> jelmer: no such command on my machine
<jelmer> Kakadu: you'll need to have bzrtools installed, I think
<Kakadu> installed already
<jelmer> Kakadu: bzr fetch-ghosts?
<Kakadu> Purpose: Attempt to retrieve ghosts from another branch.
<Kakadu> No idea what 'ghost' means
 * Kakadu is googling
<bob2> it's uh complicated
<bob2> I think you basically want what I said, ie use a repo and pull into it
<Kakadu> bob2: i.e. I need to make a repo in another place of my filesystem and pull to it? Am I understanding u correctly?
<bob2> guess so
<bob2> what are you trying to do
<Kakadu> I have a tool which gets sources from many locations
<Kakadu> and we have designed some API which is good for git and darcs
<Kakadu> API is here: https://github.com/samoht/opam/blob/master/src/repositories/opamVCS.mli
<bob2> oh man
<Kakadu> And I'm thinking how suitable it will be for bazaar
<Kakadu> bob2: what do you expect? package manager
<Kakadu> afk 5 min
<bob2> well, you'll need to read the bzr tutorial then
<bob2> so you know what a shared repo is
<jelmer> That API documentation has a confusing use of the term staging area
<jelmer> In Git terminology it usually refers to the index; you seem to be using it more in the context of a repository containing changes that are not yet applied to the working tree/index.
<Kakadu> it seems that bzr's shared repo is what git has by default...
<bob2> sort of
<bob2> you'll need to learn bzr if you want to write a tool on top of it
#bzr 2013-04-23
<felipec> when a branch has diverged from the remote, is there a way to get the revision objects programatically?
<felipec> like in git, I don't need to do 'git pull', I can do 'git merge', and I see the remote stuff in 'origin/master' (for example)
<felipec> er, I can do 'git fetch'
<bob2> sure, bzr missing
<bob2> or doing the same with git and a repo/clone
<felipec> bob2: yeah, but I want to do what bzr missing does but programatically
<felipec> bob2: from what I can tell, the repot revisions are not copied locally, so I would need to query the remote branch to fetch the information
<bob2> yes of course
<bob2> if you want it to be like git, use a repository
<felipec> bob2: I'm actually working on git-remote-bzr (the official bazaar support from git)
<felipec> bob2: and I wasn't really aware of bzr repositories
<felipec> only exploring them right now
<bob2> well
<bob2> you'll definitely want to read the bzr tutorial before trying to write an interoperable tool for it :)
<felipec> bob2: too late, it's already written, and already released
<felipec> what is the oldest version of bazaar that supports repositories/
<bob2> thousands of years ago
<felipec> hmm, branch.repository.find_branches() seems to be rather slow
<felipec> is there some remote repository I can test listing the branches?
<bob2> thousands on launchpad.net
<felipec> bob2: for example
<felipec> preferably a small one
<felipec> all the projects I see on launchpad.net have the repository inside the branch
<bob2> ?
<bob2> I really would read the bzr tutorial
<bob2> launchpad just exposes the branches to you, how it's stored does not matter to you as a remote user
<bob2> and this is unrelated to the above
<bob2> (if you don't want to query the remote for info every time, you want to clone it into a local repository and ask that)
<felipec> bob2: I already have
<felipec> and I cansee the repository: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~felipec/%2Bjunk/test/.bzr/)
<bob2> yes
<felipec> also, I created a local repository, and I get nothing while calling get_branches()
<bob2> that's not related to your goal of not having to query remote branches
<felipec> bob2: that's not my only goal
<bob2> what is your goal
<felipec> bob2: another goal I have is to be able to clone all the branches in a repository
<felipec> bob2: I have many goals
<bob2> suspect it'll be hard to get useful help here without a broader explanation then
<felipec> bob2: I want to list all the branches in a repository
<felipec> what more explanation do you need?
<bob2> good luck =)
<felipec> even 'bzr branches' doesn't list them
<felipec> bob2: yeah, thanks for *nothing*
<bob2> :/
<felipec> that's what you get for trying to support a dead SCM
<felipec> a bunch of users that have no idea what they are doing, but somehow want bzr to magically work on git, one or two developers unwilling to help, unmaintained spaghetti code, and few online resources
<fullermd> In some recent version branches started needing some arg (I guess -R) to do the search.
<felipec> fullermd: yeah, I eventually found that out
<felipec> I can list the branches now, but with a ControlDir, not with a BzrDir
<felipec> well, I can, but it's cumbersome
<felipec> now, I'm trying to find the best way to clone all the branches
<felipec> I guess I should 'sprout' the repository, and then 'sprout' all the branches
<felipec> there's no such thing as main, or default branch in a repo, right?
<vila> felipec: I don't want to sound rude or anything, but bob2 is right, if you don't start using the right words when asking questions about bazaar, we're all losing time
<fullermd> Meaningless statement, yes.  Really, repos don't know anything about branches under them anyway.
<vila> felipec: there is no such things as a list of branches for a given repo
<vila> felipec: a branch on the other hand can refer to one or several repos and all of the revisions in the history of a branch are stored in these repos
<felipec> fullermd: Repository::find_branches() begs to differ
<vila> felipec: I don't think you fully understand what find_branches does then
<fullermd> Technically, that doesn't find branches using the repository, only under it.
<vila> felipec: it walks the file system findin... yeah, what fullermd said
<fullermd> All the find_branch's/find_bzrdir's evaluate roughly to `find -type d -print | xargs hi-there-are-you-a-branch`
<felipec> fullermd: I did not ask to "find branches using the repository", did I?
<fullermd> "in" implies (though doesn't require, true) it.
<fullermd> In meaningful use cases, the distinction probably doesn't matter.
<fullermd> Teally, in meaningful use cases, the whole 'repo' question in the first place probably doesn't matter.  You don't care about the repo one way or another, you just want to clone some set of branches.
<fullermd> And Really even, too.
<felipec> 'in' is not a superset of using, so it doesn't matter
<vila> ha, nit-picking about word definitions are we ?
<felipec> vila: wasn't you the one that just complained about the words being used?
<felipec> and btw, I didn't use any words wrongly, repositoryes do have branches in them
<felipec> anwyay, moving on
<vila> felipec: indeed, I told you to use the right words in the right context and you didn't care
<felipec> bzr branches -> * (default)
<felipec> I wonder what that (default) means, and why it's named *
<vila> felipec: no, repo do not contain branches
<vila> felipec: that's the git definition, not the bazaar one
<felipec> bzr branches -R . -> and I wonder why that branch is called '.'
<fullermd> That's a side effect of 'branches' by default doing something that isn't supported.
<felipec> vila: I can 'bzr branch' it
<fullermd> It's not _called_ '.', because branches don't have names.  Just locations, and '.' is the location.
<felipec> vila: and I can 'bzr branch' the subdirectories in it
<felipec> fullermd: and what about '* (default)' ?
<fullermd> That would be the something-that-isn't-supported.
<vila> a branch can have a repo, so you branch it but you don't branch the repo
<felipec> fullermd: BzrDir::sprout() is doing that
<felipec> vila: it doesn't matter... the repo does have branches in it
<vila> amazing....
<vila> I've seen people being less than friendly when asking for help but here... what can I say, I've tried but I think my time will be best used somewhere else
<felipec> vila: if the repository does _not_ have branches in it, why does Repository::find_branches() returns branches?
<vila> felipec: read the log both fullermd and I have already answered, repos do not contain branches, their location on the file system though is (in most usual cases) above the branches that are using it, so find_branches() walk the file system to find them
<felipec> vila: yeah, you are "helping", keep telling you that
<felipec> vila: all you are doing is trying to correct me, when the code shows you are wrong
<felipec> repos do contain branches
<felipec> as repo.find_branches() shows
<felipec> the question was: there's no such thing as main, or default branch in a repo, right?
<felipec> the answer was: no
<vila> indeed
<felipec> vila: and yet, you never answered the question
<vila> felipec: if you know the code better than me why are you even listening to my answers ?
<felipec> vila: which answers?
<vila> felipec: everybody answered your question but you're not listening
<felipec> all I heard was you trying to correct what I said
<vila> when a question is incorrect, the only way to answer is to first correct the question so it can be answered
<felipec> vila: but you didn't answer
<felipec> and it was correct
<vila> you're coming with a git background where a repo contains branche definitions, that's not the case in bzr
<vila> felipec: so you care more about your question being correct than about a correct answer ? Your choice
<felipec> vila: I did not ask if a repo contains branch definitions, nor did I say it
<felipec> vila: it was you the one that cared about the correctness of the question, not me
<felipec> all I cared for was the answer
<felipec> which I didn't get
 * vila stops feeding the troll
<felipec> vila: you are the troll, I am actually writing a useful bzr tool
<felipec> by definition, a troll purposedly disrupts the communication in a project, so progress is inhibitted, but I'm the one doing something productive here
<felipec> I take it you are not programing on bzr.bzr atm
<felipec> all right, I've added support for bzr repos in remote-bzr
<felipec> https://github.com/felipec/git/commit/5fa8fd57241c16f9af5ba2857ff999bf0931dd97
<felipec> I whish there was an easier way to detect if a controldir is a branch or a repo though
<felipec> how does a branch finds it's repositories? checking the directories above?
<smgz> felipec: yup
<felipec> smgz: I did fetch a branch repository into another repo, and then sprouted the branch in a directory under the other repo
<felipec> it seems there are some objects in that second repo
<smgz> it only ascends to the first repo found
<felipec> smgz: I thought vila said above  that a branch can refer to multiple repos
<smgz> it can, but not via that mechanism
<felipec> smgz: so under what mechanism then
<smgz> it's called stacking, and don't do it.
<felipec> smgz: I might need to if I don't find a way for all the branches to use the same repo
<smgz> just put the repo in the parent directory (create with `bzr init-repo`) then branch into it
<felipec> smgz: I am not using the command line
<felipec> smgz: it's not finding it: bzrlib.errors.NoRepositoryPresent: No repository present: "file:///home/felipec/tmp/test/.git/bzr/alt/clone/master/"
<smgz> what fun, you get to debug the logic when there's a .git directory involved. try --no-plugins
<felipec> smgz: it's not the command line
<smgz> then you get to debug your code directly.
<felipec> smgz: it's not my code that is triggering that error
<felipec> smgz: same happens from the command line
<felipec> bzr: ERROR: No repository present: "file:///home/felipec/tmp/test/.git/bzr/alt/clone/master/"
<felipec> ln -s $PWD/../.bzr/repository .bzr
<felipec> and it works
<felipec> ah, create_repository(shared=True)
<Jeeves_> Hi all
<Jeeves_> Q: Is there any documentation available on how to use the bzrlib python modules?
<smgz> Jeeves_: you mostly want to refer to the docs under developers, and the docstring/api documentation, for instance at <http://people.canonical.com/~mwh/bzrlibapi/bzrlib.html> (not sure what version that's for...)
<smgz> (you can generate your own though for local browsing if you like)
<Jeeves_> smgz: I'll have a look. Because http://doc.bazaar.canonical.com/en/ seems just about how to use the program, right?
<smgz> see the "Developer docs" link on that page
<smgz> *linked from, <http://doc.bazaar.canonical.com/bzr.dev/developers/>
<Jeeves_> That seems to be about working *on* bzrlib
<smgz> some parts
<smgz> you want to read overview.html at least
<Jeeves_> ok, thanks
<yacc|2> Any idea what the branch url for bzr-svn is?
<yacc_> Any idea how to make bzr know that some url is a svn repo? Seems the auto-detect fails badly here: http://www.fpaste.org/5g1w/
<qengho> james_w: Hi. I'm interested in picking up the libv8 packaging in Ubuntu.  It is Debian's, so far, with in-branch sources. Is it smart or possble to convert that to a debian/ -only branch and not break things?
<james_w> qengho: you can't convert the official branch
<james_w> but you could have your own version if you wanted
<qengho> james_w: hrm, thanks.
<rossouwap> Hello, noob here: I'm trying to figure out why a bzr update is going extremely slowly. 3-10 kB/s. Any ideas?
<qengho> james_w: Er, should the quilt ".pc" directory be versioned? That seems wonky.
<qengho> In a UDD branch, I mean.
<qengho> rossouwap: Hrm, what branch format? ("bzr info") What transport?  Is it CPU bound?  Disk bound?
<rossouwap> qengho: format 2a, not sure what you meanby CPU bound or disk bound
<james_w> it is a bit wonky indeed, but it's currently intended behaviour
<qengho> rossouwap: it could be "normal". I'm not sure. If you're branching something big, then initialize a "shared repository" in the parent dir so that branches of the same family after this one are very cheap.
<qengho> rossouwap: ("bzr init-repo .." or some place upward in the dir structure.)
<rossouwap> qengho: thanks. I'll have to read more before I do anything I think (I'm still learning bzr). Was just alarmed to see an update work so slowly. Project is hosted on launchpad, and initial clone put +-800 mb onto disk. I'm sure I'm using ssh as well, as it asks for my key passphrase.
<qengho> rossouwap: After your branch finishes,"mv new-dir to-be-removed && bzr init-repo . && bzr branch to-be-removed new-dir && rm -r to-be-removed;"  That will fill a shared repository by branching locally and discarding a copy, so you don't see that cost again on this computer. The only disadvantage is that you can't move that branch outside of this directory.
<qengho> james_w: Either there's a bug, a bad import, or I'm dumb.   http://pastebin.ubuntu.com/5596373/
<james_w> qengho: that looks like a bug to me
<qengho> james_w: Reported.   https://bugs.launchpad.net/bzr-builddeb/+bug/1171999
<ubot5> Launchpad bug 1171999 in bzr-builddeb "On import-upstream, unapplying checked-in .pc/ quilt patch-state makes unversioned conflicts" [Undecided,New]
<qengho> Longest bug summary ever.
<james_w> thanks qengho
#bzr 2013-04-24
<quicksilver> vila: after using DVC for about 7 years I just noticed there are commands to add and rename files :)
<vila> quicksilver: :-)
<fullermd> Sure, it's Meta-Alt-Super-Quizjax-Dolphin Theta.
<vila> quicksilver: wait, rename ?
<quicksilver> vila: C-x V f M
<quicksilver> M for move I suppose
<vila> quicksilver: wow, dvc-rename, so M for renaMe ;-D
<quicksilver> well maybe :)
<vila> quicksilver: I alternate between using 'bzr add' most of the times and adding from the dvc-status buffer when... I don't know, moon phase probably
<vila> fullermd: I don't have a Quizjax key...
<vila> how does it look like ?
<fullermd> It's the pedal second from the left.
<fullermd> I've found it's easiest if you use your tail to actuate it.
<quicksilver> vila: I had been using M-! bzr add
<quicksilver> but the command has the advantage of defaulting to the current file
<quicksilver> or the current entry in a dired window
<vila> quicksilver: doh, I so forget about M-! ...
<quicksilver> this is always the best channel to discover emacs tricks.
<quicksilver> I'd tell you about C-u M-| perltidy, but you're python-using heathens.
<ElMonkey> hi there, i'm trying to use bzr-git
<ElMonkey> bzr plugins says "bzr_git (failed to load)"
<ElMonkey> i can't find any docs on how to troubleshoot this
<ElMonkey> are there any requirements i need?
<ElMonkey> i just branched lp:bzr-git into the plugins folder
<fullermd> Are you calling the plugin dir 'bzr_git'?  You probably want just 'git'...
<ElMonkey> fullermd, ok, i'll try that
<ElMonkey> fullermd, thanks, that did it!
<ElMonkey> wth is up with that?
<fullermd> Has to do with the way python imports them and naming conventions.
<ElMonkey> then http://wiki.bazaar.canonical.com/BzrPlugins probably shouldnt recommend using underscores :/
<jelmer> ElMonkey: underscores are fine
<jelmer> ElMonkey: it's just that bzr-git's canonical name is 'git'
<felipec> man, Repository::find_branches() is *exteremly* slow on the emacs repo
<jelmer> felipec: you really don't want to use find_branches()
<felipec> jelmer: so what do I use to find all the branches?
<jelmer> felipec: it basically does a "find . | grep \.bzr"
<felipec> jelmer: even that shouldn't be this slow
<jelmer> felipec: is this on a local repository?
<felipec> jelmer: no
<felipec> emacs's repository
<felipec> ControlDir.list_branches() throws nothing
<jelmer> felipec: right, so you're basically recursively browsing the entire remote repository and grepping for .bzr
<jelmer> felipec: right, .list_branches() lists colocated branches
<felipec> jelmer: even 'find -name .bzr type d' should be fast
<felipec> but either way, there's no other option
<jelmer> felipec: it checks files as well, and browses recursively - into directories for which a .bzr subdirectory exists too
<felipec> a deficiency in bazaar design then
<jelmer> felipec: it's a differnet way of thinking about it
<jelmer> felipec: generally people work with remote branches
<jelmer> felipec: not repositories - repositories are merely a container for revisions, not for branches
<jelmer> I would argue that Repository is an inappropriate location for find_branches()
<felipec> geez, find_bzrdirs is extremely inefficient
<lifeless> I was sure there was a bug about remote finding being slow
<felipec> this is my version of find_bzrdir
<felipec> http://pastie.org/7711627
<felipec> takes 0.99s on emacs repo, while bzr's is 154s
<felipec> what is the best way to check if a controldir is a branch, or a repository?
#bzr 2013-04-25
<felipec> wtf?! http://pastie.org/7712448
<felipec> why would find_branches_old() would work, but not find_branches()
<felipec> they return the exact same thing
<felipec> but one causes the server to choke when cloning, and the onter doesn't
<felipec> is iter_files_recursive() borked?
<felipec> forget about the cloning, simply storing the branches in an array makes it fail
<felipec> this is ridiculous
<felipec> aha!
<felipec> http://pastie.org/7713105
<felipec> why can't I list the tags from a Repository() object?
<felipec> aren't the tags shared by all the branches?
<lifeless> tags are per-branch
<felipec> lifeless: I've seen branches that don't have the revisions a tag points to
<felipec> they show with a '?'
<lifeless> Indeed. Broadly speaking 'iz bug'
<beuno> o/ lifeless
<felipec> it seems my computer runs out of memory simply traversing a repository with multiple branches
<felipec> would it be reasonable  to assume that I need to unref the object of the branches I'm not traversing?
<felipec> or do I need to do something more?
#bzr 2013-04-26
<pfsmorigo> hi, i saw that you can do a bzr branch in the same dir. this is better that with diff dirs?
#bzr 2013-04-27
<spundun> hi all...
<spundun> I ran selftest.
<spundun> I get the result OK, followed by a bunch of text that looks like errors
<spundun> so I'm confused, did the testsuite run correctly or not
<spundun> http://pastebin.com/xh4gYZz1
<spundun> TestSFTPInit.test_init is leaking threads among 41 leaking tests.
<spundun> 1 non-main threads were left active in the end.
<spundun> and Option file from ... was changed from locations to <CREATED>. The <DELETED> value will be saved
<spundun> what do these messages mean?
#bzr 2013-04-28
<jelmer> pfsmorigo: it's different, not necessarily better :-)
<ali1234> how do i wipe all uncommited changes from the working directory?
<bob2> bzr help revert
<pfsmorigo> jelmer: so, no downsides?
<pfsmorigo> jelmer: is there a help to use branches in the same dir? it seems to be a hidden feature... :P
<bob2> bzr colo has some docs online
<bob2> but I don't think it was finished
<pfsmorigo> s/help/manual,docs/
<Amis> Is it possible to somehow edit tags of previous commits or add entries to "fixed bugs" without reverting all the way back?
<LeoNerd> Tags are editable, yes.. add/delete however you like
<Amis> And how?
<Amis> For adding a bugfix tag I just have to add a new tag using the bugtracker's abbreviation?
<bob2> bzr help tag
<Amis> I can't really see anything there related to bugtracker tags
<Amis> Which must be something special
<bob2> ?
<Amis> Or they are not tags at all
<bob2> did you mean "bzr commit --fixes?"
<bob2> those are not tags
<Amis> Yea, I mean those
<bob2> also they're properties of the revision, so I'm pretty sure are uneditable
<Amis> Darnit
#bzr 2014-04-21
<benonsoftware> Hi, I'm trying to get a branch, but keep getting: bzr: ERROR: Certificate error: hostname 'anonscm.debian.org' doesn't match u'alioth.debian.org'
<benonsoftware> Is there anyway I can get bzr to ignore the error?
<benonsoftware> Nevermind sorry, I've gotten the branch from somewhere else
<mark06> how can I see the diff between a merged branch and the merge itself?
<mark06> that is, those changes you make specific for the merge, not part of the merged work itself...
#bzr 2014-04-23
<Wiz_KeeD> dudes
<jelmer> Wiz_KeeD!
#bzr 2015-04-20
<noob> anyone up
<Guest23440> I got Bzr-Explorer here, and a repo to contribute to.. never used bzr before and have some experience with git..
<Guest23440> by a repo.. i basically meant a team on launchpad
<Guest23440> eixt
<Guest23440> exit
#bzr 2015-04-21
<CcxCZ> is bzr-externals still the thing to manage related branches? or is there something nicer I'm not aware of?
<MarkyC> Hey, I'm a gitter. I'd like to contribute to lp:scratch. I've done bzr branch lp:scratch and made some changes (haven't committed them yet)
<MarkyC> I'd like to move my changes to a branch bugfix-1080904 and push them to my launchpad repo so I can make a merge request. Can someone assist me with this?
<fullermd> What you call the branch on LP and what you call it locally don't have any necessary relation.  So the simplest thing is just commit and push.
<MarkyC> I feel like if I push it may think I'm trying to push into "master" (or the bzr equivalent)
<fullermd> Well, remember, in bzr the thing you're push'ing around (and branch'ing initially) isn't a "repo" with branches in it, it's a single branch.
<fullermd> It doesn't have any "name", apart from the URL or path or whatever access schemata.
<MarkyC> forgive me; before today, I've only heard of bzr, but never actually worked with it
<fullermd> Hey, if it weren't for people in that situation, I'd have nothing to do here   ;)
<fullermd> If you were doing long-term ongoing stuff, there are alternate workspace/etc setups you'd want to investigate.
<MarkyC> I see on this page ( https://code.launchpad.net/~elementary-apps/scratch/scratch/+activereviews ) the other committers all have branches beginning with their names then scratch (the project I'm committing to), then their "feature branch name", so if I just add, commit, and push, I'll have something similar?
<fullermd> But for a oneoff, "bzr branch lp:whatever ; <hack> ; bzr push lp:~/whatever/bugfix-12345" or the like works fine.
<fullermd> Yeah, the LP scheme is something like <user>/<project>/<branch>; it uses that internally to tie stuff together.
<fullermd> (technically a LP thing, not a bzr thing)
<fullermd> I _think_ LP properly expands bare "~" to "~you"; if not you might have to spell out your username there.
<MarkyC> fullermd: I see, thank you. One more question though: does bzr commit (without the -m flag) open up a vim editor for me to write my commit message in?
<fullermd> Should pop up $EDITOR like most other programs, yeah.
<fullermd> Or $VISUAL, etc.
#bzr 2015-04-22
<spiv> And you can 'bzr uncommit' if you screwed up the commit somehow :)
<fullermd> Oh, hi spiv   :)
#bzr 2015-04-24
<dreamcat4^> hello! pls help. i would like to uninstall / reinstall bzr + bzr-svn on ubuntu 14.10.
<dreamcat4^> it seems 'broken' on my system ATM (for want of a better word).
<dreamcat4^> hmm. it seems due to the bzr-svn plugin. as when i remove that... then it works again.
<dreamcat4^> so how do i unstall bzr-svn on 14.10 ?
<dreamcat4^> i tried this method of installing bzr-svn as a ~/.bazaar/ plugin. but it cause many error msgs :(  ----> http://askubuntu.com/a/362874
<dreamcat4^> what about this .spec file? ---> https://github.com/pld-linux/bzr-svn/blob/master/bzr-svn.spec
<dreamcat4^> ah, thats for building a .rpm from...
<dreamcat4^> $ bzr svn
<dreamcat4^> Option "guessed-layout" is not allowed.
<dreamcat4^> bzr: ERROR: unknown command "svn"
<maxb> dreamcat4^: I believe bzr-svn is now unmaintained and has bitrotted sufficiently to be a pain to make work with latest bzr
<maxb> Indeed bzr-svn isn't packaged in 14.10
<dreamcat4^> maxb: yes. i am aware of this now. :(
#bzr 2015-04-25
<mark06> is it possible to clone all branches from a project into a single repository?
<mark06> for example if you want to mirror your bazaar project into github, you need to keep track of each branch manually
<jelmer> mark06: bzrtools has a command for that
<jelmer> mark06: oh, hmm, perhaps it was a separate plugin
<mark06> hmm I guess git-bzr-ng will not understand a multi-branch bzr repo anyway
<jelmer> mark06: I think that's more of a git-bzr-ng than a bzr question
<mark06> the use I would make of that is irrelevant
<mark06> I still was curious to know if bzr was capable of doing that
<mark06> but thanks anyway!
<jelmer> mark06: if you use colocated branches, cloning a bzr directory somewhere should clone all branches
<mark06> I asked because I saw some other extension for git with syntax like git clone bzr::lp:project
<mark06> docs saying that it would clone all branches, but the example was actually with bzr:// protocol and not from launchpad
<mark06> I tried same url style but got a really weird error on windows
<mark06> anyway, next question, is bzr code ready to be compiled under 64-bit?
<mark06> I was thinking about building bzr 2.6 for windows, but it needs to compile on both 32 and 64-bit
<jelmer> mark06: Yeah, it has worked on 64-bit for a long time - for as long as we've been running it on 64-bit Linux machines
<mark06> I saw one windows installer/build project somewhere but can't remember, anyone knows this?
<mark06> why no 64-bit release then jelmer?
<jelmer> mark06: see https://bugs.launchpad.net/bzr/+bug/331342
<ubot5> Ubuntu bug 331342 in Bazaar Windows Installers "bzr python-based installer requires 32-bit python on windows; unclear message" [Medium,Confirmed]
<mark06> so the fix is as easy as making the installer like 64-bit python?
<mark06> what is the installer built with, nsis by any chance?
 * jelmer doesn't have a clue
<mark06> ok
<jelmer> (was never involved with the Windows side of things)
 * mark06 hopes at least 64-bit compiation is not an issue if he ever tries to compile bzr on windows
<mark06> should 2.6 bring reasobable bug fixes and performance on windows as compared to current release 2.5?
<jelmer> mark06: I'm pretty sure it won't be an issue, bzr itself doesn't have anything problematic wrt 64 bit
<mark06> one thing I experience is small display bug with qbzr that I fix by updating the plugin separately.... another issue is that it's really ugly on windows 8... I needed to use compatibility mode
<jelmer> mark06: I'm sure other people would appreciate it if you made a 64bit build and put it out there :)
<mark06> ok I will maybe give it a try if I have time
<mark06> thanks all!
<mark06> good night
#bzr 2018-04-23
<dorian__> Hey there. Our bazaar server was down, so I unbound myself with "bzr unbind" and committed locally with "bzr commit". The server is up again, and when I "bzr bind" myselft my commits show as pending merge. I would like to push them to the server on the main branch so that the bzr history looks like it never had any issue. Do you know how to do that ?
<dorian__> s/bzr history looks like it never had any issue/bzr history looks like the server never had any issue/
