[04:30] <poolie> hi spiv
[04:30] <spiv> Hi poolie.
[06:55] <poolie> hi vila!
[06:55] <vila> poolie: hey ! (Almost there ;)
[06:56] <vila> poolie: I will submit a first config interpolation today (limited to the same file to start with), I just need to polish the docs
[06:57] <vila> same file means you can't have {xxx} defined in a file and interpolated in another
[06:57] <vila> but that will be enough for the package-importer for example
[07:13] <lifeless> what do you mean by interpolation here?
[07:18] <poolie> vila, http://people.canonical.com/~mbp/kanban/vila-kanban.html
[07:18] <poolie> lifeless, i think he means variable expansion
[07:18] <lifeless> ah
[07:19] <lifeless> it might be better to refer to that, and document it as that
[07:19] <lifeless> just a thought
[07:19] <vila> 'that' ?
[07:19] <vila> oh variable expansion ?
[07:20] <vila> hmm, we aren't consistent about 'variable' vs 'option' when referring to configs, I think we should commit to 'option' and update the docs (most of the code if not all use 'option' already)
[07:22] <vila> poolie: so, it's better than I thought, what is missing is some bugs related to the docs (brz-website and/or bzr-all-docs)
[07:22] <vila> no big deal but those are ones I
[07:22] <vila> d like to get rid of today
[07:23] <vila> then there are the pending bugs still assigned to me
[07:23] <poolie> vila, do you have an example of one of those bugs
[07:23] <poolie> i'd like to work out why they're missing
[07:24] <vila> bug #716450 and the answer is: it's not assigned to me ;D
[07:25] <vila> and filed against the wrong project on top of that ;) It should be bzr-all-docs IIRC
[07:25] <poolie> :)
[07:27] <vila> there is also bug #716123, already landed but you asked for some more tweaks there
[07:27] <vila> and then there is 'repair-repo' which should be a wip somewhere
[07:27] <poolie> vila, i doubt i'm going to get to it today (and maintain familial happiness)
[07:28] <vila> this one may overlap with Eric's mp I should check that too
[07:28] <poolie> so could you perhaps help jelmer unblock his two pending mps?
[07:28] <vila> get to what ?
[07:28] <vila> and please maintain familial happiness, fundamental underlying assumption that should never be violated ;)
[07:29] <vila> poolie: the hook ones ? Didn't I already approved them ?
[07:29] <vila> jelmer: just ask ;D
[07:31] <vila> lifeless: what's wrong with interpolation ? I thought it was a pretty standard term for replacing a reference by its value, how do you call it otherwise ? (my query is about english not technic)
[07:32] <lifeless> vila: do you mean taking something like 'lp:$USER/foo/bar' and replacing the $USER with the value of the option USER ?
[07:36] <vila> yup
[07:37] <vila> except it will be lp:{USER}/foo/bar
[07:37] <poolie> if we're going to this, let's be sure to use that style consistently everywhere
[07:37] <poolie> even beyond configs
[07:37] <vila> yup
[07:38] <lifeless> vila: so, thats generally referred to as variable expansion, or macro expansion
[07:38] <vila> it's already used by bugtracker and mergetools, difftool needs to be fixed
[07:38] <lifeless> or substition rather than expansion
[07:39] <vila> ha right I like substitution better, but what does interpolation refer to then ?
[07:39] <lifeless> I've never (until now) seen it referred to as interpolation - interpolation (to me) is a mathematics technique
[07:39] <lifeless> you can generate a curve for some data points by interpolation
[07:39] <poolie> i have seen it called interpolation
[07:39] <poolie> you're inserting the contents of the variable into the string
[07:39] <lifeless> extrapolation is when you try to go beyond the edges of the data set
[07:40] <vila> so, in my mp I introduce a config.interpolate(string), using substitute there... sounds.. weird
[07:40] <poolie> however i agree that is an uncommon word for it
[07:41] <vila> config.expand sound better 8-/
[07:42] <lifeless> huh
[07:42] <lifeless> http://en.wikipedia.org/wiki/Variable_(programming)#Interpolation
[07:42] <lifeless> however, the page has no references :) !cite
[07:43] <vila> ha ! Right, I got it from perl (99% sure)
[07:43] <vila> single quotes don't interpolate, double ones do
[07:44] <poolie> i think 'variable substitution' is a pretty clear unambiguous name
[07:44] <vila> poolie: config.substitute isn't clear though
[07:44] <vila> expand_refs ?
[07:45] <vila> still, 2,840,000 hits from google for 'variable interpolation' is a sign that it's not that unusual...
[07:46] <vila> and s/variable/option/ anyway
[07:47] <vila> . o O (Or should I just use variable and get a new empty name space for free ;-)
[07:47] <vila> config.get_variable ftw ?
[07:47] <vila> no more compatibility problems :D
[07:48] <lifeless> 7M for variable expansion
[07:48] <vila> 7M ?
[07:48] <lifeless> sale for variable substituion
[07:48] <lifeless> vila: count of google hits
[07:48] <vila> ha !
[07:49] <lifeless> 7000000
[07:49] <vila> so config.expand, and 'option', deal ?
[07:52] <poolie> expand_variables or something
[07:52] <poolie> is there a bug for this?
[07:52] <vila> Hmm, I don't remember
[07:53] <vila> It's one item in the config doc in devnotes, it became the most urgent one for me in the package importer context
[07:54] <poolie> oh i see
[07:54] <poolie> how?
[07:55] <vila> 1) testing locally requires a couple of additional tweaks, 2) mthaddon filed a bug asking for the log files to be in a configurable dir
[07:55] <vila> 3) abentley proposed  a mp adding cruft around config POLICY_ which I want to get rid of
[07:55] <poolie> and you want to use one variable to set the importer base, and then to have others relative to that?
[07:56] <vila> exactly
[07:57] <vila> and probably using a p-i specific config file
[07:59] <poolie> ok
[07:59] <vila> 4) implement {nick} handling so I can use 'bzr push' in looms with a 'push_location=lp:~{launchpad_username}/{project}/feature-{nick}' or something
[07:59] <poolie> it's good to add
[07:59] <poolie> it doesn't seem really on the most direct route, but hopefully it's pretty cheap
[08:01] <vila> poolie: ?
[08:03] <poolie> well, it's not strictly needed for getting udd going
[08:03] <poolie> however, it should be a small change, and i can see it being useful elsewhere
[08:05] <poolie> do you see what i mean?
[08:05] <vila> given that I'm testing on a lucid-based setup before deploying to an hardy-based setup and that I want to make *ultra* sure I don't push to lp by mistake, having a single point to check and guarantee that makes testing bearable again (and I don't even mention being ready to get rid of ssh access...)
[08:06] <vila> s/that makes/that, makes/
[08:07] <poolie> hm
[08:07] <poolie> i guess we should separate the configuration out of the tree?
[08:10] <vila> yes, and make sure we don't need to create lp_creds.txt in every test branch too
[08:10] <vila> and so on
[08:11] <vila> there *are* easier short terms fixes but I'd rather implement long term ones before we migrate
[09:58] <vila> babune switched to jenkins http://babune.ladeuil.net:24842/ \o/
[10:33] <pfarrell> I love how bzr diff can use meld .. it's really sexy. I have a quick question: is it possible to get bzr to open all the diffs in meld at once (meld can diff trees of files), rather than open up meld once for each changed file?
[14:35] <jelmer> http://asset.soup.io/asset/1171/4343_1de6_400.jpeg
[16:20] <vila> jelmer: :-D
[16:34] <vila> jelmer: by the way, do you need help with your hook mps ?
[16:43] <jelmer> vila: Yeah, that'd be great. I'm not entirely sure what needs to change, and it'd be great to finish that work.
[16:46] <vila> jelmer: AIUI, the pt1 is ok to go, introducing a central registry can be done as a further submission
[16:47] <vila> jelmer: the other one just need some doc and that should go in doc/en/user-guide/hooks
[16:59] <jelmer> vila: Thanks, I'll land the first and update the second!
[16:59] <vila> go go go ! LD
[17:00]  * jelmer also *finally* has coffee. There shouldn't be any more dodgy MPs today
[17:00] <Tak> coffee? you're well into beer time!
[17:01] <jelmer> heh, depends on where you are I guess :)
[17:22] <jelmer> vila: oh, I see jam beat me to your config-expand-options branch
[17:22] <vila> jelmer: the more the meyer (mayor ?) ;)
[17:23] <jelmer> merrier?
[17:23] <fullermd> meilleur?   :p
[17:26] <vila> fullermd: yeah meilleur but you don't say that in english
[17:26] <fullermd> Well, I don't say it in French either.  Not so's you could understand anyway...
[17:32]  * vila bangs head, vbox is randomly killing vms , 3 times in a raw it killed the one I was working on while also killing a babune one it was supposed to properly shut down :-(
[18:52] <knighthawk> Am I the only one finding the Eclipse plugin extremely buggy? Like I can't even do an update.
[18:56] <maxb> Which eclipse plugin? bzr-eclipse or qbzr-eclipse ?
[19:04] <knighthawk> huh I *think* bzr-eclipse which is the lease buggy?
[19:05] <knighthawk> least
[19:05] <knighthawk> lest
[19:05] <knighthawk> yeah least
[19:09] <maxb> Ah. In my experience bzr-eclipse is just nowhere near finished to an acceptable level of polish
[19:10] <maxb> qbzr-eclipse is much nicer, but doesn't integrate tightly with eclipse for most things - instead it's some minimal eclipse integratation to make it easy to call out to qbzr to do stuff
[19:11] <knighthawk> thanks maxb, I'll give qbzr a try. bzr-eclipse isn't working at all really.
[19:12] <maxb> It's a shame. MercurialEclipse is incredibly good - except for the bit that then I'd have to use Mercurial :-)
[19:14] <lifeless> :)
[19:19] <knighthawk> lol - @ maxb - yeah I *just* moved our shop over to bazaar and if I can't figure out an eclipse solution I afraid we may be moving over to mercurial or worst (IMHO) git.
[19:19] <knighthawk> not that git is bad, just I don't want to have to work with it.
[19:19] <lifeless> so the qbzr developer is pretty active
[19:20] <lifeless> qbzr-eclipse its intended to be lightweight and mostly just driving qbzr
[19:20] <maxb> qbzr-eclipse is currently the best Eclipse/Bazaar solution that I am aware of. It's kind of the only one.
[19:20] <lifeless> there can be only one
[19:20] <lifeless> wait, wrong movie.
[19:20] <knighthawk> lol
[19:21] <knighthawk> I'll give it a try today. but what i need is a tool that will work more or less like the bzr-svn plugins so developers that won't bother to learn the difference can still checkin / update
[19:23] <knighthawk> my core team has been learning bzr and working fine with bzr-explorer on all three platforms (Linux, McOS, Win)  but we have developers outside of my team that need access to the repos. my other options is some kind of bzr-svn bridge but that scares me.
[19:24] <maxb> knighthawk: You mean "like the Eclipse svn plugins" ?
[19:27] <knighthawk> maxb, right. sorry
[19:28] <maxb> Regrettably I don't think there is any true Eclipse Team plugin for Bazaar that's actually worth using. bzr-eclipse is an idea not carried through to completion, whilst qbzr-eclipse is good, but a different way of working
[19:28] <knighthawk> we all use Eclipse (or some sort of Eclipse derivative like Zend Studio or Demandware Studio)
[19:29] <lifeless> first thing is to try qbzr
[19:29] <lifeless> first thing is to try qbzr-eclipse
[19:29] <lifeless> see if its capable of doing what you need
[19:29] <lifeless> failing that talk to guilermo
[19:29] <knighthawk> yeah my fear is that is going to push us to hg (now that I've convinced them that we need a DSVC)
[19:33] <knighthawk> so far my team likes qbzr-eclipse *way* better (I haven't had a chance to look yet) but they aren't really the audience I need to accept it.
[21:29] <axeld> I'm relatively new to bzr, and have a problem with pending merges - does anyone have a little time to help?
[21:30] <axeld> I'm using bzr with a SVN backend, after I pulled the latest changes (via "up"), my local commits were converted to pending merges
[21:30] <axeld> so far so good
[21:31] <axeld> But my local files are now changed again, and neither push, nor dpush find anything to push
[21:31] <axeld> Is there anything I can do besides trying to redo the local commits again?
[21:34] <maxb> axeld: You can't push your local commits whilst they are *pending* merges - you need to commit them first
[21:34] <axeld> maxb: but how? If I do a "bzr commit", it seems to want to commit all changes at once
[21:35] <maxb> Yes
[21:35] <maxb> The change history remains there, in the merged commits
[21:35] <axeld> How does that work with the SVN backend?
[21:36] <maxb> Although, hmm, if you want it directly visible on the svn mainline, that won't quite do what you want
[21:36] <axeld> That was what I was aiming for
[21:37] <maxb> I'm a little confused, because you said you pulled with "up", yet you ended up with pending merges.... are you working in a local branch or a checkout? Perhaps paste 'bzr info' ?
[21:38] <axeld> It's on another machine -- anything particular you're interested in?
[21:38] <maxb> well, whether it's a checkout or a branch, mainly
[21:39] <axeld> It shows the same address for "checkout of branch", "push branch", and "parent branch"
[21:39] <axeld> Location: checkout root: .
[21:39] <maxb> Ah, when you make a local commit, you do 'bzr commit --local' ?
[21:39] <axeld> Exactly
[21:40] <axeld> Has this changed recently, or did I setup the repository differently this time?
[21:40] <maxb> I don't think anything has changed recently
[21:41] <maxb> Right, so if you want your local commits linearized, you need to use rebase, not update
[21:42] <axeld> Can I setup bzr always to do local commits, and only push manually?
[21:42] <axeld> And how do I rebase?
[21:42] <axeld> (after an update, that is)
[21:42] <maxb> To always commit locally, change your checkout into a branch with 'bzr unbind'
[21:43] <maxb> Having unbound, 'update' will no longer attempt to fetch new changes from the remote. You would use 'pull' for that
[21:43] <axeld> great, thanks!
[21:44] <maxb> pull will error if the remote has diverged from your local branch
[21:44] <axeld> Any idea on how I could fix my problem, too? :-)
[21:44] <axeld> Diverged in what way?
[21:45] <axeld> The workflow is that there is a central SVN repository with development going on, and I use bzr in order to be able to commit independently from that, and push my changes from time to time
[21:45] <maxb> Diverged in the sense of the revision graph - i.e. remote has new commits and so do you locally
[21:46] <axeld> And how would I resolve the issue then?
[21:46] <maxb> I think 'bzr rebase --pending-merges' might possibly be what you want in your current branch
[21:47] <axeld> How do I get the rebase extension?
[21:47] <maxb> What is your OS?
[21:47] <axeld> It doesn't seem to be part of the base install
[21:47] <maxb> hmm, have you not been using it before now?
[21:47] <axeld> Ubuntu 10.10
[21:47] <axeld> I've never rebased
[21:47] <axeld> In my old setup, I always used push/pull
[21:48] <axeld> (with an older release)
[21:48] <axeld> Now, I used "up", maybe accidently, but since it worked, I didn't question it
[21:48] <maxb> What did you previously do when there were changes in svn to the branch you were working on locally?
[21:49] <axeld> AFAIR (it's been some time), I just couldn't push my changes if there were changes on the server, and I had to pull first
[21:49] <Odd_Bloke> Hello all.  I'm trying to use bzr-builddeb on a Debian sid box but I'm getting API mismatches (bzr 2.3, builddeb wants 2.2).
[21:49] <Odd_Bloke> james_w: ^
[21:50] <maxb> axeld: But, you would not be able to pull new changes from the server if you had local commits
[21:50] <axeld> maxb: my memory might very well fail me, but that's how I remember it
[21:51] <axeld> maxb: is it possible that rebase is now called rewrite?
[21:51] <maxb> Yes, the plugin has been renamed (but the command has not)
[21:51] <axeld> installing it
[21:52] <axeld> maxb: it says: "no revisions to rebase"
[21:52] <maxb> What exactly did you run?
[21:53] <axeld> maxb: "bzr rebase --pending-merges"
[21:53] <maxb> hmm
[21:53] <maxb> And what does 'bzr st' say?
[21:53] <axeld> It shows the files of my local commits as modified, and lists "pending merge tips"
[21:54] <axeld> okay, just the pending merges when I use -v
[21:54] <maxb> Hmm. I've never used rebase --pending-merges before. It sounds like it is not doing what it claims
[21:54] <axeld> How would I look at those with log?
[21:55] <maxb> look at the pending merges?
[21:55] <axeld> yes
[21:55] <axeld> In order to recreate them again manually :/
[21:55] <maxb> We've not reached the point of that being necessary
[21:56] <axeld> I hope so
[21:56] <axeld> But I am clueless
[21:56] <maxb> First, can you confirm that you have no *uncommitted* changes besides the modifications originating from the merged local commits?
[21:56] <axeld> BTW on the other topic: how would I resolve the case in an unbound repository if I have local commits and new changes in the server?
[21:57] <maxb> Normally one would simply merge.
[21:57] <maxb> Your situation is more complicated because you want to linearize the changes for the sake of how they appear in svn
[21:57] <axeld> maxb: I'm not 100% sure, but pretty much - at least the changed files do contain the changes I already committed locally
[21:57] <axeld> And I don't think I made any other changes afterwards
[21:57] <axeld> exactly
[21:58] <axeld> I would need to rebase the pending merges, the question is just how
[21:58] <maxb> OK, well, if you're in doubt, run a 'bzr diff' and save the output somewhere, because I'm about to ask you to do stuff that throws away the existing modifications in this tree
[21:59] <axeld> alright, I'm ready when you are :-)
[22:01] <maxb> ok, now we're doing to do something slightly messy because bzr doesn't provide a command to get the revision-id of pending merge tips
[22:02] <maxb> sed -n 4p .bzr/checkout/dirstate | xargs -0n1 echo
[22:02] <maxb> will print you the revision ids of the current base of the working tree, plus the pending merge tips
[22:03] <maxb> I'm assuming there's only one pending merge tip, right? (So you got a count of 2, followed by 2 revids?)
[22:04] <maxb> You've already run 'bzr unbind' by now, right?
[22:05] <maxb> If so, 'bzr pull --overwrite -r revid:the-revid-of-the-former-pending-merge-tip . && bzr revert' will put you back to where you were before the 'bzr up'
[22:06] <axeld> I haven't unbound yet, wasn't sure if it was a good idea yet
[22:07] <axeld> And yes, I see a "2", and then two lines, which don't really look like revision IDs, but what do I know
[22:07] <maxb> email@address.tld-stuff is a revid
[22:07] <maxb> So is svn-v4:stuff
[22:08] <axeld> that are the two ids indeed
[22:09] <maxb> The first being a svn-v4 one and the second an email one, right?
[22:09] <axeld> Just wondered why they look so differently - but I guess one is from me, and the other one from SVN trunk
[22:09] <axeld> maxb: exactly
[22:09] <maxb> It's because one is a commit made in svn and translated into bzr, whereas the other is a commit made directly in bzr
[22:09] <axeld> thanks
[22:09] <maxb> OK, so, unbind, pull --overwrite, revert, ....
[22:10] <axeld> which revid is the one I need to pass to pull?
[22:10] <axeld> the svn one?
[22:11] <maxb> the second one, the email
[22:11] <axeld> ok
[22:11] <maxb> The point is, we are resetting your working branch to the state based on your local commits
[22:11] <axeld> ah, okay
[22:11] <axeld> so that's done now, I have no modified files or pending merges anylonger
[22:12] <maxb> right. Now, I don't know why 'rebase --pending-merges' was being awkward, but from where we are now, we should be able to use plain old 'bzr rebase' with no options, to rebase your local commits on top of the new commits found in the parent branch
[22:12] <maxb> So, give that a try :-)
[22:13] <axeld> It says: no revisions to rebase
[22:13] <maxb> this makes no sense
[22:13] <axeld> so that's consistent, at least 8-)
[22:13] <maxb> What does 'bzr missing' say/
[22:13] <maxb> ?
[22:14] <axeld> You have 3 extra revisions
[22:14] <axeld> Those are my local commits
[22:14] <maxb> by definition you have something to rebase, then :-/
[22:15] <axeld> Great; looks like the rebase module doesn't like my setup
[22:16] <maxb> um. so. 'bzr rebase :parent' possibly?
[22:16] <axeld> still says the same
[22:18] <maxb> well, gah, 'bzr rebase' behaves just as I expect for me locally :-/
[22:18] <axeld> In any case, you seem to know a lot about bzr, thanks for trying to help!
[22:19] <maxb> I'm rather perplexed :-/
[22:20] <maxb> Unfortunately I can't think of what to ask, and I'm guessing this project is private?
[22:20] <axeld> yes, unfortunately
[22:21] <axeld> What would happen if I pull or push now?
[22:25] <maxb> wait.... you said 'bzr missing' said "You have 3 extra revisions" ... nothing about extra revisions in the remote?
[22:25] <maxb> gah
[22:25] <maxb> all this talk of rebasing has blinded me to the utterly obvious
[22:25] <maxb> You can just 'bzr push'
[22:26] <maxb> But, if that's so, I still don't understand how 'bzr update' got you to the state of having your local commits as a pending merge :-/
[22:27] <axeld> If I bzr up again, will that bind my repository again?
[22:27] <maxb> No
[22:27] <maxb> 'bzr bind', for that
[22:28] <axeld> okay
[22:28] <axeld> well, great, it's done! Thanks a lot!
[22:28] <maxb> I still don't understand how your revisions got to be a pending merge, but at least they're where they need to be now
[22:29]  * maxb --> afk