[00:15] <spiv> Yeah
[00:18] <maxb> spiv: If you land your loom bzr-2.4 branch, then I think we can celebrate the daily builds PPA being all green for the first time ever :-)
[00:19] <spiv> maxb: ooh, that's quite an incentive :)
[00:19] <spiv> maxb: I need people to review https://code.launchpad.net/~spiv/bzr/branch-revs-to-fetch/+merge/51710 before I can though!
[00:20] <maxb> ah...
[00:20]  * jelmer waves to poolie, spiv, maxb
[00:21] <jelmer> spiv: I had a look earlier today and was wondering if revs_to_fetch() wouldn't be more appropriate on InterBranch
[00:22] <spiv> jelmer: hmm!
[00:22] <jelmer> it seems like it should belong on InterBzrDir, but we have no such thing
[00:22] <spiv> I don't think it would belong on InterBzrDir
[00:23] <jelmer> spiv: I'm thinking of a case when there are e.g. multiple heads
[00:23] <jelmer> like colocated branches
[00:24] <spiv> Well, for the logic we have today that this is a refactoring of, it wouldn't belong on InterBzrDir
[00:24] <jelmer> spiv: fair enough
[00:25] <spiv> Colocated branches are an interesting case.
[00:25] <jelmer> spiv: still, I think InterBranch might be a better location than Branch as that e.g. allows custom InterBranch implementations to override the behaviour
[00:26] <spiv> jelmer: yeah, I didn't remember about InterBranch at all
[00:27] <spiv> It may even make the 'use default local logic' hack in remote.py slightly neater.
[00:27] <spiv> (or maybe not, but worth trying)
[00:28] <spiv> Can you maybe elaborate a little in a review comment about the sort of thing that custom InterBranch would want to do here?
[00:28] <jelmer> spiv: sure
[00:29] <spiv> I think I can guess pretty well, but not guessing is even better :)
[00:29] <spiv> Also,
[00:29] <spiv> Do you think this is heading in a direction that'll be overall a bit nicer for foreign formats?
[00:30] <spiv> I'm pretty happy that it's made it pretty easy to improve the way bzr-loom fetches, but that's also a pretty similar format to the builtin ones in that it has a regular bzr repo underneath it.
[00:31] <jelmer> spiv: yeah, I think it is
[00:32] <spiv> That's good to hear.  :)
[04:06] <lifeless> :(
[05:00] <amriedle> jelmer: in subvertpy, is there support for svn mergeinfo --show-revs = merged/eligible ?
[05:05] <yjmbo> I'd like to use bzr+ssh:// to get to a branch, in a cron scripted task. I need to specify a keyfile for authentication. I don't see any way to pass options to the ssh command (i.e. like rsync does), and this task doesn't really have an associated user account, so no ~/.bazaar directory to leave a config file. BZR_SSH doesn't allow arbitrary commands to be used. How can I achieve this?
[05:24] <spiv> yjmbo: hmm, I thought we did allow arbitrary commands somehow
[05:25] <spiv> yjmbo: ah, so I think BZR_SSH doesn't take arbitrary commands, but it does take arbitrary paths
[05:26] <spiv> yjmbo: i.e. you could make a shell script that does "ssh -OIdentityFile=...", and set BZR_SSH to that script.
[06:06] <yjmbo> spiv, I tried point to a script with BZR_SSH, but it had to have a pre-approved name. So I called it 'ssh', put it first in PATH, and accidentally fork-bombed my server.
[06:06] <yjmbo> When my server recovers I'll try again :-) But it looks like the only way to pass ssh options is to fake the environment, rather than explicitly pass them in.
[06:22] <spiv> yjmbo: you should be able to pass any path, which version of bzr do you have?
[06:24] <spiv> yjmbo: using a path has been supported since 2.1.0
[06:29] <yjmbo> spiv, it should be 2.1.1 but I cannot tell you what happened when I tried because I've lost that server session. Need an intervention from the VM host to get back in, too. I'll try again tomorrow and see what happens then!
[09:51] <jam> morning all
[09:54]  * fullermd waves at jam.
[09:55] <jam> fullermd: good to know I'll see you around in any TZ I switch to
[09:55]  * fullermd is a constant   :)
[10:13] <Manikandan2> when i use the cmd bzr branch lp: nova i got the folooeing errorbzr branch lp:nova
[10:13] <Manikandan2> Write failed: Broken pipehing revisions:Inserting stream:Estimate 26772/42003
[10:13] <Manikandan2> Write failed: Broken pipe
[10:13] <Manikandan2> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.          ट
[10:17] <maxb> Manikandan2: my initial thought would be a local connectivity problem
[10:19] <maxb> Manikandan2: works fine for me
[10:22] <Manikandan2> दक
[10:23] <Manikandan2> ok i will check it thank u
[10:23] <Manikandan2> it is downloading for some, after that only it gives broken pipe error
[11:28] <stefanlsd> is http://wiki.bazaar.canonical.com/BzrHooks still the best info re hooks?
[11:32] <spiv> stefanlsd: probably not
[11:32] <spiv> stefanlsd: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/hooks-help.html and http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/hooks.html are better I think
[11:32] <stefanlsd> aah. thanks. yeah
[11:33] <spiv> (which is where that wiki page tries to link to, but its links are a bit stale)
[11:54] <maxb> I'm contemplating some plugin to automatically sync branches from one server to a backup when they change. I'm thinking LockHooks.lock_released is the best way for me to do this. Anyone have some thoughts on that?
[11:55] <spiv> maxb: Branch's post_change_branch_tip perhaps matches better.
[11:55] <spiv> Although I guess lock_released will catch updates to tags too.
[11:55] <maxb> spiv: Unforunately that will fail to tell me about tags changing
[11:55] <maxb> yup
[11:56] <spiv> We should at a hook point for that!
[11:56] <maxb> tags in general need some love
[11:56] <spiv> Well, at least tagged revisions are (mostly) fetched now.
[11:56] <maxb> I would like to see info on new/changed tags reported by push/pull
[11:57] <spiv> *nod*
[11:57] <maxb> Also, merging tags probably should omit revisions not in the ancestry of the destination branch
[11:58] <spiv> Hmm, I'm not sure about that.
[11:58] <maxb> oh?
[11:59] <spiv> I'm just not sure enough of the use cases to have a strong opinion, but my suspicion is that at least some users expect tags to never be omitted by default.
[12:01] <spiv> Partly because tags are merged in several different contexts.
[12:10] <maxb> Hmm. I'm trying to think of a way in which a tag referring to a non-present revision id would be useful
[12:21] <spiv> not-in-ancestry != not-present
[12:22] <spiv> But I think there are probably cases where even tags of ghost revisions may be useful.
[12:22] <spiv> Anyway, zzzz time.
[12:42] <jam> hi spiv
[12:42] <jam> bye spiv :)
[12:49] <empity> hallo everyone
[12:49] <empity> I had some conflicts, but I didn't care about the changes
[12:49] <empity> so I removed simply them and pull again
[12:49] <empity> but they don't get pulled
[12:49] <empity> can I force this somehow?
[12:50] <empity> with git I think they are written if you remove them
[12:56] <maxb> If you pulled, got conflicts, and reverted them, then you already have the changes, so there is nothing new to pull.
[13:53] <exarkun> is there a windows installer that includes bzr and bzr-svn?
[13:54] <jelmer> exarkun: the default installer includes bzr-svn I believe
[13:55] <exarkun> hm, I guess that is what http://wiki.bazaar.canonical.com/WindowsDownloads suggests
[13:55] <exarkun> I wonder why it's not working
[13:55] <jelmer> I think you have to click a checkbox in the setup to enable it
[14:30] <maxb> jelmer: Hi. You've not pushed bzr-rewrite 0.6.2 into lp:bzr-rewrite
[14:30] <jelmer> maxb: it's a mirror
[14:30] <jelmer> maxb: might take a while to update
[14:30] <maxb> ah
[14:30] <maxb> grr, LP should make that more prominent
[14:33] <jelmer> maxb: btw, you're aware you have two approved reviews for landing into bzr-cvsps-import?
[14:33] <jelmer> uhm, s/reviews/mps/
[14:33] <maxb> *blink*
[14:35] <maxb> Oh, they've been re-opened by jam's delayed merge proposal emails
[15:07] <jam> jelmer: so what hours do you usually work?
[15:07] <jelmer> jam: 10-6 CET
[15:08] <jam> jelmer: so for another ~2 hrs?
[15:08] <jam> I think I'm shooting for 8:30 - 5 CET myself.
[15:09] <jelmer> yep, although I'll probably head out a bit earlier today and then do some more work around the UDD meeting in the evening
[15:09] <jelmer> jam: I think that (8:30-5) is roughly the hours vila works, too
[15:10] <jam> jelmer: I'm pretty sure vila works until past 6 or 7. At least, that's what I recall from the US :)
[15:11] <jelmer> jam: I guess it's probably more like 8:30-7:00 :)
[15:11] <jelmer> I'm often around in the evenings too
[15:11] <jelmer> I just hate mornings.
[15:12] <jam> I think vila nominally stops at 5, but he almost never actually stopped then. At least, I remember him saying around 10 that he should go, and 10+7 = 5pm.
[15:14] <mgz> jam is in europe?
[15:30]  * jelmer heads out to vote and errands
[15:42] <jam> mgz: I just moved. My wife got a promotion for 2 years in the Netherlands.
[15:43] <mgz> great! more timezone overlap means I get to bug you even more? :)
[15:52] <jam> mgz: /ignore, /ignore /ignore, dangit, it just doesn't work
[15:52] <jam> :)
[16:34] <achiang> this is a silly question, but... how can i push a branch to just a filesystem?
[16:34] <achiang> say i have a local branch, and i have an account on a remote machine
[16:34] <achiang> i just want to push my branch to a directory on the remote machine somewhere
[16:35] <james_w> achiang, if bzr is on the remote machine then "bzr push bzr+ssh:///remote/some/path" should work
[16:35] <james_w> if it's not installed then use "sftp://"
[16:35] <achiang> james_w: great, thank you. i had my syntax wrong, was missing an extrah '/'
[16:36] <james_w> achiang, err, I think I added an extra one actually :-)
[16:36] <achiang> oh
[16:36] <james_w> achiang, what error did you get?
[16:36] <achiang> james_w: it was a conceptual misunderstanding on my part
[16:37] <achiang> james_w: i was attempting to use scp/rsync semantics, like such:
[16:37] <james_w> ah
[16:37] <achiang> bzr push bzr+ssh://remote:./local/path/in/home/dir
[16:37] <achiang> but bzr push bzr+ssh://remote/home/achiang/local/path/in/home/dir works
[16:37] <james_w> if you have modern bzr on the server then ~ will work
[16:38] <james_w>  bzr+ssh://remote/~/local/path/in/home/dir
[16:38] <achiang> Bazaar (bzr) 2.1.1
[16:38] <james_w> I can't remember the version that was added, sorry
[16:40] <achiang> james_w: no worries, i got it to work
[16:40] <achiang> i think this is actually nicer than git; iirc, you must git init first before you can push somewhere
[16:41] <achiang> git init on the remote machine, that is; rather simply pushing and creating a new repo
[16:41] <achiang> so kudos to bzr for Doing The Right Thing (tm)
[16:44] <achiang> james_w: another dumb question -- what's the best way for a local repo to sync back up with upstream? i've been using bzr merge ; bzr commit, which isn't so nice because it introduces a merge commit. is there an equivalent to git's fast-forward?
[16:44] <james_w> achiang, "bzr pull"
[16:44] <achiang> james_w: ah, thank you
[16:45] <achiang> james_w: much nicer, thanks!
[16:47] <james_w> achiang, oh yeah, there's "bzr merge --pull", which is more like "git merge", and does the fast-forward if it can
[16:47] <james_w> it doesn't auto-commit like git
[16:47] <achiang> git merge definitely introduces a merge commit there
[16:48] <achiang> in git, i usually say, "git fetch ; git rebase <refspec>" where <refspec> is usually 'origin'
[16:48] <achiang> that does a fast-forward thingy, but it's only good for leaf-node developers
[16:49] <achiang> 'bzr pull' does what i want in the simple case quite nicely
[16:50] <james_w> sorry, I meant "git pull"
[16:51] <LeoNerd> If your branch is a strict ancestor of upstream, then  bzr pull  is what you want
[16:52] <LeoNerd> (You can tell this by  bzr missing  only listing revisions you don't have, not extra ones you have that upstream does not)
[16:52] <achiang> that terminology is confusing. shouldn't it be "descendent" ?
[16:53] <LeoNerd> No... your branch being an ancestor, meaning it's older than... Upstream will be newer, having more commits..
[16:53] <LeoNerd> So  pull  just introduces those revisions into your branch, from upstream
[16:54] <achiang> LeoNerd: got it, that makes sense... kinda. :)
[16:54] <briandealwis> achiang: I think the confusion comes from provenance (where did the branches originate) vs contents (revisions)
[16:55] <briandealwis> I too was initially confused reading LeoNerd's description
[16:56] <achiang> yes, i think most people think of provenance when it comes to terminology (ancestors, children) rather than contents
[16:56] <achiang> but i appreciate all the explanations, very helpful, thanks
[21:28] <yshavit> Hi all, I've got a criss-cross warning on a bzr merge... there's only a couple conflicts and they're pretty easy to resolve. If I manually resolve them, is the criss-cross taken care of, or does it still linger (ie, will it cause problems down the line) ?
[21:29] <poolie> yshavit, it's now taken care of as far as merging those particular revisions
[21:29] <poolie> of course another one way occur in future
[21:29] <yshavit> poolie: but it's not like every branch/merge from that branch is now going to have that, right?
[21:33] <poolie> no
[21:33] <yshavit> poolie: awesome, thanks :)
[21:35] <poolie> it's not really a problem if this occurs
[21:35] <poolie> basically it means A is merging from B and B is merging from A, without them ever pulling
[21:35] <poolie> which is fine
[21:35] <poolie> but the conflicts will sometimes get more complicated than if they both merge to and pull from a trunk
[21:36] <yshavit> poolie: okay, thanks. I was pretty sure that was the case, I just wanted to make sure since I hadn't seen that before.
[22:56] <spiv> Morning folks.