[00:01] I think thats a possible occurence when you cherrypick with a reference branch that has more data than the actual branch you are merging too [00:01] what command did you use to create the bundle ? [00:02] just bzr send --mail-to=bla . remote-branch [00:02] bbiab sorry [00:02] np [00:03] Stavros: the branch against which it will generate the bundle is the first argument [00:04] oh :/ [00:04] so you probably want to swap the arguments [00:04] the second argument defaults to "." [00:04] ah, this was the command: bzr send -r 269 -o file.patch . [00:04] so the "." needs to be the branch url? === mw is now known as mw|out [00:07] ah, that worked, thanks [00:07] this "bzr send [SUBMIT_BRANCH] [PUBLIC_BRANCH]" is a bit confusing, i took "public branch" to mean the remote branch [00:14] jelmer: Actually, the second argument doesn't default to anything. If you don't supply it, no source_branch appears in your merge directive. [00:16] New bug: #214298 in bzr "'bzr pull' internal error parsing for an int in bzr 1.3" [Undecided,New] https://launchpad.net/bugs/214298 [00:19] hmm okay, i've merged the changes, which were apparently done while the branches diverged... what do i do now? [00:19] are the changes only in the working copy, or do they appear as a commit in the repo? [00:24] bah, i don't understand this bundle thing... [00:24] now there are "pending merges" in my repo [00:25] backing up a bit, did you commit after merging? [00:25] well, i edited the changes because the branches had diverged, so i redid what i had done in the intermediate commits [00:25] and i haven't committed yet, no [00:26] i thought bzr's merge would take care of the diverging, though... [00:26] a merge isn't recorded until it is commited [00:26] aha [00:26] so how do i commit it to make sure the developer and his commit message is preserved? [00:27] well, the working copy records that there are pending merges, but it's not recorded in the branch [00:27] aha [00:27] so if i wanted to get rid of it i'd just revert? [00:28] when you merge from someone ele, you create a new commit, saying "merged blah blah" and that commit will incorporate the merged work [00:28] aha [00:28] so now i need to actually commit that? [00:28] and what happens now that i edited the working copy? [00:28] abentley: ah, ok [00:28] well, I dunno what you've done since - but you only want to commit the merge itself + any fixups needed [00:29] i just changed a few lines in those files, and they reappeared unchanged, since the revision was old [00:29] if you want to go back to where you were before any of this, bzr revert --forget-merges will get you back to the last commited state [00:29] aha [00:29] so if i commit now it should commit the correct, changed thing? [00:30] I've lost track of what you've done, sorry, but if the only changes you've done were "bzr merge someurl ; vi blah blah" then commiting now is what you want [00:30] well, let me explain [00:31] a dev made a change to a file, and i did too, at the same time [00:31] but I've got to head, so sorry and good luck :) [00:31] oh [00:31] thanks :) [00:31] i have to go too, come to think of it [00:31] thanks for your help [00:31] bob2: --forget-merges is different to what you describe [00:33] Stavros: I have a suggestion for you [00:34] Stavros: forget bundles for a bit; just work with regular branches on your local disk [00:34] i have [00:34] Stavros: bundles don't alter the workflow, all they do is provide a different transport [00:34] i can't do what i want without bundles, sadly :/ [00:34] yes, i just expect this transport to work like branches, and it looks like it doesn't [00:34] because branches would have merged the changes correctly [00:34] once you get bzr's workflow without bundles, bundles drop in transparently [00:35] Stavros: if you can put up a script showing what you did we can help you understand what is going on [00:35] hm, let me try to summarize [00:35] person A makes a change, person B pulls and makes a change, person A makes another change and person B sends his change to A [00:36] now, person A does bzr merge and the merged file has lost that last change from A [00:37] this is very hand wavy [00:37] I can't tell if you are missing key steps like 'push' 'commit' etc [00:37] hmm [00:37] what do you want me to write exactly? the commands? [00:38] that would be ideal [00:38] (i don't know the exact commands of the other person, though) [00:38] ok, sec [00:38] let me get a pastebin [00:40] how about this? http://dpaste.com/43838/ [00:42] right [00:42] 'pull' means 'become the contents of $URL [00:43] if you pull and both you and someone else have done work, you get an error [00:43] even if the branches have diverged? shouldn't it warn? [00:43] yes [00:43] if you force it, you lose your work [00:43] i didn't force it, though [00:43] just pulled [00:43] in general you should use *merge* to integrate other peoples work [00:43] aha [00:43] and pull when maintaining a mirror of another branch [00:44] but merge does the same, it just doesn't commit [00:44] merge does *not* do the same [00:44] it did :p [00:44] let me try it again [00:44] merge integrates two branches into an intermediate state in your working tree [00:44] yes [00:44] the subsequent commit will record the combined work [00:45] no argument there [00:45] i'm saying that the merging didn't work correctly [00:45] because it still gives me the other person's changes [00:45] well you didn't have 'merge' in that transcript [00:45] instead of both of the changes merged [00:45] yes, i did it now [00:45] replace the last "pull" with "merge" [00:45] so, in the absence of knowing what B did, I have to assume they overwrote your changes [00:46] so bzr is seeing: change 1, change 2, change 3(reverses 2), change 4 [00:46] all in a series [00:46] however, we can debug this [00:46] 'bzr log' [00:46] will show you the history [00:46] invluding all the actions taken by B (not at command level, but as outcomes) [00:46] yes, that doesn't show the last one, because i merged and didn't commit yet [00:46] bzr log -v will show a summary of the action changes [00:47] so commit ;) [00:47] ah, sec [00:47] bzr diff -r X..Y will show the changes between X and Y [00:47] bzr diff -c Y will show the change committed in Y [00:47] ok, done [00:47] we can use this to figure out where the change from line 12 went [00:48] actually, it was more like "i made changes in lines 30-40, the other person made a change to line 1 (with the old lines 30-40), and now bzr replaced my change with his lines" [00:49] so it just reverted to the old ones [00:49] thats what you are seeing [00:49] yes [00:49] and bzr can tell us when it happened [00:49] ah [00:50] bzr log doesn't show much more, it just shows what i said [00:50] old lines being added [00:50] so use bzr diff [00:50] err, i mean diff, sorry [00:50] it shows the old lines being reinstated during his commit ? [00:50] yes [00:50] was his commit a merge ? [00:50] let me check log [00:51] anyhow, basically what you have here is person B reverting your change in some manner, and bzr faithfully bringing the reversion back to you [00:51] it doesn't say, it just says "committed", but i don't think it was a merge, there wasn't anything he could have merged [00:51] yes, exactly [00:51] but what's puzzling is that bzr should be smart enough to undo that, shouldn't it? [00:52] no, its not meant to undo it [00:52] if we both diverged from a single graph node, shouldn't it merge both our changes? [00:52] if he incorporated your change [00:52] hang on [00:52] ok [00:52] if he incorporated your change into his tree [00:52] and decides its wrong [00:52] so puts it back [00:52] oh, i don't think he did... [00:52] ah [00:52] and then you merge from him [00:52] maybe he mixed something up in the working copy... [00:52] i see what you're saying [00:52] bzr is *meant* to put it back in your tree [00:53] yes [00:53] this isn't a *failure to merge* [00:53] this is *merging a reversion* [00:53] yes, but this assumes that he consciously reverted it [00:53] and you can tell its that because in his commit you can see the reversion [00:53] aha [00:53] this could be a mistake - new toolchain etc [00:53] or it could be deliberate [00:54] bzr can't tell you that sorry :P [00:54] it's probably a mistake, because it's two lines [00:54] hmm [00:54] it's odd though, it's not an easy mistake to make, is it [00:54] merge; revert FILENAME; commit [00:54] that will do it [00:54] yes, that's a conscious revert [00:54] merge; revert; commit [00:54] that won't do it [00:55] because 'revert PATH' preserves pending merges. [00:55] ah [00:55] whereas 'revert' clears the pending merge list [00:55] (bzr help revert) [00:55] hmm yes [00:55] or perhaps he forced a commit after pulling and bzr warning him the branches had diverged [00:55] so in particular, 'bzr revert .' after a merge will discard all the content of the merge while preserving the fact of the merge [00:55] but hmm, wouldn't it incorporate the merge in the working copy when pulling? [00:56] aha [00:57] well, i'll just do this by hand then, it's not a big deal [00:57] thanks a lot for your help! [00:58] so; you shouldn't need to do anything by hand :P. [00:58] in particular to get your changes back now: [00:58] bzr merge . -r X..Y [00:58] wait, what does that do? [00:58] where X is the commit before Y and Y is the commit where you put those two lines in [00:58] oh wow [00:58] let me do that [00:58] will merge from your own history the change he discarded [00:58] if that works, it will be very very cool [01:00] actually wth, those commits where a while ago [01:00] how did he manage that? damn [01:01] apparently those changes were done in two different revisions [01:02] hey, what do you know, that DID work! [01:02] that's great! [01:08] Stavros: :) [01:12] poolie: I attached that branch to that bug [01:36] another one sent :) [01:37] hello [01:39] spiv: call ? [01:39] spiv: I want to talk about the repository get stream smart method [02:08] hello every body! [02:08] I was just talking to a friend who is playing around with Launchpad on his Windows box that's living inside a corporate firewall. [02:09] we hit https://bugs.edge.launchpad.net/bzr/+bug/190209 -- xmlrpc doesn't respect $http_proxy [02:09] Launchpad bug 190209 in bzr "launchpad plugin xmlrpc does not use $http_proxy (branching lp: uris does not use system http proxy)" [Medium,Confirmed] [02:09] but, I was thinking, I bet he doesn't have any environment variable with proxy settings [02:10] on account of being on Windows [02:11] which led me to wonder, what *should* we do for proxy settings on Windows? [02:22] i think there should be a per-location configuration variable [02:22] fyi, its possible to fetch the IE proxy settings. UUIC, firefox stores its own - I assume in the profile directory [02:26] markh: hi [02:27] hello markh [02:27] markh: your strategy document; I have a comment to make - I think it would be better to say 'we are going to do X, Y and Z. We chose this because: ... historical exposition and status of things' [02:27] are you (still) in china? [02:28] lifeless: re the knit index, i'd be inclined not to expose it [02:28] markh: I think I'd like Bazaar to do that. [02:28] poolie: Hi - I'm leaving on Saturday [02:29] but the first iteration should be variables in the config file. [02:29] What should I do about xml8? Ian sorta reviewed it, but said he wasn't sure he should cast a binding vote. [02:29] markh: right now, when I read it to review it comes across as a very informative document, but you have to get to the end always [02:29] lifeless: you mean explicitly make decisions? [02:29] (due to his inexperience with that code) [02:29] abentley: I have one more major thing I feel very urgent to do - killing knit joins [02:30] abentley: then I'll do a review of the code in detail for you [02:30] markh: yes! [02:30] markh: open questions are things for the list; decisions are things for the tree. [02:30] lifeless: okay, thanks. [02:30] markh: if the decision can't be taken yet, thats fine- it can still go in the tree. [02:30] markh: but if it *can be taken*, we should take it. We *can* change our mind later. [02:31] lifeless: yes, I agree, thanks. In the initial drafts I didn't want to come across as having pre-conceived decisions without relevant consultation. I agree I should re-edit it to reflect the fact it does seem to have consensus. [02:32] markh: I appreciate your tact; however I encourage you to lead where you know the territory [02:32] its was more a "new kid on the block" thing :) I'll do that in the future as I get known better [02:32] thanks though! [02:32] lifeless++ === BasicMac is now known as BasicOSX [02:35] so re IE proxies, the next pywin32 build should be able to do everything IE can wrt proxies, including auto-detect, and proxies specified on a per-url basis (or per-zone, or whatever it is that IE does). That should be out in a few weeks (or maybe even days!) [02:35] nice [02:35] simply by calling 2 functions exposed by winhttp.dll, but that's ok [02:35] so I guess doing it now with ctypes would be fairly easy [03:02] Odd_Bloke: Are you planning to update your patch for check? [03:03] lunch [03:32] moin [03:35] hello [03:35] hi poolie [03:47] a quick question, bzr still supports non-dirstate branches? [03:47] ppa documentation patch sent to pqm [03:47] Verterok: do you mean older formats? [03:47] yes, older formats are still supported [03:47] back to about 0.1 [03:47] I suppose so [03:49] poolie: thanks, I asked because to improve bzr-eclipse decorations I wrote a dirstate reader in Java :) [03:49] oh i see [03:49] some emacs dude did this too [03:49] well, that should cover almost all users [03:49] I think we should change dirstate every release now [03:49] * poolie starts releasing 1.3.1 [03:50] lifeless: I get the idea from there [03:50] oh, great! [03:50] because it is totally unsupported to do that [03:50] well, now [03:51] i think people can rely on us not changing the format without changing the format string [03:51] they can [03:51] lifeless: it's just a temp workaround, until the xml-thing get's finished [03:51] but we should be able to rely on people not reading our gizzards [03:53] lifeless: I agree, actually the this java "dirstate reader" only support format 3, and check this, if it's not format 3, it fallback to 'bzr inventory' [03:54] Verterok: why have the reader at all if inventory is sufficient? [03:54] in a small tree the it is ~15x times faster [03:55] Verterok: I think that the time would have been better spent fixing bzrlib.builtins.cmd_inventory to be 15 times faster [03:56] I'm sure that most of the time is used in the startup of 'bzr inventory' [03:57] lifeless: sure, I could try to improve inventory [03:59] but I really don't know how to/where start :-P [03:59] bzr --lsprof-file=foo.cachegrind inventory [04:00] lifeless: thanks [04:06] poolie: abentley: spiv: I have sent an RFC about fetch/join etc to the list [04:06] would be obligated if you could eyeball [04:07] my Make is a bit rusty... [04:15] thanks for your detailed comments on my page designs :-P [04:16] :) [04:28] spiv: I sent an updated post_change_branch_tip hook patch that merges Ian's work with mine [04:31] jamesh: Why isn't branch one of the ChangeBranchTipParams? It seems funny to have a tuple where one of the items is just a bag of data anyway. [04:32] abentley: because that's what Ian's branch had? [04:32] poolie: well, its pretty much what we've all been saying for months, so I didn't see anything to disagree with or suggest something different [04:32] jamesh: Well, he's not around, and you're the one submitting the code... [04:32] abentley: I've got no problem making the change you suggested [04:33] abentley: and Ian's branch never actually called the hooks so I doubt he was depending on it :) [04:33] I'll just see what else is out there. [04:34] lifeless: ok, i'm glad you agree [04:34] or indeed more than agree [04:35] abentley: thanks [04:35] abentley: replied [04:36] jamesh: Yes, if you could make that change, I'd appreciate it. [04:37] oh interesting, 'make check' seems to fail at the moment because of something broken in hardy's libraries [04:37] hm [04:37] lifeless: So the data stream would be tagged to indicate whether the texts were annotated/unannotated? [04:39] could people please run [04:39] python -Werror -c 'import xml.etree.cElementTree' [04:40] and tell me if it works? [04:42] lifeless: ^^ [04:42] poolie: works fine in OS X 10.4 (ppc), python-2.5 [04:42] thanks [04:42] abentley: yes, the data stream is self delimiting in that respect (see knit.get_data_stream) [04:43] poolie: can you ls ls /usr/lib/python2.5/site-packages/_xmlplus/ [04:43] there is a bug in lp about this, which I have already commented on being not bzr's fault [04:43] poolie: but it crash on python-2.4 (Linux) [04:43] oh great [04:43] thanks [04:43] poolie: ls -R on that dir [04:43] I think you'll find that the tree is empty [04:44] yes for me too it has subdirectories but no files [04:44] lifeless: Yeah, I know how it works now, just weren't sure whether you were changing it. [04:44] so this is a borked package upgrade leaving an optional thing around which is going to barf [04:44] and oddly enough dpkg -S doesn't know anything about it [04:44] abentley: I'll be tweaking [04:44] poolie: yes, because its gone as far as ts concerned [04:44] abentley: but I'll keep that property [04:44] thanks [04:45] abentley: sent an updated bundle [04:45] jamesh: Thanks. [04:45] spiv: so, I think its time to do Weave.get_data_stream/insert_data_stream [04:45] spiv: I'm thinking the simplest approach is just to extract all the texts as full-texts [04:45] and during insertion generate full-texts and insert [04:46] yes it's bug 212917, i'll redirect it [04:46] Launchpad bug 212917 in python2.5 ""make check" got an internal error" [Undecided,New] https://launchpad.net/bugs/212917 [05:04] lifeless: from the relatively little I know about weaves, that sounds reasonable to me. [05:06] lifeless: do we even care enough about weave to update them? Maybe the weave <-> weave fetcher should be using a private version of join? [05:12] * Verterok goes to the bed, while macports builds kdelibs3+kcachegrind [05:12] g'night all [05:17] abentley: weave -> knit [05:18] abentley: while we want to support that we either need join, or we need data stream support for weaves. [05:18] the latter seems cleaner [05:18] lifeless: Oh. Well, it wouldn't be computationally expensive to generate the deltas, but it might not be worth the time, so I'm okay with making weave suck more. [05:19] could someone help me. i'm getting a memory error for pretty much all commands: http://pastie.caboo.se/177690 [05:19] abentley: I've sent mail just now as it happens [05:20] however, I was able to make a branch and it seems to work ok [05:20] mae^, you seem to be using an old version of bzr. I'd recommend you upgrade, there have been many performance enhancements since [05:20] mae^: that version of bzr corrupted dirstate files from time to time [05:21] mae^: the C extensions handle that corruption with the symptoms you are reporting [05:21] ah, good to know. i shall upgrade. many thanks [05:21] mae^: you'll need to: a) upgrade to a bzr version like 1.0, or 1.3.1 (something newer :)) [05:21] mae^: and b) you probably need to recreate that tree - bzr branch to a new directory will work, but the .bzr/checkout/dirstate file may still give you grief [05:21] gee, didn't know its been that long [05:22] there are notes in launchpad about this, or you can ask here and someone should be able to step you through getting a pristine dirstate/not accessing the tree. [05:22] mae^, bzr does a new release every month or so, so it might of not been that long :) [05:22] 5 months [05:22] so is this something bzr can fix or check beyond upgrading the binaries? [05:23] upgrading the binaries will avoid creating the problem again [05:23] and the current repo? [05:23] you probable did a 'bzr mv' that hit the bug in 0.91 [05:23] 14:20 < lifeless> mae^: and b) you probably need to recreate that tree - bzr branch to a new directory will work, but the .bzr/checkout/dirstate file may still give you grief [05:23] the bzr 1.3 stack is built in gutsy-backports now, just in case the PPA isn't up to sync yet [05:23] of course by that I mean 1.3.1 [05:24] ok, well I'll upgrade and see where that gets me === Verterok is now known as Verterok_ [05:37] (out for a bit, back soon) [05:43] upgrade + branch'd .bzr dir did it [05:44] lifeless: thx === mwhudson_ is now known as mwhudson [07:10] * poolie merging "make dist" patch [07:22] on the CLI, is "baz" the same thing as "bzr" or did I grab the wrong thing? [07:22] lech: Nothing to do with each other. [07:22] you need bzr instead [07:23] aka bazaar-ng? [07:23] lech: yes [07:24] alright, thanks [07:24] poolie: Maybe it's time to get rid of http://bazaar-vcs.org/Baz1x [07:24] "you are welcome to use" is not really the right message anymore :) [07:24] and having anything besides a loud "baz is not bzr" on that page probably isn't helping. [07:25] lech: what platform are you on, and how did you get that installed? [07:25] afc, good point [07:25] poolie, debian on a headless box [07:25] apt-cache displayed bazaar in my search results so I figured that was it [07:25] with 'install bazaar'? [07:25] (I am recently made aware of this because when I asked what version of bzr a person had a few hours ago as they were adding build support for their distro to my project, they responded "1.4.2" and I was like "WTF?") [07:25] right [07:25] poolie, yes [07:26] I suspect though bzr requires bazaar to be installed though, no? [07:26] lech, afc, there's a bug open about it; dysfunctional debian process (imao) is making it slow to fix [07:26] no [07:26] poolie: yeah [07:26] it's hard to get rid of obsolete software. [07:26] poolie, you mean it showing up in the update tree? [07:27] i mean at minimum it should not be called 'bazaar' anymore [07:27] hah... you guys should do a 1.4.3 revision of baz... containing bzr :) [07:28] [Ok, I'll shut up now] [07:28] there is still some value in having it [07:28] Yeah. You really don't need http://bazaar-vcs.org/Baz1x/Downloads at all. It's diluting your brand. [07:28] for people who have very specific needs, such as using it to convert to bzr [07:28] instead of removing it, why not simply update it and use it as an alias? :) [07:29] that's the plan [07:29] lech: it is completely different software [07:29] lech: the only thing that it has in common is that both are revision control tools. [07:29] AfC, according to the URL it displays in the package tree, it's the same thing [07:29] at least, it points to bazaar (bzr) pages [07:30] in aptitude at least [07:30] Like I said, massive branding problem [07:30] ahh, alright [07:30] well, thanks for helping clean things up in that respect for me [07:31] poolie: it's not Debian being dysfunctional really, it's baz failing to build. [07:31] fetching a project moves it to the current directory I happen to be in, correct? [07:32] s/moves/puts [07:32] james_w: i think it's a bit bizarre that failing to build means it remains available [07:32] lech: that's right [07:33] poolie: Seriously though, I don't think you guys hosting debs of baz is helping very much [07:34] poolie: the argument is that the old version built fine, so you might as well let people use it. [07:34] poolie: the problem is that we can't rename the package, as you need to build it to do that. [07:36] i can appreciate the argument but i don't think it's a good tradeoff in this case [07:37] ok, first use of bzr with my first error [07:38] lech: back up: do you have a recent (ie >= 1.3) version of Bazaar installed? [07:39] Bazaar (bzr) 0.11.0 [07:39] Jesus [07:39] I am guessing that might be a no? [07:39] it's about 18 months old [07:39] for us that's a long time :) [07:39] wow, yeah... what the hell [07:40] I even did a full package update before this [07:40] lech: these guys are moving _very_ fast, at roughly one release per month. That makes it at least 15 versions old [07:40] if you're on the last stable debian release that may be the problem [07:41] I'm on sarge for this box [07:41]