| lifeless | abentley: do you think it would be unreasonable to have a flag to control this? | 00:01 |
|---|---|---|
| abentley | lifeless: No. | 00:01 |
| spiv | I know bialix already tried arguing for such a thing. | 00:01 |
| spiv | It does feel like sometimes send is trying to insist it knows better than the user. | 00:02 |
| abentley | spiv: everyone just complains about the way it is, but no one proposes a solution. | 00:02 |
| abentley | spiv: It does. | 00:02 |
| spiv | abentley: lifeless just proposed a flag just a second ago :P | 00:02 |
| lifeless | abentley: ok, I'll put doing such a flag on my queue | 00:02 |
| igc | morning | 00:02 |
| abentley | spiv: What does the flag do? | 00:02 |
| spiv | abentley: don't know, you just said "No" rather than asking ;) | 00:02 |
| lifeless | abentley: there was a double negative - 'not unreasonable' | 00:03 |
| abentley | spiv: two options are: 1. force it to use the revision spec 2. supply a second revision spec. | 00:04 |
| lifeless | abentley: I would have defaulted to doing 1, do you think 2 is better? | 00:04 |
| abentley | lifeless: Yes, if you're also cherrypicking. | 00:05 |
| lifeless | abentley: as it happens I am; ok. | 00:05 |
| abentley | lifeless: So presumably you want to force it in order to choose a revision older than the base of your revision spec. | 00:06 |
| abentley | Is that right? | 00:06 |
| abentley | spiv: And I do think that send's overcaution is warranted. It's very hard for users to know when they've done it wrong. | 00:08 |
| abentley | It's only when someone else has to get them to resend it that they find out. | 00:08 |
| lifeless | abentley: so for me I wanted to send beuno my last commit | 00:08 |
| lifeless | abentley: lp was offline | 00:08 |
| abentley | lifeless: Do you have a local mirror of trunk? | 00:09 |
| lifeless | as a user I imagined that if I did a cherry pick, it would include the data for the cherrypick (because I know it will grab *more*, I didn'tknow it would grab less) | 00:09 |
| lifeless | abentley: I am trunk | 00:09 |
| lifeless | (as in, yes, I have trunk, I am hacking on trunk, and I only have one local branch) | 00:10 |
| abentley | So are you trying to send beuno everything he doesn't already have, or just specific changes? | 00:10 |
| lifeless | just a single commit to trunk that he didn't pull before lp went to maintenance | 00:10 |
| lifeless | the command I tried was 'send -r -2..-1', which had the right diff, but no data | 00:10 |
| lifeless | erm, 'send -r -2..-1 . . ' for full disclosure :P | 00:11 |
| abentley | Okay, so in this case, option 1 works. You don't want him to apply a cherrypick, you want to send everything he doesn't have. | 00:11 |
| lifeless | right, I'd be happy with a flag that said 'use the range to select what to copy even if it looks like its there'. But perhaps thats not enough for everyone... | 00:12 |
| abentley | If you wanted him to apply a cherrypick of 4..5, but he only had 2, option 1 would break. | 00:12 |
| lifeless | abentley: yah | 00:12 |
| lifeless | abentley: I have an alternative idea though, what if 'send' never sent _less_ than the selected range? | 00:12 |
| lifeless | abentley: and there was a flag to tell it to send less if needed | 00:12 |
| lifeless | s/needed/possible/ | 00:13 |
| abentley | Seems like pointless irregularity to "never send less" than selected range. | 00:13 |
| lifeless | I think it would have prevented the other folk with this issue experiencing problems, and it would have done what I naively expected it to do | 00:14 |
| abentley | so the model is, -r selects what changes to apply, submit_branch determines what revisions are needed to do that. | 00:15 |
| jam | I think forcing the minimum number of deltas to send would satisfy the majority of users that are bit by 'bzr send' not sending their revisions | 00:15 |
| abentley | I don't think your proposal would have helped igc last week. | 00:15 |
| jam | abentley: I did say "majority" | 00:16 |
| jam | he would still need to use an appropriate target, but he could at least do | 00:16 |
| jam | bzr send -rthread: | 00:16 |
| jam | bzr send -rthread: ../bzr.dev | 00:16 |
| jam | Which would select the right revisions to show in the diff | 00:16 |
| jam | and the right revisions to include in the bundle | 00:16 |
| abentley | jam: i.e. no different from now. | 00:17 |
| jam | abentley: right, but everyone else who wants to do "bzr send -r -2..-1" would also benefit | 00:17 |
| jam | which is what bialix wanted orignially | 00:17 |
| jam | as he just wanted to send what he had worked on | 00:17 |
| jam | and knew where things were | 00:17 |
| jam | having to create a "temp" branch is sub-optimal | 00:17 |
| abentley | jam: it shouldn't be temp. | 00:18 |
| abentley | Branches are fantastically cheap, and you need to keep track of what other people don't have if you want to send stuff to them. | 00:18 |
| abentley | a branch is a good way to do that. | 00:19 |
| jam | abentley: they aren't very cheap untless you have --no-trees set | 00:19 |
| lifeless | abentley: so thats the problem - there was no way in advance to predict that the common reference point - 'trunk' - would be unavailable to beuno | 00:19 |
| jam | really, they aren't | 00:19 |
| jam | especially when I'm just working on a simple bugfix for a plugin | 00:19 |
| abentley | jam: I mean if you have --no-trees, of course. | 00:20 |
| jam | the big thing about plugins is that I work on them "in-place" because I want to test what I'm doing | 00:22 |
| jam | so I have to force another trunk branch | 00:22 |
| jam | and put mine in place, etc | 00:22 |
| abentley | jam: If it's casual hacking, you can just use the public branch as the submit branch. | 00:23 |
| jam | abentley: sure, but it is a whole lot longer to type than just "-r -2" | 00:23 |
| jam | I have to remember it, etc | 00:24 |
| abentley | So I am quite convinced that option 1 isn't powerful enough, option 2 is too complicated, and option 3 makes send impossible to understand. | 00:25 |
| jam | I don't see how it is impossible to understand, but unfortunately it is family time | 00:26 |
| jam | hopefully we can discuss more later | 00:26 |
| abentley | jam: okay. The basic reason is that it makes the model more complicated, because sometimes it does X, sometimes it does Y, and so you never know what it's going to do. | 00:27 |
| * beuno is off to a dinner | 00:28 | |
| lifeless | train time | 00:28 |
| beuno | bbl | 00:28 |
| abentley | jam: If people don't grasp send now, making what it does more complicated isn't going to help. | 00:29 |
| jam | >= X is (IMO) *easier* to understand because it fits more what people expect | 00:39 |
| jam | specifically if I give a range, it includes that range | 00:39 |
| poolie | jam, are you still here? | 00:44 |
| jam | poolie: off and on | 00:48 |
| poolie | jam, i was going to ask about that xcross bug but jml just turned up and he's been working on it too | 00:49 |
| jam | poolie: you got my emails, right? | 00:49 |
| poolie | i did | 00:50 |
| * mwhudson wishes for an after: revisionspec | 00:51 | |
| spiv | mwhudson: there could be lots of revisions that would match, though. | 00:52 |
| mwhudson | spiv: it's clear enough for a mainline revision, isn't it? | 00:52 |
| mwhudson | i mean, before: could match >1 revision too... | 00:52 |
| * igc gets some breakfast | 00:53 | |
| mwhudson | (i presume it always takes the left hand parent, though 'help revisionspec' doesn't actually say this) | 00:53 |
| spiv | mwhudson: That's true. Possibly even for non-mainline revisions if you define an appropriate ordering (e.g. based on our current dotted revno scheme, i.e. topological based on when branches were merged to mainline) | 00:53 |
| spiv | mwhudson: right, before: always takes the left hand parent AFAIK. | 00:54 |
| mwhudson | spiv: basically, bzr log --short submit:.. is *almost* want i wanted to see | 00:54 |
| spiv | mwhudson: sounds like there's a bug report/feature request or two to be made :) | 00:54 |
| mwhudson | well | 00:54 |
| spiv | (I mean, made somewhere more permanent than IRC) | 00:55 |
| mwhudson | actually i think i want bzr missing --mine-only | 00:55 |
| mwhudson | --short | 00:55 |
| * mwhudson makes an alias | 00:55 | |
| abentley | jam: It can't make it easier to understand, since they also need to understand the normal behavior. | 01:03 |
| poolie | spiv, where are you? | 01:08 |
| spiv | poolie: on the 10:30 train | 01:09 |
| spiv | eta about 11:10 I guess. | 01:10 |
| poolie | ok | 01:10 |
| jml | hitchhiker is pretty cool | 01:42 |
| markh | jam: you around? | 02:18 |
| poolie | lifeless: you said "The thing is, they are xml's that are being asked for" but is it guaranteed at this level that the fulltext inventories are xml? | 03:04 |
| poolie | ok review for the last non-test files sent | 03:05 |
| spiv | Have sent reviews of a few more test files, about to tackle test_knit. | 03:12 |
| lifeless | poolie: the calling code expects xml | 03:16 |
| lifeless | poolie: if its not it will blow up | 03:16 |
| jam | markh something resembling around | 03:18 |
| jam | weird, markh isn't present, but I don't see a disconnect for him | 03:19 |
| mwhudson | * markh has quit (Read error: 104 (Connection reset by peer)) | 03:20 |
| mwhudson | 8 minutes ago | 03:20 |
| * igc lunch | 03:21 | |
| spiv | jam: I just gave him a ping | 03:22 |
| spiv | jam: he'll be on again in a sec | 03:22 |
| jam | mwhudson: yeah, mine doesn't have that line | 03:22 |
| jam | spiv: if you want, ping poolie and lifeless if they are there | 03:23 |
| jam | they both wanted to talk with me | 03:23 |
| jam | or, I guess, *poke* them for me :) | 03:23 |
| markh | jam: you have a sec to share your recent experiences building the windows installer? | 03:24 |
| jam | sure | 03:24 |
| jam | once I got dependencies done | 03:24 |
| markh | so, I saw a docutils error - did you see that? | 03:24 |
| poolie | jam, hi | 03:24 |
| jam | it was mostly just "make installer" | 03:24 |
| markh | yeah, but that grinds to a halt at a couple of places for me :) | 03:25 |
| jam | I'll try real quick | 03:25 |
| jam | I haven't done it since 1.5 | 03:25 |
| markh | oh, roght | 03:25 |
| markh | sorry - I thought you did the most recent binaries | 03:25 |
| jam | markh: I didn't know someone *did* newer binaries | 03:26 |
| jam | I have to do a few quick hacks to the makefile myself | 03:26 |
| jam | namely, adding "-c mingw32" to the build lines | 03:26 |
| jam | make installer PYTHON=/cygdrive/c/python25/... | 03:26 |
| jam | since I use Make from cygwin | 03:26 |
| jam | but win32 python | 03:26 |
| jam | markh: this time, it got all the way to wanting to run "cog.py" for me | 03:27 |
| jam | which means all of the .html files built fine | 03:28 |
| markh | my problem with docutils is the same as Alex reports many months ago via https://lists.ubuntu.com/archives/bazaar/2007q4/035100.html - I get the same results with docutils 0.4, the "snapshot" on their site, and also the svn version | 03:28 |
| markh | the issue appears to be the "." in the option name | 03:28 |
| jam | markh: I seem to be using docutils.__version__ == 0.4 | 03:29 |
| markh | I started with 0.4, but now have 0.5 | 03:29 |
| jam | I do remember the --pack-0.92 being an issue | 03:30 |
| markh | The problem doesn't appear on Linux either - but the fact Alex and I both saw it many months apart means there is *some* issue here | 03:30 |
| markh | yeah, that is it | 03:30 |
| jam | I thought we sorted it out somehow | 03:30 |
| markh | maybe I need to "clean" my tree somehow? Its certainly up-to-date though | 03:30 |
| jam | markh: look at tools/rst2html.py | 03:30 |
| jam | There is a workaround if "docutils.__version__ <= 0.4.1" | 03:30 |
| markh | ah - ok, thanks - I'll dig a little more. | 03:31 |
| jam | markh: it may be that the hack just needs to be updated for whatever version | 03:31 |
| markh | I started with 0.4 though - I'll need to dig a little | 03:34 |
| markh | so, apparently I already had 0.5 installed and trying to install 0.4 over the top left 0.5 in place. It does look like the "." issue isn't fixed in docutils svn, so maybe that version check should just be removed completely? | 03:58 |
| whitelynx | I've been looking through the bzrlib api docs for some way to get the username of the author of a given commit; can anyone point me in the right direction? | 04:17 |
| whitelynx | i have a branch object to work with, and i just need the username of the author of the most recent revision | 04:18 |
| mwhudson | the most recent revision is | 04:18 |
| mwhudson | last_rev = branch.repository.get_revision(branch.last_revision()) | 04:19 |
| mwhudson | then last_rev.get_apparent_author() | 04:19 |
| whitelynx | aah, i missed .repository | 04:19 |
| whitelynx | cool | 04:19 |
| whitelynx | thank you very much :-D | 04:19 |
| mwhudson | np | 04:19 |
| sabdfl | hi folks | 04:42 |
| thumper | hi sabdfl | 04:52 |
| mwhudson | hello sabdfl | 04:54 |
| sabdfl | hi folks | 04:54 |
| mwhudson | yay, i have loggerhead running without turbogears or cherrypy | 05:16 |
| beuno | mwhudson, :) :) :) | 05:18 |
| beuno | now, if you can do something about files changed, we can drop sqlite too! | 05:19 |
| mwhudson | but using the loggerhead.conf gile | 05:19 |
| mwhudson | which is the new bit | 05:19 |
| beuno | mwhudson, I looked up to revno 186. Did you do more work after that? | 05:19 |
| lifeless | beuno: wb | 05:19 |
| lifeless | hi sabdfl | 05:20 |
| mwhudson | beuno: i just pushed 187 | 05:20 |
| beuno | howdy lifeless. I'm pushing the last changes to my clean url branch, and bzr-super-search is up :) | 05:20 |
| lifeless | beuno: online demo? | 05:20 |
| mwhudson | well, i'm ignoring some bits of the config file | 05:20 |
| mwhudson | which i probably shouldn't ignore | 05:21 |
| lifeless | mwhudson: you know about 'get_public_branch' ? | 05:21 |
| Peng | "Is it possible the remote side is supports RPCs for a given version?"? | 05:21 |
| mwhudson | lifeless: yes, what about it? | 05:21 |
| lifeless | mwhudson: for the gnome bug on 'download command' | 05:21 |
| mwhudson | lifeless: oh right, yes | 05:21 |
| beuno | mwhudson, pushing my changes to clean urls. It's basically work on annotate. | 05:22 |
| mwhudson | beuno: ok, i still haven't gotten around to looking at it properly :) | 05:22 |
| beuno | "Rev 187: woohoo it works" -> lol | 05:22 |
| mwhudson | yeah, i'm not very good at super professional commit messages | 05:23 |
| beuno | that's pretty descriptive to me :p | 05:23 |
| beuno | mwhudson, it may be a good idea for start-loggerhead.py to stop asking for Turbgears on that branch now | 05:24 |
| lifeless | beuno: can you run up super-search on your adsl or something ? | 05:24 |
| lifeless | beuno: I don't have LH running anywhere yet | 05:24 |
| mwhudson | beuno: oh yeah :) | 05:24 |
| beuno | lifeless, I absolutely can, and will | 05:25 |
| beuno | mwhudson, one more thing. I'd *really* like to change python2.4 to python on the start/stop header. It works perfectly with python 2.5 (I constantly have to shelve it because I change that manually) | 05:29 |
| beuno | is there some other reason not to change it that I'm missing? | 05:29 |
| mwhudson | i really can't think of one | 05:30 |
| beuno | :) | 05:30 |
| beuno | I discovered -f -C on start-loggerhead, so I don't have to comment out the deamon out to test | 05:31 |
| mwhudson | ah :) | 05:31 |
| mwhudson | what does -C do? | 05:31 |
| mwhudson | oh something dumb with pidfiles | 05:32 |
| beuno | makes sure it's not already running | 05:32 |
| beuno | yes | 05:32 |
| beuno | I have a bug sort of related to that | 05:32 |
| beuno | close and open it enough times, and, eventually, you'll have to kill -9 it | 05:32 |
| mwhudson | i wonder what people use for serving their wsgi applications for real | 05:33 |
| mwhudson | i'm not sure it's paste.httpserver | 05:33 |
| lifeless | beuno: tell me when its up :) | 05:34 |
| beuno | lifeless, putting it together now. I'll ping you the second it does something | 05:35 |
| * Peng runs away. | 05:37 | |
| spiv | We have BUGFIXES and BUG FIXES sections in our NEWS file. | 05:41 |
| spiv | In the same release in some cases. | 05:42 |
| Peng | Of course. Everyone knows that "BUGFIXES" is for when the fix is more important than the bug and "BUG FIXES" is for when the bug is more important. | 05:44 |
| Peng | Duh. | 05:44 |
| Peng | :) | 05:44 |
| spiv | Peng: Hmm, I thought maybe BUG FIXES was for the case when introducing a bug fixed something else ;) | 05:49 |
| Peng | Hmm, that too. | 05:49 |
| poolie | i think separate words is (are?) better | 05:57 |
| mwhudson | mmm, wsgi makes it a bit harder than it could be to test things | 05:57 |
| lifeless | poolie: 'are' | 05:57 |
| mwhudson | oh well | 05:57 |
| poolie | hm ok we already had a thread about forums | 06:00 |
| lifeless | poolie: pull --overwrite from http://people.ubuntu.com/~robertc/baz2.0/versioned_files | 06:03 |
| lifeless | beuno: some trouble ? (just keen to see it :P) | 06:27 |
| beuno | lifeless, not really, it just takes a lot of time with template and all :/ | 06:28 |
| beuno | I should have something working in a few minutes | 06:28 |
| beuno | me and simpletal don't agree on how I can output HTML | 06:28 |
| lifeless | heh | 06:29 |
| Peng | poolie: I swear I'll do something actually useful one day, but until then, trivial typos are still nice to fix. | 06:31 |
| beuno | lifeless, apart from that, everything is in place, so it's just a matter of working out the quirks now | 06:31 |
| lifeless | beuno: cool. I thought from your earlier comment it was already done :) | 06:32 |
| beuno | lifeless, just the javascript bit, I had to glue stuff together now | 06:33 |
| beuno | templates put a lot of overhead to the process | 06:33 |
| beuno | mwhudson's wsgi branch will change that :) | 06:33 |
| mwhudson_ | next steps with that branch are making it less of a hack, i think | 06:35 |
| mwhudson_ | (and thinking about how to test it) | 06:35 |
| beuno | yay! sort-of-works | 06:46 |
| beuno | lifeless, need to fix a small glitch, and I'll send you the URL :) | 06:47 |
| lifeless | ©ol! | 06:47 |
| epsy | hi | 06:50 |
| epsy | i have a problem, bzr just crashed | 06:50 |
| Peng | go on | 06:50 |
| epsy | since user avatars aren't that useful to be versionned, i did a bzr rm --keep on the images/avatars dir | 06:51 |
| epsy | now this is what i get: | 06:51 |
| epsy | bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: images/avatars/upload | 06:51 |
| epsy | parent of: (('images/avatars/upload', '5ef0e1b75641934ad6285db9860c3a40_97.jpg', '5ef0e1b75641934ad628-20080427193459-5bbck3mpjk6eryxr-135 | 06:51 |
| epsy | 9'), [('f', '0c0cad69edec800fc7b17e76719263785e7d07f2', 55692L, 0, 'AADZjEevoDtHr6A7AAAAGAI3NioAAIG2'), ('f', '0c0cad69edec800fc7b17e76719263785e7d07f2', 55692L, 0, 'xclan@fiji-20080427193835-i2lnc7oj8cj54cq9')]) | 06:51 |
| poolie | what command were you running? | 06:52 |
| epsy | images/avatars/upload/5ef0e1b75641934ad6285db9860c3a40_97.jpg doesn't exist | 06:52 |
| epsy | bzr status and bzr diff | 06:52 |
| epsy | should i pastebin the traceback? | 06:53 |
| poolie | epsy: can you file a bug for it please? | 06:53 |
| epsy | ok, i'll do in the evening | 06:53 |
| poolie | i suspect it has removed the directory but not the subdir or something | 06:53 |
| poolie | thanks | 06:53 |
| epsy | looks like | 06:53 |
| lifeless | beuno: if you can leave the demo running once its working, I'll show it to Jc2k and bkor when they get up | 07:04 |
| lifeless | beuno: I have to go catch a train now, back on line in ~1hr15 | 07:04 |
| beuno | lifeless, hold on 2' | 07:06 |
| beuno | and I'll show you *something* | 07:06 |
| lifeless | ok | 07:06 |
| beuno | lifeless, http://200.127.6.219:8080/bazaar/bzr_garbage/changes | 07:07 |
| lifeless | beuno: nice | 07:10 |
| beuno | of course, it's just something thrown on the page. There should be a floating diff and all that | 07:10 |
| lifeless | beuno: better in a drop down etc etc :) | 07:10 |
| beuno | exactly :) | 07:10 |
| lifeless | beuno: also, it doesn't seem to handle two terms correctly (like if you type "fetch c" into the box) | 07:11 |
| epsy | bbl | 07:11 |
| lifeless | it should as for index.suggest([('fetch',), ('c',)]) | 07:11 |
| lifeless | but yeah - coolness | 07:11 |
| beuno | lifeless, yes, I had to work around an issue where it transformd any string into a list of characters | 07:11 |
| lifeless | and nifty fast given the link etc | 07:12 |
| lifeless | ok train time | 07:12 |
| lifeless | but you rock | 07:12 |
| beuno | lifeless, I'll have something better when you come back :) | 07:12 |
| beuno | mwhudson_, ^ | 07:13 |
| mwhudson_ | beuno: it doesn't seem to find anything | 07:14 |
| mwhudson_ | beuno: but i like the idea :) | 07:14 |
| beuno | mwhudson_, really? it doesn't find terms as you type? | 07:14 |
| mwhudson_ | beuno: no, when you press return | 07:15 |
| beuno | it's the bzr-search branch | 07:15 |
| beuno | so I'd suggest something like "test" | 07:15 |
| mwhudson_ | oh | 07:15 |
| beuno | and, it tries every 200ms, so don't be un a hurry to type :) | 07:16 |
| mwhudson_ | ok | 07:16 |
| mwhudson_ | but if you type rober | 07:16 |
| mwhudson_ | it suggests robert | 07:16 |
| beuno | yes | 07:16 |
| mwhudson_ | but searching for robert doesn't give any hits | 07:16 |
| === mwhudson_ is now known as mwhudson | ||
| beuno | well, that's because I broke search while doing this | 07:16 |
| mwhudson | :) | 07:17 |
| beuno | I was running against a train, so made a few exceptions while coding :p | 07:17 |
| spiv | Heh. | 07:18 |
| mwhudson | #bzr: championing Train Driven Development | 07:18 |
| beuno | hahaha | 07:19 |
| beuno | I always stick with TDD :) | 07:19 |
| * beuno hides from vila | 07:20 | |
| vila | beuno: better late than never ;-p | 07:21 |
| mwhudson | interesting | 07:23 |
| mwhudson | you have a/b versioned | 07:24 |
| mwhudson | bzr mv a/b b | 07:24 |
| mwhudson | bzr rm a | 07:24 |
| mwhudson | oh, modify b | 07:24 |
| mwhudson | then bzr rm a | 07:24 |
| mwhudson | -> cannot remove modified file | 07:24 |
| lifeless | back | 08:17 |
| beuno | damn, too fast :p | 08:17 |
| beuno | I did fix search and whatnot | 08:18 |
| lifeless | cool | 08:19 |
| beuno | and pushed the branch | 08:19 |
| beuno | trying to make the drop down more ajaxish | 08:19 |
| Jc2k | this sounds shiny | 08:21 |
| Jc2k | the evil plan worked, i guess | 08:21 |
| lifeless | indeed it did muahahaha | 08:22 |
| mwhudson | morning Jc2k | 08:22 |
| Jc2k | morning :) or evening.. :) | 08:23 |
| liw | I'm trying to apply a bundle I got via e-mail, and I get this: bzr: ERROR: Revision is not compatible with KnitRepository('file:///home/liw/p/python-coverage/upstream/.bzr/repository/') | 08:23 |
| liw | what am I doing wrong? | 08:24 |
| Peng | liw: You're using different types of repositories (one probably has rich roots) | 08:25 |
| liw | so I need to ask the bundle submitter to switch to a different type of repository? that's inconvenient | 08:27 |
| lifeless | liw: are you using bzr-svn ? | 08:28 |
| Peng | liw: Run 'bzr info'. What format does it say you're using? | 08:28 |
| liw | lifeless, nope, plain bzr | 08:28 |
| lifeless | liw: bzr tries to preserve this, something strange has to have gone on to cause this | 08:28 |
| liw | Standalone tree (format: dirstate) | 08:28 |
| Peng | Yikes. | 08:28 |
| Peng | That's ooold. | 08:29 |
| lifeless | liw: I suspect they branched into a rich-root repository, and thats caused the bundle to have data your repository can't represent | 08:29 |
| lifeless | liw: we want to change teh default and have everyone upgrade | 08:29 |
| liw | so what should I do? | 08:31 |
| liw | hmm, my local branch is made from the branch on my web server, if I "bzr upgrade" that one, and make a new branch locally, it has dirstate-tags | 08:33 |
| liw | but still no luck merging the bundle | 08:33 |
| mwhudson | you probably need --dirstate-rich-root or whatever it's called | 08:34 |
| mwhudson | or --rich-root-pack | 08:34 |
| mwhudson | these are repository upgrades, not branch upgrades, fwiw | 08:34 |
| liw | what's the difference between --rich-root and --rich-root-pack? | 08:38 |
| jml | liw: the first is rich root with knits | 08:39 |
| jml | liw: the second is rich root with packs | 08:39 |
| jml | I think. | 08:39 |
| lifeless | liw: first, talk to yourr contributor and figure out what happened | 08:39 |
| lifeless | liw: secondly, I'd apply the bundle with patch :P | 08:39 |
| Peng | jml is correct. | 08:40 |
| liw | jml, that is not entirely informative to me, being as I'm ignorant about bzr internals :) | 08:40 |
| Peng | liw: Packs are the awesome new(er) repository format. They're fast and stuff. | 08:40 |
| lifeless | liw: there are two dimensions | 08:41 |
| liw | "bzr help formats" isn't particularly useful for choosing, either, imo | 08:41 |
| lifeless | liw: disk representation | 08:41 |
| lifeless | liw: and semantic structure | 08:41 |
| lifeless | liw: 'rich root' is in the second and is not backwards compatible | 08:41 |
| liw | lifeless, can we pretend for a moment that I don't care about implementation details and just want to pick a format? :) | 08:42 |
| Peng | liw: pack-0.92 | 08:43 |
| spiv | liw: you almost certainly want the default format (pack-0.92) | 08:43 |
| lifeless | liw: *you should not change anything* | 08:44 |
| lifeless | liw: I gave you isntructions above | 08:44 |
| spiv | Your contributor seems to be using a non-default format though, and it would be good to find out why. | 08:44 |
| spiv | Anyway, listen to lifeless :) | 08:44 |
| Peng | Hmm, I guess signed messages on the list (or at least those with attachments) use PGP/MIME? | 08:47 |
| liw | lifeless, yeah, I'm asking him, but in the mean while, I already ran "bzr upgrade" :) | 08:48 |
| liw | lifeless, before you said anything, even | 08:48 |
| ToyKeeper | lifeless: So, you're working on making bzr use a single storage format? | 08:48 |
| Peng | ToyKeeper: Ideally, there would be one perfect format, and they're working toward that. The only reason there are multiple formats is to be able to make backwards-incompatible improvements, and because some are experimental. | 08:50 |
| ToyKeeper | Well, finding the best way to organize the data is a good goal, and not at all simple. :) | 08:51 |
| lifeless | liw: 'bzr upgrade' on its own is fine and safe | 08:52 |
| lifeless | Peng: my mails probably do | 08:52 |
| lifeless | Peng: rfc 16?? IIRC | 08:53 |
| Peng | lifeless: Yeah, I think so. You use Evolution, and the details are entirely different from Thunderbird/Enigmail's PGP/MIME, but it seems to be doing the same thing. | 08:54 |
| Peng | Not only did I send a really trivial patch, signed with an untrusted gpg key, but I didn't use PGP/MIME, so the patch itself wasn't signed. :D | 08:55 |
| beuno | aaaaaaaanyway, I'm off to bed | 08:58 |
| beuno | lifeless, nicer way of showing suggestions will land soon-ish, but not today :) | 08:58 |
| beuno | pushed everything to LP :) | 08:59 |
| beuno | I'll leave LH running in case you want to play around more | 09:00 |
| poolie | ok that's enough for me | 09:01 |
| lifeless | poolie: night poolie | 09:05 |
| lifeless | beuno: its looking promising all the same | 09:06 |
| ToyKeeper | D'oh... noticed a typo 5 seconds after submitting a bug. | 09:16 |
| lifeless | :P | 09:17 |
| lifeless | should I close it with 'bzr-aspell' is a good idea? | 09:17 |
| ToyKeeper | Heh, not a spelling error... the grammar was broken after re-arranging some phrases. | 09:18 |
| ToyKeeper | Maybe I should just file another one... "launchpad needs an 'oops' button". :) | 09:20 |
| mwhudson_ | there is a bug for "i should be able to edit my comment for a while after posting it" | 09:20 |
| ToyKeeper | Yeah, kinda figured that one would already exist. And there is a function to edit the original bug description. :) | 09:21 |
| * igc dinner | 09:22 | |
| === mwhudson_ is now known as mwhudson | ||
| mtaylor | hey all | 10:05 |
| mtaylor | if I've got a revid | 10:06 |
| mwhudson | hello mtaylor | 10:06 |
| mtaylor | hi mwhudson | 10:06 |
| mtaylor | and I want to find the revno | 10:06 |
| mtaylor | either of that revid | 10:06 |
| mtaylor | OR | 10:06 |
| mtaylor | of the left-most revision that contains that revid | 10:06 |
| mtaylor | (since revision_id_to_revno won't work on revids that are sub-sets of a merge) | 10:07 |
| mtaylor | is there a sensible way to do this that I'm missing? | 10:07 |
| mwhudson | you want to find the revno of the mainline revision that merges your revid? | 10:07 |
| mtaylor | yes | 10:07 |
| mwhudson | and are we talking programmatically or just now and then in the shell? | 10:07 |
| mtaylor | programattically | 10:08 |
| mtaylor | this is for inside of a post-push email hook | 10:08 |
| mwhudson | i don't think there's a very clean way of doing this | 10:08 |
| mtaylor | so, just in case I'm missing something _else_... | 10:08 |
| mwhudson | i guess you can keep taking the left hand parent until you get a revision that's in the revision_history of the branch | 10:09 |
| mtaylor | how do I get the left hand parent? | 10:10 |
| mtaylor | do I have to get the repository first? | 10:11 |
| mtaylor | gah. how about get_parent | 10:11 |
| mwhudson | branch.repository.get_revision(revid).parent_ids[0] | 10:11 |
| mtaylor | oy | 10:11 |
| mtaylor | ok | 10:11 |
| mtaylor | mwhudson: is there a chance that given a revid I will keep trying that and get in to an endless loop somehow? | 10:14 |
| mwhudson | mtaylor: no | 10:15 |
| mtaylor | ok. good | 10:15 |
| mwhudson | and if you know that the revid is in the branch, you'll definitely get a mainline revision eventually too | 10:16 |
| mwhudson | hang on | 10:16 |
| mwhudson | i think i've been giving you bogus advice :( | 10:16 |
| mwhudson | mtaylor: you want to know the revision that _merged_ the revid you've got, don't you? | 10:17 |
| mtaylor | yes | 10:17 |
| mwhudson | do you expect it to be a recent revision that merged it, or could it be arbitrary? | 10:17 |
| mtaylor | I expect it to be recent (this is in post-push, and I'm doing this on old_revid | 10:18 |
| mwhudson | (i've been telling you how to find the common ancestor of branch tip and your revid) | 10:18 |
| mwhudson | mtaylor: then | 10:18 |
| mwhudson | hm, i have code sort of for this even somewhere | 10:18 |
| mtaylor | mwhudson: I essentiall want to get a revno I can pass to log.show_log() | 10:19 |
| mtaylor | mwhudson: to get the diff of what was just pushed | 10:19 |
| lifeless | mtaylor: you have a revid | 10:19 |
| mtaylor | can I pass a revid to show_log() | 10:19 |
| lifeless | mtaylor: erm, why are you using log to get a diff ? | 10:19 |
| lifeless | 'revspec' handles user input to revnos and revids | 10:20 |
| mtaylor | lifeless: what should I use instead? | 10:20 |
| lifeless | passing revid:REVISIONID to a revspec will do what you need, but I'm confused why you wouldn't use diff :) | 10:20 |
| mtaylor | lifeless: this is in a plugin? | 10:21 |
| mwhudson | oh eh | 10:21 |
| lifeless | mtaylor: nope, core. also have you looked at the email plugin and what it does? | 10:21 |
| mwhudson | you have a much easier problem than you suggested i think :) | 10:21 |
| lifeless | mtaylor: I'd really expect the sort of thing you want to be part of the email plugin TBH | 10:21 |
| mtaylor | lifeless: yes... this is actually a fork of email plugin | 10:21 |
| mwhudson | mtaylor: this is the code to do the hard thing: http://pastebin.ubuntu.com/21114/ :) | 10:21 |
| mtaylor | mwhudson: sweet! | 10:22 |
| mwhudson | mtaylor: listen to lifeless though | 10:22 |
| mtaylor | ok | 10:22 |
| mwhudson | mtaylor: but it sounds like bzr diff -r revid:old_revid is what you want | 10:23 |
| lifeless | well, the post commit hook already handles all of this | 10:23 |
| mtaylor | yes. that is exactly what I want | 10:24 |
| lifeless | because a commit can move more than one revno (especially in bound branches) | 10:24 |
| mtaylor | lifeless: yes. but the post commit hooks inputs are a little different than the info given to post-push | 10:24 |
| mtaylor | because revnos don't change in post-commit | 10:24 |
| lifeless | yes they do | 10:24 |
| * mtaylor looks at code again... | 10:25 | |
| lifeless | (uncommon, but its possible to change revnos by doing a commit, if the right hand parent of the tree is the tip of the branch and the left hand parent is deeper in the branch) | 10:25 |
| mtaylor | so, bzr-email does this: self.revno = self.branch.revision_id_to_revno(self._revision_id) | 10:26 |
| mtaylor | ahh.. hang on | 10:26 |
| mtaylor | lifeless: ok... I was looking in the wrong area. I think I see what you're talking about now | 10:27 |
| mtaylor | lemme give this a try | 10:27 |
| mtaylor | ok. | 10:28 |
| * mtaylor has been stating the problem incorrectly | 10:28 | |
| mtaylor | I'm not crashing in the diff code when the revnos change, I'm crashing in the log code (thus why I was using show_log) | 10:28 |
| * mtaylor smacks self in head | 10:28 | |
| lifeless | :) | 10:29 |
| uws | jelmer, bkor, Jc2k: FYI, I've blogged about my Gnome Bazaar/SVN import experience here: http://uwstopia.nl/blog/2008/06/importing-bazaar-branches-into-gnome-svn | 10:33 |
| Jc2k | cool :) | 10:36 |
| lifeless | uws: if you'd like gnome to move to bazaar, you could note that in that post :) | 10:36 |
| lifeless | uws: like 'but hopefully only temporarily, if we move to bazaar' :) | 10:36 |
| uws | lifeless: good idea :) | 10:36 |
| uws | lifeless: refresh, first paragraph | 10:37 |
| uws | lifeless: another update, 3rd paragraph | 10:38 |
| Jc2k | uws: i've been a bad boy and moved /BzrForGnomeDevelopers to /Bazaar. i dont know how to make it auto forward, so there is an extra click right now.. | 10:39 |
| lifeless | uws: hasn't updated for me :X | 10:40 |
| uws | Jc2k: update | 10:40 |
| uws | lifeless: ctrl-shift-r ? | 10:41 |
| lifeless | http://uwstopia.nl/2008/06/gnome-specimen-now-in-gnome-svn is a 404 too | 10:41 |
| Jc2k | awesome :) | 10:41 |
| Jc2k | http://uwstopia.nl/blog/2008/06/gnome-specimen-now-in-gnome-svn works for me | 10:42 |
| uws | lifeless: your missing the "/blog" part at the start of the url | 10:43 |
| * uws updates link.. | 10:43 | |
| uws | lifeless: now it works | 10:43 |
| lifeless | that was the link I saw :P | 10:44 |
| lifeless | ah, the network effect is live and well :) | 10:46 |
| lifeless | still, nice | 10:46 |
| Jc2k | uws: should the bzr push --remember svn+ssh://svn.gnome.org/svn/gnome-specimen/branches/import-from-bzr/ be pointing at trunk now? | 10:47 |
| uws | I think I've done my share of bzr pimping for today :) | 10:47 |
| uws | Jc2k: oops, sure | 10:48 |
| uws | Jc2k: More suggestions, fixes, comments? | 10:48 |
| Jc2k | uws: looks good :) | 10:49 |
| lifeless | Jc2k: did you see http://200.127.6.219:8080/bazaar/bzr_garbage/changes ? | 10:49 |
| lifeless | Jc2k: type in the search box there | 10:49 |
| Jc2k | lifeless: no | 10:49 |
| Jc2k | *looks* | 10:49 |
| lifeless | (imagine that the hits are in a floating frame etc etc | 10:53 |
| mwhudson | beuno: you have an interesting (i hope) mail | 10:53 |
| mwhudson | but i really hope you're asleep | 10:53 |
| uws | Is there a way to to tell bzr log to show all commits in the po/ directory? | 10:54 |
| uws | bzr log po/ only shows the revision in which that directory was added | 10:54 |
| mwhudson | mm, 22:00, time for dinner | 10:54 |
| uws | and bzr log po/*.po doesn't work either | 10:54 |
| lifeless | I think there is a bug open | 10:54 |
| lifeless | definitely want to do that efficiently | 10:54 |
| uws | 1200, itme for lunch :) | 10:54 |
| Jc2k | lifeless: it doesnt seem to do anything? | 10:56 |
| lifeless | Jc2k: so if you type 'te' in the search box and don't press enter or anything | 11:01 |
| lifeless | a completion list should appear at the top of the page | 11:02 |
| Jc2k | lifeless: i get FF3 history based auto complete, and nothing else.. | 11:05 |
| lifeless | Jc2k: not as a popup | 11:05 |
| lifeless | as black text - python tuples | 11:05 |
| lifeless | # ('telling',) | 11:05 |
| lifeless | # ('term',) | 11:05 |
| lifeless | # ('term1',) | 11:05 |
| lifeless | etc | 11:05 |
| Jc2k | ah, firebug says there are some GET's outstanding | 11:05 |
| Jc2k | they are taking their time ;) | 11:06 |
| lifeless | hmm | 11:06 |
| lifeless | it was near-instant for me before :) | 11:07 |
| lifeless | beuno: are you still up ? :P | 11:08 |
| Jc2k | i have timeouts showing in firebug now :( | 11:09 |
| lifeless | so, I think his home machine is shut down now | 11:11 |
| lifeless | the main page is timing out too | 11:11 |
| Jc2k | ah | 11:11 |
| lifeless | https://code.edge.launchpad.net/~beuno/loggerhead/bzr-search_integration | 11:13 |
| * Jc2k imagines autocomplete goodness | 11:14 | |
| lifeless | :P | 11:17 |
| beuno | argh, I can't sleep | 11:29 |
| beuno | Jc2k, try again :) | 11:29 |
| beuno | mwhudson, just saw the email, I'll see what can be done about it. Thanks for the review | 11:30 |
| mwhudson | beuno: oh dear | 11:31 |
| beuno | I | 11:31 |
| beuno | I'm going to skip sleeping tonight, that should make it easier tomorrow :) | 11:32 |
| Jc2k | veeerry cool beuno :) | 11:32 |
| beuno | Jc2k, thanks. It | 11:32 |
| beuno | argh | 11:32 |
| beuno | it's all based off lifeless' fast-growing bzr-search | 11:33 |
| beuno | it needs some UI love | 11:33 |
| lifeless | Jc2k: ah you've seen it work ? | 11:34 |
| Jc2k | lifeless: ys :) | 11:35 |
| Jc2k | having that, "clean urls", a skinned loggerhead, and bzr-search indexes for GNOME - doable by GUADEC? | 11:36 |
| beuno | Jc2k, when is guadec? | 11:36 |
| Jc2k | july 7th to 12th | 11:37 |
| beuno | Jc2k, yes, doable in trunk at the very least | 11:37 |
| Jc2k | (there is a big DVCS talk going down..) | 11:37 |
| beuno | (not sure when we're releasing 1.6) | 11:37 |
| Jc2k | excellent, i fear not the trunk ;) | 11:37 |
| beuno | Jc2k, are you going to be skinning it? | 11:38 |
| Jc2k | trying, at least | 11:38 |
| beuno | Jc2k, how much does it have to look like the current gnome.org? | 11:38 |
| Jc2k | beuno: at the very least i want to stick the standard GNOME header on it: http://bzr-mirror.gnome.org/ | 11:39 |
| * beuno goes make coffee and pretends he just woke up | 11:39 | |
| Jc2k | there is some standard HTML for that, i dont see a problem there | 11:39 |
| beuno | Jc2k, I can get that done for you | 11:40 |
| Jc2k | cool :) | 11:40 |
| beuno | there is a new theme coming up, but I don't know how close to that date we'll have it finished | 11:41 |
| beuno | I'll make sure we can switch at the last moment if we happen to make it | 11:41 |
| beuno | mwhudson, so... we're aiming at making bzr-search *the* search for LH, right? Just so I know how much time I can shift into it | 11:42 |
| mwhudson | beuno: sure | 11:44 |
| beuno | yay! | 11:44 |
| beuno | we should put together a roadmap of some sort at some point | 11:45 |
| beuno | and/or keep filing bugs, I suppose | 11:45 |
| beuno | lifeless, btw, "bzr search -s Robert C", *just* searches for "C" | 12:02 |
| dato | maybe try -s 'Robert C' ? | 12:03 |
| lifeless | beuno: not for me | 12:04 |
| beuno | dato, right, makes sense. I'm being stupid, thanks :) | 12:05 |
| lifeless | actually 'Robert C' is different | 12:05 |
| lifeless | it is a phrase | 12:05 |
| beuno | beuno@beuno-laptop:~/bzr_devel/bzr.dev$ bzr search -s Robert C | 12:06 |
| beuno | Suggestions: [('C',), ('CA',), ('CAUTION',), ('CHANGES',), ('CHECK_ALWAYS',), | 12:06 |
| beuno | (and a very long etc) | 12:06 |
| lifeless | on bzr search itself, doing 'bzr search -s Robert C' is missing ('Coming',), | 12:06 |
| lifeless | compared to bzr search -s C | 12:06 |
| lifeless | do this: | 12:06 |
| lifeless | :!bzr search -s C | grep Coming | 12:06 |
| lifeless | :!bzr search -s Robert C | grep Coming | 12:06 |
| beuno | right, what's it doing differently? | 12:08 |
| Jc2k | so if i have branches with trees, can i make them treeless? | 12:10 |
| Kinnison | yes | 12:11 |
| mwhudson | bzr remove-tree | 12:12 |
| Kinnison | bzr remove-tree [LOCATION] | 12:12 |
| Jc2k | ahh, awesome | 12:12 |
| Kinnison | there may also be a bzr reconfigure option but I don't know it | 12:12 |
| Jc2k | i dont suppose there is a command to do that to all the branches under a repository? | 12:12 |
| Kinnison | aah, erm | 12:12 |
| Kinnison | you wanted a no-trees repo didn't you? | 12:13 |
| mwhudson | for b in `bzr branches`; do ...; done | 12:13 |
| mwhudson | ? | 12:13 |
| Jc2k | eh, i did. and i dont fancy rerunning the conversion on 20gb of svn ;) | 12:13 |
| mwhudson | though bzr branches is a bit funny, if the mailing list be live | 12:13 |
| mwhudson | well, you can create new repos, treeless | 12:13 |
| * Jc2k goes to poke | 12:13 | |
| mwhudson | and pull the branches into them | 12:14 |
| Jc2k | i might just run the conversion again now i have a stable(ish) python-subversion | 12:16 |
| Jc2k | my initial run was a mixture of pulling trunk a 1000 at a time, then running bzr svn-import afterwards to get branches | 12:16 |
| Jc2k | so my trunk has tree, and the branches don't | 12:17 |
| * Jc2k shrugs | 12:17 | |
| lifeless | beuno: first it searches for Robert | 12:17 |
| lifeless | beuno: then it searches for terms begginning with C | 12:18 |
| lifeless | beuno: and for any term that begins with C, removes it from the result set _unless_ it turns up in one of the documents that the search for Robert found | 12:18 |
| lifeless | beuno: or in english, it only suggests things beginning with C that are relevant to things matching Robert | 12:19 |
| beuno | lifeless, ah. Sounds advanced for such a inocent search | 12:20 |
| beuno | but very cool to have | 12:20 |
| lifeless | well I figured there was no point suggesting something, if they were to put it in and get no results back | 12:20 |
| beuno | maybe that could be clearer on the UI, adding on top "All results for 'Robert' also containing 'C'" | 12:21 |
| beuno | s/containing/begin with | 12:21 |
| beuno | but of course, I'm getting picky | 12:22 |
| lifeless | sure, see the commit saying 'crap ui' or something similar :P | 12:22 |
| beuno | heh, yes. I may give that some lovin as soon as get it properly working in LH | 12:23 |
| lifeless | I would say | 12:23 |
| lifeless | "Suggestions for terms starting with 'C' and matching [('Robert',)]" | 12:23 |
| lifeless | (in the absence of nice query print-outs | 12:24 |
| lifeless | or something like that | 12:24 |
| beuno | yes, that works better | 12:24 |
| weigon_ | how can I read back the property added by "bzr commit --fixes ... " ? | 12:32 |
| weigon_ | up to now I only saw it in bzr-gtk | 12:32 |
| jelmer | launchpad will also recognize it | 12:33 |
| jelmer | and the API exposes it, of course | 12:33 |
| jelmer | I don't think there's anything in the command-line UI that exposes it atm | 12:33 |
| weigon_ | is it exposes as bzr <command> somehow ? | 12:33 |
| weigon_ | I would like to see it as part of bzr log --long | 12:34 |
| james_w | I don't believe there is | 12:35 |
| james_w | I think there was some work to expose it there, but I don't know where it got to | 12:35 |
| awilkins | What do y'all bzr vets think of bug #240910 ? | 12:37 |
| ubottu | Launchpad bug 240910 in bzr "ChrootServer cannot serve "root" of windows filesystem." [Undecided,New] https://launchpad.net/bugs/240910 | 12:37 |
| lifeless | it would be good to serve repositories on C and D simultaneously | 12:38 |
| lifeless | though, given you expose the whole FS, is it a good idea ? :P | 12:38 |
| awilkins | Not a good idea no, my beef is more with the sshd support being restricted to C:\ | 12:39 |
| lifeless | oh, clear bug, must fix | 12:39 |
| awilkins | Cygwin sftp works ok, as long as you use the /cygdrive/ roots | 12:40 |
| awilkins | So it's not a total showstopper, but obviously "smart" is intended to be the best game in town | 12:40 |
| awilkins | I think LocalTransport supporting "None" as a base would possibly work, but I'm not knowledgeable enough to know how many disasters that would cause in the rest of the code :-) | 12:44 |
| lifeless | mmm, file:// should be the root | 12:53 |
| lifeless | for unix file:/// is /, forwindows file://C|/ is, IIRC the mangling folk do correctly | 12:54 |
| Kinnison | Is there a way to usefully get (in shell) the list of associated branches for a given branch? | 12:54 |
| lifeless | info | 12:54 |
| awilkins | lifeless: Problem is that something in there resolves "/" to "file:///c:/" as the base of the LocalTransport for "/" | 12:54 |
| lifeless | yes, bug :) | 12:54 |
| lifeless | its probably related to CWD | 12:55 |
| Kinnison | lifeless: sorry. Is there a way to get the information in a form which is useful for shell scripts? | 12:56 |
| Kinnison | E.g. I'm imagining something like 'bzr get-related --parent [LOCATION]' | 12:58 |
| awilkins | lifeless: I thought the root of the problem might be in urlutils._win32_local_path* | 12:58 |
| awilkins | One emits the drive path for '/', the other chokes on a bare file:// uri | 12:58 |
| lifeless | Kinnison: not so much, no. perhaps a trivial python helper ? | 12:59 |
| lifeless | awilkins: I'm not sure, and its 10pm :) | 13:00 |
| Kinnison | lifeless: Hmm, that's about as far as I had gotten. Aah well. I might go for refactoring bzrlib.info so that it can output all the info as a series of shell assignments or something similar | 13:00 |
| Kinnison | lifeless: having bzr info --shellvars would be handy | 13:00 |
| awilkins | lifeless: I shall hack my bzrlib about a bit longer then give up :-) | 13:00 |
| awilkins | (for the afternoon, anyway) | 13:01 |
| lifeless | Kinnison: sure, you know the drill :) | 13:01 |
| Kinnison | lifeless: aye, but 'tis lunchtime now | 13:01 |
| * Kinnison waves | 13:01 | |
| mtaylor | mwhudson: I wound up using that code you pasted for me. works like a champ | 13:06 |
| mtaylor | mwhudson: not the world's _quickest_ mechanism... but it doesn't crash, which is a big improvement | 13:06 |
| awilkins | lifeless : I think special cases for "file://" and '/' in urlutils fixes that bug | 13:33 |
| awilkins | Just running the test suite. | 13:33 |
| awilkins | 22/11041 (god this laptop is wslow0 | 13:33 |
| mwhudson | beuno: if you get the chance, can you take a look at wsgi-ify? | 13:34 |
| mwhudson | i think it's pretty much ready to merge once zpt.cleaner_urls gets in | 13:34 |
| * mwhudson goes to bed | 13:35 | |
| lifeless | gnight all | 13:42 |
| beuno | mwhudson, yeap, I've been following the commits, but I'll take a look at is as a whole | 14:01 |
| lifeless | beuno: partial reads for suggestions now: | 14:04 |
| lifeless | bzr.dev$ time bzr search -s f > /dev/null | 14:04 |
| lifeless | real 0m0.723s | 14:04 |
| lifeless | user 0m0.628s | 14:04 |
| lifeless | sys 0m0.096s | 14:04 |
| lifeless | vs | 14:04 |
| lifeless | bzr.dev$ time bzr search -s f > /dev/null | 14:04 |
| lifeless | real 0m7.392s | 14:04 |
| lifeless | user 0m6.216s | 14:04 |
| lifeless | sys 0m0.368s | 14:04 |
| beuno | ah, going to be interesting to see that commit | 14:05 |
| beuno | lifeless, does that improvement hold on smaller repos? | 14:05 |
| beuno | it's very fast as-is, can't imagine now | 14:06 |
| lifeless | beuno: its pushing now | 14:09 |
| lifeless | k, revno 40 is up | 14:10 |
| lifeless | seems to be slightly faster, yes | 14:11 |
| lifeless | on bzr search itself | 14:11 |
| * beuno reads through the diffs | 14:11 | |
| lifeless | 0.533 vs 0.510 seconds :P | 14:12 |
| beuno | ah, copied over some stuff from bzr and played with that | 14:13 |
| beuno | cool | 14:13 |
| beuno | > 1 sec is very good on a repo the size of bzr | 14:14 |
| beuno | even for web :) | 14:14 |
| lifeless | > 1 sec is easy to satisfy :P | 14:14 |
| lifeless | < 1 sec is good :P | 14:14 |
| LarstiQ | just throw in a time.sleep(1)! | 14:14 |
| lifeless | hi LarstiQ | 14:14 |
| LarstiQ | hey lifeless | 14:15 |
| beuno | don't mention sleep please :/ | 14:16 |
| jam | beuno: how about duermo | 14:16 |
| lifeless | look after yourself man | 14:16 |
| lifeless | don't burn out! | 14:16 |
| lifeless | jam: beuno forgot to sleep | 14:16 |
| jam | morning lifeless | 14:16 |
| lifeless | hi jam | 14:16 |
| jam | of course, you're one to talk :) | 14:17 |
| jam | and, considering I was up until >1am last night, so am I | 14:17 |
| lifeless | oh, I get crabby and shitty when I don't sleep enough | 14:18 |
| lifeless | its all smoke n mirrors | 14:18 |
| lifeless | beuno: your demo is down again :P | 14:18 |
| james_w | hi jam | 14:18 |
| beuno | lifeless, that's because I came to the office :) | 14:18 |
| lifeless | beuno: ah | 14:18 |
| jam | morning james_w | 14:18 |
| lifeless | beuno: well, show jam, hopefully he will ooh and aah too :) | 14:19 |
| jam | lifeless: Oh, I agree. Though normally it is the day *after* I don't sleep well | 14:19 |
| jam | so if I fail to sleep on Tues night, I'm crabby on Thurs | 14:19 |
| beuno | lifeless, http://intranet.pentacorp.net:8080/bazaar/bzr_garbage/changes | 14:19 |
| jam | Wed I'm still running on adrenaline :) | 14:19 |
| lifeless | yah | 14:19 |
| beuno | howdy jam | 14:20 |
| lifeless | jam: check the search widget in that url out | 14:20 |
| jam | yeah, the partial match is pretty cool | 14:20 |
| jam | and interactive | 14:20 |
| jam | though having it show ('foo',) is a bit... odd :) | 14:20 |
| lifeless | jam: 'make it work' :) | 14:21 |
| jam | conceptually very cool beuno, nice work | 14:21 |
| beuno | I have something prettier in store, it will just take a day or two | 14:21 |
| jam | now you just need to clean it up, put it in a drop down, etc | 14:21 |
| jam | but first, you need to sleep :) | 14:21 |
| beuno | heh | 14:21 |
| beuno | well, I'm going to ignore the fact I didn't sleep, so I can get back on a normal schedule | 14:22 |
| beuno | so I'll probably make less sense as the hours go by | 14:22 |
| lifeless | well | 14:22 |
| lifeless | I'll go now to avoid the ugliness ;) | 14:22 |
| lifeless | gnight everyone | 14:22 |
| beuno | heh | 14:23 |
| beuno | g'night lifeless | 14:23 |
| jam | sleep tight lifeless | 14:25 |
| adam_vollrath | Heylo, quick question. What's the Bazaar Windows client equivalent to TortoiseSVN/CVS? Or any other Windows client? | 15:07 |
| vila | markh: ^ | 15:09 |
| Jc2k | adam_vollrath: i dont know anything about it, but i just found this: http://bazaar-vcs.org/TortoiseBzr | 15:10 |
| vila | that's the one | 15:10 |
| adam_vollrath | ah, I should've googled. Thank you. | 15:10 |
| pygi | adam_vollrath, I'd suggest using Olive, I think it works better, i.e. TortoiseBzr is still not finished | 15:42 |
| === gour_ is now known as gour | ||
| Tsmith | so! I have made copious changes to my branch; how can i diff this to the trunk? | 16:25 |
| james_w | Tsmith: "bzr diff -r ancestor:submit:" may get you what you want. | 16:26 |
| james_w | also "bzr send -o- | less" | 16:26 |
| Tsmith | what's submit? | 16:26 |
| james_w | the "submit" branch | 16:27 |
| james_w | it's what send defaults to. | 16:27 |
| james_w | it falls back to the parent if one isn't defined | 16:28 |
| Tsmith | -o- | less worked | 16:28 |
| jam | james_w: you don't need "ancestor:submit:" submit: implies ancestor: | 16:28 |
| james_w | ah, ok, so "diff -r submit:" will give you the same as the preview in the merge directive? | 16:29 |
| jam | james_w: if it doesn't, let me know :) | 16:30 |
| jam | you could also use "cd trunk; bzr merge --preview ../feature-branch" | 16:30 |
| jam | that will also show conflicts, etc | 16:30 |
| jam | which may be good/bad | 16:30 |
| Tsmith | i get 2 diff things w/ diff -r submit: and -o- less | 16:30 |
| james_w | can you see what the differences are? | 16:31 |
| Tsmith | that's waht i'm trying to find out | 16:32 |
| james_w | i.e. is one including trunk changes? Is one using an older base revision? | 16:32 |
| Tsmith | bzr merge preview is terribly messed up | 16:39 |
| Tsmith | it creatse a 19,895 line diff compared to the other 600 line one | 16:39 |
| Tsmith | nevermind | 16:40 |
| Tsmith | trunk was really out of date ;p | 16:40 |
| yacc | Any way to get bzr stat to report the relative paths of files, when running bzr stat .? => currently the output of bzr stat needs manual cutting off the unneeded prefix when selective commiting files. | 17:24 |
| james_w | yacc: I don't know of one, there's a bug open saying that paths should be relative somewhere | 17:36 |
| gour | what is eta for 1.6? | 17:36 |
| yacc | james_w, so my best guess is, when the pulse of my life slows down again to write a plugin that copies stat and monkey patches it to provide a relstat command, I guess. | 17:37 |
| james_w | yacc: or write a patch to bzr that makes stat use relative paths? | 17:38 |
| yacc | well, I have no idea if that's what everyone wants to have. | 17:38 |
| yacc | :) | 17:38 |
| yacc | james_w, anyway, till now I just managed to write one plugin that does not meddle with bzrlib, it does only monkey patch some of the standard python modules as needed ;) | 17:39 |
| james_w | it should at least be an option I think, so it would be great to have a patch to core. | 17:40 |
| james_w | https://bugs.edge.launchpad.net/bzr/+bug/30159 | 17:41 |
| ubottu | Launchpad bug 30159 in bzr "paths are always from root of branch" [Low,Confirmed] | 17:42 |
| yacc | james_w, ~jdobrien/bzr/bugfix (New) - Fix In Progress | 17:43 |
| james_w | yacc: "In Progress" is actually a little generous for that branch it seems. | 17:45 |
| yacc | james_w, yeah, but the last message applies to me too :( | 17:46 |
| === _thumper_ is now known as thumper | ||
| === mw is now known as mw|food | ||
| === kiko is now known as kiko-phone | ||
| === kiko-phone is now known as kiko | ||
| === kiko is now known as kiko-phone | ||
| === kiko-phone is now known as kiko | ||
| === mw|food is now known as mw | ||
| Jc2k | does git have any equivalent to git gc --prune --agressive ? | 21:32 |
| Jc2k | (not sure if gc is the right command..) | 21:32 |
| Jc2k | yeah, git-gc | 21:33 |
| james_w | you mean does bzr? | 21:34 |
| Jc2k | whoops, yeah | 21:34 |
| Jc2k | jeez, is not even 10pm yet :) | 21:34 |
| james_w | no, it doesn't unfortunately | 21:35 |
| james_w | I think there was a plugin to do something similar, but it was plastered with big scary labels. | 21:35 |
| Jc2k | i see | 21:35 |
| Jc2k | at the moment, my bzr mirror of gnome takes 34gb and my git mirror takes 6gb.. | 21:36 |
| james_w | have you done "bzr pack"? | 21:36 |
| Jc2k | no, i think thats what im looking for | 21:36 |
| james_w | also "find . -name obsolete_packs -type d | xargs du -skh" | 21:37 |
| james_w | it doesn't do as much as "git gc --prune --aggressive", it's like "git pack" | 21:37 |
| james_w | however, the gc won't do much if anything on these mirrors. | 21:38 |
| james_w | as it removes unreferenced objects, and you will only get them after rebases and the like, simply mirroring stuff shouldn't cause that. | 21:38 |
| LeoNerd | Or uncommit | 21:39 |
| Jc2k | i see | 21:39 |
| LeoNerd | I quite often uncommit | 21:39 |
| LeoNerd | I've been known to have four attempts at a commit, before the fifth one finally sticks :) | 21:39 |
| Jc2k | the disturbing thing about Git in GNOME is that so many of the strong supporters use it in weird ways. i've not found a consistent story for making a git "mirror". | 21:40 |
| Jc2k | there are at least 2 documented hacky scripts, neither of which seem to work | 21:41 |
| Jc2k | where as bzr svn-import <PATH TO REPO> just works | 21:41 |
| ToyKeeper | Heh, simplicity isn't really one of git's priorities. :) | 21:44 |
| Jc2k | its not really the simplicity, its the fact that i can't find a consistent story | 21:44 |
| Jc2k | when i asked one group about their use of git-svn they didnt even realise it could do a full clone of branches and tags and all | 21:45 |
| mwhudson | morning | 21:46 |
| Jc2k | anyway, bath whilst bzr repacks things :) | 21:46 |
| Jc2k | morning mwhudson | 21:46 |
| psycoman | hoe can i make a diff with my local brach and the branch in launch pad ? | 21:48 |
| psycoman | my branch was created from the launchpad branch | 21:49 |
| Verterok | psycoman: try with: bzr diff -r branch:<your_lp_branch> | 21:56 |
| Verterok | psycoman: if you want to only see the new revisions, you should use: 'bzr missing' | 21:57 |
| psycoman | Verterok: like this ? bzr diff -rbzr diff -r lp:~yurimalheiros/textflow/0.3.x | 22:03 |
| psycoman | bzr diff -r lp:~yurimalheiros/textflow/0.3.x | 22:03 |
| Verterok | psycoman: bzr diff -r branch:lp:~yurimalheiros/textflow/0.3.x | 22:06 |
| === mario_ is now known as pygi | ||
| Jc2k | james_w: after just bzr pack, it now takes up 10gb more space :D | 23:02 |
| mwhudson | that'll be all the obsolete_packs i guess | 23:03 |
| james_w | Jc2k: yeah, check for obsolete_packs directories and purge them. | 23:03 |
| Jc2k | kk | 23:03 |
| bkor | Jc2k: bzr pack --i-mean-it | 23:04 |
| Jc2k | fun :) | 23:06 |
| * Jc2k is sad its not real :( | 23:07 | |
| Jc2k | james_w: its totally safe to clobber all obsolete_packs folders? | 23:08 |
| james_w | Jc2k: they're there as a backup in case something went wrong with the pack. | 23:08 |
| mwhudson | after the pack has finished, yes | 23:08 |
| Jc2k | i see | 23:08 |
| james_w | they'll be deleted at the next pack anyway. | 23:08 |
| Jc2k | ah cool | 23:08 |
| james_w | I think it's mostly insurance against disk syncs anyway. | 23:09 |
| james_w | or rather things going bad while the data is still being written out. | 23:09 |
| bkor | why not delete it right away instead of waiting for the next time? | 23:13 |
| james_w | not sure, ask lifeless | 23:13 |
| Jc2k | i dont think that helped much :( | 23:20 |
| Jc2k | well, its about the same as before i started | 23:20 |
| james_w | that's not good | 23:20 |
| james_w | There was an allegation that bzr-svn creates large repositories, but I never saw any evidence to back it up. | 23:21 |
| james_w | I'm sure lifeless will be interested in investigating this though. | 23:21 |
| Jc2k | james_w/lifeless/jelmer: 33GB of rich-root-pack bazaar repos from 20GB of SVN (vs about 6gb of git FWIW) | 23:26 |
| Jc2k | james_w/lifeless/jelmer: this is after a bzr pack and deleting obselete packs from each modules .bzr/repository folder | 23:27 |
| james_w | git has the same data? | 23:27 |
| james_w | i.e. all the same branches? | 23:27 |
| mwhudson | bzr-svn creates long revision and fileids, which are stored uncompressed in the indices | 23:28 |
| Jc2k | james_w: yes | 23:29 |
| fullermd | I don't think pack does much [any] additional compression or such. | 23:40 |
| fullermd | It just builds up larger pack files. | 23:41 |
| Jc2k | these are the figures i have: | 23:43 |
| Jc2k | x469yq@isshin:/srv$ du -s -m bzr/ | 23:43 |
| Jc2k | 33567 bzr/ | 23:43 |
| Jc2k | x469yq@isshin:/srv$ du -s -m svn/ | 23:43 |
| Jc2k | 25468 svn/ | 23:43 |
| Jc2k | x469yq@isshin:/srv$ du -s -m git/ | 23:43 |
| Jc2k | 6228 git/ | 23:43 |
| Jc2k | those folders should be roughly equal.. | 23:43 |
| Pieter | bzr blows up even larger than git? | 23:46 |
| Pieter | eh | 23:46 |
| Pieter | svn | 23:46 |
| Jc2k | i'll try recreating one of the larger repositories in the morning to make sure its not a side effect of anything i've done | 23:51 |
| awilkins | I found that it made large revisions when it was getting the branching scheme wrong | 23:52 |
| awilkins | ie. for my 120MB tree, some revisions were an extra 120MB because it thought they were not a branch. | 23:53 |
| Jc2k | interesting | 23:53 |
| awilkins | The effect was particularly profound on this tree becuase the tree is large with respect to the size of the history | 23:54 |
| awilkins | I'm not sure how easy it would be to spot if you were't watching for it (branching the trunk, then watching the repo as you do branches) | 23:55 |
| Jc2k | hmm | 23:56 |
| awilkins | In an SVN repo, you can tell the size of each revision because they are in seperate files | 23:56 |
| Pieter | Jc2k: how many commits does that repo have? | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!