=== robbyoconnor is now known as r0bby
=== r0bby is now known as robbyoconnor
[00:27] <JPeterson> "bzr branch lp:jp-test ." returns " Target directory "." already exists."
[00:27] <JPeterson> how do i fix it?
[00:28] <fullermd> branch has a --use-existing-dir.  But are you sure you want to drop the branch right in '.'?  (as opposed to ./jp-test/)
[01:32] <JPeterson> thx
[01:35] <felipec> it looks like I can do ControlDir.open('lp;foo'), and operate in in the branch as if it was local... but the operations are too slow
[01:36] <felipec> is there a facility to have an intermediary local branch?
[01:37] <fullermd> Pretty sure not really.  The facility looks like "bzr branch lp:foo local ; ControlDir.open('local')"   8-}
[01:39] <felipec> fullermd: yeah, I'm doing something like that, but what happens when I want to push to lp:foo?
[01:40] <felipec> I guess I need to pull and push to make sure they are in sync
[01:40] <felipec> I thought perhaps this concept of 'bound' branches would help
[01:40] <fullermd> Oh, you can "push lp:foo" or "push :parent" or (after the first time) just plain "push", depending on when/if you expect somebody to fiddle your branch behind your back.
[01:41] <fullermd> That would also be a possibility, as long as you're OK with things happening upstream the moment you do them (and handling the case of upstream moving behind your back).
[01:43] <felipec> hmm, I'm not sure
[01:44] <felipec> maybe I should do a clone for the initial import, and after that push directly to the server
[02:12] <JPeterson> "https://code.launchpad.net/~john-peterson3/calibre/calibre/+merge/132832" returned "Timeout error Sorry, something just went wrong in Launchpad. We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience. Trying again in a couple of minutes might work. (Error ID: OOPS-342f8cc9c38bf1ad53e6f28f3f2c2db4)"
[03:09] <felipec> I'm reading about bound branches... supposedly when a commit is made on the local branch, it should be pushed to the parent branch
[03:09] <felipec> no?
[03:10] <fullermd> Correct.
[03:11] <felipec> fullermd: but the API doesn't do that...
[03:12] <fullermd> Well, I don't know at what level the magic happens.  Are you sure you actually made a bound branch?
[03:13] <felipec> fullermd: branch.bind(remote_branch)
[03:13] <bob2> don't do bound branches
[03:16] <felipec> looks like in addition to builder.commit, I need to import_last_revision_info_and_tags
[05:01] <AfC> bob2: well, bound branches are part of the magic fairy dust that makes `bzr switch` work, at which point you have a the ability to reuse a Working Tree across different Branches
[05:02] <bob2> sadness
[05:03] <bob2> I underspecified, binding to shared repos is my concern
[06:07] <lifeless> AfC: huh? switch works fine w/out bound branches
[06:08] <AfC> lifeless: really? That's new
[06:09] <AfC> lifeless: when I learnt it, you had to have a checkout to be able to switch
[06:09] <JPeterson> holy cow how do i remove this https://code.launchpad.net/~john-peterson3/calibre/calibre/+merge/132832/comments/285737 message? it's a duplicate message.
[06:09] <JPeterson> do i have to fraking ask an admin to remove my own messages?
[06:10] <lifeless> AfC: lightweight checkouts work fine
[06:14] <JPeterson> admin moron? can you delete my message?
[06:15] <JPeterson> it's a  duplicate. it's worthless. it must be deleted.
[06:19] <AfC> lifeless: um, ok. I guess I would have said that's still a checkout. Happy to be corrected, cheers.
[06:19] <AfC> lifeless: [still a bother to set up]
[06:21] <lifeless> AfC: it is a checkout, but its not a bound branch
[06:21] <lifeless> AfC: all the bound branch complexity can't happen in a lightweight checkout
[06:25] <AfC> lifeless: fair enough
[06:26] <bob2> a) #launchpad
[06:26] <bob2> b) not being a dick is helpful when asking for something
[08:13] <mathrick_> how can I add extra "see also" for a command?
[08:21] <vila> mathrick_: look for _see_also examples in bzrlib/builtins.py
[08:24] <mgz> morning!
[08:24] <fullermd> Again?  I just dealt with one of those yesterday...
[08:25] <mathrick_> vila: ah, thanks. I was looking for that in bzrlib.commands.Command, but it isn't documented it seems
[08:25] <vila> mathrick_: quite possible, there is a leading '_' after all ;)
[08:27] <mathrick_> hmm, right. Why does it have that, though?
[08:27] <mathrick_> it doesn't seem like something "internal" to me
[08:31] <vila> mathrick_: hysterical raisins, I can't see why it's not public indeed (but I may miss some detail...)
[08:32] <mathrick_> btw, it seems like a missed opportunity that bzr help plugins/foo doesn't list the commands provided
[08:38] <vila> mathrick_: patches welcome ;) That sounds like a good idea. I don't remember what's the default behavior is but I think a plugin can already do that...
[08:39] <vila> at least 'bzr help qbzr' does (usual kudos to our qbzr friends ;)
[08:39] <mathrick_> vila: I believe it's simply hardcoded into the docstring
[08:39] <mathrick_> all the plugins I've seen do that
[08:40] <vila> indeed it is
[09:12] <vila> fullermd: urgh, bug #1075213 gives me a headache :-/
[09:12] <ubot5> Error: Launchpad bug 1075213 could not be found
[09:12] <vila> see ?
[09:12] <vila> bug #1072513
[09:12] <ubot5> Launchpad bug 1072513 in Bazaar "log can show too few revs" [High,New] https://launchpad.net/bugs/1072513
[09:16] <vila> fullermd: but basically I think it's related to -v inspecting all the *file* revs while !-v looks at the ancestry graph
[09:17] <vila> fullermd: by "file revs" I mean the existing file texts that are referenced in the revision inventories
[10:29] <mathrick_> uhh, is that expected behaviour?
[10:29] <mathrick_> C:\Users\Trendware\Dev\bzr-submit>bzr info ./this-doesnt-exist
[10:29] <mathrick_> Standalone tree (format: 2a)
[10:29] <mathrick_> Location:
[10:29] <mathrick_>   branch root: .
[10:29] <mathrick_> ie. no error being returned
[10:32] <vila> mathrick_: yes. 'bzr info' walks upward from the location you give so it ends up in C:\Users\Trendware\Dev\bzr-submit which is a real branch
[10:33] <mathrick_> that's pretty counterintuitive to me
[10:33] <mathrick_> though it might be because I want to check for a branch that (possibly) lives in a subdir, so I want it to error out on non-existent location
[10:39] <mathrick_> if I trigger pdb on a bzr error (with BZR_PDB=1), how can I inspect the exception that caused the debugger to step in?
[10:41] <vila> meh, no general answer for that, it depends on where the debugger puts you in, you may try so start with 'pp locals()' maybe
[10:41]  * vila off for errands
[10:42] <mathrick_> perhaps exc_info() will help
[12:47] <hasselmm> any reason bzr doesn't install the grep plugin by default?
[12:51] <ReekenX> How to what will be changed from repository without running `bzr up`?
[12:51] <ReekenX> I can't find on Google anything related to this
[12:52] <mathrick_> ReekenX: you're missing a word in your question, it makes it unclear
[12:52] <mathrick_> try repeating it
[12:53] <ReekenX> mathrick_: Before updating a code with `bzr up` I want see changes coming (what will be changed in my source code).
[12:53] <mathrick_> hmm, what is the API to use when I want to ensure I'm in a branch, and not a repo?
[12:54] <mathrick_> ReekenX: try bzr missing :bound
[12:56] <ReekenX> mathrick_: Thanks a lot! And sorry for poor english skills (trying to improve).
[12:57] <mathrick_> that's alright, it just looked like you missed a word
[12:57] <mathrick_> ReekenX: btw, note that with lightweight checkouts, it won't work. Lightweight checkouts are pretty hard to inspect in general, because they have almost no state on their own
[13:31] <mathrick_> hrmpf
[13:32] <mathrick_> how do I distinguish between NotBranchError meaning "location doesn't exist" and "location is a repository"?
[13:32] <mathrick_> I want to error out only if I get a repo, but not when I get a branch or a non-existent location
[13:41] <vila> mathrick_: bzrlib.branch.Branch.open() ?
[13:42] <mathrick_> vila: but won't it also give me NotBranchError on non-existent paths?
[13:42] <vila> from memory, I can't say
[13:43] <vila> mathrick_: writing a test for it will allow you to explore at will
[13:45] <mathrick_> poking reveals it will
[13:46] <mathrick_> oh well, not that important
[13:46] <mathrick_> I will get it right later
[14:03] <mathrick_> OK, what is the canonical way to set the submit location?
[14:05] <mathrick_> from the command line, that is, and/or programmatically
[14:07] <mathrick_> aha, bzr config submit_branch="../upstream"
=== ReekenX is now known as ReekenX|AFK
[15:31] <fullermd> vila: Well, if it weren't headache-inducing, what would be the fun in filing the bug?   ;p
[15:31] <vila> mathrick_: yup, 'bzr config' is the manual way (bzr config --remove may help too)
[15:31] <vila> fullermd: hehe
[15:33] <vila> fullermd: I didn't dig enough to fully understand (I mainly tried the script with make_dir=false and looked at the branches with bzr qlog A B C)
[15:33] <vila> fullermd: the only weird thing I noticed that was you were merging older versions of the branch itself
[15:33] <vila> fullermd: nothing illegal there but the result may be confusing for the user
[15:34] <fullermd> Oh, that's not enough.  You don't really have a headache until you start commenting out the [1] lines and watching new revs start appearing like magic.
[15:35] <fullermd> Well, the Real Branch where I first ran across it was a little twisty in how it came together; that was the simplest way I could come up with to reproduce it.
[15:36] <vila> fullermd: I have no doubts the real one was even harder to grasp...
[15:36] <vila> fullermd: any of the [1] ? In a particular order ?
[15:37] <fullermd> Nope.  For every one you comment out, one more of the "right" revs shows up in the log output.  So any 3 of them, and all 4 "right" revs show up.
[15:38] <fullermd> Or uncomment the exit in the [2] block; that causes 2 of them to show up.  So skipping [2] via the exit, and commenting out any 1 of the [1]'s, and everything works right too   :)
[15:39] <fullermd> No correspondence between which one you comment out and which "right" rev shows up; they always uncover themselves in the same order.  Neat, huh?
[15:43] <vila> fullermd: hmpf
[15:44] <fullermd> The Particular Magic in the real case that I copied into the test case was how one branch off trunk added a dir with a couple files and was merged, and then another branch that started off trunk from before that landed merged trunk with those changes, made other changes in the dir, then was itself landed on trunk.
[15:45] <fullermd> But I had to add in those --unchanged rev in the test case (in the real case there were of course real commits to other stuff in the tree before/after the revs touching the dir in those landings) to make it start showing up.
[15:48] <fullermd> So I didn't actually discover that quirk by removing them and watching stuff show up; when the test worked right while the real didn't, I started adding them and watched stuff _disappear_   8-}
[15:48] <fullermd> Perhaps you could hear me whimpering and curled up in the corner when that happened...
[16:03] <fullermd> vila: Incidentally; I just tested; the extra merge in [2] isn't itself apparently part of the necessary special sauce.  Replacing that block with 2 more --unchanged revs on C has the same effect.  So there's one more step of simpliciation.
[16:05] <fullermd> (it would be simplification, but that's more letters, so obviously not as simple...)
[16:08] <fullermd> I guess I should note that on the bug, so future generations can share in the WTF.
[16:10] <vila> fullermd: yup (sry otp) (and yes, less letters is simpler)
[16:11] <fullermd> Say hi to whoever it is for me  ;>
[16:51] <fullermd> vila: There's the updated script and some notes on the bug.  Y'know, just in case that headache went away   8-}
[16:55] <vila> fullermd: cool, I'll update mine
[16:56] <fullermd> Slightly more normal looking history without the extra merge.
[16:58] <fullermd> http://picpaste.com/pics/qlog.1352134680.png
[16:59] <fullermd> Though I did add a few extra notes about tweaks you can do to the "Merge A:1" without affecting the outcome, just to muddy the waters up a bit...
[17:09] <fullermd> Anyway.  Headache widely shared; my work here is done!
=== yofel_ is now known as yofel
=== iBasic is now known as BasicOSX