| lifeless | 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 |
|---|---|---|
| lifeless | what command did you use to create the bundle ? | 00:01 |
| Stavros | just bzr send --mail-to=bla . remote-branch | 00:02 |
| lifeless | bbiab sorry | 00:02 |
| Stavros | np | 00:02 |
| jelmer | Stavros: the branch against which it will generate the bundle is the first argument | 00:03 |
| Stavros | oh :/ | 00:04 |
| jelmer | so you probably want to swap the arguments | 00:04 |
| jelmer | the second argument defaults to "." | 00:04 |
| Stavros | ah, this was the command: bzr send -r 269 -o file.patch . | 00:04 |
| Stavros | so the "." needs to be the branch url? | 00:04 |
| === mw is now known as mw|out | ||
| Stavros | ah, that worked, thanks | 00:07 |
| Stavros | this "bzr send [SUBMIT_BRANCH] [PUBLIC_BRANCH]" is a bit confusing, i took "public branch" to mean the remote branch | 00:07 |
| abentley | 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:14 |
| ubotu | 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:16 |
| Stavros | hmm okay, i've merged the changes, which were apparently done while the branches diverged... what do i do now? | 00:19 |
| Stavros | are the changes only in the working copy, or do they appear as a commit in the repo? | 00:19 |
| Stavros | bah, i don't understand this bundle thing... | 00:24 |
| Stavros | now there are "pending merges" in my repo | 00:24 |
| bob2 | backing up a bit, did you commit after merging? | 00:25 |
| Stavros | well, i edited the changes because the branches had diverged, so i redid what i had done in the intermediate commits | 00:25 |
| Stavros | and i haven't committed yet, no | 00:25 |
| Stavros | i thought bzr's merge would take care of the diverging, though... | 00:26 |
| bob2 | a merge isn't recorded until it is commited | 00:26 |
| Stavros | aha | 00:26 |
| Stavros | so how do i commit it to make sure the developer and his commit message is preserved? | 00:26 |
| bob2 | well, the working copy records that there are pending merges, but it's not recorded in the branch | 00:27 |
| Stavros | aha | 00:27 |
| Stavros | so if i wanted to get rid of it i'd just revert? | 00:27 |
| bob2 | 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 |
| Stavros | aha | 00:28 |
| Stavros | so now i need to actually commit that? | 00:28 |
| Stavros | and what happens now that i edited the working copy? | 00:28 |
| jelmer | abentley: ah, ok | 00:28 |
| bob2 | well, I dunno what you've done since - but you only want to commit the merge itself + any fixups needed | 00:28 |
| Stavros | i just changed a few lines in those files, and they reappeared unchanged, since the revision was old | 00:29 |
| bob2 | 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 |
| Stavros | aha | 00:29 |
| Stavros | so if i commit now it should commit the correct, changed thing? | 00:29 |
| bob2 | 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 |
| Stavros | well, let me explain | 00:30 |
| Stavros | a dev made a change to a file, and i did too, at the same time | 00:31 |
| bob2 | but I've got to head, so sorry and good luck :) | 00:31 |
| Stavros | oh | 00:31 |
| Stavros | thanks :) | 00:31 |
| Stavros | i have to go too, come to think of it | 00:31 |
| Stavros | thanks for your help | 00:31 |
| lifeless | bob2: --forget-merges is different to what you describe | 00:31 |
| lifeless | Stavros: I have a suggestion for you | 00:33 |
| lifeless | Stavros: forget bundles for a bit; just work with regular branches on your local disk | 00:34 |
| Stavros | i have | 00:34 |
| lifeless | Stavros: bundles don't alter the workflow, all they do is provide a different transport | 00:34 |
| Stavros | i can't do what i want without bundles, sadly :/ | 00:34 |
| Stavros | yes, i just expect this transport to work like branches, and it looks like it doesn't | 00:34 |
| Stavros | because branches would have merged the changes correctly | 00:34 |
| lifeless | once you get bzr's workflow without bundles, bundles drop in transparently | 00:34 |
| lifeless | Stavros: if you can put up a script showing what you did we can help you understand what is going on | 00:35 |
| Stavros | hm, let me try to summarize | 00:35 |
| Stavros | 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:35 |
| Stavros | now, person A does bzr merge and the merged file has lost that last change from A | 00:36 |
| lifeless | this is very hand wavy | 00:37 |
| lifeless | I can't tell if you are missing key steps like 'push' 'commit' etc | 00:37 |
| Stavros | hmm | 00:37 |
| Stavros | what do you want me to write exactly? the commands? | 00:37 |
| lifeless | that would be ideal | 00:38 |
| Stavros | (i don't know the exact commands of the other person, though) | 00:38 |
| Stavros | ok, sec | 00:38 |
| Stavros | let me get a pastebin | 00:38 |
| Stavros | how about this? http://dpaste.com/43838/ | 00:40 |
| lifeless | right | 00:42 |
| lifeless | 'pull' means 'become the contents of $URL | 00:42 |
| lifeless | if you pull and both you and someone else have done work, you get an error | 00:43 |
| Stavros | even if the branches have diverged? shouldn't it warn? | 00:43 |
| Stavros | yes | 00:43 |
| lifeless | if you force it, you lose your work | 00:43 |
| Stavros | i didn't force it, though | 00:43 |
| Stavros | just pulled | 00:43 |
| lifeless | in general you should use *merge* to integrate other peoples work | 00:43 |
| Stavros | aha | 00:43 |
| lifeless | and pull when maintaining a mirror of another branch | 00:43 |
| Stavros | but merge does the same, it just doesn't commit | 00:44 |
| lifeless | merge does *not* do the same | 00:44 |
| Stavros | it did :p | 00:44 |
| Stavros | let me try it again | 00:44 |
| lifeless | merge integrates two branches into an intermediate state in your working tree | 00:44 |
| Stavros | yes | 00:44 |
| lifeless | the subsequent commit will record the combined work | 00:44 |
| Stavros | no argument there | 00:45 |
| Stavros | i'm saying that the merging didn't work correctly | 00:45 |
| Stavros | because it still gives me the other person's changes | 00:45 |
| lifeless | well you didn't have 'merge' in that transcript | 00:45 |
| Stavros | instead of both of the changes merged | 00:45 |
| Stavros | yes, i did it now | 00:45 |
| Stavros | replace the last "pull" with "merge" | 00:45 |
| lifeless | so, in the absence of knowing what B did, I have to assume they overwrote your changes | 00:45 |
| lifeless | so bzr is seeing: change 1, change 2, change 3(reverses 2), change 4 | 00:46 |
| lifeless | all in a series | 00:46 |
| lifeless | however, we can debug this | 00:46 |
| lifeless | 'bzr log' | 00:46 |
| lifeless | will show you the history | 00:46 |
| lifeless | invluding all the actions taken by B (not at command level, but as outcomes) | 00:46 |
| Stavros | yes, that doesn't show the last one, because i merged and didn't commit yet | 00:46 |
| lifeless | bzr log -v will show a summary of the action changes | 00:46 |
| lifeless | so commit ;) | 00:47 |
| Stavros | ah, sec | 00:47 |
| lifeless | bzr diff -r X..Y will show the changes between X and Y | 00:47 |
| lifeless | bzr diff -c Y will show the change committed in Y | 00:47 |
| Stavros | ok, done | 00:47 |
| lifeless | we can use this to figure out where the change from line 12 went | 00:47 |
| Stavros | 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:48 |
| Stavros | so it just reverted to the old ones | 00:49 |
| lifeless | thats what you are seeing | 00:49 |
| Stavros | yes | 00:49 |
| lifeless | and bzr can tell us when it happened | 00:49 |
| Stavros | ah | 00:49 |
| Stavros | bzr log doesn't show much more, it just shows what i said | 00:50 |
| Stavros | old lines being added | 00:50 |
| lifeless | so use bzr diff | 00:50 |
| Stavros | err, i mean diff, sorry | 00:50 |
| lifeless | it shows the old lines being reinstated during his commit ? | 00:50 |
| Stavros | yes | 00:50 |
| lifeless | was his commit a merge ? | 00:50 |
| Stavros | let me check log | 00:50 |
| lifeless | 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 |
| Stavros | 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 |
| Stavros | yes, exactly | 00:51 |
| Stavros | but what's puzzling is that bzr should be smart enough to undo that, shouldn't it? | 00:51 |
| lifeless | no, its not meant to undo it | 00:52 |
| Stavros | if we both diverged from a single graph node, shouldn't it merge both our changes? | 00:52 |
| lifeless | if he incorporated your change | 00:52 |
| lifeless | hang on | 00:52 |
| Stavros | ok | 00:52 |
| lifeless | if he incorporated your change into his tree | 00:52 |
| lifeless | and decides its wrong | 00:52 |
| lifeless | so puts it back | 00:52 |
| Stavros | oh, i don't think he did... | 00:52 |
| Stavros | ah | 00:52 |
| lifeless | and then you merge from him | 00:52 |
| Stavros | maybe he mixed something up in the working copy... | 00:52 |
| Stavros | i see what you're saying | 00:52 |
| lifeless | bzr is *meant* to put it back in your tree | 00:52 |
| Stavros | yes | 00:53 |
| lifeless | this isn't a *failure to merge* | 00:53 |
| lifeless | this is *merging a reversion* | 00:53 |
| Stavros | yes, but this assumes that he consciously reverted it | 00:53 |
| lifeless | and you can tell its that because in his commit you can see the reversion | 00:53 |
| Stavros | aha | 00:53 |
| lifeless | this could be a mistake - new toolchain etc | 00:53 |
| lifeless | or it could be deliberate | 00:53 |
| lifeless | bzr can't tell you that sorry :P | 00:54 |
| Stavros | it's probably a mistake, because it's two lines | 00:54 |
| Stavros | hmm | 00:54 |
| Stavros | it's odd though, it's not an easy mistake to make, is it | 00:54 |
| lifeless | merge; revert FILENAME; commit | 00:54 |
| lifeless | that will do it | 00:54 |
| Stavros | yes, that's a conscious revert | 00:54 |
| lifeless | merge; revert; commit | 00:54 |
| lifeless | that won't do it | 00:54 |
| lifeless | because 'revert PATH' preserves pending merges. | 00:55 |
| Stavros | ah | 00:55 |
| lifeless | whereas 'revert' clears the pending merge list | 00:55 |
| lifeless | (bzr help revert) | 00:55 |
| Stavros | hmm yes | 00:55 |
| Stavros | or perhaps he forced a commit after pulling and bzr warning him the branches had diverged | 00:55 |
| lifeless | 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 |
| Stavros | but hmm, wouldn't it incorporate the merge in the working copy when pulling? | 00:55 |
| Stavros | aha | 00:56 |
| Stavros | well, i'll just do this by hand then, it's not a big deal | 00:57 |
| Stavros | thanks a lot for your help! | 00:57 |
| lifeless | so; you shouldn't need to do anything by hand :P. | 00:58 |
| lifeless | in particular to get your changes back now: | 00:58 |
| lifeless | bzr merge . -r X..Y | 00:58 |
| Stavros | wait, what does that do? | 00:58 |
| lifeless | where X is the commit before Y and Y is the commit where you put those two lines in | 00:58 |
| Stavros | oh wow | 00:58 |
| Stavros | let me do that | 00:58 |
| lifeless | will merge from your own history the change he discarded | 00:58 |
| Stavros | if that works, it will be very very cool | 00:58 |
| Stavros | actually wth, those commits where a while ago | 01:00 |
| Stavros | how did he manage that? damn | 01:00 |
| Stavros | apparently those changes were done in two different revisions | 01:01 |
| Stavros | hey, what do you know, that DID work! | 01:02 |
| Stavros | that's great! | 01:02 |
| lifeless | Stavros: :) | 01:08 |
| spiv | poolie: I attached that branch to that bug | 01:12 |
| lifeless | another one sent :) | 01:36 |
| poolie | hello | 01:37 |
| lifeless | spiv: call ? | 01:39 |
| lifeless | spiv: I want to talk about the repository get stream smart method | 01:39 |
| jml | hello every body! | 02:08 |
| jml | 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:08 |
| jml | we hit https://bugs.edge.launchpad.net/bzr/+bug/190209 -- xmlrpc doesn't respect $http_proxy | 02:09 |
| ubotu | 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 |
| jml | but, I was thinking, I bet he doesn't have any environment variable with proxy settings | 02:09 |
| jml | on account of being on Windows | 02:10 |
| jml | which led me to wonder, what *should* we do for proxy settings on Windows? | 02:11 |
| poolie | i think there should be a per-location configuration variable | 02:22 |
| markh | fyi, its possible to fetch the IE proxy settings. UUIC, firefox stores its own - I assume in the profile directory | 02:22 |
| lifeless | markh: hi | 02:26 |
| poolie | hello markh | 02:27 |
| lifeless | 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 |
| poolie | are you (still) in china? | 02:27 |
| poolie | lifeless: re the knit index, i'd be inclined not to expose it | 02:28 |
| jml | markh: I think I'd like Bazaar to do that. | 02:28 |
| markh | poolie: Hi - I'm leaving on Saturday | 02:28 |
| jml | but the first iteration should be variables in the config file. | 02:29 |
| abentley | What should I do about xml8? Ian sorta reviewed it, but said he wasn't sure he should cast a binding vote. | 02:29 |
| lifeless | 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 |
| markh | lifeless: you mean explicitly make decisions? | 02:29 |
| abentley | (due to his inexperience with that code) | 02:29 |
| lifeless | abentley: I have one more major thing I feel very urgent to do - killing knit joins | 02:29 |
| lifeless | abentley: then I'll do a review of the code in detail for you | 02:30 |
| lifeless | markh: yes! | 02:30 |
| lifeless | markh: open questions are things for the list; decisions are things for the tree. | 02:30 |
| abentley | lifeless: okay, thanks. | 02:30 |
| lifeless | markh: if the decision can't be taken yet, thats fine- it can still go in the tree. | 02:30 |
| lifeless | markh: but if it *can be taken*, we should take it. We *can* change our mind later. | 02:30 |
| markh | 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:31 |
| lifeless | markh: I appreciate your tact; however I encourage you to lead where you know the territory | 02:32 |
| markh | its was more a "new kid on the block" thing :) I'll do that in the future as I get known better | 02:32 |
| markh | thanks though! | 02:32 |
| poolie | lifeless++ | 02:32 |
| === BasicMac is now known as BasicOSX | ||
| markh | 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 |
| poolie | nice | 02:35 |
| markh | simply by calling 2 functions exposed by winhttp.dll, but that's ok | 02:35 |
| markh | so I guess doing it now with ctypes would be fairly easy | 02:35 |
| abentley | Odd_Bloke: Are you planning to update your patch for check? | 03:02 |
| lifeless | lunch | 03:03 |
| Verterok | moin | 03:32 |
| poolie | hello | 03:35 |
| Verterok | hi poolie | 03:35 |
| Verterok | a quick question, bzr still supports non-dirstate branches? | 03:47 |
| poolie | ppa documentation patch sent to pqm | 03:47 |
| poolie | Verterok: do you mean older formats? | 03:47 |
| poolie | yes, older formats are still supported | 03:47 |
| poolie | back to about 0.1 | 03:47 |
| Verterok | I suppose so | 03:47 |
| Verterok | poolie: thanks, I asked because to improve bzr-eclipse decorations I wrote a dirstate reader in Java :) | 03:49 |
| poolie | oh i see | 03:49 |
| lifeless | some emacs dude did this too | 03:49 |
| poolie | well, that should cover almost all users | 03:49 |
| lifeless | I think we should change dirstate every release now | 03:49 |
| * poolie starts releasing 1.3.1 | 03:49 | |
| Verterok | lifeless: I get the idea from there | 03:50 |
| Verterok | oh, great! | 03:50 |
| lifeless | because it is totally unsupported to do that | 03:50 |
| poolie | well, now | 03:50 |
| poolie | i think people can rely on us not changing the format without changing the format string | 03:51 |
| lifeless | they can | 03:51 |
| Verterok | lifeless: it's just a temp workaround, until the xml-thing get's finished | 03:51 |
| lifeless | but we should be able to rely on people not reading our gizzards | 03:51 |
| Verterok | 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:53 |
| lifeless | Verterok: why have the reader at all if inventory is sufficient? | 03:54 |
| Verterok | in a small tree the it is ~15x times faster | 03:54 |
| lifeless | Verterok: I think that the time would have been better spent fixing bzrlib.builtins.cmd_inventory to be 15 times faster | 03:55 |
| Verterok | I'm sure that most of the time is used in the startup of 'bzr inventory' | 03:56 |
| Verterok | lifeless: sure, I could try to improve inventory | 03:57 |
| Verterok | but I really don't know how to/where start :-P | 03:59 |
| lifeless | bzr --lsprof-file=foo.cachegrind inventory | 03:59 |
| Verterok | lifeless: thanks | 04:00 |
| lifeless | poolie: abentley: spiv: I have sent an RFC about fetch/join etc to the list | 04:06 |
| lifeless | would be obligated if you could eyeball | 04:06 |
| poolie | my Make is a bit rusty... | 04:07 |
| poolie | thanks for your detailed comments on my page designs :-P | 04:15 |
| poolie | :) | 04:16 |
| jamesh | spiv: I sent an updated post_change_branch_tip hook patch that merges Ian's work with mine | 04:28 |
| abentley | 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:31 |
| jamesh | abentley: because that's what Ian's branch had? | 04:32 |
| lifeless | 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 |
| abentley | jamesh: Well, he's not around, and you're the one submitting the code... | 04:32 |
| jamesh | abentley: I've got no problem making the change you suggested | 04:32 |
| jamesh | abentley: and Ian's branch never actually called the hooks so I doubt he was depending on it :) | 04:33 |
| abentley | I'll just see what else is out there. | 04:33 |
| poolie | lifeless: ok, i'm glad you agree | 04:34 |
| poolie | or indeed more than agree | 04:34 |
| lifeless | abentley: thanks | 04:35 |
| lifeless | abentley: replied | 04:35 |
| abentley | jamesh: Yes, if you could make that change, I'd appreciate it. | 04:36 |
| poolie | oh interesting, 'make check' seems to fail at the moment because of something broken in hardy's libraries | 04:37 |
| poolie | hm | 04:37 |
| abentley | lifeless: So the data stream would be tagged to indicate whether the texts were annotated/unannotated? | 04:37 |
| poolie | could people please run | 04:39 |
| poolie | python -Werror -c 'import xml.etree.cElementTree' | 04:39 |
| poolie | and tell me if it works? | 04:40 |
| poolie | lifeless: ^^ | 04:42 |
| Verterok | poolie: works fine in OS X 10.4 (ppc), python-2.5 | 04:42 |
| poolie | thanks | 04:42 |
| lifeless | abentley: yes, the data stream is self delimiting in that respect (see knit.get_data_stream) | 04:42 |
| lifeless | poolie: can you ls ls /usr/lib/python2.5/site-packages/_xmlplus/ | 04:43 |
| lifeless | there is a bug in lp about this, which I have already commented on being not bzr's fault | 04:43 |
| Verterok | poolie: but it crash on python-2.4 (Linux) | 04:43 |
| poolie | oh great | 04:43 |
| poolie | thanks | 04:43 |
| lifeless | poolie: ls -R on that dir | 04:43 |
| lifeless | I think you'll find that the tree is empty | 04:43 |
| poolie | yes for me too it has subdirectories but no files | 04:44 |
| abentley | lifeless: Yeah, I know how it works now, just weren't sure whether you were changing it. | 04:44 |
| lifeless | so this is a borked package upgrade leaving an optional thing around which is going to barf | 04:44 |
| poolie | and oddly enough dpkg -S doesn't know anything about it | 04:44 |
| lifeless | abentley: I'll be tweaking | 04:44 |
| lifeless | poolie: yes, because its gone as far as ts concerned | 04:44 |
| lifeless | abentley: but I'll keep that property | 04:44 |
| poolie | thanks | 04:44 |
| jamesh | abentley: sent an updated bundle | 04:45 |
| abentley | jamesh: Thanks. | 04:45 |
| lifeless | spiv: so, I think its time to do Weave.get_data_stream/insert_data_stream | 04:45 |
| lifeless | spiv: I'm thinking the simplest approach is just to extract all the texts as full-texts | 04:45 |
| lifeless | and during insertion generate full-texts and insert | 04:45 |
| poolie | yes it's bug 212917, i'll redirect it | 04:46 |
| ubotu | Launchpad bug 212917 in python2.5 ""make check" got an internal error" [Undecided,New] https://launchpad.net/bugs/212917 | 04:46 |
| spiv | lifeless: from the relatively little I know about weaves, that sounds reasonable to me. | 05:04 |
| abentley | 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:06 |
| * Verterok goes to the bed, while macports builds kdelibs3+kcachegrind | 05:12 | |
| Verterok | g'night all | 05:12 |
| lifeless | abentley: weave -> knit | 05:17 |
| lifeless | abentley: while we want to support that we either need join, or we need data stream support for weaves. | 05:18 |
| lifeless | the latter seems cleaner | 05:18 |
| abentley | 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:18 |
| mae^ | could someone help me. i'm getting a memory error for pretty much all commands: http://pastie.caboo.se/177690 | 05:19 |
| lifeless | abentley: I've sent mail just now as it happens | 05:19 |
| mae^ | however, I was able to make a branch and it seems to work ok | 05:20 |
| beuno | 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 |
| lifeless | mae^: that version of bzr corrupted dirstate files from time to time | 05:20 |
| lifeless | mae^: the C extensions handle that corruption with the symptoms you are reporting | 05:21 |
| mae^ | ah, good to know. i shall upgrade. many thanks | 05:21 |
| lifeless | mae^: you'll need to: a) upgrade to a bzr version like 1.0, or 1.3.1 (something newer :)) | 05:21 |
| 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:21 |
| mae^ | gee, didn't know its been that long | 05:21 |
| lifeless | 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 |
| beuno | mae^, bzr does a new release every month or so, so it might of not been that long :) | 05:22 |
| lifeless | 5 months | 05:22 |
| mae^ | so is this something bzr can fix or check beyond upgrading the binaries? | 05:22 |
| lifeless | upgrading the binaries will avoid creating the problem again | 05:23 |
| mae^ | and the current repo? | 05:23 |
| lifeless | you probable did a 'bzr mv' that hit the bug in 0.91 | 05:23 |
| lifeless | 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 |
| jdong | the bzr 1.3 stack is built in gutsy-backports now, just in case the PPA isn't up to sync yet | 05:23 |
| jdong | of course by that I mean 1.3.1 | 05:23 |
| mae^ | ok, well I'll upgrade and see where that gets me | 05:24 |
| === Verterok is now known as Verterok_ | ||
| poolie | (out for a bit, back soon) | 05:37 |
| mae^ | upgrade + branch'd .bzr dir did it | 05:43 |
| mae^ | lifeless: thx | 05:44 |
| === mwhudson_ is now known as mwhudson | ||
| * poolie merging "make dist" patch | 07:10 | |
| lech | on the CLI, is "baz" the same thing as "bzr" or did I grab the wrong thing? | 07:22 |
| AfC | lech: Nothing to do with each other. | 07:22 |
| poolie | you need bzr instead | 07:22 |
| lech | aka bazaar-ng? | 07:23 |
| AfC | lech: yes | 07:23 |
| lech | alright, thanks | 07:24 |
| AfC | poolie: Maybe it's time to get rid of http://bazaar-vcs.org/Baz1x | 07:24 |
| AfC | "you are welcome to use" is not really the right message anymore :) | 07:24 |
| AfC | and having anything besides a loud "baz is not bzr" on that page probably isn't helping. | 07:24 |
| poolie | lech: what platform are you on, and how did you get that installed? | 07:25 |
| poolie | afc, good point | 07:25 |
| lech | poolie, debian on a headless box | 07:25 |
| lech | apt-cache displayed bazaar in my search results so I figured that was it | 07:25 |
| poolie | with 'install bazaar'? | 07:25 |
| AfC | (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 |
| poolie | right | 07:25 |
| lech | poolie, yes | 07:25 |
| lech | I suspect though bzr requires bazaar to be installed though, no? | 07:26 |
| poolie | lech, afc, there's a bug open about it; dysfunctional debian process (imao) is making it slow to fix | 07:26 |
| poolie | no | 07:26 |
| AfC | poolie: yeah | 07:26 |
| AfC | it's hard to get rid of obsolete software. | 07:26 |
| lech | poolie, you mean it showing up in the update tree? | 07:26 |
| poolie | i mean at minimum it should not be called 'bazaar' anymore | 07:27 |
| AfC | hah... you guys should do a 1.4.3 revision of baz... containing bzr :) | 07:27 |
| AfC | [Ok, I'll shut up now] | 07:28 |
| poolie | there is still some value in having it | 07:28 |
| AfC | Yeah. You really don't need http://bazaar-vcs.org/Baz1x/Downloads at all. It's diluting your brand. | 07:28 |
| poolie | for people who have very specific needs, such as using it to convert to bzr | 07:28 |
| lech | instead of removing it, why not simply update it and use it as an alias? :) | 07:28 |
| poolie | that's the plan | 07:29 |
| AfC | lech: it is completely different software | 07:29 |
| AfC | lech: the only thing that it has in common is that both are revision control tools. | 07:29 |
| lech | AfC, according to the URL it displays in the package tree, it's the same thing | 07:29 |
| lech | at least, it points to bazaar (bzr) pages | 07:29 |
| lech | in aptitude at least | 07:30 |
| AfC | Like I said, massive branding problem | 07:30 |
| lech | ahh, alright | 07:30 |
| lech | well, thanks for helping clean things up in that respect for me | 07:30 |
| james_w | poolie: it's not Debian being dysfunctional really, it's baz failing to build. | 07:31 |
| lech | fetching a project moves it to the current directory I happen to be in, correct? | 07:31 |
| lech | s/moves/puts | 07:32 |
| poolie | james_w: i think it's a bit bizarre that failing to build means it remains available | 07:32 |
| AfC | lech: that's right | 07:32 |
| AfC | poolie: Seriously though, I don't think you guys hosting debs of baz is helping very much | 07:33 |
| james_w | poolie: the argument is that the old version built fine, so you might as well let people use it. | 07:34 |
| james_w | poolie: the problem is that we can't rename the package, as you need to build it to do that. | 07:34 |
| poolie | i can appreciate the argument but i don't think it's a good tradeoff in this case | 07:36 |
| lech | ok, first use of bzr with my first error | 07:37 |
| AfC | lech: back up: do you have a recent (ie >= 1.3) version of Bazaar installed? | 07:38 |
| lech | Bazaar (bzr) 0.11.0 | 07:39 |
| AfC | Jesus | 07:39 |
| lech | I am guessing that might be a no? | 07:39 |
| poolie | it's about 18 months old | 07:39 |
| poolie | for us that's a long time :) | 07:39 |
| lech | wow, yeah... what the hell | 07:39 |
| lech | I even did a full package update before this | 07:40 |
| AfC | lech: these guys are moving _very_ fast, at roughly one release per month. That makes it at least 15 versions old | 07:40 |
| poolie | if you're on the last stable debian release that may be the problem | 07:40 |
| lech | I'm on sarge for this box | 07:41 |
| AfC | lech: let me guess. You're using Debian. You'll need to point your sources at the packages published by the Bazaar hackers (several are [or once were] Debian packagers) | 07:41 |
| poolie | james_w probably knows the best source for it... | 07:41 |
| lech | I have backports, but apparently it appears it snagged from one of the stable mirrors | 07:41 |
| james_w | do we still build .debs for Debian? | 07:42 |
| poolie | I do not | 07:42 |
| poolie | I would kind of like to though | 07:42 |
| lech | deb-ppc please | 07:42 |
| lech | :D | 07:42 |
| AfC | There's a 1.3 on the backports page you guys link to http://backports.org/debian/pool/main/b/bzr/ | 07:42 |
| poolie | i probably should build them separately and put them onto bazaar-vcs | 07:42 |
| poolie | oh | 07:42 |
| poolie | ppc may be hard | 07:42 |
| james_w | lech: the backport was only for etch I'm afraid. | 07:42 |
| poolie | that looks good | 07:42 |
| poolie | s390 even :) | 07:43 |
| lech | damn | 07:43 |
| AfC | lech: Bazaar builds very quickly and easily from source, so if you get stuck you can always just build it manually. | 07:43 |
| poolie | but not ppc afaics | 07:43 |
| poolie | i meant ppc may be hard for me to build myself only because i use an i386 machine | 07:43 |
| poolie | but as afc says, just installing from source may be easier | 07:43 |
| lech | I think at this rate I might just be better off downloading individual files off the branch I'm staring at in my browser | 07:43 |
| poolie | i wonder why there is no ppc theer? | 07:43 |
| poolie | lech, get a source tarball from /Download and try that? | 07:44 |
| lech | I'm afraid I don't know how to build from source unless you think you can talk me through it | 07:44 |
| poolie | sure | 07:44 |
| lech | point me to the tarball | 07:44 |
| AfC | Eeek! http://bazaar-vcs.org/InstallationFaq talks about bzr-0.8 | 07:44 |
| poolie | https://launchpad.net/bzr/1.3/1.3/+download/bzr-1.3.tar.gz | 07:44 |
| lech | let me back root out to a working temp directory | 07:45 |
| AfC | [I mean, no it doesn't have to be absolutely current, but relatively recent would probably be a good idea :)] | 07:45 |
| poolie | the example that mentions it is not really a good idea anyhow | 07:46 |
| poolie | just symlinking the script will still work but has several shortcomings | 07:46 |
| poolie | lech: how did you go | 07:49 |
| poolie | AfC: thanks for finding it | 07:49 |
| lech | sec | 07:50 |
| poolie | abentley: bb having trouble again, "temporarily unable to service" | 07:51 |
| * AfC heads out | 07:52 | |
| lech | poolie, ok untarred and ready to go | 07:56 |
| lech | worst thing that can happen is this won't work :) | 07:57 |
| poolie | lech: i have a meeting in a minute, suggest you follow the README and InstallationFaq and let me know if you have trouble | 07:57 |
| poolie | indeed | 07:57 |
| poolie | should be just | 07:57 |
| poolie | sudo python setup.py install | 07:57 |
| poolie | andyou're done | 07:57 |
| poolie | i'll still be here so do ask if you get stuck | 07:59 |
| poolie | or others may help | 07:59 |
| lech | launching python setup.py install then | 07:59 |
| lech | Bazaar (bzr) 1.3 | 08:01 |
| poolie | yay | 08:01 |
| lech | although, I did see a ton of warnings fly by in screen | 08:01 |
| lech | lets see if it properly snags what I need | 08:02 |
| lech | we has transfer | 08:03 |
| poolie | great | 08:07 |
| poolie | what are you pulling btw? | 08:07 |
| lech | http://www.intertwingly.net/code/venus/ | 08:07 |
| lech | niice, the server just died on me | 08:08 |
| lech | ok, so it seems to have died a fraction of the way through the process. how do I "finish" that job? just do "bzr pull" ? | 08:11 |
| lech | ok, can't even do that | 08:12 |
| * lech hoses the directory and tries again | 08:12 | |
| AfC | lech: fwiw that server didn't answer me when I tried it | 08:21 |
| lech | AfC, I just now noticed that there are tgz/zip links for the package which I missed earlier | 08:21 |
| AfC | Well, now you have Bazaar, and can start using it for any work you're doing. It's really rather smart. | 08:22 |
| lech | indeed | 08:23 |
| lech | thanks for the help guys, I'll pop in when I need it again :) | 08:23 |
| * lech tips his hat | 08:23 | |
| doko | poolie: does /usr/lib/python2.5/site-packages/_xmlplus still exists on your system? are there files in this dir? | 09:41 |
| === mrevell__ is now known as mrevell | ||
| poolie | doko: it exists but it is empty | 10:04 |
| poolie | correction. it contains two empty dirs | 10:04 |
| doko | hmm, strange. I assume your system was upgraded from gutsy? | 10:06 |
| poolie | yes | 10:06 |
| poolie | maybe from feisty | 10:06 |
| poolie | via gutsy | 10:06 |
| doko | ok, will try to reproduce this | 10:06 |
| === mrevell_ is now known as mrevell | ||
| Winterstream | I've been looking for a command that will allow me to view a previous revision of a file, but I haven't found anything yet. | 11:12 |
| Winterstream | How can I do this? | 11:12 |
| luks | bzr cat -r | 11:13 |
| Winterstream | ah, thanks luks | 11:13 |
| yacc | How do I tell bzr log to show only revisions commited after say 2008-03-20? | 11:33 |
| bob2 | bzr help revisionspec -> date | 11:36 |
| ignas | is bzr calculating test coverage on their codebase? | 11:46 |
| AfC | define "calculating" and "coverage" | 11:48 |
| bob2 | someone should strap z3c.coverage into bzr selftest | 11:48 |
| ignas | AfC: something like: http://schooltool.pov.lt/coverage/ | 11:49 |
| ignas | every once in a while | 11:49 |
| ignas | just to see if you are testing your code ;) or just think that you are... | 11:49 |
| LarstiQ | ignas: there is a --coverage option | 11:50 |
| ignas | are there restults published anywhere? | 11:50 |
| LarstiQ | no idea | 11:50 |
| * dato waves to LarstiQ | 11:51 | |
| LarstiQ | ignas: I'm not familiar with the output it generates either. | 11:51 |
| LarstiQ | hey dato :) | 11:51 |
| ignas | emm, how do i run bzr tests? | 11:57 |
| bob2 | bzr selftest | 11:58 |
| speakman | What's the current and fastest repo format? | 11:58 |
| speakman | (but still safe...) | 11:58 |
| ignas | bob2: and i pass --coverage to that? | 11:58 |
| bob2 | pack-0.92 is the current default (if anything is faster it'd be the s3kr1t dev formats) | 11:59 |
| speakman | ok, nothing's stable yet? | 11:59 |
| bob2 | ignas: dunno where LarstiQ meant you to use --coverage, afaict selftest doesn't take that option and in fact crashes if you try to use it :) | 12:00 |
| ignas | it seems that there is no such option ... | 12:00 |
| bob2 | the dev ones are not, hence their name ;p | 12:00 |
| LarstiQ | bob2: bzr --coverage coverage_dir status | 12:01 |
| bob2 | oh, a global option, awesome | 12:01 |
| LarstiQ | bob2: I only figured that out ten minutes ago after looking at NEWS and then `bzr help global-options` ;) | 12:01 |
| ignas | oh | 12:02 |
| ignas | I ran McCabe complexity analysis on the code and was very interested in how much one function is tested ;) | 12:03 |
| ignas | according to the internets 50 is "beyond testability and pretty much unmaintainable" and bzr has a 98 ;) | 12:07 |
| james_w | ignas: which function? | 12:17 |
| ignas | bzr/bzrlib/workingtree_4.py - InterDirStateTree.iter_changes | 12:19 |
| ignas | it has 5 tests i think ;) | 12:19 |
| ignas | james_w: how do you like it? ;) | 12:32 |
| james_w | ignas: yeah, that's nice | 12:35 |
| ignas | james_w: http://ignas.pov.lt/bzr_coverage/reports/bzrlib.workingtree_4.html | 12:43 |
| ignas | it's covered quite well though | 12:44 |
| ignas | so someone could refactor it into something maintainable ;) | 12:44 |
| skam123 | hi there | 12:53 |
| skam123 | i try to us the bzr->bugzilla integration but the offical documentation is not that comprehensive to me | 12:54 |
| skam123 | is someone using this integration? | 12:54 |
| james_w | skam123: I think I know how it works, what are you trying to do? | 12:55 |
| skam123 | james_w: our developers woulr appreciate if the --fixes switch would set a given bug on commit to fixed | 12:57 |
| skam123 | right now bugzilla is running stand alone, bazaar rep is somewhere on the server-fs. users are committing using ssh+bzr, there is no bzr server running | 12:58 |
| james_w | skam123: ah, the integration won't do that for you I'm afraid, it just marks the fact that it is fixed in bzr. | 12:59 |
| skam123 | ah. ok | 12:59 |
| james_w | a script could them close bugs for you if you like, but at the moment bzr has no facility for doing that. | 12:59 |
| james_w | I think it's too much to make bzr do all that, but it would be great to have some example scripts or something for people to set up. | 13:00 |
| skam123 | hm | 13:01 |
| skam123 | has anybody tried some tool like http://www.mkgnu.net/?q=scmbug | 13:01 |
| === mw|out is now known as mw | ||
| aantn | hello | 14:07 |
| aantn | There seems to be a bug in bzr | 14:08 |
| aantn | it causes problems if filenames have characters like é in them | 14:08 |
| hmeland_ | aantn: Which bzr version are you using? | 14:09 |
| aantn | 1 sec | 14:10 |
| aantn | b0le is the one with the problem | 14:10 |
| aantn | (hello) | 14:10 |
| aantn | It's on my branch | 14:10 |
| aantn | b0le: which version of bzr are you using? | 14:11 |
| b0le | 1.1.0 | 14:13 |
| b0le | upgrading to 1.3 at the moment, will try again after that... | 14:14 |
| luks | what kind of problems does it cause? | 14:15 |
| b0le | https://bugs.launchpad.net/bzr/+bug/63324 - similar to this | 14:17 |
| ubotu | Launchpad bug 63324 in bzr "exceptions.UnicodeEncodeError: 'ascii' codec can't encode character" [Medium,Confirmed] | 14:17 |
| luks | b0le: can you be more specific? ideally paste the traceback? | 14:18 |
| === cpro1 is now known as cprov | ||
| b0le | luks: unfortunately I didn't keep the output, and have just updated to 1.3, and am trying again (though it seems to take quite a while...) | 14:19 |
| spiv | b0le: or perhaps like https://bugs.edge.launchpad.net/bzr/+bug/135320 ? | 14:23 |
| ubotu | Launchpad bug 135320 in bzr "bzr merge - exceptions.UnicodeDecodeError" [Undecided,New] | 14:23 |
| b0le | "With LANG=en_AU.UTF-8 this works for me." | 14:25 |
| b0le | however, "bzr grep" fails, even with LANG... (after I have sucessfully "bzr co"-ed the repo with the above env variable) | 14:26 |
| b0le | "bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 29: ordinal not in range(128)" is pretty close to what the error was (just different byte and position) | 14:27 |
| b0le | luks: spiv: aantn: http://pastebin.ca/978294 | 14:35 |
| luks | "encoding: 'ANSI_X3.4-1968', fsenc: 'ANSI_X3.4-1968', lang: None" | 14:36 |
| luks | I'm not sure what exactly that encoding is, but I'd bet it's something similar to ascii | 14:36 |
| luks | and so doesn't support characters like é | 14:36 |
| dato | luks: that's the formal name for C/ASCII | 14:37 |
| luks | ah | 14:37 |
| aantn | is there something I can change on my branch so that it'll use the proper encoding? | 14:39 |
| aantn | I can always change the filenames, if I must | 14:39 |
| b0le | exporting LANG fixed it last time - so is that a problem with my setup? | 14:39 |
| luks | aantn: no, it's a problem on the client side | 14:40 |
| luks | the only way you can fix it is to restrict yourself to ascii | 14:40 |
| aantn | luks: that's not terrible | 14:40 |
| aantn | I only use the é in one or two places | 14:41 |
| luks | bzr doesn't know to encode characters like é if the client system tells it to use ASCII | 14:41 |
| b0le | luks: do you know why LANG=... fixes "bzr co", but "bzr grep" still fails | 14:42 |
| spiv | Or change the client system's locale something other than ASCII (e.g. by setting LANG=en_US.UTF-8) | 14:42 |
| luks | b0le: bzr grep is a plugin, and probably not tested on non-ascii characters | 14:42 |
| spiv | b0le: yeah, that's probably a bug in the grep plugin. File a bug on the plugin. | 14:43 |
| luks | if it does have a bug tracker, it would be worth filing a bug report | 14:43 |
| b0le | luks: spiv: aantn: thanks for the help :) | 14:45 |
| spiv | (If there's no plugin, try mailing the bazaar mailing list I guess) | 14:45 |
| spiv | Er, | 14:45 |
| spiv | If there's no *bugtracker*, I mean :) | 14:46 |
| aantn | b0le: I think I'll just change the é to an e | 14:48 |
| SheikPunk | how to ignore files by extension | 15:07 |
| SheikPunk | ignore for example .log files | 15:07 |
| luks | bzr ignore '*.log' ? | 15:09 |
| SheikPunk | luks: i go try | 15:09 |
| SheikPunk | luks: and all directory? | 15:09 |
| SheikPunk | bzr ignore 'logs/*' | 15:09 |
| luks | bzr ignore b/ should be enough | 15:10 |
| luks | er | 15:10 |
| luks | bzr ignore logs/ | 15:10 |
| luks | :) | 15:10 |
| luks | dunno why I typed 'b' there | 15:10 |
| SheikPunk | luks: thanks... | 15:12 |
| ubotu | New bug: #214619 in bzr "exceptions.KeyError when branching from 1.1 server via bzr+ssh" [Undecided,New] https://launchpad.net/bugs/214619 | 15:26 |
| === beuno_ is now known as beuno | ||
| === kiko is now known as kiko-afk | ||
| fbond | Hi, I'm using the loom plugin. When I make changes to a thread and then move up-thread, the new changes to the lower thread are applied as new commits on the higher thread, but what I really want is to rebase the higher thread on top of the new commits on the lower thread. Anyone follow me? | 16:12 |
| fbond | What is the best way to do this? | 16:12 |
| james_w | fbond: you may be able to do it with the rebase plugin. | 16:14 |
| james_w | I'm interested in why you are using the loom plugin if you want to do this though. | 16:14 |
| james_w | rebasing a thread will probably stop you from moving up thread from the one you rebase. | 16:14 |
| fbond | Well, I want the loom plugin to act more like quilt, I guess. | 16:15 |
| fbond | james_w: perhaps I should not be using loom, but should instead just branch and rebase? | 16:16 |
| fbond | i.e. create feature branches... | 16:16 |
| james_w | that would be the better solution currently. | 16:16 |
| james_w | it may be possible to make a quilt mode for loom at some point. | 16:17 |
| james_w | can I ask why you don't just use quilt on top of bzr? | 16:17 |
| james_w | I'm unsure of what the tradeoffs here. | 16:18 |
| fbond | Hmm... I don't really love quilt... | 16:18 |
| fbond | I actually just used shelve for a while. | 16:18 |
| fbond | But shelve is un-fun in that it doesn't deal with adds, moves, etc... | 16:18 |
| fbond | quilt would be roughly the same in that respsect... | 16:18 |
| james_w | yeah, shelves not viable for all this. | 16:18 |
| james_w | true. | 16:18 |
| fbond | The ideal situation would be an extension of loom that rebases when I do up-thread, I think. | 16:19 |
| fbond | Maybe bzr up-thread --rebase | 16:19 |
| fbond | Or bzr rebase --replace, to replace a section of history with another section... | 16:19 |
| james_w | yeah, it's not ideal because it means that the threads above no longer share history with those below | 16:20 |
| fbond | Well, they all have to be rebased... | 16:20 |
| james_w | and lack of history means merging can't be as good. | 16:20 |
| fbond | So maybe, then, `bzr rebase-threads' to rebase all threads above the current one. | 16:21 |
| asabil | fbond: bzr-interactive may help | 16:25 |
| asabil | it containes a record-patch | 16:25 |
| asabil | that records the patch in patches/ | 16:25 |
| asabil | and can be managed using quilt | 16:26 |
| asabil | it is barebone though | 16:26 |
| === dwon is now known as dwon__ | ||
| === dwon__ is now known as dwon_ | ||
| fbond | james_w: https://bugs.launchpad.net/bzr-loom/+bug/214657 | 16:55 |
| ubotu | Launchpad bug 214657 in bzr-loom "Should support rebasing threads" [Undecided,New] | 16:56 |
| ubotu | New bug: #214657 in bzr-loom "Should support rebasing threads" [Undecided,New] https://launchpad.net/bugs/214657 | 17:05 |
| brink_ | I'd like to migrate a Sourceforge Subversion project to either bzr or git. I was hoping to get some advice. Sourceforge doesn't support anything but Subversion and SVN. I'm considering Launchpad, but I'm not that familiar with it. I'm also not entirely sure how to get everyone on board for a switch to distributed development. It seems to me the project really needs support for distributed development, but I'm not s | 17:09 |
| NfNitLoop | brink_: you got cut off at "I'm not s..." | 17:16 |
| NfNitLoop | brink_: The nice thing is that you don't necessarily have to get everyone on board. | 17:16 |
| NfNitLoop | You can use bzr-svn with an ongoing svn project. | 17:16 |
| NfNitLoop | and sync changes between the two repositories. | 17:17 |
| brink_ | The ending is ...I'm not sure how to explain it to a generally skeptical audience unfamiliar with the concept. | 17:17 |
| NfNitLoop | You can just create your own bzr branch, register it with Launchpad... | 17:17 |
| NfNitLoop | and keep them in sync. | 17:17 |
| NfNitLoop | then people can choose to use svn or bzr. | 17:17 |
| NfNitLoop | (I think Launchpad even has an option to keep a branch in sync automatically, but IIRC you have to contact them and set it up that way.) | 17:18 |
| brink_ | I actually tried using Launchpad as an experiment. The import status has been "Testing" for more than a week. But as I said, I'm not that familiar with Lauchpad, so maybe I'm doing something wrong. | 17:19 |
| james_w | brink_: can you give a pointer to where you tried? | 17:19 |
| jdong | brink_: the launchpad importer thing hasn't inspired my confidence either | 17:20 |
| jdong | brink_: I'd personally also suggest using bzr-svn to mirror Subversion projects into bzr | 17:20 |
| brink_ | Here's the link: https://code.launchpad.net/sphinx4/trunk | 17:20 |
| NfNitLoop | you may have to babysit your first import though, so that it doesn't kill your box. Stupid memory leaks. >.< | 17:20 |
| brink_ | Is bzr-svn more useful than the Launchpad mirror? | 17:21 |
| brink_ | Can bzr-svn be merged back? | 17:22 |
| james_w | brink_: yeah, you can merge back when using bzr-svn. | 17:22 |
| jelmer | 'evening awilkins | 17:49 |
| awilkins | Hello there jelmer | 17:50 |
| === kiko-afk is now known as kiko | ||
| aelkner__ | can someone help me with a problem i'm having with bzr? | 18:55 |
| aelkner__ | is anyone here? | 18:56 |
| beuno | aelkner__, sure | 18:56 |
| aelkner__ | i think i got the lastest version when i did my updates on my linux box | 18:57 |
| aelkner__ | but now bzr co is giving me the following failure | 18:57 |
| aelkner__ | bzr: ERROR: Invalid http response for http://staging.schooltool.org/bzr2/schooltool/schooltool.lyceum.journal/.bzr/repository/packs/71f1ff934019ef067e17e22956a982c2.pack: Expected a boundary (TXyz-fP5Lqw3jFjqmB=L) line, got '' | 18:57 |
| james_w | hi beuno | 18:57 |
| aelkner__ | bzr --version: | 18:57 |
| aelkner__ | Bazaar (bzr) 1.3.1rc1 | 18:58 |
| aelkner__ | Python interpreter: /usr/bin/python 2.5.1.final.0 | 18:58 |
| aelkner__ | Python standard library: /usr/lib/python2.5 | 18:58 |
| aelkner__ | bzrlib: /usr/lib/python2.5/site-packages/bzrlib | 18:58 |
| aelkner__ | Bazaar configuration: /home/aelkner/.bazaar | 18:58 |
| aelkner__ | Bazaar log file: /home/aelkner/.bzr.log | 18:58 |
| beuno | hey james_w :)\ | 18:58 |
| aelkner__ | does that help? | 18:58 |
| beuno | aelkner__, could you paste your .bzr.log into a pastebin of some sort (ie, not the channel) | 18:59 |
| aelkner__ | buone: how do i get to the pastebin for #bzr? | 18:59 |
| james_w | aelkner__: is there a proxy in the way? | 18:59 |
| beuno | aelkner__, I usually usehttp://paste.ubuntu-nl.org/ | 19:00 |
| aelkner__ | janes_w: i don't know if there's a proxy in the way | 19:00 |
| beuno | aelkner__, it would seem like a setup problem (http server, proxy, etc) instead of a bzr error | 19:00 |
| james_w | this error has been reported a few times, and every time there is a proxy in the way. | 19:01 |
| james_w | there's a bug report | 19:01 |
| aelkner__ | ignas: do you know of a proxy on the host side? | 19:01 |
| ignas | you got the error both with launchpad and on schooltool.org | 19:01 |
| ignas | so if there is a proxy - it's either on both websites, or at your place it seems | 19:02 |
| beuno | LP doesn't have a proxy, that's for sure | 19:02 |
| aelkner__ | how would i check for a proxy? | 19:02 |
| aelkner__ | is there a command that i can run from my machine? | 19:03 |
| beuno | aelkner__, I'm not sure we'll be able to help you with detecting a proxy | 19:06 |
| ignas | emm, so what should i recommend to people who are behind a proxy and want to bzr get the development branch? | 19:07 |
| james_w | you can use ssh | 19:08 |
| ignas | you mean developers can | 19:08 |
| james_w | though there may be people with port 22 firewalled, and a transparent http proxy that does this. | 19:08 |
| james_w | ignas: nope, anyone can download a branch over ssh from launchpad. | 19:09 |
| ignas | what about users that want to see the latest and greatest? | 19:09 |
| james_w | at least I assume that works for mirrored branches as well. | 19:09 |
| ignas | so lp:~ignas/some-branch is not something that will reliably work? | 19:10 |
| ignas | it is a bit insane that if they want to make a read only checkout of my code they have to have a user on launchpad | 19:18 |
| ignas | or not be using a proxy | 19:18 |
| james_w | not be using a broken proxy | 19:20 |
| james_w | the bug report in question was looked at by squid developer and he said the bug there is fixed in the latest versions. | 19:20 |
| ignas | i see | 19:23 |
| laga | hello! | 19:35 |
| laga | i've just updated my bzr tree and resolved some conflicts. however, i still get messages like "Conflict adding file mythbuntu_common/dictionaries.py.BASE. Moved existing file to mythbuntu_common/dictionaries.py.BASE.moved.". none of these files exist. what can i do to resolve this? | 19:36 |
| === mw is now known as mw|out | ||
| james_w | laga: that's pretty odd. | 19:50 |
| laga | james_w: yeah. :) i use bzr 1.3.1rc1 on ubuntu hardy | 19:51 |
| james_w | laga: I think this may happen if someone accidentally commits the files spat out in a previous conflict/ | 19:53 |
| james_w | not sure why they don't exist though. | 19:53 |
| laga | yeah, i think so too. | 19:53 |
| laga | i tried to bzr remove them, but it just said 'mythbuntu_common/dictionaries.py.BASE does not exist.' | 19:54 |
| james_w | does "bzr resolve 'mythbuntu_common/dictionaries.py.BASE'" work? | 19:54 |
| laga | james_w: yeah, it does. thanks! :) | 19:55 |
| laga | i should remember that, it's pretty obvious once you see it | 19:56 |
| muszek_ | hi... a newbie question: I (user muszek) have created a repo. another user on the same machine (tomekg) made a checkout and bind'ed his repo to mine. Now when he tries to commit, he gets a "permission denied" error. I figure it's about "regular unix file permissions"... how should I handle this? | 19:56 |
| james_w | laga: once you have resolved all the conflicts and committed we should make sure that you haven't got anything in your branch that will cause problems later, so please ping me. | 19:56 |
| james_w | muszek_: yes, it sounds like file permissions would be the issue. | 19:57 |
| laga | james_w: ok. | 19:57 |
| laga | james_w: ping. | 19:57 |
| james_w | the common way to solve this would be to make your file owned by the a group that you are both a member of, and then make all directories g+s. | 19:57 |
| james_w | laga: :-) | 19:57 |
| laga | ;) | 19:58 |
| james_w | so, can you pastebin me the output of "bzr inventory" and "bzr log -r -1 -v" please? | 19:58 |
| muszek_ | james_w: but how should it be done properly? first thing that comes to my mind is to chmod everything so that owner&group can write and add tomekg to my group... but that doesn't seem to elegant... | 19:58 |
| muszek_ | s/to/too | 19:58 |
| james_w | muszek_: yes, that's the correct way, except you should use a different group and add you both too it | 19:59 |
| laga | james_w: here we go: http://www.pastebin.ca/978671 | 19:59 |
| james_w | and as well as making files and directories writeable, make all directories g+s, i.e. set the group sticky bit. | 19:59 |
| james_w | laga: ok, that all looks ok to me, I don't know where those problems came from. | 20:00 |
| muszek_ | james_w: do you know about any article on the topic? (I'm affraid I'll be doing something wrong, especially when messing with .bzr directory) | 20:00 |
| james_w | muszek_: nope sorry | 20:01 |
| laga | james_w: PEBKAC, most likely. thanks for your time. | 20:01 |
| james_w | laga: I don't think it was. No problem anyway | 20:02 |
| james_w | muszek_: groupadd "newgroup" | 20:02 |
| james_w | adduser muszek newgroup | 20:02 |
| james_w | adduser newgroup | 20:03 |
| james_w | oops, | 20:03 |
| james_w | adduser tomekgnewgroup | 20:03 |
| james_w | adduser tomekg newgroup | 20:03 |
| james_w | that's better | 20:03 |
| james_w | chown muszek:newgroup -R branch | 20:03 |
| james_w | chmod g+w -R branch | 20:04 |
| james_w | find branch -type d -exec chmod g+s '{}' \; | 20:04 |
| james_w | I think that's right | 20:04 |
| muszek_ | james_w: thanks (I'll handle it, I have some "find..." one liner from the times we were doing it over ftp | 20:05 |
| === mw|out_ is now known as mw | ||
| abentley | spiv: Why doesn't RemoteBzrDir implement set_make_working_trees? | 20:50 |
| nixternal | OK, somehow my docs repo got mucked and now I have this error: | 20:53 |
| nixternal | bzr: ERROR: No repository present: "file:///home/nixternal/work/ubuntu/docs/repos/kubuntu-hardy/" | 20:53 |
| nixternal | right after i did a bzr revert this happened | 20:53 |
| abentley | nixternal: What does it say when you run "bzr info"? | 21:00 |
| nixternal | same error | 21:00 |
| abentley | Is kubuntu-hardy a repository, or a branch within a repository? | 21:01 |
| nixternal | a repo | 21:01 |
| abentley | What do you get from ls /home/nixternal/work/ubuntu/docs/repos/.bzr ? | 21:02 |
| nixternal | backup.bzr branch branch-format branch-lock checkout README repository.backup | 21:02 |
| abentley | Did you recently try to upgrade your repository? | 21:03 |
| * nixternal looks | 21:03 | |
| nixternal | bah, looks like I did a bzr upgrade and not a bzr up | 21:03 |
| abentley | Okay, so either repository.backup or backup.bzr should provide a working repository. | 21:04 |
| abentley | Let's start by renaming repository.backup to repository. | 21:05 |
| nixternal | done | 21:06 |
| nixternal | booyah! that worked | 21:06 |
| abentley | Try bzr info /home/nixternal/work/ubuntu/docs/repos | 21:06 |
| nixternal | lookin' good :) | 21:06 |
| abentley | Good. What format is it currently in? | 21:07 |
| nixternal | dirstate-with-subtree | 21:07 |
| abentley | That is an experimental format. Converting it into a supported format is somewhat roundabout. | 21:09 |
| nixternal | I am a bzr dummy...I can get away with utilizing svn syntax to get by | 21:10 |
| abentley | Is the trunk branch in a public location? | 21:11 |
| nixternal | https://code.launchpad.net/ubuntu-doc/+branches | 21:12 |
| nixternal | I just have a tad bit more work in this repo and then it is done with due to us moving to intrepid branches | 21:13 |
| abentley | Well, ubuntu-intrepid is in the right format. So when you switch to it, I'd recommend using a new shared repository. | 21:16 |
| nixternal | roger that, thanks for the tip | 21:17 |
| abentley | np. | 21:17 |
| Vantage | hi, I'm doing some performance testing on bzr against a converted CVS repo and for some reason the performance of bzr 1.3 seems to be much worse than the last time I tested (pre-1.0) | 21:28 |
| Vantage | in a lightweight checkout a diff between to revisions is taking almost 20 seconds (on a local machine) | 21:28 |
| Vantage | heavyweight checkout takes about 4 seconds for the same diff | 21:28 |
| Vantage | and cvs across a network is under 1 second... | 21:28 |
| beuno | Vantage, many of the peformance issues are being currently worked on, but if you could send in more information to the mailing list, it might help as a use case to test against | 21:30 |
| Vantage | beuno: ok, is there anything specific in this regard that's alreay known? Like I said, I had been playing with previous versions of bzr (0.18 and one of the 0.9s) and don't recall it being this slow before | 21:32 |
| beuno | Vantage, most of them are knonw, yes. We moved to a different storage format that enables to scale much better, but it regressed in some areas | 21:33 |
| lifeless | Vantage: what bzr versioned are you using today? | 21:33 |
| beuno | so a lot of work is being done to improve even what we had before :) | 21:33 |
| Vantage | lifeless: 1.3 | 21:33 |
| lifeless | abentley: bb is down | 21:33 |
| lifeless | Vantage: 1.4 is significantly faster at log | 21:34 |
| Vantage | bzr log also takes about 4 seconds or so for lightweight or heavyweight | 21:34 |
| Vantage | lifeless: is 1.4 out? | 21:34 |
| Vantage | lifeless: what about diffs? | 21:34 |
| abentley | lifeless: Starting up... | 21:34 |
| lifeless | Vantage: for diff; I'm working on the issues with diff, but understand that comparing 'single file diff' with 'tree wide diff' will always be biased to the single file implementation of a vcs | 21:34 |
| Vantage | lifeless: even if you request it for a single file? e.g. bzr diff -r2..1 index.html ? | 21:35 |
| abentley | lifeless: working now. | 21:35 |
| nixternal | just noticed 'bzr revert' doesn't work...could that upgrade have mucked that up as well abentley? | 21:36 |
| Vantage | lifeless: of course, even given that, at 20 seconds it's not really usable ;) | 21:36 |
| nixternal | abentley: I meant 'bzr add' | 21:37 |
| abentley | nixternal: I suppose it's possible. What version of bzr are you running? | 21:37 |
| nixternal | 1.3.1-rc1 | 21:38 |
| nixternal | bzr: ERROR: exceptions.AssertionError: | 21:38 |
| lifeless | abentley: looks like many of the email votes from last night haven't been noticed ? | 21:39 |
| abentley | lifeless: I ran them through manually this morning. They should have been. | 21:39 |
| lifeless | abentley: http://bundlebuggy.aaronbentley.com/request/<1207701408.9506.118.camel@lifeless-64> | 21:39 |
| lifeless | abentley: I'm hoping I can land all my patches as one merge | 21:39 |
| lifeless | abentley: :P | 21:39 |
| abentley | God, I hate the way firefox mangles urls. | 21:40 |
| lifeless | Vantage: say you have a tree with a root directory of 20,000 files. | 21:40 |
| abentley | nixternal: Please provide the whole error message via pastebin. | 21:40 |
| abentley | ubotu: paste | 21:40 |
| ubotu | New bug: #214777 in bzr-gtk "gcommit: unsupported operand type(s) for /: 'float' and 'NoneType'" [Undecided,New] https://launchpad.net/bugs/214777 | 21:40 |
| ubotu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the channel topic) | 21:40 |
| nixternal | abentley: http://paste.ubuntu-nl.org/62682/ | 21:41 |
| lifeless | Vantage: a vcs that stores separate revision numbers, and one file on disk for each of the 20K files can diff a single file with less work than a vcs that has to indirect through the list of all revisions for the two revisions to figure out internal keys for the 20K files | 21:41 |
| abentley | lifeless: Can you look at nixternal's bug? | 21:42 |
| lifeless | Vantage: that said, 20 seconds sounds like a bug to me. | 21:42 |
| Vantage | lifeless: any way to get more information on what's taking so long in the process? debug flag or something like that? | 21:42 |
| lifeless | Vantage: are you using bzr+ssh? if so -Dhpss. you can use -Dtransport | 21:43 |
| lifeless | too | 21:43 |
| lifeless | and you can get lsprof information as well with --lsprof-file=foo.cachegrind | 21:43 |
| lifeless | abentley: sure, I can peek | 21:43 |
| lifeless | nixternal: hi | 21:43 |
| Vantage | lifeless: this is just on the local file system | 21:43 |
| nixternal | howdy lifeless | 21:44 |
| lifeless | Vantage: 20 seconds on local file system? you said lightweight checkout... | 21:44 |
| lifeless | Vantage: lightweight checkout of what branch | 21:44 |
| lifeless | nixternal: you're just running 'bzr add' ? | 21:44 |
| Vantage | lifeless: yeah, and the shared repo is on the same filesystem | 21:44 |
| Vantage | lifeless: HEAD | 21:44 |
| nixternal | lifeless: 'bzr add' or 'bzr add foo/bar/foobar.xml' | 21:44 |
| lifeless | Vantage: what format is the shared repo ? | 21:44 |
| lifeless | nixternal: so it looks like the file is already added | 21:45 |
| nixternal | but it isn't | 21:45 |
| lifeless | nixternal: but we're not detecting this correctly; can we try starting fresh - make a new branch from the current one's last commit | 21:45 |
| Vantage | lifeless: it's a converted cvs repo using cvsps-import | 21:45 |
| ubotu | New bug: #214784 in bzr-gtk "Gcommit fails with unknown error: float division" [Undecided,New] https://launchpad.net/bugs/214784 | 21:45 |
| lifeless | Vantage: that doesn't tell me what format :P. 'bzr info' will | 21:46 |
| Vantage | lifeless: basically I converted the cvs repo, then checked out a heavyweight copy of head and a lightweight copy of head to another directory | 21:46 |
| Vantage | lifeless: i'll get that | 21:46 |
| Vantage | lifeless: Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack) | 21:46 |
| nixternal | lifeless: if I branch that, I will be waiting about 3 hours for it to finish | 21:48 |
| abentley | lifeless: Got your vote in. | 21:48 |
| lifeless | nixternal: why would it take three hours ? | 21:50 |
| lifeless | Vantage: does it say anything about the repository? | 21:50 |
| nixternal | if you mean 'bzr branch lp://foo@bar/blah/blah/blah' | 21:51 |
| lifeless | nixternal: no, I said your current tree's last revision | 21:51 |
| nixternal | how do I go about doing that? | 21:51 |
| lifeless | bzr branch . ../foo | 21:51 |
| Vantage | lifeless: Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack) | 21:52 |
| Vantage | Location: | 21:52 |
| Vantage | light checkout root: . | 21:52 |
| Vantage | checkout of branch: /home/user/revision_control/shared_repos/bzr_shared/bzr/test/branches/HEAD | 21:52 |
| Vantage | shared repository: /home/user/revision_control/shared_repos/bzr_shared/bzr/test | 21:52 |
| nixternal | transferring now | 21:52 |
| abentley | nixternal: by the way /home/nixternal/work/ubuntu/docs/repos does not look like a repository. It looks like a standalone tree. | 21:53 |
| lifeless | Vantage: garh. I feel an urge to delete a swathe of info patches; older versions may have been ugly, but they gave what I needed | 21:53 |
| lifeless | Vantage: what does bzr info /home/user/revision_control/shared_repos/bzr_shared/bzr/test/branches/HEAD tell you? | 21:53 |
| abentley | lifeless: bzr info -v will tell you the repository format. | 21:54 |
| lifeless | abentley: its bizarre that you'd need that as its no more expensive to get than what we already do without -v | 21:54 |
| lifeless | and the lightweight checkout format can accurately tell you - | 21:55 |
| Vantage | lifeless: here's the format section from bzr info -v | 21:55 |
| Vantage | lifeless: Format: | 21:55 |
| Vantage | control: Meta directory format 1 | 21:55 |
| Vantage | working tree: Working tree format 4 | 21:55 |
| Vantage | branch: Branch format 6 | 21:55 |
| Vantage | repository: Packs containing knits without subtree support | 21:55 |
| lifeless | Vantage: ok thanks | 21:55 |
| lifeless | Vantage: how many files are in your project | 21:55 |
| Vantage | lifeless: and that came from within the lightweight checkout | 21:56 |
| lifeless | Vantage: and how many lines are in /home/user/revision_control/shared_repos/bzr_shared/bzr/test/.bzr/repository/pack-names | 21:56 |
| nixternal | lifeless: branch completed (glad I know that trick now) | 21:56 |
| abentley | lifeless: it's not about being un-expensive, it's about being un-verbose. | 21:56 |
| Vantage | lifeless: this module that i'm testing has about 3000 | 21:56 |
| lifeless | abentley: in the format: (...) we could filter that to only show ones plausible for the repository; thats what I'm talking about | 21:57 |
| lifeless | abentley: we show that by default | 21:57 |
| nixternal | and bzr add works :) | 21:57 |
| lifeless | nixternal: ok, if the project is open please file a bug on the problem with add; if you can remember doing anything else like mvs/renames/deletes in the other copy | 21:57 |
| lifeless | nixternal: a copy of .bzr/checkout/dirstate for the broken copy would be useful | 21:58 |
| nixternal | roger that | 21:58 |
| nixternal | thanks again! | 21:58 |
| lifeless | nixternal: and the paths it was having trouble with | 21:58 |
| abentley | lifeless: So then you get people saying: "I told bzr to create dirstate-tags checkout and it created a pack-0.92 one instead. WTF?" | 21:58 |
| Vantage | lifeless: the file has 31 lines in it | 21:58 |
| lifeless | abentley: it doesn't change what bzr did | 21:59 |
| abentley | No, it only makes it look like it did the wrong thing. | 21:59 |
| lifeless | abentley: but if they say that it may be highlighting that use of a shared repository should give a ui hint that it did | 21:59 |
| lifeless | abentley: e.g. 'checked out XXX into foo/bar of shared repository /path/to/repo/' | 21:59 |
| lifeless | Vantage: you might try doing 'bzr pack' and see if that alters the performance you are seeing for 'diff -r x..y foo.html' | 22:00 |
| lifeless | abentley: is the a bb page which shows the review requests I sent in that have not been approved (either by not being reviewed, or by being bounced) ? | 22:01 |
| lifeless | s/the/their/ | 22:01 |
| abentley | bounced? | 22:02 |
| lifeless | resubmit | 22:02 |
| abentley | Not at present. | 22:02 |
| lifeless | I'm trying to figure out if there are any threads in my stack that are not ready to merge | 22:03 |
| lifeless | it would be cute to be able to do 'bzr missing' against a virtual branch that shows bb requests that are approved as merged | 22:05 |
| ubotu | New bug: #214800 in bzr "bzr diff on removed file fails" [Undecided,New] https://launchpad.net/bugs/214800 | 22:06 |
| Vantage | lifeless: pack seems to have gotten it down to 5 seconds | 22:07 |
| abentley | lifeless: My listing shows your http://bundlebuggy.aaronbentley.com/request/%3C1207695099.9506.109.camel@lifeless-64%3E as unapproved. | 22:08 |
| lifeless | abentley: do you think it can go ? | 22:08 |
| abentley | I had the same qualms as John. Have you checked whether it's a performance regression? | 22:09 |
| lifeless | not at the very large scale; I can say that iter_rev_trees didn't use the inventory cach eanyway | 22:09 |
| lifeless | the cache was only used during fetch; disabling it make the inventory knit get read three times; that patch brings that down to 2 times, and the patch to eliminate join() that I'm working on will bring it back down to one. | 22:10 |
| abentley | It looks as though it was also used in commit. Is that wrong? | 22:12 |
| lifeless | certainly for packs | 22:12 |
| lifeless | replying to johns mail | 22:12 |
| abentley | I think it's not used by commit. It's just the way the diff hunks line up that's confusing. | 22:13 |
| lifeless | basically though I'm happy for knit based formats to get somewhat slower; they are holding pack formats back from stacking and fast build tree etc | 22:15 |
| lifeless | Vantage: thanks for that data point; I think we will have to find this performance issue in index lookups sooner rather than later | 22:16 |
| Vantage | lifeless: no problem. Thanks for the help. 5 seconds is still a little slow, but considerably better than 20 | 22:17 |
| lifeless | Vantage: how long is 'bzr ls -r X' where X is the revision you used to diff ? | 22:18 |
| lifeless | Vantage: also, you might try getting the revids and doing 'bzr diff -r revid:A..revid:B' and see if that is any faster | 22:19 |
| lifeless | Vantage: this will help figure out where the time is going | 22:19 |
| Vantage | lifeless: as in number of files? | 22:20 |
| lifeless | Vantage: not sure what you mean | 22:20 |
| Vantage | lifeless: "how long is 'bzr ls -r X'" - How long is the number of files? | 22:21 |
| Vantage | lifeless: I was using revno for the diff | 22:21 |
| lifeless | what is the time taken by 'bzr ls -r X' | 22:21 |
| lifeless | Vantage: yes, I figured you where, if you try revids you may find its faster | 22:21 |
| Vantage | lifeless: ah... real 0m3.822s | 22:22 |
| Vantage | user 0m2.548s | 22:22 |
| Vantage | sys 0m0.164s | 22:22 |
| lifeless | Vantage: try 'time bzr ls -r X > /dev/null' | 22:22 |
| abentley | lifeless: bb:approve | 22:22 |
| lifeless | abentley: where there any other pending in this arc of work? | 22:23 |
| Vantage | lifeless: real 0m3.097s | 22:23 |
| Vantage | user 0m2.476s | 22:23 |
| Vantage | sys 0m0.156s | 22:23 |
| Vantage | lifeless: where do you get the revids? | 22:23 |
| lifeless | Vantage: so that says that of the 5 seconds to diff, 3 is figuring out the revno to revid mapping | 22:23 |
| lifeless | Vantage: log --show-ids | 22:24 |
| lifeless | oh, getting the inventory out is part of the 3 seconds as well | 22:24 |
| abentley | lifeless: I don't believe so. | 22:24 |
| lifeless | abentley: sweeet, I'll land the entire set | 22:25 |
| abentley | I gotta say it's irritating to see all yours sail through while mine tend to be blocked or ignored. | 22:25 |
| lifeless | hmm | 22:26 |
| Vantage | lifeless: what's the syntax for using revid and what's the format of the id? I tried it, but I don't think I did it correctly | 22:31 |
| lifeless | revid:XXXXXXX | 22:31 |
| Vantage | lifeless: the revision-id is cvs-blah-date-what looks like a hash | 22:31 |
| lifeless | Vantage: yah, its opaque data, not a structured format | 22:32 |
| Vantage | lifeless: ah, got it. i was getting "paths are not versioned because I was in the wrong directory... argh... | 22:33 |
| Vantage | lifeless: real 0m5.269s | 22:33 |
| Vantage | user 0m4.928s | 22:33 |
| Vantage | sys 0m0.196s | 22:33 |
| lifeless | hmm ok | 22:33 |
| Vantage | so still 5 seconds | 22:33 |
| lifeless | Could be we are still mapping | 22:33 |
| lifeless | if the tree can be published, I'd be happy to have you file a bug and investigate | 22:33 |
| abentley | Which version of Bazaar? | 22:34 |
| Vantage | lifeless: unfortunately, I can't do that... | 22:34 |
| lifeless | abentley: 1.3 I believe | 22:35 |
| Vantage | abentley: 1.3 | 22:35 |
| lifeless | Vantage: thats a shame. I'm sure we will fix the performance issue eventually; but you know - reproducible cases are easier to work on. | 22:35 |
| abentley | handling of revision specs is much faster in bzr.dev | 22:35 |
| Vantage | lifeless: agreed, of course, it's not my call ;) | 22:36 |
| lifeless | abentley: I have a solid share of ignored ones - some sit around for months | 22:46 |
| lifeless | -> food bbs | 22:47 |
| lifeless | abentley: I'm going to read your stacking policy stuff today and give the feedback you asked for | 22:51 |
| abentley | lifeless: Cool. | 22:53 |
| abentley | lifeless: I really wanted your response to the "Playing with stacked branches" message | 22:54 |
| lifeless | abentley: yes, thats the one I have starred to read | 22:58 |
| lifeless | I've felt a little time pressure on the api work; | 22:58 |
| lifeless | 4 or 5 more methods and we're at the point of being able to migrate across, | 22:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!