| bendj | TresEquis: sure. or @ http:// or webdav, etc. hrm. with a little juggling, i *could* live with one-way only ... still not ideal for the long term. but ... | 00:00 |
|---|---|---|
| * TresEquis is running live mirrors of the repoze SVN repository to each of bzr, git, and hg | 00:01 | |
| TresEquis | mostly to say STFU to folks who want us to commit to *their* DVCS choice | 00:01 |
| bendj | TresEquis: I was hoping to say STFU to projects that want me to commit to crowbarring MY workflow to fit THEIR rcs choice ;-) | 00:04 |
| TresEquis | sure | 00:04 |
| TresEquis | SVN doesn't suck too badly as the "centralized" repo | 00:04 |
| TresEquis | and if everybody else can do branches, etc. using their tool of choice, then that makes SVN an "implementation detail" | 00:05 |
| bendj | sneaker-net with Hollerith field punched cards was, at times, easier .... sigh. | 00:05 |
| TresEquis | only those who can commit to the central repo need to care about | 00:05 |
| lifeless | mwhudson: https://code.launchpad.net/~mwhudson/launchpad/code-import-workers-copy-too-much/+merge/24282 | 00:06 |
| lifeless | mwhudson: did you see my note? | 00:06 |
| mwhudson | lifeless: yes, i meant to ask you about that | 00:07 |
| mwhudson | lifeless: i don't understand how it's "wrong", i can see it might be less than perfect | 00:07 |
| lifeless | theres nothing that says the control dir is .bzr | 00:07 |
| mwhudson | oh come on | 00:07 |
| lifeless | we've tried pretty hard to make it possible for loom or things like that to use different dirs | 00:08 |
| lifeless | its a shame to bypass that | 00:08 |
| lifeless | anyhow | 00:08 |
| lifeless | if you want to use .bzr + clone, do so - but using .transport will be shorter and easier to read IMO | 00:08 |
| lifeless | I guess for lp which enforces .bzr as the control dir name there are less degrees of freedom, at least at the moment. | 00:09 |
| bendj | xnox: TresEquis k. so to be clear -- as long as i'm only branching, with NO re-commit back to upstream, despite NOT support svn:{externals,ignores}, mmy bzr-svn branch/co *of* (from?) the central svn repo will be locally complete, with all the externals, etc pulled in. correct? | 00:09 |
| bendj | AND, I can hack to my heart's delight, then 'bzr merge' to repull upstream changes later? | 00:09 |
| mwhudson | lifeless: it seemed more symmetric to me to clone on both transports | 00:11 |
| xnox | bendj, well bzr treats imported svn revisions as regular bzr commits. So yes you can do anything with your branch. As long as you do not rewrite history you will be able to merge from svn. | 00:11 |
| lifeless | mwhudson: if I was writing it I would use relpath and the transport itself, I think. | 00:11 |
| mwhudson | if the control dir was called something other than .bzr i should be doing something else, like comparing .transport and .root_transport | 00:11 |
| xnox | bendj, so commit .bzrignore and use join to get the externals. And got wild =) | 00:12 |
| xnox | bendj, just don't use rewrite plugin and don't uncommit svn revisions | 00:12 |
| lifeless | mwhudson: perhaps a :XXX that it won't handle non .bzr control dirs [contrasting with cloning or a complete copy] | 00:12 |
| xnox | and don't merge partial revisions e.g. merge -r-20..-19 | 00:12 |
| lifeless | mwhudson: and use the code you wrote | 00:13 |
| mwhudson | lifeless: i can agree to that, certainly | 00:13 |
| bendj | xnox i clearly misunderstood the need -- some, anyway -- for maintaing the externals/ignores for one-way-only checkout/branch. still, the need's fully there for re-commit. just ping-ed the "power that be" for input. pending ... | 00:14 |
| bendj | xnox: does your 'method', by any chance, exist anywhere in print? on the wiki, perhaps? | 00:14 |
| xnox | bendj, well I can blog it now to planet =) | 00:15 |
| lifeless | mwhudson: I don't suggest these things just to make your life hard :P | 00:16 |
| lifeless | mwhudson: its a corollary to not using the standard bzr glue to do things | 00:16 |
| mwhudson | indeed | 00:16 |
| bendj | xnox: Would be useful if 'immortalized' ... btw, WHICH Planet? | 00:16 |
| xnox | Ubuntu Planet =) | 00:16 |
| mwhudson | doing the right (well, more right) thing doesn't seem to hard actually | 00:16 |
| bendj | xnox: thx. (rss to the rescue ...) | 00:17 |
| mwhudson | lifeless: is this the sort of thing you meant? http://pastebin.ubuntu.com/424287/ | 00:17 |
| lifeless | mwhudson: that would make me maximally happy, if you're able to use it | 00:18 |
| lifeless | mwhudson: you can make it a little more compact if you like: (sec, typing) | 00:18 |
| mwhudson | lifeless: it passes my tests, so yeah i'm happy to use that | 00:19 |
| lifeless | http://pastebin.ubuntu.com/424288/ | 00:20 |
| lifeless | mwhudson: the mkdir and ensure_base were redundant, so I folded together | 00:20 |
| mwhudson | lifeless: well, not quite, because ensure_base will only create '.' | 00:23 |
| mwhudson | but a create_prefix is cleaner anyway | 00:24 |
| lifeless | mwhudson: oh, doh :) | 00:24 |
| xnox | bendj, published | 01:19 |
| xnox | bendj, http://tinyurl.com/bzr-join | 01:19 |
| bendj | xnox: Thanks -- just caught it on the feed :-) | 01:39 |
| xnox | bendj, does it look ok ? | 01:39 |
| xnox | i mean formatting | 01:40 |
| bendj | xnox: yup. formatted nicely on this end | 01:41 |
| bendj | brb ... | 01:43 |
| bendj | ping xnox | 02:39 |
| xnox | bendj, pong | 02:39 |
| bendj | xnox: just fyi, http://github.com/andrep/git-svn-clone-externals. adaptable, perhaps .. | 02:40 |
| xnox | yeah i guess but =) | 02:41 |
| bendj | aha, the 'yahbut' ... | 02:41 |
| xnox | what's the point =) | 03:03 |
| xnox | i like my way cause I know I'm on single branch, i can share it with people and work together | 03:03 |
| xnox | and my joined branch doesn't require any other commands / plugins | 03:03 |
| bendj | xnox Sure. Different strokes ... adminttedly, I'm looking at a scripted solution for projects with large #'s of svn:externals ... | 03:06 |
| bendj | agh! admittedly | 03:06 |
| xnox | bendj, I know a tool like that =) | 03:07 |
| xnox | it starts with "s" and ends with "n" | 03:07 |
| bendj | comment += $comment . ' ... and that pulls it all into a local DVCS.' | 03:08 |
| xnox | =) | 03:26 |
| bendj | This page (http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/svn_plugin.html) references "rich-root", as in: 'bzr init-repo --default-rich-root'. manpage fails to mention "--default-rich-root" as a specific option, and states for "--default" that "Provides rich roots which are a one-way transition.". | 03:40 |
| bendj | And, of course, search in docs (http://doc.bazaar.canonical.com/bzr.dev/en/search.html) on 'rich-root' comes back empty. | 03:40 |
| bendj | W. T. F. ?! | 03:40 |
| bendj | where is this documented? Buehler? Buehler? | 03:40 |
| idnar | I think the docs are a bit out of sync | 03:41 |
| idnar | the new default format in bzr 2.0 is the 2a format, which is a "rich root" format | 03:41 |
| idnar | so there's no (longer) --default-rich-root, because --default is already rich root | 03:41 |
| idnar | I'd say svn_plugin.html should be changed, I'd suggest filing a bug report | 03:42 |
| bendj | idnar: Ugh. Ok, b4 I do, I'm gonna try to 'sed' the commentary at https://answers.launchpad.net/bzr/+question/71563#6 "... The reason appears to be that bzr doesn't set a unique root ID for a branch unless it was *created* as a rich-root branch. ...", to see if it stil holds. | 03:44 |
| bendj | idnar: Thanks. I think. | 03:44 |
| bendj | Although, I think I've bumped squarely into the lack of nested-tree support. again. But by another path ... | 03:45 |
| idnar | spiv: (moving from #launchpad) I guess that would help, but I wouldn't want to define a prefix for each and every one of my projects | 05:06 |
| spiv | I can't find the plugin I was thinking of, but bzr-bookmarks is perhaps close enough. | 05:07 |
| idnar | maybe what I really need is a browser plugin so I can click a button when I'm viewing a merge proposal, and have it grab the corresponding branch | 05:07 |
| idnar | that's not the only time I branch a new remote branch, but it's probably the most common | 05:08 |
| * idnar looks at bzr-bookmarks | 05:08 | |
| spiv | I *think* actually that bzr-bookmarks will look at locations.conf, but perhaps only if you already have a branch. Hmm. | 05:09 |
| thumper | idnar: make something that hooks into the scheme provider | 05:09 |
| thumper | idnar: so if you click on lp:some-branch it fires up an app to get it :) | 05:09 |
| _habnabit | If I did a bzr checkout by accident instead of a bzr branch from a launchpad branch, is there an easy way to switch? | 07:27 |
| _habnabit | I have uncommitted changes that I don't want to implicitly push. | 07:27 |
| spiv | _habnabit: bzr reconfigure --standalone | 07:27 |
| spiv | Oh, oops, wrong option | 07:27 |
| _habnabit | --branch ? | 07:28 |
| spiv | bzr reconfigure --tree | 07:28 |
| _habnabit | Aha. | 07:28 |
| _habnabit | Thanks! | 07:28 |
| spiv | (Or 'bzr unbind') | 07:28 |
| _habnabit | That did it. | 07:28 |
| _habnabit | Oh nice, that looks like exactly what I want. | 07:28 |
| vila | hi all ! | 07:50 |
| vila | spiv: Can we talk briefly about https://code.edge.launchpad.net/~vila/bzr/401599-strict-warnings/+merge/23932 ? | 07:52 |
| vila | spiv: I've got the feeling you're searching for a test modification that has been done in a previous submission where the behaviour changed, this one was about the displayed message which was misleading | 07:54 |
| spiv | vila: well, I've checked what trunk without that does, and what that patch changes. | 07:54 |
| vila | spiv: we were still saying 'use --no-strict to force the push' even if the push was already occurring | 07:54 |
| spiv | vila: what other submissions should I know about? I didn't notice any mention of them in that proposal. | 07:55 |
| vila | spiv: did you see a behaviour change ? | 07:55 |
| spiv | I did, and I agree with it. But I don't see a test for the behaviour change. | 07:56 |
| spiv | (To be precise: a behaviour change in your proposal relative to what was in trunk) | 07:56 |
| vila | huh ? Which one ? | 07:56 |
| spiv | Er, the bits of the patch that touch files other than NEWS and bzrlib/tests/* | 07:57 |
| vila | spiv: the previous submission is revno 5151 in trunk | 07:57 |
| spiv | i.e. the behaviour change described in the NEWS entry. | 07:58 |
| spiv | I'm rather confused. | 07:58 |
| vila | spiv: well, the other files only modified the displayed message, not if we push or not | 07:58 |
| spiv | The display of a message *is* behaviour. | 07:59 |
| vila | haaa, that's were we were misundestanding each other :) | 07:59 |
| === knitt1 is now known as knittl | ||
| vila | ok, I made a distinction between whether we were pushing or not (or dpushing or sending) and what message we displayed | 08:00 |
| vila | before the last submission the tests weren't checking the message, I changed that and that only | 08:00 |
| spiv | But the tests still don't test that no warning is displayed in cases where we expect no warning: i.e. tests that would have caught the original spurious warnings. | 08:01 |
| vila | spiv: they do now | 08:01 |
| spiv | No, they test something much weaker. | 08:01 |
| vila | more focused, not weaker | 08:02 |
| vila | for example: push displays 'Created new branch' | 08:02 |
| spiv | On stderr? | 08:02 |
| vila | if we change it to 'Created new branch up to revno nn' the test doesn't have to be impacted because we already check that we push the right revision | 08:03 |
| vila | yes on stderr | 08:03 |
| vila | I mentioned that in my previous answer (but you didn't cite this part) | 08:03 |
| spiv | Not deliberately, I just missed that bit :) | 08:03 |
| vila | no worries | 08:03 |
| vila | the truth is, after your review, I tried to build the full stderr content and this was... dirty | 08:04 |
| vila | As I said I'm not a big fan of assertContainsRe since it weakens some tests, but here.... I found the balance was in favour of it | 08:05 |
| spiv | So, the test for "doesn't contain this regex" is weak, in the sense of being fragile. | 08:05 |
| vila | kind of, | 08:06 |
| spiv | (Even though it is focused on the specific messages we care about) | 08:06 |
| vila | it's also robust about spurious changes in the part it didn't care | 08:06 |
| spiv | Because it will easily pass incorrectly with minor wording changes. | 08:06 |
| spiv | So the risk of incorrect failures is low, but the risk of incorrect successes is high. | 08:07 |
| vila | If the changes are in unrelated messages, the test shouldn't have to care | 08:07 |
| poolie | hi vila | 08:07 |
| spiv | It would be nice if run_bzr could give us a list of warnings emitted to the user, or even just a list of messages. | 08:07 |
| vila | hey poolie ! | 08:07 |
| poolie | spiv, that would be nice | 08:08 |
| spiv | Rather than a single lump of bytes that got written to stderr. | 08:08 |
| vila | spiv: pfew, yeah | 08:08 |
| poolie | there is code to capture them, of course | 08:08 |
| poolie | but not on by default there | 08:08 |
| poolie | more standardization needed | 08:08 |
| spiv | But, we may be able to cheat that by splitting stderr by lines? | 08:08 |
| vila | poolie: that needs to be factored out for trace.warning :-) I think I know about at least 3 or 4 call sites now | 08:08 |
| spiv | Because in many cases there's a one-to-one correspondence between a line and a message/warning. | 08:08 |
| poolie | vila, how about a brief call? | 08:09 |
| spiv | vila: So, I feel these tests of cmd_push ought to be able to account for every line of output | 08:10 |
| vila | spiv: my position is that, on principle I agree with you about the strict checking of stderr, but in this specific case I made an exception because: 1) I see little to be gained, 2) the resulting code was awful (I revert to the simpler version I landed when I saw that) | 08:10 |
| vila | poolie: just a sec | 08:11 |
| spiv | vila: perhaps pass a regex list to add to a default list that expects to see the "N new revisions" or whatever. | 08:11 |
| spiv | (using "line" as proxy for "message or warning", which perhaps is overly optimistic) | 08:11 |
| vila | spiv: yeah I thought about that too, but it's all the same in the end, if we check regexps there will still be holes and adding unrelated messages there is just asking for trouble: when they change the tests will fail for the wrong reason | 08:12 |
| spiv | I agree the benefit for cmd_push is low, but ideally we'd find a way to do this that we can reuse in other places. | 08:12 |
| spiv | Capturing the warnings emitted more directly might be better than asserting about the exact bytes on stderr, I can see arguments either way. | 08:13 |
| spiv | (It's kind of a shame we only get 2 channels to emit messages on!) | 08:13 |
| vila | and to be honest, using blackbox tests there feels wrong, but it's often the case when trying to observe the behavior of command lines options that are handled in command.run() | 08:13 |
| spiv | But, if there's one thing I'd like you to take away from this review: | 08:14 |
| vila | test should fail first ? :) | 08:14 |
| spiv | It's don't claim that what is shown in the UI is not behaviour ;) | 08:14 |
| vila | hmm | 08:15 |
| bialix | heya bzr! | 08:15 |
| bialix | _o/ vila | 08:15 |
| vila | spiv: I'll think about it | 08:15 |
| vila | hey bialix | 08:15 |
| vila | poolie: calling | 08:15 |
| poolie | hi bialix | 08:16 |
| spiv | vila: I can argue about in some detail, but perhaps the main justification for me saying that is "it'll confuse people" :) | 08:16 |
| bialix | hi poolie :-) | 08:16 |
| vila | spiv: I agree, it's just my poor english | 08:16 |
| spiv | vila: and that english is poor! | 08:16 |
| bialix | vila: http://ostatic.com/blog/more-bad-english-please | 08:17 |
| bialix | I've fwd this article to ru_bzr people and suggest to not shy filing more bug reports | 08:17 |
| * bialix is working as english proxy sometimes | 08:18 | |
| lifeless | spiv: small request - start setting commit messages (e.g. on | 08:18 |
| lifeless | https://code.edge.launchpad.net/~gagern/bzr/bug387117/+merge/23750) | 08:18 |
| spiv | lifeless: it's a bit grating at the moment that feed-pqm-by-email and feed-pqm-by-lp-queue-magic expect different formats for the commit messages, AIUI. | 08:20 |
| idnar | :) | 08:21 |
| idnar | er, wrong window | 08:21 |
| spiv | So that discourages me from setting it unless I'm about to submit it myself. | 08:21 |
| spiv | Thinking of which, if PQM is reading directly from LP, perhaps it should just set the author revprop rather than putting it in the commit message. | 08:23 |
| lifeless | spiv: feed by lp queue seems very reliable to me know, I've been tracking it this week and no exceptions in th elogs according to spm | 08:23 |
| lifeless | s/know/now/ | 08:23 |
| lifeless | spiv: I don't think setting author is appropriate | 08:23 |
| lifeless | pqm is merging, the history knowledge of who introduced lines is in the history | 08:24 |
| spiv | Then why are we putting the name in the commit message? | 08:24 |
| lifeless | spiv: I'm not sure. I know why we put the queuer there, but the author never really made sense to me. | 08:25 |
| spiv | I thought it was because we wanted to credit the author for people viewing the mainline, but PQM didn't give us control of any fields other than the message. | 08:25 |
| lifeless | I got asked to do it/followed what Martin was doing or whatever some years ago | 08:25 |
| lifeless | spiv: pqm has always been modifiable | 08:26 |
| lifeless | spiv: I object to mangling metadata incorrectly to solve reporting problems; we should just report better. | 08:26 |
| spiv | Sure, but lack of tuits involved in improving PQM, getting it deployed, tested, and upgrading the pqm-submit plugin devs were using to use it meant that never happened because the workaround was bearable. | 08:27 |
| lifeless | spiv: I'd be happy to drop the trailing (author) | 08:27 |
| lifeless | if we were to set author in pqm, it should be to the queuer, IMO. | 08:28 |
| lifeless | because they are conceptually responsible for the merge | 08:28 |
| spiv | I don't see that "author" is an incorrect name for the field. Yes it might not be the sole work of that person, but the person responsible for proposing the patch is assumed to be the person responsible for assembling it and otherwise doing some significant work towards making it land. | 08:29 |
| lifeless | I've a little trouble binding things there | 08:29 |
| spiv | I'm not particularly against thinking of a better field, I just don't know that the distinction is more important. | 08:29 |
| lifeless | could you rephrase | 08:29 |
| spiv | The primary person we typically credit in commit messages is generally the person that proposed the patch. The person that proposed a patch is generally the person that wrote most of it, or at least did significant work on it (e.g. backporting). Calling people that do that "author" seems good enough for me. | 08:31 |
| spiv | Especially if it unclutters the commit logs :) | 08:31 |
| lifeless | do you mean the person in the trailing () or the leading () ? | 08:31 |
| lifeless | spiv: perhaps we can talk more next week on this | 08:33 |
| lifeless | spiv: I'm really convinced we should be able to show the people without setting author on a merge daemon | 08:33 |
| spiv | Well, we aren't completely consistent about how we use trailing/leading (), so the answer seems to be "trailing, or leading if trailing is absent, or 'for $name' in leading if given" | 08:33 |
| spiv | Yes, showing the people is the main thing. The second thing is not abusing commit messages. | 08:34 |
| spiv | Author is a convenient hammer for achieving those two, but I'm not wedded to it. | 08:34 |
| lifeless | I don't like setting author for a few reasons; we don't do it when we do merges by hand in other projects; it doesn't map well IMO to the intent; it will generally tag precisely zero lines. | 08:35 |
| spiv | What do you mean by tagging lines? | 08:36 |
| lifeless | in annotate | 08:36 |
| lifeless | you see the revisions that introduce text to the tree | 08:36 |
| lifeless | the annotation view of bzr shouldn't [in general] attribute *any* lines to pqm | 08:36 |
| spiv | Sure. I'm not too bothered by annotate. | 08:36 |
| lifeless | the most grating thing to me, I think, is that the old default log avoids the question entirely; it shows *the right stuff*, and there aren't any questions about the contributors to a patch. | 08:37 |
| spiv | I'd be happy to see lp-proposed-by and lp-landed-by revprops. | 08:37 |
| lifeless | spiv: proposed/landed/queued ? | 08:38 |
| poolie | hi lifeless | 08:38 |
| lifeless | hi poolie | 08:38 |
| spiv | lifeless: sure, whatever names, just capturing the data in a sane way :) | 08:38 |
| lifeless | spiv: ack | 08:38 |
| spiv | But there's more than just log (old or new): there's qlog, there's loggerhead, there's the branch page on LP... | 08:39 |
| spiv | And none of them, today, report the authors/committers of non-mainline revisions in their default view. | 08:40 |
| lifeless | yeah | 08:40 |
| lifeless | this saddens me | 08:40 |
| spiv | Me too. And AfC for that matter :) | 08:40 |
| spiv | The existence of PQM as the committer on mainline is far from the most interesting fact about that revision. | 08:41 |
| spiv | *Any* of the people involved would be better, in many ways. | 08:42 |
| lifeless | queuer is IMO signed-off-by in git | 08:42 |
| spiv | Right. | 08:43 |
| spiv | Ooh, there *is* a way to see Queued proposals for a branch: https://code.edge.launchpad.net/~bzr-pqm/bzr/bzr.dev/+merges?field.status=QUEUED (empty atm) | 08:46 |
| lifeless | whats maximise-window-vertically in vim, again ? | 08:47 |
| spiv | Ctrl-W _ | 08:48 |
| lifeless | thanks | 08:49 |
| === radoe_ is now known as radoe | ||
| spiv | Apparently there's a "Code failed to merge" state. | 08:58 |
| lifeless | yes | 08:58 |
| lifeless | can't be used | 08:58 |
| spiv | Heh. | 08:58 |
| lifeless | see my branch, nag thumper to reply to my review | 08:58 |
| AfC | spiv: indeed | 08:59 |
| * AfC is abashed that spiv remembers him. Aw shucks. | 09:00 | |
| vila | poolie: about https://code.edge.launchpad.net/~jbowtie/bzr/fix-555439/+merge/24289 is the contributor agreement in the pipe ? | 09:31 |
| vila | spiv: Can we mark https://code.edge.launchpad.net/~spiv/bzr/push-relock/+merge/23767 as wip ? | 09:33 |
| thumper | lifeless: I'll talk to you about it tomorrow, there are things I want to discuss | 09:33 |
| lifeless | thumper: naturally | 09:37 |
| lifeless | thumper: needs to be early, I have a plane flight at 1:30, leaving 10:45 or so | 09:37 |
| thumper | ok | 09:37 |
| thumper | lifeless: ping me in the morning | 09:37 |
| poolie | vila: https://code.edge.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537 was originally created on the 3rd of March | 10:00 |
| poolie | therefore is nearly 2 months old | 10:00 |
| poolie | the overview page only shows the date a review was most recently requested | 10:00 |
| poolie | and i see you have been following up on that and need win32 help | 10:01 |
| poolie | (bialix :-) | 10:01 |
| poolie | for those wondering, i'm not nagging vila, i'm just answering why the "oldest mp" graph says 2 months when there don't immediately seem to be any so old | 10:04 |
| spiv | vila: hmm, I suppose. Although I don't know if the next step should be "make read-locks upgradable into write-locks" or just "land this hack" | 10:14 |
| lifeless | I'm ni favour of the former, quite strongly. | 10:18 |
| lifeless | I think its only slightly more work. | 10:18 |
| vila | poolie: thanks | 10:26 |
| vila | spiv: at your leisure, I'm just trying to clean up the review queue | 10:27 |
| sproaty | I just added my work pc's SSH key to LP, did a launchpad-login but my commit didn't come through 'linked' to my username? | 10:46 |
| spiv | sproaty: the commit linkage is based on the name+email you've set with "bzr whoami" | 10:49 |
| spiv | (Or the name+email bzr has guessed if you haven't explicitly set it; either way, "bzr whoami" will show you what name is being recorded in your commits) | 10:49 |
| sproaty | ah ok I just changed those (after commiting :p) | 10:50 |
| spiv | There's a bug + patch for making bzr never guess the 'whoami', btw. Sounds like that would have helped you :/ | 10:50 |
| sproaty | thanks | 10:52 |
| sproaty | ahh I changed whoami now I get this when pushing bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~sproaty/whyteboard/development/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() | 10:58 |
| sproaty | https://answers.launchpad.net/bzr/+question/24695 doing lauchpad-login and bzr bind as suggested here, problem still exists | 10:58 |
| spiv | sproaty: what command are you trying? "bzr push lp:~sproaty/whyteboard/development"? | 11:02 |
| spiv | sproaty: it's trying http rather than bzr+ssh, which suggests that either you aren't using the lp: URL, or somehow the "bzr launchpad-login" hasn't taken effect. | 11:03 |
| sproaty | that's what I pushed to earlier (with wrong whoami) - now I'm just doing push | 11:03 |
| sproaty | ah there we go | 11:03 |
| sproaty | specifying the url directly again worked | 11:04 |
| spiv | Ok, it's probably remembered the http one. If you do "bzr push --remember lp:~sproaty/whyteboard/development" that should solve that. | 11:04 |
| sproaty | are these now right? http://paste.pocoo.org/show/207461/ | 11:04 |
| sproaty | cool cool | 11:05 |
| spiv | No, none of the branches on launchpad should start with http:// if you have done launchpad-login | 11:16 |
| === AfC1 is now known as AfC | ||
| === mrevell is now known as mrevell-lunch | ||
| bialix | what's the purpose of commit object passed to generate_commit_message_template function? | 13:04 |
| bialix | is there any real-life examples of commit_message_template hook? | 13:04 |
| bialix | jelmer: I found your patch of commit_message_template hook: http://markmail.org/thread/etkxlj6osy65rhfb . can you point me on any existing hooks? | 13:06 |
| jelmer | bialix: bzr-builddeb has one I believe | 13:09 |
| jelmer | bialix: it fills in the commit message based on the contents of debian/changelog | 13:09 |
| bialix | that's what I need | 13:09 |
| bialix | commit object should have link to working tree, right? | 13:10 |
| jelmer | yeah, I think so | 13:10 |
| bialix | commit.work_tree | 13:11 |
| bialix | oki | 13:11 |
| bialix | jelmer: do you know why commit_message_template hook gets the commit object as argument? why not passing just working tree there? | 13:16 |
| bialix | jelmer: actually you're the author of that hook | 13:18 |
| bialix | qann say so | 13:18 |
| spiv | It's a more flexible interface. | 13:19 |
| spiv | It allows us to add more attributes to the commit object without breaking existing hooks. | 13:20 |
| bialix | spiv: for example? | 13:20 |
| jelmer | bialix: specified_files | 13:20 |
| spiv | If we passed arguments like working tree directly then to add another argument then it would break the hook. | 13:21 |
| bialix | but that hook launched only with work_tree argument attached to commit object!!! | 13:22 |
| bialix | jelmer: I don't see where specific_files attached to commit_object | 13:22 |
| jelmer | bialix: it's not yet attached, but it would be a good candidate | 13:22 |
| jelmer | bialix: and we'd like to be able to make that sort of change without breaking existing hooks | 13:22 |
| jelmer | so it can't really be an argument to the hook | 13:23 |
| bialix | :-/ | 13:23 |
| spiv | Generally new hooks have dedicated "params" objects | 13:23 |
| bialix | guys, I need the way to run these hooks without calling wt.commit so I can use them in qbzr | 13:23 |
| bialix | today it seems impossible hard | 13:23 |
| bialix | because hooks called from commit object | 13:24 |
| bialix | and I need valid commit object to fire hooks | 13:24 |
| bialix | it's a kinds of recursion, it's not? | 13:24 |
| spiv | commit_message_template is a hook for controlling the message template to use for a commit.' | 13:25 |
| bialix | when you start to talk about flexible I'm starting to fear | 13:25 |
| spiv | So by definition it needs a commit object | 13:25 |
| spiv | Why can't you create one? | 13:25 |
| bialix | I can create one, but I should attach all required attributes there manually | 13:25 |
| bialix | because they're attached only when actual commit started | 13:26 |
| bialix | so far I see there is only work_tree and branch attributes attached, then hook fired | 13:26 |
| bialix | now you say there is need for specific_files | 13:26 |
| bialix | it's a kinda open can of worms | 13:26 |
| * bialix don't like open ended | 13:26 | |
| jelmer | bialix: specific_files isn't there yet but it might be added in the future | 13:27 |
| spiv | I'm not sure why qbzr can't call wt.commit? | 13:27 |
| spiv | Perhaps look at how cmd_commit does this. | 13:27 |
| bialix | spiv: because we allows user to enter message *before* we call commit | 13:27 |
| bialix | it's a gui application | 13:28 |
| spiv | The hook is invoked by generate_commit_message_template, which is invoked by the get_message callback that cmd_commit passes to tree.commit | 13:28 |
| bialix | yes, exactly | 13:28 |
| spiv | Why not allow the user to enter the message during commit, like the CLI? | 13:28 |
| bialix | and tree.commit is the real commit | 13:28 |
| bialix | spiv: http://groups.google.com/group/qbzr/t/f266b47d77e4bacb | 13:29 |
| spiv | The issue is that the real commit can affect what goes in the template. | 13:29 |
| bialix | why? | 13:30 |
| bialix | or more precisely: how? | 13:30 |
| spiv | Because the template often includes a summary of affected files, etc. | 13:30 |
| bialix | I see this hook as CLI-only thing | 13:30 |
| spiv | I don't see that way. | 13:30 |
| bialix | spiv: in qcommit user can select/deselect files interactively | 13:30 |
| bialix | so the summary will be known only when commit started | 13:31 |
| bialix | I need template *before* | 13:31 |
| bialix | heh | 13:31 |
| spiv | Ok, then you can't use the hook that generates templates based on that information. | 13:31 |
| spiv | Perhaps we could add a hook that works from a more limited set of information, although it would be correspondingly less useful... | 13:33 |
| bialix | I can live with that | 13:33 |
| spiv | But that post you just linked to suggests that you do want your templates to know if changelog/news is going to be part of this commit. | 13:34 |
| spiv | So it sounds to me like you have contradictory requirements. | 13:34 |
| bialix | spiv: currently that hook don';t have such info | 13:34 |
| bialix | spiv: I don't care if user will deselct the changelog file -- because user can just select suggested templated and delete it as well | 13:35 |
| bialix | it's a GUI | 13:35 |
| spiv | Actually, glancing at the code, specific_files does seem to be defined at the point the message_callback is invoked. | 13:35 |
| bialix | *exactly* | 13:35 |
| spiv | bialix: ah, now that suggests a solution to me: | 13:36 |
| spiv | bialix: start a real commit to get the message template then abort it. | 13:37 |
| bialix | ? | 13:37 |
| bialix | sounds crazy | 13:37 |
| spiv | Well, AFAICT that actually matches exactly the behaviour you want: | 13:38 |
| bialix | spiv: I think I don't want to start commit until user presses OK | 13:39 |
| spiv | You want to the initial message (that the user can edit) to be what the hook suggests if the user just committed everything. | 13:39 |
| bialix | yes | 13:39 |
| bialix | that's my point | 13:39 |
| spiv | So, construct that commit, use it to get the template, then abort it and throw it away. | 13:39 |
| spiv | Then once the user has edited the message and files etc, and clicked ok, do a commit (and let it finish). | 13:40 |
| bialix | how I can abort commit? | 13:40 |
| spiv | By raising an exception from the message_callback. | 13:40 |
| * bialix scratches a head | 13:41 | |
| spiv | It's a bit of a hack (and will quietly log a traceback), but will work. | 13:41 |
| bialix | yep, it looks like a hack | 13:41 |
| bialix | thanks for the suggestion, but I don't like this idea | 13:41 |
| spiv | We can add some sort of cleaner API (perhaps just an explicit AbortCommit exception) if this is useful for you. | 13:42 |
| spiv | Just because the way to abort the commit is a hack? | 13:42 |
| bialix | I don't know yet | 13:42 |
| spiv | Fair enough :) | 13:42 |
| bialix | I don't know yet if I need AbortCommit | 13:42 |
| bialix | I don't like idea of aborting commit because it's a waste | 13:43 |
| spiv | That's true. | 13:43 |
| spiv | The only other option is providing a way for a GUI to interactively configure the Commit object between starting and finishing it. | 13:44 |
| spiv | And I think that would either be a lot more complex for bzrlib, or actually work out to be essentially the same as "throw the first one away and restart it". | 13:44 |
| bialix | yes, but for this I need to understand the required API of the hook, and it's not defined yet | 13:44 |
| spiv | Because you are fundamentally asking for repeated work. | 13:45 |
| bialix | no, when qcommit will start the real commit there will be passed real commit message and the hooks won't fired | 13:45 |
| spiv | The commit message template by definition depends on what is being committed. | 13:45 |
| spiv | And you want that template before finalising what is committed. | 13:46 |
| bialix | I'm reading the http://bazaar.launchpad.net/%7Ebzr-builddeb-hackers/bzr-builddeb/trunk/annotate/head%3A/__init__.py#L85 | 13:46 |
| bialix | and I see that in the end there's a lot of manual work | 13:46 |
| bialix | no real benefit from commit object | 13:46 |
| bialix | or maybe I'm blind | 13:47 |
| spiv | Oh, to be fancy you don't *have* to abort the first commit if the user doesn't deselect any files or change anything other than the message... | 13:47 |
| bialix | spiv: actually we run plain `bzr commit` under the hood | 13:47 |
| bialix | that's why I don't want to manually invoke wt.commit | 13:47 |
| bialix | maybe I can think about using MemoryTree instead, but anyway it's a waste | 13:48 |
| spiv | Well, if you want to integrate very closely, at some point you need to use bzrlib directly. | 13:48 |
| jelmer | bialix: perhaps you can propose an interface for the object that's pased to the commit_message_template_hook ? | 13:48 |
| bialix | no, I'm only want to have template | 13:48 |
| bialix | it was to spiv | 13:48 |
| jelmer | bialix: that interface could then be implemented by Commit as well as some qbzr-specific object | 13:48 |
| spiv | bialix: I agree that hook's params don't provide as many convenience methods as it could or should | 13:49 |
| bialix | jelmer: ok, I'll think about this | 13:49 |
| spiv | bialix: I've recently don't some work on the merge_file_contents hook to add that sort of convenience. | 13:49 |
| bialix | but it's real and used now, so anywy there is should be a way for backward compatibility | 13:49 |
| spiv | (although there's a long way to go) | 13:49 |
| === mrevell-lunch is now known as mrevell | ||
| LeoNerd | Hrm.. bzr ci is now failing for me, because it can't talk to gnome keyring, apparently. I don't even run gnome.. | 14:50 |
| LeoNerd | ** Message: secret service operation failed: The name org.freedesktop.secrets was not provided by any .service files | 14:50 |
| vila | LeoNerd: does bzr-gtk appears in the output of 'bzr plugins -v' ? | 14:51 |
| LeoNerd | Yup | 14:52 |
| vila | LeoNerd: if you don't run gnome... don't install it :-) | 14:52 |
| vila | LeoNerd: yet, it's a bug, can you file it ? | 14:52 |
| LeoNerd | gtk != gnome | 14:52 |
| LeoNerd | gtk provides nice shiney visual stuff. | 14:53 |
| LeoNerd | I don't know if it's a bug... | 14:53 |
| vila | ha, that kind of user :) | 14:53 |
| vila | it is a bug you can't use bzr ci with bzr-gtk installed | 14:53 |
| vila | s//that/ | 14:53 |
| LeoNerd | It worked this morning :) | 14:53 |
| LeoNerd | I haven't changed anything to my knowledge... | 14:54 |
| LeoNerd | It's possible that xfce starts a gnome-keyring-alike, which has since died.. | 14:54 |
| vila | canonical answer: then it works as it worked before ;) | 14:54 |
| vila | LeoNerd: we had trouble with gnome-keyring in the past, so be sure to mention all the relevant versions (for a fully handwaved value of relevant) | 14:55 |
| LeoNerd | Hmm... Temporary workaround for now..? | 14:55 |
| vila | bzr --no-plugins ci | 14:55 |
| LeoNerd | Righty... usefully this isn't one of my bzr-svn checkouts ;) | 14:56 |
| vila | LeoNerd: ha silly me: BZR_PLUGIN_DISABLE=gtk | 14:56 |
| LeoNerd | Ahh | 14:56 |
| vila | damn, not monetioned in 'bzr help env-variables' :-/ | 14:57 |
| vila | BZR_DISABLE_PLUGINS=gtk sorry | 14:57 |
| LeoNerd | Hrm.. neither of those seem to work... | 15:01 |
| vila | LeoNerd: bzr version ? | 15:01 |
| LeoNerd | Bazaar (bzr) 2.1.1 | 15:01 |
| vila | LeoNerd: right, you need 2.2b1 or newer, so next workaround is .... | 15:02 |
| vila | temporarily move the gtk directory out of the plugins dir :-} | 15:03 |
| LeoNerd | Heh... which is in /usr/lib/python... | 15:03 |
| vila | I knew it :-( | 15:03 |
| vila | LeoNerd: fix your damn installation ! | 15:03 |
| vila | cough, sry | 15:03 |
| * LeoNerd goes for apt-get remove bzr-gtk | 15:04 | |
| LeoNerd | Possibly the actually-gtk things could be separated from the gnome things? Make it two plugins? | 15:04 |
| vila | LeoNerd: please file a bug against bzr-gtk, having to uninstall it as the only workaround speak volume... | 15:04 |
| LeoNerd | GTK does not imply Gnome | 15:04 |
| vila | yeah, that's what the fix should do | 15:05 |
| jelmer | bzr-gtk doesn't require GNOME in any way... | 15:05 |
| vila | but gtk/keyring.py already trap import errors around gnomekeyring, which is weird | 15:05 |
| vila | jelmer: even gnomekeyring ? | 15:06 |
| LeoNerd | jelmer: Then why does it die fatally because gnome-keyring isn't running? | 15:06 |
| jelmer | vila: yeah, gnomekeyring isn't required. we just skip it if it isn't there. | 15:06 |
| LeoNerd | http://paste.leonerd.org.uk/?show=870 | 15:06 |
| jelmer | LeoNerd: that bug has already been fixed | 15:07 |
| LeoNerd | Ahh.. | 15:07 |
| vila | looks like... yeah as jelmer said :) | 15:07 |
| jelmer | LeoNerd: it's probably not packaged anywhere though | 15:07 |
| LeoNerd | Hmmm | 15:07 |
| vila | LeoNerd: which bzr-gtk version ? | 15:07 |
| LeoNerd | Candidate: 0.98.0-1 | 15:07 |
| jelmer | LeoNerd: afaik it's triggered by newer versions of gnomekeyring, older versions would never raise IOError | 15:08 |
| LeoNerd | Ah.. Hrm. I see | 15:08 |
| LeoNerd | Thing is.. I know bzr was working yesterday... admittedly in svn checkouts, not nayive bzr ones.. | 15:08 |
| vila | by the way, hi jelmer ! | 15:08 |
| LeoNerd | *native | 15:08 |
| vila | LeoNerd: OS ? | 15:08 |
| jelmer | moinmoin Vincent :-) | 15:08 |
| LeoNerd | Debian mostly-testing | 15:08 |
| vila | no updates (checking) ? | 15:09 |
| LeoNerd | Have just distupgrad'ed now... nothing newer | 15:09 |
| jelmer | I haven't uploaded any bzr-gtk packages since I fixed that issue in bzr-gtk trunk I think | 15:09 |
| vila | LeoNerd: that doesn't rule out an update since yesterday (quite the contrary) | 15:09 |
| LeoNerd | Just did update; still 0.98.0-1 | 15:10 |
| vila | LeoNerd: I'm trying to find if it's an install issue or a runtime one | 15:10 |
| vila | LeoNerd: well, in that case that could coming from gtk itself | 15:11 |
| vila | s/could/& be/ | 15:11 |
| === oubiwann is now known as Wooster_ | ||
| === Wooster_ is now known as oubiwann | ||
| mathrick | jelmer: poke? | 16:15 |
| mathrick | jelmer: git://repo.or.cz/org-mode.git <-- I cloned that, and bzr tag gets confused. It shows ?? as the revno for tag past release_6.35g, and if I tell it to branch off, say, release_6.35i, it claims there's no such revision | 16:17 |
| mathrick | 6.35g and earlier ones work fine | 16:17 |
| mathrick | git can also clone them alright, although when I tell it to git log `git rev-parse release_6.35i`.., it shows something but the returned hash (014cae20013eb2b4261b4da78827573ab921bfc7) is *not* listed | 16:18 |
| jelmer | mathrick: I would suspect that revision is not on the mainline of your branch | 16:18 |
| jelmer | mathrick:so there's no way to assign a revno to it | 16:19 |
| mathrick | uhh, can't it use the dotted notation? | 16:19 |
| jelmer | mathrick: how would it do that if the revision is not on the branch? | 16:19 |
| mathrick | jelmer: the same way bzr log does it? | 16:20 |
| mathrick | I'm not sure I follow | 16:20 |
| jelmer | mathrick: bzr tags doesn't show revno's for tagged revisions not on the mainline either, even when you're not in a git-imported branch | 16:21 |
| mathrick | I'd argue it's a UI bug then | 16:21 |
| mathrick | I mean, not telling me "can't show because it's not on mainline" | 16:21 |
| jelmer | mathrick: how? What revno would you assign to it without causing conflicting revno's? | 16:21 |
| jelmer | mathrick: that's what the ?? is intended to do, though I admit that could be a bit clearer.. | 16:22 |
| mathrick | jelmer: bzr log assigns them somehow, how is that different in tags' case? | 16:22 |
| jelmer | mathrick: bzr log works in the context of a single branch | 16:23 |
| jelmer | mathrick: imagine you have two different revisions A and B that have the same ancestor | 16:23 |
| mathrick | okay | 16:23 |
| jelmer | that ancestor could have revno 42 | 16:23 |
| jelmer | what revno would you give its descendants? | 16:23 |
| mathrick | depends on which of A and B is in the mainline | 16:24 |
| jelmer | mathrick: let's say A is in the mainline | 16:24 |
| mathrick | jelmer: oh, I see, and both A and B are tips of the tree? | 16:24 |
| jelmer | mathrick: right | 16:25 |
| jelmer | mathrick: so bzr tags' output would be very confusing if it claimed that two tags were set on revision 43 while they were in fact different revisions | 16:25 |
| mathrick | okay, but then I can still specify tag:foobar as the revspec, no? | 16:25 |
| jelmer | mathrick: yes, you can - if that revision is available locally | 16:25 |
| mathrick | the thing is, git works in this case, and bzr tells me the revision doesn't exist | 16:25 |
| jelmer | mathrick: bzr-git tries to stay consistent with Bazaar in this regard, and only fetches the branch mainline | 16:26 |
| jelmer | mathrick: not necessarily the tags that aren't on the mainline or their ancestors | 16:26 |
| mathrick | jelmer: aha, so bzr clone foo -r tag:foobar would fail on pure bzr branches if it's not in the mainline? | 16:26 |
| jelmer | mathrick: clone foo -rtag:foobar would work. clone foo and then trying to access the tags would fail | 16:27 |
| jelmer | mathrick: if you explicitly specify you want that specific tag is should work | 16:27 |
| mathrick | jelmer: so I did clone the full repo above, and then tried to branch it off at tag:release_6.35i, and that failed | 16:27 |
| jelmer | mathrick: that's correct in that it's (afaik) compatible with bzr's behaviour | 16:28 |
| jelmer | mathrick: I think we should consider fixing it, but I'd prefer to fix it in bazaar first | 16:28 |
| mathrick | jelmer: aha, so currently bzr would fail in the same situation on a pure bzr branch, and you consider that something that should be rectified and allowed to work. Am I reading you correctly? | 16:29 |
| jelmer | mathrick: yeah | 16:29 |
| mathrick | multi-branch history is the most confusing part of any DVCS, so UI bugs here are really not helpful | 16:30 |
| fullermd | Urr? Wait, what? | 16:30 |
| fullermd | branch and tags and all work just peachy with tags not on the mainline. | 16:30 |
| mathrick | jelmer: out of curiosity, how would I get a non-mainline tag into a bzr branch? | 16:31 |
| mathrick | I can't just merge, since that automatically gets it into the mainline | 16:31 |
| jelmer | fullermd: does "bzr pull" fetch the contents of revisions that are not on the mainline but have tags ? | 16:32 |
| fullermd | Sure. Easily demonstrable by looking at your local bzr.dev mirror; there's only like 2 tags on the mainline. | 16:32 |
| fullermd | Wait, fetch the REVISIONS? How could pull work at all if it didn't fetch the revisions, whether they're on the mainline or not? | 16:33 |
| * fullermd is confuzzled now. | 16:33 | |
| jelmer | fullermd: iirc pull only fetches the branch tip and its ancestors | 16:33 |
| fullermd | Sure, but it's still an ancestor even if it's not on the mainline. | 16:34 |
| jelmer | fullermd: right | 16:34 |
| fullermd | OK, now I'm completely lost. Are we agreeing or disagreeing? | 16:35 |
| jelmer | fullermd: I was using confusing terminology I think | 16:35 |
| jelmer | fullermd: tags don't have to be set on revisions that are part of the tips ancestry | 16:35 |
| jelmer | fullermd: they can be set on arbitrary revisions. and bzr pull doesn't fetch those arbitrary revisions iirc | 16:35 |
| fullermd | Oh, yes. pull doesn't AFAIK poke into tags at all except to blanket grab 'em. | 16:36 |
| jelmer | fullermd: right, git does fetch all tags even if they point at arbitrary revisions | 16:36 |
| fullermd | Oh, wait, were you using 'non-mainline' to refer to a completely separate branch? | 16:37 |
| jelmer | fullermd: yep | 16:37 |
| jelmer | fullermd: and I'll be the first to admit that's confusing... | 16:37 |
| fullermd | Ah. | 16:39 |
| fullermd | OK, carry on; I'll go be unhelpful somewhere else for a while :) | 16:39 |
| jelmer | :-) | 16:45 |
| bialix | does bzr has the method to check that some path is inside some dir? | 16:47 |
| bialix | e.g. I have root directory and want to make sure the supplied relpath is inside my tree | 16:48 |
| bialix | check relpath for .. ? and check it's not abspath? | 16:48 |
| bialix | osutils.is_inside | 16:50 |
| kojiro | Hmm, I'm using bzr+svn and I'm very new. I understand to push my changes to the svn repo I would use bzr push svn+ssh://blah/my/repo, right? | 16:51 |
| kojiro | If that's right, then is there some way I can have bzr 'remember' the location of the push target? | 16:53 |
| kojiro | oh, maybe the answer is --remember? | 16:57 |
| === salgado is now known as salgado-lunch | ||
| bialix | PathNotChild: Path "C:/root/foo/bar/spam" is not a child of path "C:/root/foo/bar/" <-- what? | 17:01 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| === IslandUsurperAFK is now known as IslandUsurper | ||
| === salgado-lunch is now known as salgado | ||
| === oubiwann is now known as Wooster_ | ||
| === Wooster_ is now known as oubiwann | ||
| === oubiwann is now known as Wooster_ | ||
| === Wooster_ is now known as oubiwann_ | ||
| === oubiwann_ is now known as oubiwann | ||
| === FryGuy_ is now known as FryGuy- | ||
| jelmer | moin lifeless | 21:52 |
| jelmer | lifeless: I still don't think I understand your suggestions for my url subsegments split/join patch | 21:52 |
| jelmer | lifeless: you seem to assume that there's always going to be key/value pairs? | 21:52 |
| lifeless | jelmer: I thought thats what we'd agreed on as a first pass | 21:53 |
| lifeless | and certainly for emitting things | 21:53 |
| jelmer | lifeless: I thought we were just going to leave it open as a possibility for later | 21:54 |
| jelmer | lifeless: key/value pairs that is | 21:54 |
| lifeless | jelmer: I understood the reverse: start explicit, add magic later if wanted. | 21:55 |
| jelmer | lifeless: anyway, I can live with just key/value pairs for now; that at least makes your statements more comprehensible :-) | 21:55 |
| lifeless | :) | 21:55 |
| jelmer | lifeless: also, s/if wanted//. I'm pretty sure I'll want that magic | 21:57 |
| lifeless | I really don't like the huge confusion I expect users to experience at foo,bar rather than foo,branch=bar | 21:58 |
| lifeless | We know that undocumented things generate confusion | 21:58 |
| lifeless | and that the more hints we give, the less confusion | 21:58 |
| jelmer | ... and more typing | 21:59 |
| jelmer | there's a balance in there somewhere | 21:59 |
| lifeless | right | 22:00 |
| lifeless | thus I'm ok with *accepting* foo,bar | 22:00 |
| lifeless | but not [currently] ok with *emitting* foo,bar | 22:01 |
| jelmer | ah, I see the distinction now | 22:02 |
| * jelmer blames the caffeine withdrawal | 22:02 | |
| jelmer | lifeless: thanks, I'll resubmit | 22:02 |
| lifeless | jelmer: accepting foo,bar is a little ugly too - I think we *have* to accept foo,branch=bar [as we emit it, and to support looms, pipelines etc] | 22:06 |
| lifeless | jelmer: but I'll not argue against it :P | 22:06 |
| jelmer | lifeless: I'm in favor of accepting both, the short form as more of a DWIM kind of thing | 22:09 |
| a212901390231901 | erk, I thought I sent a message to Martin Pool and list, but don't see it in the list archives | 22:16 |
| a212901390231901 | will send again, if it arrives twice, apologies | 22:16 |
| === salgado is now known as salgado-afk | ||
| jam | Peng: are you around? | 22:26 |
| jam | or mwhudson | 22:27 |
| mwhudson | jam: otp | 22:27 |
| jam | k | 22:28 |
| drewww | I'm having this problem: https://answers.launchpad.net/bzr/+question/24695 and I've done everything in the thread and bzr is still trying to use http to push to launchpad - any suggestions? | 22:35 |
| jelmer | drewww: what does 'bzr lp-login' tell you? | 22:36 |
| drewww | returns my username properly | 22:37 |
| drewww | "dharry" in this case | 22:37 |
| drewww | I've tried rebinding after setting my login | 22:37 |
| jelmer | do you have ssh keys registered on launchpad? | 22:37 |
| drewww | updated the ssh keys | 22:37 |
| drewww | yep | 22:37 |
| lifeless | bzr info output might help | 22:38 |
| drewww | ah, hmm | 22:38 |
| drewww | http://pastebin.com/DrjxSmjL | 22:38 |
| drewww | how do I get the push branch to not be http? | 22:38 |
| drewww | the pull one looks right | 22:38 |
| drewww | er, checkout | 22:39 |
| jam | drewww: bzr push --remember probably | 22:39 |
| mwhudson | jam: here now | 22:39 |
| jam | mwhudson: some questions wrt loggerhead, especially wrt codebrowse | 22:40 |
| mwhudson | jam: ok | 22:40 |
| drewww | jam: same issue, "cannot lock LockDir" and it's going over http | 22:40 |
| jam | drewww: 'bzr push --remember $NON_HTTP_URL" | 22:40 |
| drewww | ahhh | 22:40 |
| jam | mwhudson: 1) I was wondering if the file-change cache is specifically beneficial even in 2a format repos | 22:40 |
| mwhudson | jam: i'm pretty sure it's a lot less vital in 2a format repos | 22:41 |
| jam | I can see where cPickle can be faster than iter_changes | 22:41 |
| mwhudson | it probably is still a bit faster though | 22:41 |
| jam | just wondering if it is really worth it | 22:41 |
| drewww | jam: looking good - thanks! | 22:41 |
| mwhudson | jam: i'm not sure | 22:41 |
| mwhudson | the motivation was not 2a repos, lets put it that way | 22:42 |
| jam | mwhudson: sure | 22:42 |
| jam | I don't know that it is worth my effort to sort out right now, but maybe someday... | 22:42 |
| jam | mwhudson: 2) I think it was beuno who mentioned that loggerhead only uses sqlite when it is available, but doesn't require it | 22:43 |
| jam | do you think that is important? | 22:43 |
| jam | Given that it creates a TEMP dir even if it isn't configured, the dependency on sqlite seems pretty minor | 22:43 |
| jam | I suppose py <2.6 doesn't have it built in? | 22:43 |
| mwhudson | i think it's built in in 2.5 | 22:44 |
| jam | mwhudson: it is here :) | 22:44 |
| mwhudson | yeah | 22:45 |
| mwhudson | so, no, i don't think i care about that | 22:45 |
| mwhudson | (codebrowse is running on 2.5 now) | 22:45 |
| chx | how can i update to a specific tag? | 22:46 |
| jam | chx: It sort of depends what you mean by "update", but "bzr update -r tag:XXXX" | 22:47 |
| chx | jam: now that's weird, i read the docs it does not mention -r | 22:47 |
| jam | chx: update -r was introduced recently | 22:47 |
| jam | not sure when | 22:47 |
| chx | hm i only have 2.0.3 | 22:48 |
| chx | jam: another question, how can i ask which tag a tree is at? revno says a number | 22:48 |
| jam | chx: I don't think we have that info, you can do "bzr log" and it will show tags | 22:51 |
| jam | "bzr log -r `bzr revno --tree`" | 22:51 |
| chx | jam: is that even necessary? just bzr log |head -3|tail -1|cut -d: -f2 seems to spit out the tag name. | 22:53 |
| jam | chx: it depends where you update to | 22:57 |
| jam | etc | 22:58 |
| jam | I think log follows the branch, and not the working tree | 22:58 |
| chx | ah | 22:58 |
| chx | jam: thx for all. | 23:22 |
| jelmer | 'lo jam | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!