[00:15] Yeah [00:18] 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] maxb: ooh, that's quite an incentive :) [00:19] maxb: I need people to review https://code.launchpad.net/~spiv/bzr/branch-revs-to-fetch/+merge/51710 before I can though! [00:20] ah... [00:20] * jelmer waves to poolie, spiv, maxb [00:21] spiv: I had a look earlier today and was wondering if revs_to_fetch() wouldn't be more appropriate on InterBranch [00:22] jelmer: hmm! [00:22] it seems like it should belong on InterBzrDir, but we have no such thing [00:22] I don't think it would belong on InterBzrDir [00:23] spiv: I'm thinking of a case when there are e.g. multiple heads [00:23] like colocated branches [00:24] Well, for the logic we have today that this is a refactoring of, it wouldn't belong on InterBzrDir [00:24] spiv: fair enough [00:25] Colocated branches are an interesting case. [00:25] 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] jelmer: yeah, I didn't remember about InterBranch at all [00:27] It may even make the 'use default local logic' hack in remote.py slightly neater. [00:27] (or maybe not, but worth trying) [00:28] 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] spiv: sure [00:29] I think I can guess pretty well, but not guessing is even better :) [00:29] Also, [00:29] Do you think this is heading in a direction that'll be overall a bit nicer for foreign formats? [00:30] 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] spiv: yeah, I think it is [00:32] That's good to hear. :) === BasicPRO is now known as BasicOSX === Ursinha is now known as Ursinha-afk [04:06] :( [05:00] jelmer: in subvertpy, is there support for svn mergeinfo --show-revs = merged/eligible ? [05:05] 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] yjmbo: hmm, I thought we did allow arbitrary commands somehow [05:25] yjmbo: ah, so I think BZR_SSH doesn't take arbitrary commands, but it does take arbitrary paths [05:26] yjmbo: i.e. you could make a shell script that does "ssh -OIdentityFile=...", and set BZR_SSH to that script. [06:06] 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] 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] yjmbo: you should be able to pass any path, which version of bzr do you have? [06:24] yjmbo: using a path has been supported since 2.1.0 [06:29] 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! === mnepton is now known as mneptok [09:51] morning all [09:54] * fullermd waves at jam. [09:55] fullermd: good to know I'll see you around in any TZ I switch to [09:55] * fullermd is a constant :) [10:13] when i use the cmd bzr branch lp: nova i got the folooeing errorbzr branch lp:nova [10:13] Write failed: Broken pipehing revisions:Inserting stream:Estimate 26772/42003 [10:13] Write failed: Broken pipe [10:13] bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. ट [10:17] Manikandan2: my initial thought would be a local connectivity problem [10:19] Manikandan2: works fine for me [10:22] दक [10:23] ok i will check it thank u [10:23] it is downloading for some, after that only it gives broken pipe error [11:28] is http://wiki.bazaar.canonical.com/BzrHooks still the best info re hooks? [11:32] stefanlsd: probably not [11:32] 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] aah. thanks. yeah [11:33] (which is where that wiki page tries to link to, but its links are a bit stale) [11:54] 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] maxb: Branch's post_change_branch_tip perhaps matches better. [11:55] Although I guess lock_released will catch updates to tags too. [11:55] spiv: Unforunately that will fail to tell me about tags changing [11:55] yup [11:56] We should at a hook point for that! [11:56] tags in general need some love [11:56] Well, at least tagged revisions are (mostly) fetched now. [11:56] I would like to see info on new/changed tags reported by push/pull [11:57] *nod* [11:57] Also, merging tags probably should omit revisions not in the ancestry of the destination branch [11:58] Hmm, I'm not sure about that. [11:58] oh? [11:59] 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] Partly because tags are merged in several different contexts. [12:10] 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] not-in-ancestry != not-present [12:22] But I think there are probably cases where even tags of ghost revisions may be useful. [12:22] Anyway, zzzz time. [12:42] hi spiv [12:42] bye spiv :) [12:49] hallo everyone [12:49] I had some conflicts, but I didn't care about the changes [12:49] so I removed simply them and pull again [12:49] but they don't get pulled [12:49] can I force this somehow? [12:50] with git I think they are written if you remove them [12:56] If you pulled, got conflicts, and reverted them, then you already have the changes, so there is nothing new to pull. === Ursinha-afk is now known as Ursinha [13:53] is there a windows installer that includes bzr and bzr-svn? [13:54] exarkun: the default installer includes bzr-svn I believe [13:55] hm, I guess that is what http://wiki.bazaar.canonical.com/WindowsDownloads suggests [13:55] I wonder why it's not working [13:55] I think you have to click a checkbox in the setup to enable it [14:30] jelmer: Hi. You've not pushed bzr-rewrite 0.6.2 into lp:bzr-rewrite [14:30] maxb: it's a mirror [14:30] maxb: might take a while to update [14:30] ah [14:30] grr, LP should make that more prominent [14:33] maxb: btw, you're aware you have two approved reviews for landing into bzr-cvsps-import? [14:33] uhm, s/reviews/mps/ [14:33] *blink* [14:35] Oh, they've been re-opened by jam's delayed merge proposal emails === zyga is now known as zyga-food [15:07] jelmer: so what hours do you usually work? [15:07] jam: 10-6 CET [15:08] jelmer: so for another ~2 hrs? [15:08] I think I'm shooting for 8:30 - 5 CET myself. [15:09] 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] jam: I think that (8:30-5) is roughly the hours vila works, too [15:10] jelmer: I'm pretty sure vila works until past 6 or 7. At least, that's what I recall from the US :) [15:11] jam: I guess it's probably more like 8:30-7:00 :) [15:11] I'm often around in the evenings too [15:11] I just hate mornings. [15:12] 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] jam is in europe? [15:30] * jelmer heads out to vote and errands [15:42] mgz: I just moved. My wife got a promotion for 2 years in the Netherlands. [15:43] great! more timezone overlap means I get to bug you even more? :) === zyga-food is now known as zyga [15:52] mgz: /ignore, /ignore /ignore, dangit, it just doesn't work [15:52] :) [16:34] this is a silly question, but... how can i push a branch to just a filesystem? [16:34] say i have a local branch, and i have an account on a remote machine [16:34] i just want to push my branch to a directory on the remote machine somewhere [16:35] achiang, if bzr is on the remote machine then "bzr push bzr+ssh:///remote/some/path" should work [16:35] if it's not installed then use "sftp://" [16:35] james_w: great, thank you. i had my syntax wrong, was missing an extrah '/' [16:36] achiang, err, I think I added an extra one actually :-) [16:36] oh [16:36] achiang, what error did you get? [16:36] james_w: it was a conceptual misunderstanding on my part [16:37] james_w: i was attempting to use scp/rsync semantics, like such: [16:37] ah [16:37] bzr push bzr+ssh://remote:./local/path/in/home/dir [16:37] but bzr push bzr+ssh://remote/home/achiang/local/path/in/home/dir works [16:37] if you have modern bzr on the server then ~ will work [16:38] bzr+ssh://remote/~/local/path/in/home/dir [16:38] Bazaar (bzr) 2.1.1 [16:38] I can't remember the version that was added, sorry [16:40] james_w: no worries, i got it to work [16:40] i think this is actually nicer than git; iirc, you must git init first before you can push somewhere [16:41] git init on the remote machine, that is; rather simply pushing and creating a new repo [16:41] so kudos to bzr for Doing The Right Thing (tm) [16:44] 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] achiang, "bzr pull" [16:44] james_w: ah, thank you [16:45] james_w: much nicer, thanks! [16:47] achiang, oh yeah, there's "bzr merge --pull", which is more like "git merge", and does the fast-forward if it can [16:47] it doesn't auto-commit like git [16:47] git merge definitely introduces a merge commit there [16:48] in git, i usually say, "git fetch ; git rebase " where is usually 'origin' [16:48] that does a fast-forward thingy, but it's only good for leaf-node developers [16:49] 'bzr pull' does what i want in the simple case quite nicely [16:50] sorry, I meant "git pull" [16:51] If your branch is a strict ancestor of upstream, then bzr pull is what you want [16:52] (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] that terminology is confusing. shouldn't it be "descendent" ? [16:53] No... your branch being an ancestor, meaning it's older than... Upstream will be newer, having more commits.. [16:53] So pull just introduces those revisions into your branch, from upstream [16:54] LeoNerd: got it, that makes sense... kinda. :) [16:54] achiang: I think the confusion comes from provenance (where did the branches originate) vs contents (revisions) [16:55] I too was initially confused reading LeoNerd's description [16:56] yes, i think most people think of provenance when it comes to terminology (ancestors, children) rather than contents [16:56] but i appreciate all the explanations, very helpful, thanks === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno === zyga is now known as zyga-afk === zyga-afk is now known as zyga === Ursinha is now known as Ursinha-food === wallyworld___ is now known as wallyworld === medberry is now known as Guest57670 [21:28] 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] yshavit, it's now taken care of as far as merging those particular revisions [21:29] of course another one way occur in future [21:29] poolie: but it's not like every branch/merge from that branch is now going to have that, right? [21:33] no [21:33] poolie: awesome, thanks :) [21:35] it's not really a problem if this occurs [21:35] basically it means A is merging from B and B is merging from A, without them ever pulling [21:35] which is fine [21:35] but the conflicts will sometimes get more complicated than if they both merge to and pull from a trunk [21:36] poolie: okay, thanks. I was pretty sure that was the case, I just wanted to make sure since I hadn't seen that before. === Ursinha-food is now known as Ursinha [22:56] Morning folks.