[00:02] poolie: review done [00:03] poolie: I haven't made a vote as such, I'll leave it up to you. I would consider it needs-fixing if I were to vote [00:03] k [00:03] is this the same one ian reviewed? [00:03] yes [00:04] I didn't comment on the stuff he caught [00:04] k [00:04] i'm going to try to close mail soon and do that [00:10] I'm going to look at this mv a b; mv b a; fail bug [00:10] as I have dirstate paged in currently [00:10] then onto commit via deltas [00:16] i need help understanding the difference between rebase and merge --remember. the situation is 3 unbound branches, A, B, C. C was branched from A, A got merged to B, and C wants to get all of B's changes from now on. [00:16] It's about tree topology [00:16] merge joins two branches of a tree back together [00:16] rebase pretends there wasn't a branch at all [00:16] IIUC, rebase would make C look like it branched from B *today* and replay all of C's changes after that. [00:16] Yup [00:17] and merge --remember would apply the changes and set parent_location for future use. [00:17] merge: -----<======\---- [00:17] rebase: -------\_________ [00:17] (by terrible ASCII-art) [00:18] poolie: when thinking about testing [00:18] s/terrible/awesome/ [00:18] poolie: do remember that running the whole stack is very expensive [00:19] poolie: I hope that many easy bugs are best tested via tweaks to existing tests rather than new tests [00:20] LeoNerd: thanks [00:21] any ideas what this error means? bzr: ERROR: bzrlib.errors.NotLefthandHistory: Supplied history does not follow left-hand parents [00:23] lifeless: running the whole stack in the sense of run_bzr? [00:23] yes [00:23] we say somewhere in our testing notes [00:23] mt-: um, it depends on the context [00:23] yes i do remember that [00:24] that best practice for blackbox tests is to use the low level API for setting up the scenario [00:24] and only use the full stack when we're testing it [00:26] poolie: http://paste.ubuntu.com/218399/ [00:27] poolie: somebody else is doing that. It works fine when I do it :S [00:28] lifeless: yes, that's pretty much what i said in my mail [00:29] morning all [00:29] i'm not ignorant of that [00:29] poolie: ok cool [00:29] i'm just questioning whether it is worth trading some of that off against having: [00:29] better illustrations of what happens [00:29] hi poolie, lifeless [00:29] and easier approachability for people writing tests [00:29] casually [00:29] whether the second would actually happen enough to be worthwhile is uncertain [00:30] hello igc [00:31] I am skeptical. We have lots of contributors that have wafted up and cloned tests very successfully [00:31] MT-: that would seem to be a bug, perhaps provoked by something in the source branch [00:31] hi igc [00:31] MT-: the first thing i would try is going to a more recent bzr [00:33] poolie: I'll try that, thanks [00:37] poolie: https://bugs.edge.launchpad.net/bzr/+bug/395556 - you say in there you'll merge some tests. Have you? [00:37] Ubuntu bug 395556 in bzr "bzr mv (rename in place) causes commit to fail depending on specific filenames" [High,Confirmed] [00:37] so, we also have lots of contributors who balk at writing a test [00:38] possibly they would do that even if testing was zero effort at all [00:38] we can test this cheaply [00:38] by writing the tests ourselves, but *not* fixing up fallout [00:39] by cheaply I mean, without inventing infrastructure that might not be used. [00:39] that's a factor too [00:39] if the contributors don't follow up and fix the regressions we find, then its pretty certain they wouldn't test that will regardless [00:40] will? [00:40] e [00:40] anyhow, yes [00:40] it may be that in fact they've put up a patch that doesn't actually work [00:40] i'm just trying to think of some answer to "testing is too hard" beyond "suck it up" [00:40] :? [00:41] also, in reviewing aaron's patch, i do think it's suboptimal that there is no clear demonstration of how it actually works [00:41] I agree with that [00:41] like the idea that lp should put screenshots of the proposed fix on bugs [00:41] heh, the analogy is interesting [00:42] because testing by comparing to screenshots is pretty sucky [00:42] we do have the ability, in run_bzr, to provide inputs to commands [00:42] as a stdin stringio? [00:42] poolie: the tests for bug 395556, did they land? and where can I find them - are they XFAIL's? [00:42] Launchpad bug 395556 in bzr "bzr mv (rename in place) causes commit to fail depending on specific filenames" [High,Confirmed] https://launchpad.net/bugs/395556 [00:43] i'll check, was talking to someone :-P [00:43] poolie: yes, though I think we provide glue to make it easier to use than that [00:43] i think i submitted them [00:44] yes, there are knownfailure tests in trunk [00:44] grep for that bug number [00:44] thanks [00:45] LeoNerd: i went with merge --remember, but the parent_location of the branch did not change upon commit... what am i misunderstanding? [00:45] one way to look at it is i'm suggesting more or higher-quality glue [00:45] input as blah(... stdin="y\n\n\n\r\n") is not so easy to review [00:46] improving that can be done stepwise [00:46] without going away from the other things that are good in our test suite [00:46] and i think not at a terribly high cost [00:47] spiv, re https://code.edge.launchpad.net/~mbp/bzr/391411-reconfigure-stacked/+merge/8527 [00:48] would making RemoteRepository be a Repostiory subclass be very traumatic? [00:51] * jml -> chatswood for breakfast. [00:53] poolie: not sure. Well, I'm sure there was a reason why it wasn't done like that initially. [00:53] Perhaps a good starting point would be to create a new common base class for RemoteRepository and Repository, and gradually move things into that? [00:54] Perhaps we'll be able to collapse that base class and Repository fairly rapidly. [00:54] heh, that's what i was doing [00:54] lifeless didn't like it :) [00:54] Heh. [00:54] but maybe with a comment it would get by [00:54] It is a little odd to me that we have Branch and BzrBranch, but no similar split for Repository. [00:55] Has anyone here used bzr from a virtual machine? [00:56] so [00:56] I don't recall any good reason for them being different [00:56] I think it is worth doing a test run with RR as a subclass of Repository [00:56] it will answer the question much faster than speculation [00:57] its true that there is potential for confusion, having a proxy object subclass the thing it proxies [00:57] but that shouldn't be worse than with Branch [00:57] spiv: we do have a split in the repository classes [00:58] spiv: Repository is the abstract interface - we have wildly different subclasses [00:58] GungaDin: yes, people have used bzr from vms [00:58] GungaDin: some of the core developers do so regularly. [00:59] and they're able to checkout stuff without problems? [00:59] with bzr+ssh? [01:00] yes and yes [01:01] I really encourage you to file a bug so that *all* the developers can help you, rather than just the ones that see what you type here. [01:01] I also installed Ubuntu in VirtualBox... and the problem persists. [01:01] btw.. I was able to checkout with https... but not with bzr+ssh. [01:02] well, I can't be sure it's a bug. [01:02] at least not necessarily in Bazaar. [01:03] thats fine [01:03] bug trackers are a place to discuss problbems [01:04] there is no requirement that everything in them be known to be a bug prior to putting the thing in the bug tracker [01:04] if there was such a requirement, very few bugs would ever be put in bugtrackers [01:05] ok [01:05] I don't think it's bzr... [01:05] now for the first time it's gone past this stage... [01:05] and it'sa ctually building the tree... [01:06] its happening to bzr [01:06] what the hell is going on... [01:06] ?! [01:06] even if its not bzr we'd like to know whats going on [01:06] I have a section of a bug tracker that's almost entirely used for discussions and notes.. [01:06] so that we can advise other people if they have these symptoms [01:06] lifelfess - I'd like to file as much as i can... but it's happening at my work... so I'm a bit limited getting all the info. [01:06] or perhaps we can come up with a change to bzr to reduce this happening [01:07] GungaDin: I can appreciate that [01:07] what would you have me do, then? [01:08] file a bug :) [01:09] tell us what you can [01:09] this will let folk that are not here right now chime in [01:09] it sounds like it just worked for you though? [01:18] ok, I filed a bug report. [01:19] yes, now it just worked.... [01:19] well thats some good news:) [01:20] see? isn't filing bugs good? :) [01:26] anyway, thanks for your help. [01:39] Hi igc - I'm finished everything I wanted to on the TreeWidget. Any thoughts on what to tackle next? [01:41] igc: I've pushed all my inventory delta prophylactic code btw [02:13] hi garyvdm! [02:14] Hi Ian [02:14] garyvdm: the next thing I was hoping you'd work on was ... [02:14] a better revision widget [02:14] or was it a better branch widget? I forget [02:15] anyhow, one or both of them given ... [02:15] branch widget? [02:15] numerous q* commands use those [02:16] garyvdm: I'd need to look over my notes but ... [02:16] I think the main issue was being able to select a merge directive, not just a directory [02:17] Ok - Let me look at the revision selector. [02:18] garyvdm: thanks. I suspect it was far more important than the branch one [02:19] garyvdm: there were also some small qbzr issues that someone (perhaps you?) could fix soon: [02:19] 1. the compatibility with bzr-pipeline issue [02:19] 2. qinfo working on a shared repo [02:20] 3. qrevert dropping pending merges [02:20] igc: if you have a chance - please try out lp:~garyvdm/qbzr/newwtlist [02:20] garyvdm: I'll take a look at those next week say if no-one gets to them [02:22] garyvdm: I need to focus on some 2.0 stuff this week but I promise I'll take a (another) look this weekend say [02:22] igc: Np - I understand. [02:22] (my nights are pretty full this week with family stuff) [02:23] igc: For no. 3 - I posted a mockup to the bug. How does that look? [02:24] garyvdm: that looks good [02:24] Cool - I get that done. [02:25] First - a itch scratch - Spell checker suggestions in qcommit :-) [02:26] garyvdm: also, did you see the comments from lifeless re register_lazy_decorated? [02:26] garyvdm: I'm reviewing that now btw [02:27] garyvdm: if you're in agreement with Robert's comments, I'll defer my review till you've done those changes [02:27] Yes - but unfortunately - that won't really help to solve the bzr-pipeline compatibility problem. It's a bit more complex. === TDJACR is now known as TheDJACR [02:34] garyvdm: so pipeline and qbzr are both overriding the merge command from what I've been told [02:34] garyvdm: if that's right, why does qbzr need to? [02:35] qbzr adds merge --qpreview [02:35] which shows the preview in qdiff [02:40] poolie, thanks for the prompt & clear metronome response [02:40] thanks for the metronome [02:40] also for the "these people are wrong" :-) [02:46] so, I'm thinking of not RMing 1.17+1 [02:46] I'd really like to get back into actually writing code. [02:51] garyvdm: so I think we need to rethink qdiff launching actually [02:51] qdiff or qpreview? [02:52] garyvdm: I like qdiff but sometimes I really want to use meld for a period of time, e.g. when doing a complex review [02:52] garyvdm: if I configure meld as a diff tool, then qcommit (say) still launches qdiff but then let's me launch meld from there IIUIC [02:53] garyvdm: I kind of think it should just launch meld directly [02:53] igc - You can make meld the default. Then if you click on diff in any of the qbzr windows, if will open meld [02:54] garyvdm: also, maybe "merge -qpreview" is better as "merge --review --using qdiff" or something like that [02:54] garyvdm: I tried that and it didn't seem to work for me. I'll try again soon [02:54] igc - yes [02:57] igc - it won't (go straight to meld) if you just run bzr qdiff - so we probably need to make things like bzr explorer aware of the qdiff config. [03:12] garyvdm: what about making qdiff smarter and getting it to launch the right default diff tool? [03:12] garyvdm: I can make epxlorer smarter but those smarts need to also go into ... [03:13] TortoiseBzr, qbzr-eclipse, etc. [03:13] garyvdm: seems better to just make qdiff Do The Right Thing IMO [03:14] igc - 1. If you do that, and you make some other tool the default, how do you get into qdiff? [03:15] Maybe add a option to qdiff: bzr qdiff --usingconfigdefault [03:15] 2. - err forgot what 2 was. [03:16] garyvdm: 1. not sure. Adding an option would work fine (either way). [03:18] hm [03:19] I did 'bzr uncommit' and now I regret it. however, the revision id that uncommit gave me has scrolled off my terminal. is there any way to get it back? :) [03:20] dash: install bzrtools plugin [03:20] done [03:20] dash: run bzr heads --dead [03:21] * igc lunch then back onto reviewing apply-inv-delta patch from lifeless [03:22] ach. this is branched from SVN [03:22] and i'm getting an error from the svn server as a result of that command [03:22] (not a checkout, not a lightweight checkout, a branch) [03:23] dash: sorry - not sure then. [03:25] pretty weird =/ [03:25] thanks for the pointer anyway === _thumper_ is now known as thumper === garyvdm_ is now known as garyvdm === ja1 is now known as jam [03:41] heh, ran some of the code from the heads plugin mnually [03:41] got it back :) [03:42] hooray for bzr. [04:51] lifeless: why remove the branches? because they're no longer playing the same role of being canonical and primary? [04:52] poolie: several reasons; its faster to pull from lp; lp has a branch viewer; we don't point people at the directory anyway - we have a wiki page listing the urls [04:53] this seems like a reason to change the wiki not remove them [04:53] changing the wiki is implicit [04:54] by which I mean the wiki page should point at the primary location [04:54] is bug 399540 the guy who was talking to you before here? [04:54] Launchpad bug 399540 in bzr "bzr works strangely in a virtual machine guest" [Undecided,New] https://launchpad.net/bugs/399540 [04:54] what a weird bug [04:54] I think so [05:27] igc, i've updated the spreadsheet, review it at your convenience [05:27] * poolie crosses off another item [05:41] poolie: thanks [06:44] lifeless, spiv, igc, i'm out for a bit, online again after 5 [06:44] poolie: I'll be gone by then; ciao. [06:44] ok === abentley1 is now known as abentley [07:00] so, 3 bugs fixed. [07:00] sent up for review. [07:11] ciao y'all [07:26] hi all [07:41] * spiv ducks out to shops [08:08] mwhudson: hey [08:09] mwhudson: Are the git revisions imported one-by-one by launchpad? [08:09] jelmer: no [08:09] well, what do you mean? [08:09] mwhudson: I'm subscribed to the samba branch, and woke up to find 750 new emails waiting for me... [08:09] jelmer: the emails are done one by one and the import was broken for a few weeks [08:09] jelmer: there's nothing special about git imports here [08:10] (we should probably avoid this sort of flood somehow though) [08:15] mwhudson: that'd be nice [08:16] mwhudson: does this also happen for "native" bzr branches, if somebody pushes multiple revisions to them? [08:16] jelmer: yes [08:16] hi all [08:16] i have a launchpad branch i would like to merge to [08:16] mwhudson: ah, ok [08:16] mwhudson: It's just a temporary thing then I guess, since this branch got "unbroken" because of the new bzr-git [08:17] jelmer: right [08:17] jelmer: it makes rebasing a bit interesting! [08:17] what is the syntax of that? do i got to my existing branch and say bzr merge ****** [08:23] phurl: bzr merge lp:~username/projectname/branchname [08:24] thanks [08:33] mwhudson: did something just land that makes sure the cache is kept? [08:33] mwhudson: I was a bit surprised to see the samba branch working now [08:35] jelmer: yes [08:40] mwhudson: \o/ [08:48] can anyone point me to documentation about keeping one bzr branch in another? [08:48] say I have project1/ and module1/ and I want to keep a copy of module1 within project1 [08:49] is this a vendor branch === abentley1 is now known as abentley [08:51] johnskulski, the feature is known as 'nested trees', and it's not implemented in Bazaar (yet) [08:52] jml:: i see. is there a workflow without using 3rd party tools? [08:53] johnskulski: with bzr-scmproj [08:53] have you all used either that or config-manager? are they solid? [08:53] johnskulski, it depends on what you mean by 'third party tools' and what you're exact use case is. You can do a pretty good job with symlinks & a couple of simple shell scripts [08:54] johnskulski: I've used scmproj, but most people get by without anything of the sorts [08:54] hm ok [08:54] oui ? [08:54] sorry wrong window :) [08:54] johnskulski, I haven't used config-manager directly, but I'm told that the Launchpad development team use it. [08:55] thanks for you advice. [08:56] it would be great to push back changes from individual projects [08:56] jml:: what would the shell scripts do? [08:56] generate and apply patches? [08:57] uhh, they'd reimplement config-manager :) [08:58] hehe [08:58] or as much of it as you actually need for what you want to do. [09:03] jml:: i'm confused on what commands would accmplish what I'm trying to do [09:03] (new to bzr) [09:04] johnskulski, what are you trying to do? [09:06] project/ is a bzr repository, module1/ is a bzr repo, i would like to have project/module1/ be a branch of module1 such that i can add it to the project repos (so another branch will have that) and push changes back to module1/ (bug fixes, the module is shared among other projects) [09:07] wow... getting acf locally! [09:07] acf? [09:08] johnskulski, not related to our conversation, but related to the channel more generally :) [09:08] (I'm multitasking a little atm) [09:08] ah [09:08] no worries :) [09:09] johnskulski, so, what you'd do is have a script or a make step or something in project/ that run 'bzr branch central-copy:module1' [09:10] johnskulski, that is, there'd be no tightly defined relationship between project/ & module1/ in bzr itself, it would be a part of your build scripts. [09:10] jml:: i am not sure what central-copy: means [09:10] i am not find it in the docs [09:11] there's going to be a canonical location for module1 right? [09:11] on one of your servers or launchpad or whatever [09:11] the thing that's 'trunk' for that module. [09:11] yeah this will all be on a local filesystem [09:11] right [09:11] johnskulski, is it just you working on the project? [09:11] something liek /var/bzr/shared/module1 [09:12] jml:: no about 12 of us [09:12] all diferent projects [09:12] usually sperately [09:12] why are you sharing a filesystem? [09:12] central dev [09:12] can't you afford hard drives? [09:12] anyway, that's off topic [09:13] we have a centralized development server [09:13] same machine [09:13] you can't run the project on your local machines? [09:13] night all [09:13] jml:: it doesn't matter :) [09:14] so, as I was saying, you'd have something in your build scripts that says, 'bzr branch file:///var/bzr/shared/module1' [09:15] or a variation on that. [09:16] let me tyr this, thanks! [09:16] I work on Launchpad. We have a bunch of dependencies that we manage in branches. We pull those from a server using a script, and then whenever we create a branch locally, we run another script to symlink those branches into that new branch. [09:16] (because we tend to have one branch per feature/bugfix) [09:24] jml, do you work with applications? [09:25] johnskulski, I don't follow. I work on Launchpad itself. :) [09:26] my set up is: we are a webapp shop and generally we work on 8-10 projects at a time all based off a standard framework, on top of that we have modules that we would like to include in each projects. it would be a great win if say i'm working a project and could push back changes to the framework or module [09:26] maybe another set up is more appropriate [09:26] launchpad itself? the webapp? [09:26] johnskulski, yes. [09:28] I tend to just merge in modules that I use in multiple places. That doesn't work well for the case where you want to work ON the module in the context of a given project, and then push those module changes back upstream though. [09:28] But I don't do that very often, so dealing with it manually in those cases works well enough for me. [09:28] jml:: we don't do builds, which may be something we could switch to [09:30] fullermd:: so if you fix something in the module, you generate a patch and apply it to it manually? === abentley1 is now known as abentley [09:37] johnskulski: In one form or another, yah. [09:38] Most of the time I just work on changes directly in the module though (and the ones that make that hard, I have on my list to improve so that it's not) [09:38] johnskulski: seriously, have a look at scmproj [09:40] Yah. The 'by-reference' style nested tree work will be most like what you want, and scmproj is a variant of that. [09:52] LarstiQ:: yes this looks great [09:52] thanks [09:52] this channel proves helpful everytime, thanks! === mario__ is now known as pygi === beuno_ is now known as beuno [13:23] can someone remind me what plugin is required to get the webserve thing going? [13:24] loggerhead ? [13:25] yes, thanks [13:30] how do I use this thing? [13:31] how do I see what plugin commands are avail? [13:38] bzr plugins === Pilky_ is now known as Pilky [13:53] luks: that tells me what plugins are available, not what the commands are [13:54] eyda|mon: bzr commands, although that will list builtin commands. [13:54] oh, sorry, I misread the question [13:54] But will include the plugins too :) [13:54] luks: no worries [13:54] bzr help commands [13:54] Er, sorry: bzr help commands [13:54] so there's no specific command to just list the ones for a specific plugin [13:54] bzr help commands | grep PLUGINNAME :) [13:55] I'm trying to use the loggerhead but there are no instructions on their site [13:55] bzr help plugins/ ? [13:55] grep works :) [13:55] that shows you the help page, not a list of commands [13:55] luks: sure, but it is probably more helpful [13:56] luks: seeing as loggerhead doesn't feature in commands, but does mention how it works in the plugin help [13:57] luks: to be fair, eyda|mon asked the wrong question ;) [13:57] I know nothing about loggerhead, just answering questions :) [13:57] eyda|mon: found the `bzr serve --http`? [13:57] LarstiQ: to be fair, eydaimon didn't know what question to ask because the plugin setup isn't obvious [13:57] * LarstiQ nods at eyda|mon [13:57] LarstiQ: yes, thanks [13:57] eyda|mon: also, the README file might help: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/annotate/head%3A/README [13:58] eyda|mon: asking the right question is not easy to do [13:58] I was after what I thought would be a common interface on how to use plugins [13:58] or to find out their usage anyway [13:58] Plugins can do quite a wide variety of things :) [13:58] eyda|mon: I usually look at the README [13:59] that's why I think it would be nice if I could just do bzr plugins PLUGIN and it would tell me the avilable commands [13:59] Some add commands, some extend existing commands, some add hooks, some add new formats, etc... [13:59] eyda|mon: but I think stressing something useful in the online help system is a good idea [13:59] and that includes extending, adding, hooks etc :) [14:00] ok [14:00] LarstiQ: are you suggesting I file a ticket? [14:00] eyda|mon: that's "bzr help plugin/" at the moment. [14:01] eyda|mon: I didn't yet, but yes please :) [14:01] Perhaps "bzr plugins" should suggest that, it's not particularly discoverable at the moment. [14:01] * LarstiQ nods at spiv [14:01] There is no help plugin/XYZ... [14:01] There's plugin_s_/XYZ, but that just gives the 1-liner. [14:01] fullermd: sorry, typo. Thanks [14:02] fullermd: try plugins/svn or plugins/gtk [14:02] or plugins/loggerhead [14:02] fullermd: it's not necessarily a one-liner. [14:02] Sure, but that's only if the plugin lists it. bzrtools frex tells you nothing. [14:02] File a bug on bzrtools :) [14:03] you guys are missing the help plugins :) [14:04] seems like something so useful as loggerhead should be included in bzr [14:05] eyda|mon: yeah, that's been discussed occasionally. I don't recall the outcome, though. [14:05] Well, once you add up all the so-useful-to-$PERSON's, you end up with a real big tarball ;) [14:06] fullermd: I'm more important than others so, my useful-to-eydaimon should be considered very carefully [14:06] I know we would like to make it easy to do something like "bzr serve --http" to run up a quick and simple bzr+http smart server with loggerhead. [14:06] eyda|mon: :) [14:07] yeah, like mercurials [14:07] eyda|mon: Oh, I didn't realize it was YOU. Carry on. [14:07] nothing fancy, but it works [14:07] fullermd: there we go :) [14:07] * eyda|mon wonders when people will start to grasp his importance [14:08] Probably not 'till after they give up on their screwed up sleep schedules and just synchronize with mine. [14:09] * fullermd still vaguely wishes to be able to sufficiently flexibilate URL handling on bzr+http. [14:10] (and flexibilate is totally a word. You can look it up. In my brain.) [14:12] * eyda|mon makes a new port for SimpleTAL since macports doesn't have one. [14:12] feels like I'm ALWAYS making new ports [14:12] Hey, welcome to MY life... [14:15] I've had a look at one of the 'easy' open bugs, namely #72227 -- but I am unable to reproduce the problem with the current bzr (1.17~rc1+4531+117 from the nightly ppa). [14:16]