spiv | Yeah | 00:15 |
---|---|---|
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:18 |
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:19 |
maxb | ah... | 00:20 |
* jelmer waves to poolie, spiv, maxb | 00:20 | |
jelmer | spiv: I had a look earlier today and was wondering if revs_to_fetch() wouldn't be more appropriate on InterBranch | 00:21 |
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:22 |
jelmer | spiv: I'm thinking of a case when there are e.g. multiple heads | 00:23 |
jelmer | like colocated branches | 00:23 |
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:24 |
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:25 |
spiv | jelmer: yeah, I didn't remember about InterBranch at all | 00:26 |
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:27 |
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:28 |
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:29 |
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:30 |
jelmer | spiv: yeah, I think it is | 00:31 |
spiv | That's good to hear. :) | 00:32 |
=== BasicPRO is now known as BasicOSX | ||
=== Ursinha is now known as Ursinha-afk | ||
lifeless | :( | 04:06 |
amriedle | jelmer: in subvertpy, is there support for svn mergeinfo --show-revs = merged/eligible ? | 05:00 |
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:05 |
spiv | yjmbo: hmm, I thought we did allow arbitrary commands somehow | 05:24 |
spiv | yjmbo: ah, so I think BZR_SSH doesn't take arbitrary commands, but it does take arbitrary paths | 05:25 |
spiv | yjmbo: i.e. you could make a shell script that does "ssh -OIdentityFile=...", and set BZR_SSH to that script. | 05:26 |
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:06 |
spiv | yjmbo: you should be able to pass any path, which version of bzr do you have? | 06:22 |
spiv | yjmbo: using a path has been supported since 2.1.0 | 06:24 |
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! | 06:29 |
=== mnepton is now known as mneptok | ||
jam | morning all | 09:51 |
* fullermd waves at jam. | 09:54 | |
jam | fullermd: good to know I'll see you around in any TZ I switch to | 09:55 |
* fullermd is a constant :) | 09:55 | |
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:13 |
maxb | Manikandan2: my initial thought would be a local connectivity problem | 10:17 |
maxb | Manikandan2: works fine for me | 10:19 |
Manikandan2 | दक | 10:22 |
Manikandan2 | ok i will check it thank u | 10:23 |
Manikandan2 | it is downloading for some, after that only it gives broken pipe error | 10:23 |
stefanlsd | is http://wiki.bazaar.canonical.com/BzrHooks still the best info re hooks? | 11:28 |
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:32 |
spiv | (which is where that wiki page tries to link to, but its links are a bit stale) | 11:33 |
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:54 |
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:55 |
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:56 |
spiv | *nod* | 11:57 |
maxb | Also, merging tags probably should omit revisions not in the ancestry of the destination branch | 11:57 |
spiv | Hmm, I'm not sure about that. | 11:58 |
maxb | oh? | 11:58 |
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. | 11:59 |
spiv | Partly because tags are merged in several different contexts. | 12:01 |
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:10 |
spiv | not-in-ancestry != not-present | 12:21 |
spiv | But I think there are probably cases where even tags of ghost revisions may be useful. | 12:22 |
spiv | Anyway, zzzz time. | 12:22 |
jam | hi spiv | 12:42 |
jam | bye spiv :) | 12:42 |
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:49 |
empity | with git I think they are written if you remove them | 12:50 |
maxb | If you pulled, got conflicts, and reverted them, then you already have the changes, so there is nothing new to pull. | 12:56 |
=== Ursinha-afk is now known as Ursinha | ||
exarkun | is there a windows installer that includes bzr and bzr-svn? | 13:53 |
jelmer | exarkun: the default installer includes bzr-svn I believe | 13:54 |
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 | 13:55 |
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:30 |
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:33 |
maxb | Oh, they've been re-opened by jam's delayed merge proposal emails | 14:35 |
=== zyga is now known as zyga-food | ||
jam | jelmer: so what hours do you usually work? | 15:07 |
jelmer | jam: 10-6 CET | 15:07 |
jam | jelmer: so for another ~2 hrs? | 15:08 |
jam | I think I'm shooting for 8:30 - 5 CET myself. | 15:08 |
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:09 |
jam | jelmer: I'm pretty sure vila works until past 6 or 7. At least, that's what I recall from the US :) | 15:10 |
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:11 |
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:12 |
mgz | jam is in europe? | 15:14 |
* jelmer heads out to vote and errands | 15:30 | |
jam | mgz: I just moved. My wife got a promotion for 2 years in the Netherlands. | 15:42 |
mgz | great! more timezone overlap means I get to bug you even more? :) | 15:43 |
=== zyga-food is now known as zyga | ||
jam | mgz: /ignore, /ignore /ignore, dangit, it just doesn't work | 15:52 |
jam | :) | 15:52 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:40 |
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:41 |
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:44 |
achiang | james_w: much nicer, thanks! | 16:45 |
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:47 |
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:48 |
achiang | 'bzr pull' does what i want in the simple case quite nicely | 16:49 |
james_w | sorry, I meant "git pull" | 16:50 |
LeoNerd | If your branch is a strict ancestor of upstream, then bzr pull is what you want | 16:51 |
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:52 |
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:53 |
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:54 |
briandealwis | I too was initially confused reading LeoNerd's description | 16:55 |
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 | 16:56 |
=== 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 | ||
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:28 |
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:29 |
poolie | no | 21:33 |
yshavit | poolie: awesome, thanks :) | 21:33 |
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:35 |
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. | 21:36 |
=== Ursinha-food is now known as Ursinha | ||
spiv | Morning folks. | 22:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!