| jam | lifeless: I've been working on a lazy revno mapper, which seems to work well (sometimes) | 00:00 |
|---|---|---|
| jam | I'm considering ways to refine it | 00:00 |
| lifeless | jam: is it in bzr.dev? | 00:00 |
| jam | lifeless: the *code* is in a branch (not a plugin) | 00:00 |
| fullermd | Has anybody noticed a regression in permissions in the repo? | 00:00 |
| jam | And I'm planning on submitting it for review | 00:00 |
| lifeless | jam: ok | 00:00 |
| jam | though I might still want to tweak it a bit | 00:00 |
| jam | I don't have power at home right now | 00:00 |
| jam | but | 00:01 |
| lifeless | jam: I have two use cases that I don't think will work well.. | 00:01 |
| lifeless | tags and search | 00:01 |
| jam | http://bzr.arbash-meinel.com/1.6-dev/lazy_revno when I do | 00:01 |
| fullermd | Hm. There is. | 00:01 |
| lifeless | both tend to grab data from fairly evenly distributed bits of the graph and then want a revno for it | 00:01 |
| jam | lifeless: sure, but you can still do it with local ops | 00:01 |
| jam | instead of traversing the whole graph | 00:01 |
| jam | lifeless: at the moment, the time is strictly dominated by 'get_parent_map' calls o | 00:02 |
| jam | on my pack repo | 00:02 |
| poolie | jam, spiv, igc, call in a sec | 00:02 |
| Necoro | lifeless: found the commit in the kernel - and the workaround | 00:02 |
| lifeless | jam: right, I agree that you can examine less than whole | 00:02 |
| jam | so I'm trying to find ways to minimize "leaks" | 00:02 |
| * fullermd files a bug. | 00:03 | |
| lifeless | jam: but on a 100K tree getting to the root is still what - 20K operations vs 1 for a tag name retrieval and <variable-but-small> for a search result | 00:03 |
| jam | lifeless: I don't need to get to root | 00:04 |
| jam | lifeless: just to the common ancestor | 00:04 |
| lifeless | sure | 00:04 |
| lifeless | my point is that unlike merges or 'log' these two operations tend to throw stuff up at or near root routinely | 00:05 |
| jam | for example, 45ms for 3512.2.4 | 00:06 |
| jam | lifeless: i can see your point | 00:06 |
| lifeless | how long for '3' ? :) | 00:06 |
| jam | running timeit now | 00:08 |
| lifeless | for extra credit, how long cold cache | 00:08 |
| jam | 936ms on the pack repo | 00:08 |
| * fullermd arrogantly assigns it 'critical' status. | 00:08 | |
| james_w | you got an alogrithm that didn't have to find root? neat. | 00:11 |
| james_w | or maybe I had that, I forget | 00:11 |
| james_w | at least yours works :-) | 00:12 |
| jam | james_w: no, I started from scratch :) | 00:12 |
| jam | lifeless: 617ms with a fully packed repo | 00:12 |
| lifeless | jam: not the common case :) | 00:12 |
| jam | as I mentioned, dominated by the get_parent_map time | 00:12 |
| lifeless | might want to try on a btree repo | 00:12 |
| jam | sure, something to do later | 00:13 |
| jam | family time in the dark for now | 00:13 |
| jam | :) | 00:13 |
| lifeless | wheee | 00:14 |
| jam | lifeless: unpacked btree repo is 787ms versus 936ms for pack-0.92 | 00:19 |
| lifeless | good | 00:20 |
| elmo | jelmer: dh_python: Doing nothing since dh_pycompat exists; dh_pysupport or dh_pycentral should do the work. You can remove dh_python from your rules file. | 00:30 |
| jelmer | elmo: Yeah, I noticed that as well. I need to look into avoiding that warning when using cdbs. | 00:31 |
| elmo | jelmer: both uploaded | 00:33 |
| jelmer | elmo: Thanks, much appreciated! | 00:33 |
| Peng_ | Hmm, to follow the usual schedule, I think 1.6 final should've been released shortly after 1.6b2. | 00:39 |
| Peng_ | The new smart protocol would've been the most interesting new feature. | 00:40 |
| evarlast | JFYI over here, we are in no rush for 1.6. | 00:45 |
| evarlast | release early release often is great, but BZR has been meeting our needs since 1.0. | 00:45 |
| jelmer | spiv, any chance of having the smart server support upgrade for 1.7? | 00:48 |
| Peng_ | evarlast: Sure, but pushing the release back constantly to support large new features isn't very good. | 00:49 |
| dato | Peng_: and how many times has that been done in bzr? | 00:53 |
| spiv | jelmer: there's a patch on the list for that, so that probably will happen. | 00:55 |
| spiv | jelmer: I should say it will happen, I just don't want to cram yet another thing into 1.6 :) | 00:56 |
| meteoroid | if there are no branches or tags, only a trunk/, for an svn repo, will that fudge up the recognition of branching pattern of an svn-import ? | 00:57 |
| jelmer | spiv: W00t, hadn't seen that one :-) | 00:58 |
| jelmer | spiv, It would be nice to have that in 1.6 actually now that it has started whining when branches are in an old format | 00:59 |
| * meteoroid wonders if there are ebuilds for 1.6 | 00:59 | |
| jelmer | meteoroid, that should work fine | 00:59 |
| meteoroid | jelmer: phew, i get so tired of creating empty branches and tags when svn cp will (i think) create them | 00:59 |
| meteoroid | i read somewhere that rename doesnt work when performed in bzr and pushed to svn, is that true? anything i should be sure to do from svn instead of bzr? | 00:59 |
| Peng_ | dato: Hmm, 0.15 was in the RC stage for a month. | 01:00 |
| meteoroid | i am basically using bzr as much as i can to interface with these tortoise users ;d | 01:00 |
| spiv | jelmer: by "support" I just mean "works over vfs operations" rather than "performs the upgrade server-side". | 01:00 |
| jelmer | meteoroid, no, rename works fine | 01:01 |
| meteoroid | awesome | 01:01 |
| jelmer | meteoroid, renames done from svn aren't pulled into bzr ok | 01:01 |
| meteoroid | oh, really? | 01:01 |
| jelmer | meteoroid, since svn doesn't support proper renames | 01:01 |
| meteoroid | what happens? | 01:01 |
| jelmer | meteoroid, only copy + delete | 01:01 |
| meteoroid | really? lame. | 01:01 |
| meteoroid | bad svn | 01:01 |
| jelmer | spiv: Ahh, ok | 01:03 |
| jelmer | spiv: I was hoping for running it server-side | 01:03 |
| meteoroid | so, i tried to follow the tutorial for setting up rw webdav for my bzr repos, but when i start apache, i get: Unknown DAV provider: filesystem | 01:06 |
| meteoroid | glad to post the virtualhost in question | 01:06 |
| meteoroid | using ubuntu hardy - maybe i only have dav_svn, and not dav_normal ? | 01:06 |
| meteoroid | cant find a package indicative of such support.. | 01:07 |
| markh | jelmer: what does the numeric 2nd argument in a SubversionException indicate? | 01:38 |
| markh | an svn error code? | 01:38 |
| jelmer | markh: Yep | 01:38 |
| * markh tries grepping... | 01:38 | |
| === mw is now known as mw|out | ||
| jelmer | markh: What error code are you seeing? | 01:40 |
| markh | 175002 pulling the python trunk - but only after a long time, so its possible it was transient. I'm retrying now | 01:40 |
| markh | retrieving revision 462 or 40113 now - it will be a while if it works :) | 01:41 |
| markh | of | 01:41 |
| meteoroid | jelmer: what does renaming in svn do to the bzr copy? | 01:42 |
| jelmer | markh, 175002 is SVN_RA_DAV_ERROR IIRC | 01:44 |
| jelmer | markh, In other words "Something went wrong talking webdav" | 01:44 |
| jelmer | meteoroid: Renaming in svn basically means the file appearing to be deleted and readded under a different name in bzr | 01:44 |
| markh | thanks - I'll see how the new attempt goes. But at around 1 revision every 2 seconds, it will be many many hours :( | 01:45 |
| jelmer | you may want to obtain a local copy of the svn repo | 01:45 |
| markh | or just pick a smaller one - it seemed a convenient one to test :) | 01:46 |
| pollelu | hello | 01:50 |
| pollelu | i have a big problem with bzr | 01:50 |
| pollelu | pollelu@confino:~/rapache-icons$ bzr push lp:~rapache-devel/rapache/design | 01:51 |
| pollelu | Agent admitted failure to sign using the key. | 01:51 |
| pollelu | Permission denied (publickey). | 01:51 |
| pollelu | bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) | 01:51 |
| pollelu | pollelu@confino:~/rapache-icons$ | 01:51 |
| pollelu | some idea? | 01:51 |
| james_w | Agent admitted failure to sign using the key. | 01:51 |
| james_w | you are on Intrepid? | 01:52 |
| pollelu | yes | 01:52 |
| james_w | that's a problem with gnome-keyring and/or seahorse | 01:52 |
| pollelu | Im working in intrepid | 01:52 |
| james_w | running "ssh-add" should fix it | 01:52 |
| pollelu | ok thanks | 01:52 |
| pollelu | thanks Master of BZR, my problem is now solved :) | 01:54 |
| meteoroid | jelmer: ok not a big problem just ugly change history and loss of ancestry :/ | 01:55 |
| jelmer | meteoroid, yep | 01:56 |
| jelmer | meteoroid, hopefully bzr will support file copies at some point | 01:56 |
| jelmer | lifeless, wecanhas pathtokens? | 01:57 |
| * meteoroid hopes with his crossed fingers | 01:59 | |
| gambler | Verterok, did u end up releasing that new version? | 02:00 |
| Verterok | gambler: Hi, I'm struggling with a concurrency bug... | 02:01 |
| Verterok | so, not yet...but trying to get this fixed so it can be "usable" | 02:02 |
| gambler | Verterok, ok no rush, let me know when to test | 02:03 |
| Verterok | gambler: sure, thanks! | 02:03 |
| gambler | :S | 02:03 |
| Verterok | gambler: I'll try to (at least) seed a "unofficial" build ;) | 02:04 |
| gambler | no rush :) | 02:04 |
| Odd_Bloke | jml: Thanks for the review. :D I've scanned through it and will sit down and deal with it properly tomorrow. | 02:05 |
| lifeless | beautiful : http://www.etsy.com/view_listing.php?listing_id=12792904 | 02:11 |
| markh | Sorry for the length :) I'm a little confused about merging. I've 2 branches, one a pristine copy of the upstream branch (.dev), and another .work branch, branched from the local .dev branch. The branches diverged for a while, but as the changes landed upstream, and therefore in the .dev branch, all were merged successfully and the branches now appear identical. However, every time I attempt to re-pull .work from .dev, it fails telling | 02:57 |
| lifeless | markh: has your local branch been fully merged by bzr.dev? | 02:59 |
| lifeless | markh: bzr missing will tell you | 02:59 |
| markh | lifeless: ah, no - it says I have 3 extra ones. | 03:00 |
| markh | but they are all merges :) | 03:01 |
| markh | It says I'm missing 4, but I think they are the ones I'm yet to merge-commit from .dev. (The branches in question are actually bzr-svn ones) | 03:01 |
| lifeless | so if you only have extra merges; you can pull --overwrite | 03:02 |
| markh | ah - right - and that well "re-converge" them? | 03:04 |
| markh | will | 03:04 |
| lifeless | it will discard your extra commits | 03:06 |
| markh | by "extra" you mean the merges I had to make? | 03:12 |
| jml | Odd_Bloke: my pleasure. | 03:20 |
| lifeless | markh: yes | 03:24 |
| markh | I guess its conceptual - help for '--overwrite' tells me it will let me forget local changes - but from my POV I don't have any local changes - the branches seem "identical". So once branches have diverged, --overwrite is the only way to "reconverge" them? | 03:29 |
| lifeless | markh: or to have your branch merged into bzr.dev | 03:36 |
| lifeless | markh: an older version of your branch was merged; but you have made subsequent changes that were not merged | 03:36 |
| lifeless | markh: when you do 'commit' you are recording a change | 03:37 |
| markh | yeah, or changes that were tweaked etc before being applied | 03:38 |
| spiv | markh: "changes" is perhaps a confusing term. There can changes to content, but there can also be different revision histories without having different content. If you don't care about the history differences (and it sounds like you don't, given that they are just trivial merges), then you can use --overwrite to replace your branch with a copy of trunk. | 03:39 |
| markh | yeah, I understand now, thanks. It seemed like I was forever doomed to merge/commit cycles on that branch which seemed insane :) | 03:39 |
| markh | spiv: yeah, casual reading made me assume it was simply a shortcut for reverting changes before pulling | 03:40 |
| igc | hi all | 03:41 |
| spiv | igc: hey! | 03:42 |
| spiv | igc: how's it going? | 03:42 |
| igc | pong lifeless | 03:42 |
| markh | lifeless: thanks for the explanation | 03:42 |
| igc | hi spiv | 03:42 |
| markh | igc: hi | 03:42 |
| igc | hi markh | 03:42 |
| igc | spiv: not so good this week | 03:42 |
| spiv | markh: generally I just wouldn't be keeping branches with no content differences in the first place, though. | 03:42 |
| spiv | markh: thus I never find myself making pointless merge commits that I want to throw away :) | 03:43 |
| markh | spiv: well, although the branches are currently identical, there is a good chance other work will be done, so keeping that .work branch around made sense | 03:43 |
| spiv | igc: I feared as much, you haven't been around much. :( | 03:43 |
| lifeless | so --overwrite says ignore differences | 03:43 |
| markh | igc: that's no good :( You able to keep distracted? | 03:43 |
| lifeless | I think it should be more precise | 03:43 |
| lifeless | igc: :( | 03:43 |
| igc | markh: well I'm sleeping almost continuously | 03:44 |
| igc | I need to head up to the hospital for my daily visit in 15-20 minutes but I thought I'd quickly say hi and skim my 100s of emails before then | 03:46 |
| spiv | igc: we're good at producing emails :) | 03:46 |
| igc | markh: did your changes to setup.py get merged yet? | 03:47 |
| markh | yuck - i hope you can stay positive | 03:47 |
| igc | markh: I volunteered to merge it after tweaks | 03:47 |
| markh | igc: not yet, I haven't got back to reworking that patch yet. I saw that - thanks! | 03:48 |
| igc | markh: just checking you weren't waiting on me | 03:48 |
| markh | nope - thanks - I'll let you know when I am ;) | 03:48 |
| sommer | hey all, I've borked the logs of an LP bzr branch by making changes to a local branch, then merging from lp, then commiting the merge, and finally pushing the changes | 03:50 |
| markh | igc: its not actually a real priority for me to be honest, especially while it appears I will be making the binaries themselves anyway. It wouldn't surprise me to find other tweaks necessary before a 1.6 final... | 03:50 |
| sommer | should I have done a pull instead of merge? | 03:50 |
| sommer | is there a way to restore the logs? | 03:50 |
| * markh lunches... | 03:50 | |
| igc | markh: np | 03:51 |
| sommer | apologies if this isn't the correct place to ask | 03:51 |
| spiv | sommer: this is the right place | 03:52 |
| spiv | sommer: which branch? in what way is it borked? | 03:52 |
| sommer | spiv: https://code.edge.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-intrepid | 03:52 |
| sommer | spiv: basically I overwrote the commit messages of another | 03:53 |
| sommer | spiv: happened in revision 62: http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-intrepid/revision/62 | 03:53 |
| sommer | it's happened before, but I couldn't find the steps to correct it | 03:54 |
| spiv | sommer: I'm not sure what you mean by "overwrote". Are you referring to the revisions by Matthew East visible at http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-intrepid/changes?start_revid=59.1.6 ? | 04:02 |
| sommer | spiv: yes, that's what I mean | 04:03 |
| sommer | spiv: I guess not really overwritten, but if the main branch had them it would be better :) | 04:03 |
| sommer | well I guess they're still there, but the revision number was at something like 67 | 04:04 |
| spiv | sommer: so, the history is correct. The problem is just that the display of revisions at bazaar.launchpad.net isn't as good as it should be. | 04:04 |
| sommer | spiv: yes, is there a way to correct that? | 04:05 |
| spiv | sommer: the revision numbers are specific to a particular branch. When you merge changes from another branch the history will change. | 04:05 |
| spiv | mwhudson: ^ ping? | 04:05 |
| spiv | mwhudson: what happened to showing the authors of merged revisions in loggerhead? | 04:05 |
| sommer | spiv: right, do other projects just use the new revision number then? or is there a preferred way to sync rev numbers? | 04:05 |
| spiv | sommer: why do you care about revision numbers? | 04:06 |
| sommer | spiv: to be honest, *I* don't, but my guess is others may | 04:06 |
| spiv | sommer: or do you just care about giving credit to the right person? | 04:06 |
| sommer | spiv: credit is good to | 04:06 |
| mwhudson | olckS brydcbi-o p.annf jdabi.o yd.p. | 04:07 |
| mwhudson | :) | 04:07 |
| * igc lunch | 04:07 | |
| mwhudson | spiv: so nothing's really changed there | 04:07 |
| mwhudson | spiv: it's been talked about, is all | 04:07 |
| spiv | mwhudson: I'm sure I saw a beautiful mockup at some point :) | 04:08 |
| spiv | mwhudson: ETA for the feature? | 04:08 |
| spiv | sommer: so, to credit the right person, mainly what needs to happen is that Launchpad should be displaying better information in this situation. | 04:08 |
| spiv | sommer: i.e. it sounds like you're doing everything just fine. | 04:09 |
| sommer | spiv: cool, I guess I just wanted to make sure, thanks man | 04:09 |
| spiv | sommer: optionally though, next time you could do "bzr commit --author='A. Nother Person'" when committing a merge, I think that will cause existing Launchpad (and "bzr log", etc) to primarily show that rather than you. | 04:10 |
| mwhudson | spiv: depends on tuit supply | 04:10 |
| mwhudson | spiv: you mean this sort of thing? http://people.ubuntu.com/~mwh/hacked_up_changelog_view_3.png | 04:10 |
| spiv | sommer: (the fact that you committed the revision is still recorded, it just also adds an extra property saying that you say the author is someone else) | 04:11 |
| mwhudson | spiv: or the one that displays a list of committer names where only one name is displayed now? | 04:11 |
| mwhudson | anyway, sprinting | 04:11 |
| spiv | mwhudson: right. | 04:11 |
| spiv | mwhudson: So, +1 from me for doing that one sooner rather than later, FWIW | 04:11 |
| spiv | (which isn't very much, most likely...) | 04:11 |
| mwhudson | spiv: it's probably not that hard for a seasoned bzr hacker! | 04:12 |
| spiv | Heh. | 04:12 |
| lifeless | we should add a ui to set append_revisions_only | 04:15 |
| lifeless | or perhaps make that the default for 'bzr init' | 04:15 |
| lifeless | or something | 04:15 |
| mwhudson | does that prevent uncommit? | 04:20 |
| mwhudson | option "dont_let_user_accidentally_oush_over_non_lh_parent" true | 04:21 |
| lifeless | mwhudson: it does, but we could teach uncommit to ask about overriding it | 04:23 |
| beuno | is it expected that if I run bzr status from outside the branch's dir, the doesn't show the pending merges? | 04:27 |
| beuno | Verterok just bumped into that, and we think it's a bug | 04:27 |
| beuno | mwhudson, I've been eyeballing bug #240542, but I'm not sure what the idea is for start/stop-loggerhead scripts. I get the feeling you want to nuke em | 04:31 |
| ubottu | Launchpad bug 240542 in loggerhead "Provide a description for nesting urls" [Undecided,Confirmed] https://launchpad.net/bugs/240542 | 04:31 |
| mwhudson | beuno: i think i want to ignore them for a while, then delete them | 04:31 |
| mwhudson | beuno: but i can probably be persuaded otherwise | 04:31 |
| lifeless | beuno: you mean 'bzr st foo' where foo is a tree? | 04:31 |
| beuno | mwhudson, I've been thinking about persuading you, but I have less and less reasons to | 04:32 |
| beuno | lifeless, yeap | 04:32 |
| beuno | mwhudson, I do want some sort of global config at some point, but we may want to use serve-branches, and wherever we place it | 04:32 |
| mwhudson | beuno: right, yes, the no-config-at-all approach that serve-branches had clearly isn't going to work in the long term | 04:33 |
| beuno | mwhudson, ok, I'll un-target that bug, if I find out how | 04:34 |
| lifeless | confirmed | 04:34 |
| lifeless | its a bug | 04:34 |
| beuno | Verterok, you won a bug report | 04:35 |
| lifeless | beuno: Verterok: please file a bug; high importance | 04:35 |
| Verterok | lifeless: ok, thanks for confirming it | 04:35 |
| beuno | lifeless, re: bug #248018 | 04:39 |
| ubottu | Launchpad bug 248018 in loggerhead/1.6 "slow search results override fast ones" [High,Confirmed] https://launchpad.net/bugs/248018 | 04:39 |
| lifeless | yes! | 04:40 |
| lifeless | pls fix | 04:40 |
| beuno | I'm thinking about ignoring the you if you type one letter | 04:40 |
| beuno | in addition to fixing the bug | 04:40 |
| lifeless | hmm | 04:40 |
| lifeless | btw | 04:40 |
| lifeless | the 200ms thing confuses people | 04:40 |
| lifeless | can I suggest just requesting at each keystroke | 04:40 |
| beuno | hm | 04:41 |
| lifeless | as long as the best search array so far is whats shown it will be correct, and it give people a hint | 04:41 |
| beuno | I don't think the server will like getting hit so many times | 04:41 |
| beuno | if I take away the timer, then every single keystrole will get sent | 04:42 |
| beuno | I'm pretty sure that's not a good idea | 04:42 |
| lifeless | ok | 04:42 |
| lifeless | well let me describe what I see people do | 04:42 |
| lifeless | they type in a search very quickly | 04:42 |
| lifeless | and hit enter | 04:42 |
| lifeless | they never even realise it can do completion because they don't pause long enough | 04:43 |
| lifeless | so its not discoverable | 04:43 |
| beuno | that's not necessarily a bad thing, if they already know so exactly what they want, it makes sense for the find-as-you type to be ignored, no? | 04:43 |
| lifeless | not when I'm showing people bling | 04:43 |
| beuno | I do agree it's not very discoverable | 04:43 |
| beuno | hahah | 04:44 |
| beuno | ok, we can have a special show-off edition | 04:44 |
| lifeless | even more cool would be word-completing as they type | 04:44 |
| beuno | no timer, and a cube like compiz | 04:44 |
| lifeless | com|mit | 04:44 |
| lifeless | with the | being where the insertion cursor is, and mit being pulled from the completion results | 04:44 |
| beuno | ah, that would be cool | 04:45 |
| lifeless | (this is where completion for exclusion terms is still useful btw) | 04:45 |
| spiv | Even if you don't fire off a query, showing the autocomplete box with a dim "(autocompleting...)" or something in it might be good for discoverability. | 04:45 |
| lifeless | (and this is why I'm saying 200ms is _way_ too long) | 04:45 |
| lifeless | as I type a term in... | 04:45 |
| spiv | so "rapid-type-then-hit-enter" still works, but at least the user gets a signal about the possibility of doing it a different way in the mean time. | 04:45 |
| lifeless | all the results are contained in the first response recieved from the search engine | 04:46 |
| lifeless | the more they type the smaller the response set is all | 04:46 |
| lifeless | when we start doing ranking | 04:46 |
| beuno | spiv, that's already sort of the case. It says "loading" when you start typing | 04:46 |
| lifeless | and doing clipping | 04:46 |
| lifeless | then that may change | 04:46 |
| lifeless | beuno: no it doesn't | 04:46 |
| lifeless | beuno: it says it when you pause, at least for me | 04:47 |
| spiv | For bonus cool: preload the page the with the first N autocompletes for each letter of the alphabet, so you can give instant results! | 04:47 |
| Verterok | beuno, lifeless: done, Bug #255204 | 04:47 |
| lifeless | spiv: indeed, that needs ranking though | 04:47 |
| ubottu | Launchpad bug 255204 in bzr "bzr status doesn't show pending merges when executed outside the branch dir" [Undecided,New] https://launchpad.net/bugs/255204 | 04:47 |
| beuno | lifeless, ah, you're right, it doesn't. It should. | 04:47 |
| spiv | lifeless: well, the ranking could be "the order I plucked these out of the db" ;) | 04:47 |
| lifeless | beuno: anyhow, what I'd *like* is that when I start typing it does in-field completion of the first entry in the completion results | 04:47 |
| beuno | lifeless, I need to handle sessions to be able to contain and trim results before sending the response | 04:48 |
| spiv | lifeless: and the complete results could be retrieved after the 200ms timer or something, if you want that. | 04:48 |
| lifeless | spiv: it is today, but thats not so useful :) | 04:48 |
| spiv | Ranking strikes me as an orthogonal issue. | 04:48 |
| lifeless | beuno: I don't really care about *how* it does this, just that that is what I would like to give our users. | 04:48 |
| spiv | But an important one for making search useful, I agree :) | 04:48 |
| lifeless | beuno: if that sounds nice, we can move on to talking about *how* | 04:48 |
| beuno | lifeless, in-field completion would be cool. Not sure how I would do that with javascript, but I can't think of a reason it wouldn't work | 04:49 |
| beuno | lifeless, it does | 04:49 |
| beuno | I'd really prefer doing clipping on the server side | 04:49 |
| lifeless | beuno: yes, me too | 04:49 |
| beuno | rather than dropping requests on the cliente side | 04:49 |
| beuno | hm | 04:49 |
| lifeless | beuno: erm, terminology :) | 04:49 |
| lifeless | dropping requests is needed because of async nature of the beast | 04:50 |
| lifeless | clipping is about sending less than the full set of results because, or ordering whats sent so that partially-recieved data is maximally useful | 04:50 |
| * spiv enfoodinates. | 04:51 | |
| beuno | lifeless, agreed. The interaction needs a lot of work to be impressive | 04:51 |
| lifeless | spiv: I think ranking is technically orthogonal but not user-experience orthogonal | 04:51 |
| lifeless | beuno: as a thought experiment, whats wrong with requesting on each keystroke? | 04:51 |
| lifeless | in broad terms | 04:52 |
| beuno | lifeless, the server performing one search per character | 04:52 |
| lifeless | beuno: thats all ? | 04:52 |
| beuno | lifeless, yeap, it waists tons of resources | 04:53 |
| beuno | imagine that on Launchpad | 04:53 |
| lifeless | beuno: it will be fine :) | 04:53 |
| lifeless | beuno: so, without being silly | 04:53 |
| lifeless | lets imagine you dedicate a thread to the client | 04:54 |
| lifeless | they ask for ('a',) | 04:54 |
| lifeless | you start a search for completions | 04:54 |
| lifeless | they ask for ('ab',) | 04:54 |
| lifeless | you cancel the first search and start a search for completions for ('ab',) | 04:54 |
| lifeless | etc | 04:54 |
| lifeless | at some point your searches complete faster than their requests come in, and they get completions happening | 04:55 |
| beuno | lifeless, that works fine. The thing is, we currently don't handle sessions in LH, so I can't really do that today | 04:55 |
| beuno | as to remember who requested what, on the server side | 04:55 |
| lifeless | beuno: I'm not sure it needs sessions but I'll defer that to you | 04:55 |
| beuno | I could fake sessions, I guess... | 04:56 |
| lifeless | in fact, all it really needs is a nonce per completion-interaction - the same thing sent in every completion request | 04:56 |
| beuno | and that would solve both our concerns | 04:56 |
| beuno | hrm | 04:56 |
| lifeless | but thats just me being tricky and pointing out that generic sessions are >>> what this needs | 04:57 |
| beuno | that plus inline completion would be magic | 04:57 |
| lifeless | plus arrow down to other completion results | 04:57 |
| lifeless | plus ranking | 04:57 |
| beuno | plus number of results | 04:58 |
| beuno | plus color depending on the depth of the history | 04:58 |
| beuno | or type of result returned | 04:58 |
| lifeless | well completions are interesting, because they are not looking at documents, only terms - most terms I think will show up in most document types eventually | 04:59 |
| lifeless | but sure | 04:59 |
| beuno | you could be looking for a committer's name | 04:59 |
| lifeless | http://gadgetopia.com/autosuggest/ | 04:59 |
| lifeless | that does mouse-into-the-completion-widget | 05:00 |
| beuno | ah, you can go down with your arrow keys | 05:00 |
| lifeless | thought its buggy | 05:01 |
| lifeless | yours is better about handling typing and deletion etc | 05:01 |
| beuno | yeah, it's not very polished | 05:01 |
| lifeless | but I thought you might like to see their code (LGPL!) for the arrow support | 05:01 |
| beuno | lifeless, I do, thanks. I can use parts of that | 05:01 |
| beuno | good thing is, as it stands now, I should be starting full time with Canonical con monday, so I'll have plenty of time to dive into this :p | 05:02 |
| lifeless | congrats | 05:02 |
| lifeless | thats been rather submarine news :) | 05:02 |
| beuno | hahah | 05:02 |
| beuno | yeah, it's not 100% official yet, so no blog post, yadadada, but we worked the remaining issued out today and set a startinf date | 05:03 |
| poolie | hi beuno | 05:03 |
| lifeless | very very cool cool | 05:03 |
| beuno | and thanks, I'm excited | 05:03 |
| beuno | hey poolie | 05:03 |
| lifeless | I wonder if flash is needed to do what we want | 05:05 |
| beuno | god no | 05:05 |
| beuno | we can do this with javascript, just need to bend the rules a little bit | 05:05 |
| beuno | please let's not go anywhere near flash :) | 05:05 |
| thumper | beuno: so what are you going to be focusing on most for canonical? | 05:06 |
| beuno | thumper, it's a bit blurry ATM, but mainly UI on most canonical projects. And, loggerhead :) | 05:06 |
| thumper | beuno: cool | 05:07 |
| thumper | beuno: loggerhead needs some memory love | 05:07 |
| beuno | thumper, yeah, I already have something in the works to work around the "too many changed files" issue | 05:08 |
| beuno | ajax to the rescue | 05:08 |
| thumper | I wasn't aware of the issue | 05:08 |
| thumper | I just know that loggerhead chews up memory | 05:08 |
| thumper | when run for a while | 05:08 |
| beuno | thumper, it times out on some requests | 05:09 |
| beuno | see bug #254892 | 05:09 |
| ubottu | Launchpad bug 254892 in launchpad-bazaar "Cannot view r2704 of ~mysql/mysql-server/mysql-4.1" [Undecided,New] https://launchpad.net/bugs/254892 | 05:09 |
| beuno | of course, we have to do some profiling to find out where the memory hog is today | 05:09 |
| beuno | a *lot* has changed in the past few months | 05:10 |
| mwhudson | iooh right | 05:12 |
| mwhudson | beuno: so on the files listing | 05:12 |
| mwhudson | the revnos link to a 'filtered by fileid' view | 05:12 |
| mwhudson | beuno: this is not good for performance | 05:13 |
| beuno | mwhudson, ah, right, and doesn't really *do* anything, does it? | 05:15 |
| mwhudson | not really | 05:15 |
| mwhudson | feel like fixing it? :) | 05:15 |
| beuno | mwhudson, sure, easy fix. Just link to the revno. I can do that now | 05:16 |
| mwhudson | ta :) | 05:16 |
| beuno | mwhudson, committed!D | 05:21 |
| mwhudson | :) | 05:23 |
| markh | does canonical employ/engage a graphic artist by any chance? | 05:27 |
| beuno | markh, talk to Joey Stanford, we do graphic work for Canonical | 05:28 |
| markh | beuno: is that work gratis? Or do I first need to speak to someone from canonical to approve it? :) | 05:29 |
| lifeless | markh: what do you need? | 05:30 |
| beuno | markh, canonical, approve | 05:30 |
| markh | The windows icon needs lovin, and we need a tortoise ;) | 05:30 |
| lifeless | a pissing chinese tortoise? | 05:30 |
| beuno | markh, just an icon? | 05:30 |
| lifeless | beuno: tbzr | 05:30 |
| markh | and a tortoise ;) But yeah, the couple of existing bzr icons are fairly poor quality and needs transparency plus anti-aliasing etc | 05:31 |
| * beuno looks for the current icon | 05:31 | |
| markh | the .pngs are good, but nothing seems to do an excellent job at converting them to all the various icon sizes and depths | 05:31 |
| beuno | markh, for little amount of work, I can trick someone into doing it for free. For something bigger, you'll need to get approval, etc | 05:32 |
| markh | there is an icon checked into bzr.dev - it lacks transparency and when you try and add it, lack of anti-aliasing shows up | 05:32 |
| markh | The icon at http://bazaar-vcs.org/LogoOptions is transparent, but looks auto converted and is poor at larger sizes, eg Vista | 05:33 |
| markh | oops - actually I don't think it is transparent. Higher color depth IIRC - but neither are really that great. | 05:33 |
| markh | and don't forget the tortoise ;) | 05:34 |
| beuno | markh, so, you need a large transparent bzr png, and a tortoise icon for tbzr? | 05:35 |
| markh | I blew an hour in visual studio etc, but gave up in disgust as usually happens when I try anything like that | 05:35 |
| beuno | markh, http://bazaar-vcs.org/LogoOptions?action=AttachFile&do=get&target=Bazaar+Logo+2006-07-27.svg is an svg (scales to the infinity) with transparent background | 05:35 |
| beuno | what's wrong with that again? | 05:35 |
| markh | beuno: a single .ico file can have a large number of actual icon images. The existing bzr .png files are good, but I'm having trouble getting a single .ico file, with 4 different icon sizes in that file, with high-quality versions of the .png | 05:36 |
| markh | (and depending on how many colors are actually used in the logo, the perfect world would probably have multiple color depths of each of the 4 sizes.) | 05:38 |
| beuno | markh, so, if you can tell me the the sizes that you need, I can get those 4 PNGs done | 05:39 |
| markh | the png files are even the desired size. Its more a matter of the edges of each image needing touching up. A picture is worth a thousand words - what is your email address? | 05:40 |
| beuno | I have no idea how to create a windows icon though | 05:40 |
| beuno | markh, argentina@gmail.com | 05:40 |
| lifeless | btw | 05:41 |
| lifeless | I've been meaning to say kudos to getting that email addy ;) | 05:41 |
| markh | right - whoever we suckered^h^h^h^h^h^hbegged into doing this would need access to a .ico editor. | 05:41 |
| beuno | lifeless, I got an invitation the first day it launched. "beuno" is 5 chars, so no-go, and "martin" was taken by one of the devs. "argentina" seemed like the next "I won't get that later on" choice :) | 05:42 |
| markh | beuno: to be clear, I've already got access to .png files in the desired sizes - just converting them to a transparent windows icon is the issue. | 05:42 |
| markh | every process I've tried requires touching up in the icon editor, which is where I tend to make things worse | 05:43 |
| beuno | markh, ah, ok. So a little bit trickier then I thought. I think only one of the gfx people at work have windows. I'd have to check with them if they know how to do it :) | 05:43 |
| markh | beuno: thanks, it would be great if you could | 05:44 |
| beuno | markh, I'll give it a try tomorrow. Did you send that email? that'll serve me as a reminder :) | 05:45 |
| markh | putting it together now - thanks! | 05:46 |
| beuno | markh, np. And include whatever you can think of for the tortoise icon, I will try and get something done with that too | 05:47 |
| beuno | I kinda want a new icon for LH too, but asking for 2 tortoises for 2 different projects may be a bit odd | 05:47 |
| markh | :) | 05:49 |
| beuno | markh, do you currently have an icon? | 05:49 |
| markh | yeah, I'll send what I have | 05:49 |
| beuno | cool, thanks | 05:50 |
| lifeless | poolie: ping | 05:56 |
| poolie | pong | 05:56 |
| lifeless | up for a short brainstorm? | 05:56 |
| lifeless | two topics, marks and dirstate-locks | 05:57 |
| poolie | hm | 05:57 |
| poolie | maybe later? | 05:57 |
| lifeless | tomorrow then | 05:58 |
| poolie | btw, i read the auto-add thing and i'd agree people could reasonably want them to be separate | 05:58 |
| lifeless | I started at 5am :) | 05:58 |
| poolie | silly twisted boy | 05:58 |
| lifeless | I think there is an argument for them being separable, but there is also a cost | 05:59 |
| lifeless | the status quo is that we have hard to explain behaviour | 05:59 |
| lifeless | whatever we do should make it easier to explain | 05:59 |
| poolie | lifeless, did you make a 1.6 branch? | 06:06 |
| poolie | could you please? | 06:06 |
| lifeless | garh, lynne came and said hi as I got off the phone | 06:08 |
| lifeless | doing now | 06:08 |
| lifeless | done | 06:16 |
| poolie | thanks | 06:21 |
| lifeless | jelmer: what does AOL mean ? | 06:25 |
| poolie | "me too" | 06:27 |
| lifeless | k | 06:28 |
| lifeless | I actually have a thought that we should auto-add-delete by default | 06:28 |
| lifeless | following the line of thought of requiring users to do as little as possible by default | 06:28 |
| poolie | after the habit (when aol was new to the internet) | 06:29 |
| poolie | of their users flooding a thread with "me too" top-posts | 06:29 |
| abentley | lifeless: I think that setting is particularly poor, and making it default wouldn't satisfy those who like auto-remove or those who dislike it. | 06:30 |
| lifeless | abentley: I think that it should be set to the most commonly given value; I don't know what is right now | 06:31 |
| lifeless | default on is easy to explain ('by default we record everything in your tree, no explicit action needed'), and default-off is easy to explain ('by default we record what you have asked us to record') | 06:32 |
| lifeless | default-partly-on is hard to explain and ultimately why that bug was filed in the first place | 06:33 |
| abentley | lifeless: Well, no-auto-anything is relatively safe. I don't like it, but I long ago gave up trying to understand why people wanted it. | 06:34 |
| abentley | lifeless: Auto-everything will cause stuff to be committed that shouldn't be committed, and will cause mvs to be mishandled as add + delete pairs. I consider this actively harmful. | 06:35 |
| lifeless | I can't quite parse that; do you mean that most heuristics have problems of some sort? | 06:35 |
| abentley | Auto-everything will cause stuff to be committed that shouldn't be committed. Because people will leave stuff in their source tree that they don't intend to commit, and then commit. | 06:36 |
| lifeless | abentley: auto-remove causes things to be committed that should be [deletes, not user content] and also has the same problem with add+delete pairs (people reach for add first when they see a delete) | 06:36 |
| abentley | lifeless: Do you mean "should *not* be"? | 06:37 |
| lifeless | yes | 06:37 |
| abentley | lifeless: I don't consider auto-deletion to be as dangerous as auto-addition. Nuclear launch codes. Nuclear waste. ISO images. | 06:38 |
| abentley | Auto-deletion is easy to repair. | 06:38 |
| lifeless | uncommit isn't sufficient? | 06:39 |
| * fullermd agrees. | 06:39 | |
| abentley | Auto-addition can require garbage-collecting your repo. | 06:39 |
| lifeless | so, if I write 'uncommit --gc'? | 06:39 |
| abentley | I don't agree that auto-remove has the same problem with mv. It has a problem, but it is different. | 06:39 |
| poolie | abentley, what kind of thing do you have in your tree? | 06:39 |
| fullermd | If I miss something long enough to commit it, I'm likely to miss it a lot longer, so it's more than GC, it's GC'ing many repos, and other people's code based on it. | 06:39 |
| abentley | poolie: The things in my tree that I don't want to commit are typically patches or callgrind files. Sometimes they're .orig files. | 06:40 |
| fullermd | I've got run logs in my trees all the time. | 06:40 |
| poolie | mm | 06:40 |
| fullermd | (whatever >& out and the like) | 06:40 |
| poolie | i wonder if this really means we should be marking them ignored? | 06:40 |
| abentley | lifeless: uncommit --gc would be nice, but wouldn't make me think that auto-add was a good idea. | 06:40 |
| poolie | i do often have diffs in there but i also think this is a bit dirty | 06:40 |
| abentley | lifeless: Anyhow, auto-all is a default that I would fight against. I wouldn't fight against auto-nothing, if I can unbreak my own configuration. | 06:42 |
| lifeless | abentley: ok. I have replied to the thread breaking the changes down to atoms to be discussed | 06:43 |
| lifeless | the default in the current patch is indeed auto-nothing, because its a more conservative default | 06:43 |
| abentley | poolie: It is a bit dirty, but that's what clean-tree's for :-) | 06:45 |
| poolie | mm | 06:46 |
| poolie | it seems like that almost needs an arch-like concept of patterns of cruft | 06:46 |
| poolie | maybe that belongs in a makefile though | 06:46 |
| lifeless | there is a seperate thread on that | 06:48 |
| lifeless | well, on precious vs ignored | 06:48 |
| lifeless | anyhow, I've said my bit - IMO we're more complex than we should be, and we can be simpler by a number of different possible changes | 06:48 |
| lifeless | I think the most enjoyable to use would probably be the most risky :). [see havoc penningtons unbreakme option rant] | 06:49 |
| lifeless | but I'm not going to push for that today; having the option available is enough of a positive for me today | 06:50 |
| lifeless | bbiab | 06:51 |
| lifeless | back | 07:09 |
| lifeless | RAOF_: ping | 07:09 |
| lifeless | markh: ping | 07:10 |
| markh | lifeless: hi | 07:10 |
| lifeless | whats your opinion about using glib routines in bzr (in terms of windows portability) | 07:11 |
| lifeless | (not glibC, glib - the gnome/gtk+/gimp low level support library) | 07:11 |
| markh | I've no direct experience, but I'd be surprised to find msvc works regularly. I guess it depends on what aspect of portability you are concerned with :) | 07:13 |
| lifeless | http://www.gimp.org/~tml/gimp/win32/downloads.html | 07:13 |
| lifeless | actually | 07:13 |
| lifeless | http://www.gtk.org/download-windows.html | 07:13 |
| lifeless | markh: I'm looking at writing some pure C | 07:14 |
| lifeless | markh: binding that to python separately | 07:14 |
| lifeless | and so I want tool chain you'll be happy supporting for windows builds :) | 07:15 |
| markh | heh - so this is the same thing bzr-gtk needs to bundle? | 07:15 |
| lifeless | e.g. I'm thinking scons as a build system. Not because its good, but because its better than autoconf etc on windows | 07:15 |
| markh | err - bundle on windows I guess. | 07:15 |
| markh | its likely autoconf wouldn't really be needed on windows and that a hard-coded makefile would be ok. There isn't much to "sniff" on Windows | 07:16 |
| markh | isn't there a native alternative to whatever it is you are trying to do? :) | 07:21 |
| matkor | Hi ! If I did bzr "lightweight" checkout of -r l_rev and later bzr upgrade to u_rev, I will be able to browse history see diffs etc in range of revisions from l_rev to u_rev ? | 07:21 |
| lifeless | markh: yes, but guido doesn't want CPython to be fast at the expense of clarity | 07:26 |
| lifeless | matkor: are you asking if bzr remembers what l_rev was for you ? | 07:27 |
| fullermd | You probably could, if update supported -r... | 07:27 |
| matkor | lifeless: I am asking if after after bzr update to u_rev I get no history (it still lightweight checkout) I get part of history (l_rev to u_rev) or full history (0..u_rev) is downloaded | 07:29 |
| poolie | abentley, so from your last mail it looks like it will be ok as long as auto-add is not the default? | 07:30 |
| fullermd | Well, you can't bzr update to u_rev. But if you could, it would presumably do the former (i.e., much the same as if you'd co'd that rev in the first place) | 07:30 |
| abentley | poolie: I will be okay if --auto-remove exists and --auto-add is not the default. | 07:31 |
| abentley | And if --auto-remove causes Bazaar to behave the way it does now wrt --strict. | 07:31 |
| poolie | and would auto-remove as an option to commit be much different to having it available under bzr rm? | 07:31 |
| lifeless | matkor: no history is downloaded locally | 07:32 |
| RAOF_ | lifeless: pong? | 07:32 |
| abentley | poolie: yes. It would be more work and destroy your original vision of how rm could work. | 07:32 |
| lifeless | RAOF_: do you do much C ? | 07:32 |
| poolie | test | 07:33 |
| poolie | test | 07:33 |
| RAOF_ | lifeless: Not much. I'm not totally unfamiliar with it, though. | 07:34 |
| RAOF_ | Much more C# and python. | 07:34 |
| abentley | poolie: I don't know how else to say this. I don't understand why anyone would want no-auto-anything behavior. I think auto-remove is perfect. It has been the default for many years. If it can't remain the default, there should be a way for everyone who is used to it and likes it to preserve it. | 07:34 |
| lifeless | abentley: I don't know why you say it would destroy martins' original vision of bzr rm | 07:35 |
| lifeless | could you enlarge on that ? | 07:36 |
| abentley | lifeless: martin's original vision was that bzr branches could be manipulated as much as possible using standard unix commands. cp -r would perform a branch. rm would delete a file. | 07:36 |
| lifeless | ah, of 'rm' not of 'bzr rm' | 07:36 |
| abentley | mv would move a branch. | 07:36 |
| lifeless | following that logic I would expect touch to add a file | 07:38 |
| abentley | lifeless: I don't think that was seriously contemplated at the baz 1.0 sprint. | 07:38 |
| lifeless | abentley: I don't recally rm being automatic being discussed at that sprint either - but it was a long time ago now | 07:39 |
| abentley | That's certainly how I remember it. May not be true, of course. | 07:40 |
| poolie | well | 07:42 |
| poolie | that was what i had in mind | 07:43 |
| RAOF_ | lifeless: Why were you interested in my Cness? | 07:43 |
| poolie | however, the current situation of auto-remove but not auto add is inconsistent with it | 07:43 |
| lifeless | RAOF_: I'm checking the impact of C support libraries on e.g. gnome and kde friendliness | 07:45 |
| lifeless | RAOF_: and windows | 07:45 |
| lifeless | RAOF_: as I'm planning on doing some C soon but I'm out of date on what libraries are broadly available where. | 07:46 |
| RAOF_ | I understand that glib is both ported everywhere and can make C less of a hassle. | 07:47 |
| lifeless | which reminds me | 07:47 |
| lifeless | fullermd: ^ sameish questions :) | 07:47 |
| lifeless | RAOF_: its more a culture-of-availability than raw can-do that I'm referring to | 07:47 |
| lifeless | if e.g. KDE would turn their nose up at a glib using library | 07:48 |
| RAOF_ | But apart from that, I'm not really up with the library situation, particularly on !gnome. | 07:48 |
| lifeless | yah I'm going to ask riddell too | 07:48 |
| RAOF_ | lifeless: Nah, they wouldn't. | 07:48 |
| fullermd | Well, I don't know anything about the Windows side. But I can't imagine lower-level stuff like glib could matter gnome-vs-kde-vs-whatever. | 07:48 |
| RAOF_ | fullermd: It's got a 'g' in it! | 07:48 |
| lifeless | and | 07:48 |
| fullermd | Heck, I run neither gnome nor KDE, but I've got qt and gtk apps around and working... | 07:48 |
| fullermd | gWindows? :p | 07:48 |
| lifeless | does glib play nice inprocess with kde, for kde apps using this library :P | 07:49 |
| RAOF_ | I'm pretty sure the answer to that is a firm "yes". | 07:49 |
| RAOF_ | I'm sure there's glib/QT mainloop integration somewhere. | 07:49 |
| markh | c++ can make C less hassle too ;) | 07:58 |
| lifeless | markh: yes, but at the cost of being less accessible from C | 08:00 |
| lifeless | so there are several reasons I want to write some plain C | 08:01 |
| lifeless | one is profiling - its easier to gprof a small C test driver than all of python | 08:01 |
| lifeless | another is addressing some of the [somewhat spurious] complaints from hard-core devs that bzr is not written in a language they feel comfortable in | 08:02 |
| lifeless | another is making it a bit easier for folk that are doing LPC calls to be able to get at the core logic | 08:02 |
| * fullermd acks. | 08:03 | |
| fullermd | I'm assuming you mean something different by 'LPC' than I think of... | 08:04 |
| lifeless | local procedure calls | 08:04 |
| fullermd | Too bad. I was getting all sorts of twisted evil grins at the thought of accessing bzrlib from LPC... | 08:05 |
| luks | lifeless: you know that Qt and so also KDE is linked to glib by default, right? | 08:10 |
| luks | so I don't think glib is a problem for anybody on linux | 08:10 |
| lifeless | luks: I didn't, cool | 08:13 |
| luks | it uses glib's mainloop | 08:13 |
| Bronger | Is my observation correct that Bazaar merges without warning into an out-of-date working tree? | 08:15 |
| poolie | Bronger: no, it shouldn't | 08:16 |
| Bronger | Okay, then I'll have a closer look at it again. | 08:16 |
| luks | there is one case where is does, 'bzr up', no? | 08:17 |
| poolie | well | 08:17 |
| poolie | what specifically do you mean by 'merges' | 08:17 |
| poolie | if you do an update or pull it will merge into what you have outstanding in the tree | 08:18 |
| poolie | 'merge' itself should not without --force afaik | 08:18 |
| Bronger | The scenario was as follows: Everything local on my disk, in a repo. Some branches with working trees, and one lightweight checkout that I "switch" between the working trees. I work only on teh checkout, so all branches become out of date over time. But I have to merge the trees from time to time. So I entered one branch, did "merge ../<other-branch>", no errors, no conflicts. Then, I did "bzr update", and I got further changes and conflicts. | 08:22 |
| lifeless | right, update is what did that to you | 08:33 |
| lifeless | which is actually by design, so tht you can merge to a branch which someone else just committed to | 08:34 |
| Bronger | Okay, thank you. Does the order matter? Is merge+update the same as update+merge? | 08:36 |
| luks | Bronger: just to make sure, you did 'bzr commit' after 'bzr merge'? | 08:37 |
| Bronger | No. | 08:37 |
| luks | and merge printed 'Nothing to do' or it did merge something? | 08:38 |
| Bronger | It did something. | 08:38 |
| luks | right, so the pending merges were what causes the problems with bzr update | 08:39 |
| Bronger | Yes. | 08:39 |
| luks | I'm not sure but I think 'bzr merge' followed by 'bzr merge --force' would cause the same problem | 08:40 |
| luks | 'bzr update' is very similar to 'bzr merge' in this case | 08:40 |
| lifeless | Bronger: the order does matter | 08:40 |
| lifeless | Bronger: update + merge - the merge would complain | 08:41 |
| Bronger | The root cause of my questions here is that I found out that a new part of code got lost. Apparently, during a 3-way marge, the *older* part was used. I could recover it, however, I'd like to know whether it can be caused by forgetting to say "update" before a merge, or whether I just resolved a conflict wrongly (which may well be the case ;-). | 08:41 |
| lifeless | Bronger: 3-way chooses the odd-side out, if both sides are different it conflicts | 08:41 |
| luks | Bronger: hm, you had local changes in the working tree? otherwise there is nothing to lose | 08:42 |
| luks | generally, to merge the branches and keep the working tree updated you want: 'bzr merge <something>', 'bzr commit' to commit the merge, 'bzr update' to update the working tree | 08:43 |
| Bronger | There could be local changes, too. But in case of those, Bazaar sure would complain, either by conflicts or by an error message, wouldn't it? | 08:43 |
| luks | not in case of update | 08:43 |
| luks | update is designer to work with modifications in working tree | 08:44 |
| luks | merge would complain though | 08:44 |
| Bronger | So if I update, remote changes silently overwrite my local changes? | 08:45 |
| luks | no, it will try to merge them | 08:45 |
| Bronger | Okay. | 08:45 |
| luks | which can naturally result in conflicts | 08:45 |
| Bronger | Well, then I think I just resolved the conflicts incorrectly. | 08:46 |
| Bronger | Good. Thanks to all of you! | 08:46 |
| poolie | you're welcome | 08:58 |
| james_w | hey poolie | 08:58 |
| poolie | hi james | 08:58 |
| === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6rc1! / http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/ | ||
| poolie | woo | 08:59 |
| james_w | woo indeed | 09:00 |
| awilkins | Whee, shiny new hardware. | 10:59 |
| === avc_lost is now known as acuster | ||
| lifeless | awilkins: :) | 11:26 |
| jelmer | lifeless: AOL for America Online | 12:43 |
| jelmer | lifeless, their users used to be known for their one-line "me too" postings on usenet | 12:43 |
| dwt | jelmer: What is the best way to send patches for bzr-svn to you? | 12:45 |
| jelmer | dwt, just "bzr send" them to me | 12:46 |
| dwt | Well..., that bombs... | 12:47 |
| dwt | bzr stable:1557/> send | 12:47 |
| dwt | Cannot lock LockDir(http://people.samba.org/bzr/jelmer/bzr-svn/stable/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() | 12:47 |
| * dwt is off reading send help | 12:49 | |
| mib_20juap6b | I'm trying to use bzr-svn for local versioning before commiting back to a subversion server | 12:51 |
| mib_20juap6b | The team require files being worked to be locked on the subversion server | 12:51 |
| mib_20juap6b | I've tried bzr co on both a subversion checkout and repository | 12:52 |
| jelmer | dwt: Alternatively, you can send me the patch generated by "bzr send -o foo.patch" | 12:52 |
| dwt | jelmer: Well I tried that already, same error | 12:53 |
| jelmer | dwt, did you perhaps create a checkout of bzr-svn rather than a regular cloned branch? | 12:53 |
| mib_20juap6b | In both cases running 'svn lock' on files that needed to be locked caused errors when I tried to commit back from bazaar | 12:53 |
| mib_20juap6b | Is my desired way of working not possible with bazaar? | 12:54 |
| dwt | jelmer: Yes - as far as I remember, you advised me to do that last time we chatted. | 12:54 |
| dwt | (My memory may be wrong though) | 12:54 |
| jelmer | That would surprise me, there shouldn't be a particular reason to create a bound branch if you don't have write acess to the master branch | 12:55 |
| jelmer | dwt, "bzr send" will work if you "bzr unbind" your branch I think | 12:56 |
| dwt | jelmer: Thx, I'l try that | 12:56 |
| jelmer | mib_20juap6b, I'm not sure what you're after exactly | 12:56 |
| jelmer | mib_20juap6b, should bzr-svn attempt to unlock files before doing a commit? | 12:57 |
| mib_20juap6b | mib_20juap6b: No the files must stay locked on the subversion server since that is our policy for version control | 12:59 |
| mib_20juap6b | I would like bzr to act as a client and allow me subversioning before I commit back | 12:59 |
| * AfC misses SCCS too | 12:59 | |
| dwt | jelmer: strange thing, bzr unbind fails with the same error | 12:59 |
| Necoro | hmm ... bzr help send tells me, that the default format is "4" -- but just doing a "bzr send" showed me, that it is 0.9 instead | 13:00 |
| mib_20juap6b | Ie: Subversion -> bzr shared repository (lock files) | 13:00 |
| Necoro | oh - nevermind | 13:00 |
| * Necoro should learn to read | 13:00 | |
| mib_20juap6b | bzr shared repo -> my feature repo | 13:00 |
| AfC | mib_20juap6b: if you require obscure Subversion features like the one you are describing, I imagine you're not going to be able to use bzr-svn. | 13:01 |
| AfC | mib_20juap6b: That said, there is no reason you can't create a bzr branch in-place in a Subversion checkout and then just bzr to manage the files you are manipulating. | 13:01 |
| AfC | mib_20juap6b: low tech, to be sure, but it can work well enough. | 13:01 |
| mib_20juap6b | mib_20juap6b: I tried bzr branch subversion-checkout new-bzr-branch | 13:02 |
| mib_20juap6b | But when I tried to commit back from new-bzr-branch it complained about the locked files | 13:03 |
| jelmer | mib_20juap6b: bzr-svn doesn't touch locks at the moment | 13:03 |
| jelmer | dwt: That sounds like a bug | 13:04 |
| jelmer | dwt, alternatively, you can try removing "master_branch = ..." from .bzr/branch/branch.conf | 13:05 |
| jelmer | mib_20juap6b, is not touching the locks not sufficient? | 13:05 |
| dwt | jelmer: I'l try that - but I'd like to try to reduce the bug first. | 13:05 |
| mib_20juap6b | mib_20juap6b: Maybe I am confused | 13:07 |
| mib_20juap6b | mib_20juap6b: I created the branch from the svn checkout directory and commited to it | 13:08 |
| mib_xfynoqbr | mib_xfynoqbr: How do I commit back to the subversion checkout? | 13:09 |
| AfC | mib_xfynoqbr: svn commit? | 13:10 |
| mib_xfynoqbr | I used bzr branch to create the branch. So what bzr command can commit back again? | 13:12 |
| AfC | mib_xfynoqbr: or, if your question is how do I move changes from one Bazaar branch to another (where the second just happens to also be a Subversion checkout), then `bzr pull ../other` is perhaps what you are looking for. | 13:12 |
| mib_xfynoqbr | AfC: That might be it. Let me try... | 13:12 |
| mib_xfynoqbr | "No revisions to pull" | 13:13 |
| mib_xfynoqbr | And bzr push subversion-checkout complains about the locked file! | 13:14 |
| mib_xfynoqbr | In subversion a lock only has meaning for the repository and those interacting with it since it is centralised | 13:15 |
| jelmer | mib_xfynoqbr: what command did you use to create the bzr branch? bzr checkout or bzr branch? | 13:15 |
| mib_xfynoqbr | So maybe I found a bug in bzr-svn? | 13:15 |
| mib_xfynoqbr | I tried both. This time I just did a branch. | 13:16 |
| jelmer | mib_xfynoqbr, if you used "bzr checkout", just running "bzr commit" should commit back to svn | 13:16 |
| jelmer | if you used "bzr branch", run "bzr commit" and then "bzr push" | 13:16 |
| jelmer | mib_xfynoqbr, what sort of error are you getting? | 13:16 |
| mib_xfynoqbr | jelmer: I tried both as you described | 13:16 |
| jelmer | mib_xfynoqbr, what's not working exactly? | 13:17 |
| mib_xfynoqbr | mib_xfynoqbr: SubversionException("Cannot verify lock on path '/hello'; no matching lock-token available" | 13:18 |
| mib_xfynoqbr | mib_xfynoqbr: On the commit or push back | 13:18 |
| jelmer | mib_xfynoqbr, ah, so it's the lock that's problematic | 13:19 |
| jelmer | mib_xfynoqbr, The svn lock tokens aren't stored anywhere in bzr though | 13:19 |
| jelmer | mib_xfynoqbr, so I can't think of an easy way to fix this | 13:19 |
| === sabdf1 is now known as sabdfl | ||
| splodge | \part | 13:22 |
| mib_xfynoqbr | I have just discovered that checkout does not work since if yuo give bzr a subversion checkout directory it actually works on the corresponding subversion repository | 13:24 |
| jelmer | mib_xfynoqbr, that's what it's meant to do | 13:25 |
| === thekorn_ is now known as thekorn | ||
| dwt | jelmer: There is no such file ".bzr/branch/branch.conf" the only thing I could find is .bzr/branch/location" which holds just the url | 13:49 |
| dwt | jelmer: should I just remove that fileß | 13:49 |
| dwt | ? | 13:49 |
| jelmer | dwt: hmm, that's odd | 13:50 |
| jelmer | dwt, are you working in a lightweight checkout by any chance? | 13:50 |
| dwt | I guess so | 13:50 |
| jelmer | how did you manage to commit your change? | 13:50 |
| dwt | well, I didn't | 13:50 |
| jelmer | ah, ok | 13:50 |
| jelmer | you may want to use "bzr reconfigure" to convert the lightweight checkout into a full-fledged branch | 13:51 |
| dwt | aha! :) I'l try that | 13:51 |
| jelmer | after that, you should be able to commit your change and bzr send | 13:51 |
| pfeil | Hi, I need help with hook programming for bzr. | 13:51 |
| jelmer | hi pfeil | 13:52 |
| pfeil | Can anyone help me - I am new to phyton. | 13:52 |
| jelmer | pfeil, sure, just ask your question | 13:52 |
| dwt | jelmer: From reading the docs "bzr reconfigure --branch" seems to be the most sensible thing | 13:52 |
| pfeil | I need a start_commit hook that runs a shell command for every file that will be commited | 13:53 |
| pfeil | should be simple but I hve no phyton knowledge | 13:53 |
| abentley | jelmer: it's not so strange to create a bound branch when you don't have write access to the master branch. This creates a local mirror that you can't commit to by accident. | 13:54 |
| abentley | dwt: bzr reconfigure --tree | 13:55 |
| jelmer | abentley, bzr can behave strangely in that situation though (error messages that don't make sense to users) so I don't tend to recommend it | 13:55 |
| dwt | abentley: thanks! | 13:55 |
| jelmer | abentley, I agree there is a use case for it though | 13:56 |
| abentley | jelmer: Sounds like we need to make it give better diagnostics, then. | 13:56 |
| jelmer | abentley, yes, indeed | 13:57 |
| pfeil | The questin is: can anybody help me with my problem or point me to some example code I can learn from? | 13:58 |
| jelmer | pfeil, there was some example code for a start_commit hook posted to the list recently | 13:59 |
| jelmer | pfeil, http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/45041/focus=45042 | 13:59 |
| pfeil | jelmer: Thanks for the hit, I will read into the material... | 14:00 |
| dwt | abentley: Sorry to say, but 'reconfigure --tree' bombs for me with: bzr: ERROR: Repository KnitPackRepository('file:///Users/dwt/.bazaar/plugins/svn/.bzr/repository/') is not compatible with repository KnitPackRepository('http://people.samba.org/bzr/jelmer/bzr-svn/.bzr/repository/') | 14:01 |
| dwt | abentley: am I doing something wrong? | 14:02 |
| james_w | dwt: there's a bug open on that I believe | 14:02 |
| dwt | damn. :-) | 14:02 |
| abentley | dwt: No, you've hit a corner case. | 14:02 |
| james_w | you are using a rich-root repo I guess | 14:02 |
| dwt | james_w: | 14:03 |
| dwt | I have no idea... :) | 14:03 |
| james_w | yeah, it's bzr-svn | 14:03 |
| dwt | Well, not really | 14:03 |
| dwt | its a pure bzr checkout | 14:03 |
| dwt | so bzr-svn can't have a thing to do with this | 14:03 |
| jelmer | bzr-svn itself is in rich-root-pack as well | 14:03 |
| abentley | jelmer: btw, I had to stop Bundle Buggy from scanning bzr-stats, because it uses a rich-root repo. | 14:04 |
| jelmer | dwt, for now, it's probably easiest to just save your patch somewhere and create a fresh copy of the branch | 14:05 |
| jelmer | abentley, ah, ok :-( | 14:05 |
| dwt | jeah, I was just about to propose that too. | 14:05 |
| dwt | thanks for the help | 14:05 |
| dwt | though | 14:05 |
| === mw|out is now known as mw | ||
| ahasenack | hi guys, will there be a bzr 1.5.0 for hardy on bzr's ppa? The other distros have it | 14:25 |
| james_w | If I want to retrieve a non standard value from a non-standard section of ~/.bazaar/bazaar.conf do I have to resort to accessing the file with ConfigObj directly? | 14:29 |
| dwt | jelmer: after a lot of work... the patch is on it's way. whoa how hard sending a patch can be. | 14:31 |
| pfeil | jelmer: Thanks for the hint, I have read the thread and I am running into a similar problem like my precessor: | 14:33 |
| pfeil | jelmer: I have installed bzr 1.5 on a Mac | 14:33 |
| james_w | dwt: unbinding a lightweight checkout shouldn't be possible as it doesn't make any sense to have a standalone working tree | 14:33 |
| james_w | well, it may make sense, but it's not allowed as far as I know | 14:34 |
| pfeil | jelmer: When I enter bzr hooks, I get a list of hooks - all "<no hooks installed>". The interesting thing is: There is no start_commit hook listed in the list. Any glue? | 14:34 |
| dwt | james_w: Well, I'm not yet firm with what works how in bzr and why, so at least the error message was not at all helpfull | 14:35 |
| james_w | dwt: that's true | 14:35 |
| dwt | At the time my understanding was that unbind would magically make me a lcoal repository to work with - whatever the previous condition was. | 14:35 |
| dwt | I now recognize that there are two completely different concepts in bzr | 14:36 |
| dwt | and that a lightwight-checkout is more like a svn checkout | 14:36 |
| dwt | that can never (at least not as easily) become it's own repo | 14:36 |
| dwt | oh well. | 14:36 |
| dwt | bzr is hard. You know that? | 14:36 |
| luks | it's hard if you try to use it the svn way | 14:37 |
| === abentley1 is now known as abentley | ||
| dwt | luks: I thought that this was one of the strengths of bzr? | 14:40 |
| dwt | ok, cu guys in an hour | 14:41 |
| pfeil | Can someone help me then the mutabletree class? | 14:51 |
| pfeil | Can someone help me with the mutabletree class? | 14:51 |
| luks | pfeil: somebody probably can, even if not right now | 14:55 |
| luks | but it helps if you ask the question | 14:55 |
| pfeil | luks: Thanks - Just whantet to see if there is someone active here. | 14:55 |
| pfeil | luks: I am completely new to python and I need to write a start_comit hook stat runs a shell command for every file that will be commited. | 14:56 |
| pfeil | luks: Now I have a working hook skeleton and I know how to run shell commands, My remaining problem is to interate throug all the files | 14:57 |
| pfeil | luks: I get a mutabletree as parameter for the hook. I dont know the internal stuctures or the internal concepts of bzr so this is quite a problem for me to get it done quick. | 14:58 |
| james_w | pfeil: you have your hook being triggered now? | 14:58 |
| pfeil | Should be working, I will try.... | 14:59 |
| pfeil | Is there something wrong with this line? print "clearing exec bits in " + base | 15:02 |
| luks | depends on what is base | 15:03 |
| luks | `print "clearing exec bits in", base` would be more universal | 15:03 |
| pfeil | Do I need to import something for print? | 15:03 |
| === cprov-out is now known as cprov | ||
| luks | no | 15:03 |
| pfeil | Ok, this is how it looks like: | 15:04 |
| pfeil | def start_commit_hook( tree ): | 15:04 |
| pfeil | config = LocationConfig(tree.basedir) # unsure if this is right | 15:04 |
| pfeil | base = tree.basedir | 15:04 |
| pfeil | 15:04 | |
| pfeil | #print "clearing exec bits in " + base | 15:04 |
| pfeil | I am wondering where basedir is coming from because I could not find it in the class description | 15:05 |
| pfeil | is: ' base = "Hallo there" ' valid python? | 15:06 |
| luks | starting with one space is usually not valid python | 15:06 |
| luks | apart from that, yes | 15:06 |
| jelmer | dwt, hmm, not seeing your patch yet | 15:07 |
| jelmer | rockstar, ping | 15:08 |
| pfeil | Ok, I have removed the spaces, now my hook is working. | 15:08 |
| pfeil | The main problem remains, how to iterate throu the tree and execute a shell command on all the files that will be comitted? | 15:09 |
| pickscrapeX | pfeil: I went though this recently | 15:10 |
| pickscrapeX | Are you getting a tree_delta parameter? | 15:11 |
| pickscrapeX | That's proably your mutable tree parameter... Anyway, it has a number of attributes like added, modified, renamed etc that are lists of tuples | 15:12 |
| pickscrapeX | If you iterate through those and print out the tuples you'll see what the elements are (filename, file-id, type etc). | 15:13 |
| pfeil | pickscraperx: I am sorry, I am new to phyton and I am afraid that what you are talking about is out of my knowledge scope. | 15:14 |
| === pickscrapeX is now known as pickscrape | ||
| pfeil | pickscraperx: I can only understand and modify python code, not more :-( | 15:15 |
| pickscrape | Hmm, didn't know my nick was still wrong :) | 15:15 |
| pickscrape | What exactly is it that you are wanting to do with the files that will be committed? | 15:15 |
| pfeil | os.system("build++ --minor++ " + filename ) | 15:16 |
| james_w | pfeil: you can run that on all modified and added files, would that suit you? | 15:18 |
| pfeil | Yes :-) | 15:19 |
| james_w | jelmer: is there a way to get the specific changes that are being committed in a start_commit hook, or is it that the MutableTree is already those specific changes, and differs from the changes in the working tree if specific files were requested? | 15:19 |
| jelmer | james_w: the specific_files list doesn't get specified to start_commit at the moment | 15:20 |
| jelmer | it should, though | 15:20 |
| james_w | yeah | 15:20 |
| james_w | pfeil: if all modified and added files works for you then you want something like | 15:20 |
| james_w | changes = tree.changes_from(tree.basis_tree()) | 15:21 |
| james_w | for path_info in changes.added: | 15:21 |
| pfeil | what type is changes here? | 15:21 |
| james_w | path = path_info | 15:21 |
| pfeil | sorry | 15:22 |
| james_w | # do something with path | 15:22 |
| james_w | for path_info in changes.modified: | 15:22 |
| james_w | path = path_info[0] | 15:22 |
| james_w | # do something with path | 15:22 |
| james_w | . | 15:22 |
| james_w | the first "path = path_info" should be "path = path_info[0]", same as the second | 15:23 |
| pfeil | got it, will try now... | 15:24 |
| cjwatson | lifeless: any more luck with bug 246880? | 15:25 |
| ubottu | Launchpad bug 246880 in bzr "ghost fetch issue: fail when fetching a text referenced by a live revision introduced by a ghost revision" [High,Triaged] https://launchpad.net/bugs/246880 | 15:25 |
| cjwatson | or anything more I need to add there? | 15:25 |
| pfeil | Ok, thanks james_w for your help, but the code is not exactly what I need. Perhaps I have expressed my self not correctly: | 15:28 |
| pfeil | Here is what I need: | 15:28 |
| pfeil | When I enter: bzr commit -m "Test" test.file | 15:28 |
| pfeil | I want bzr to run build++ [more options] test.file befor any other 'versioning' work is done by bzr. | 15:29 |
| pfeil | You code runns throu all modfied files in the tree, not only the test.file. | 15:29 |
| james_w | <james_w> pfeil: you can run that on all modified and added files, would that suit you? | 15:30 |
| james_w | <pfeil> Yes :-) | 15:30 |
| james_w | maybe I wasn't clear, that's the best you can do from one of these hooks currently | 15:30 |
| pfeil | james_w: This was a missunderstanding on my side. I thought you are talking about: "...all modified and added files (that where specified on the command line)..." | 15:32 |
| awilkins | jelmer: SVN locks are advisories anyway, no? You can just tell the server you are stealing them. | 15:32 |
| awilkins | Although that might be a little cavalier where they are being used :-) | 15:33 |
| jelmer | awilkins, yep | 15:33 |
| james_w | pfeil: no, *all* modified and added files, sorry | 15:33 |
| jelmer | awilkins, they also work only on files, you can't lock a directory recursively | 15:33 |
| awilkins | THey are a pain in the butt from my perspective | 15:33 |
| awilkins | ESp. the thing where someone locks a file then deletes it ; the lock is left hanging around | 15:33 |
| awilkins | And you can't rename or delete the parent folder, or create another file with the same path | 15:34 |
| pfeil | james_w: So you mean, that there is no way to find out which file the user specified on the command line and run a shell script only on this file? | 15:34 |
| james_w | pfeil: not currently, no | 15:34 |
| pfeil | james_w: ...and what if I use an other hook, pre_commit for example? | 15:36 |
| james_w | you can't modify the tree being commited from them I believe | 15:36 |
| awilkins | Can't you modify it in start_commit? | 15:36 |
| james_w | yes | 15:37 |
| jelmer | pfeil, this is just start_commit missing an argument | 15:38 |
| pfeil | What could stop me from modifying the files on the disk in the pre_commit hook? I dont want to modify the internal bzr tree. | 15:38 |
| pfeil | jelmer: What do you mean, Have I made a mistake or do you mean that there is some feature missing? | 15:39 |
| jelmer | pfeil, There is a feature missing | 15:39 |
| jelmer | pfeil, start_commit should not just receive a tree but also a list of files specified for commit | 15:40 |
| pfeil | jelmer: I see... | 15:40 |
| pfeil | Any other idea how to count up an internal revision number the cvs old school style? | 15:41 |
| fog | hi. we have a problem with bzr+ssh using a common group to allow writes. the first time a new branch is pushed the permissions of the directories are 755 instead of 775. that's my mask but can't we have bzr to "clone" the permissions of the repo directory? I have to fix them by hand every time someone pushes a new branch in the repo. | 15:41 |
| fbond | Okay, so if I use commit --fixes foo:X, how can I now display bugs fixed by revision Y? | 15:42 |
| beuno | fog, maybe related to bug #255155? | 15:43 |
| ubottu | Launchpad bug 255155 in bzr "bzr.dev no longer preserves permissions in repository" [Critical,Confirmed] https://launchpad.net/bugs/255155 | 15:43 |
| james_w | fbond: that's not possible from the command line yet | 15:44 |
| james_w | fbond: I think bzr-gtk can do it | 15:44 |
| fbond | james_w: So what use is --fixes then? :) | 15:44 |
| dwt | jelmer: I sent the patch to jelmer@samba.org | 15:45 |
| jelmer | dwt, just got it - thanks! | 15:46 |
| jelmer | dwt: Patch looks good, I've merged it | 15:48 |
| fog | doh, it is a bug then. | 15:48 |
| fog | thanks. | 15:49 |
| beuno | fog, sorry :) | 15:50 |
| fog | but I use 1.5, not .dev.. mm. | 15:50 |
| beuno | fog, on both sides? | 15:51 |
| fog | 1.5 on the client and 1.3.1 on the server | 15:54 |
| fog | mm.. time to upgrade that server :) | 15:54 |
| dwt | I'd love to debug the second problem that plagues my bzr-svn installation now | 15:56 |
| jelmer | dwt, what's that? | 15:56 |
| dwt | But I'm currently hanging on understanding how bzr maps its namespace into the plugin directory | 15:56 |
| dwt | jelmer: the problem is that it cannot resolve bzrlib.plugins.svn to ~/.bzr/plugins/svn - or at least it seams that way | 15:56 |
| james_w | dwt: ~/.bazaar/plugins/svn | 15:57 |
| dwt | sorry, thats what I mean | 15:57 |
| dwt | or meant, anyway | 15:57 |
| james_w | what's the problem you are seeing? | 15:58 |
| dwt | james_w: When I try bzr selftest svn, it can't load the svn plugin | 16:02 |
| dwt | because it can't resolve the imports to bzrlib.plugins.svn, as being in the directory ~/.bazaar/plugins/svn | 16:03 |
| dwt | here's a paste of the problem | 16:03 |
| dwt | http://paste.lisp.org/display/64873 | 16:03 |
| cjwatson | dwt: it works the other way round; bzr imports everything under ~/.bazaar/plugins/ and stashes them in the right places in its namespace | 16:03 |
| luks | dwt: if can't import it, because the plugin itself fails | 16:04 |
| luks | see ImportError: cannot import name client | 16:04 |
| dwt | hm, how can I debug this further? | 16:05 |
| luks | do you have client.so or client.py in ~/.bazaar/plugins/svn? | 16:05 |
| james_w | dwt: are you on bzr 1.6? | 16:05 |
| dwt | luks: yes, client.so | 16:05 |
| dwt | james_w: no, I'm on bzr 1.5 | 16:05 |
| luks | that looks strange then | 16:06 |
| james_w | dwt: ok, please paste the whole of one of the stanzas of ~/.bzr.log showing the failure to load the plugin | 16:06 |
| luks | dwt: oh, perhaps it's built with a different version of python? | 16:07 |
| dwt | you mean the *.so files? | 16:08 |
| luks | yes | 16:08 |
| dwt | luks: I'l check that after I pasted the errors from loaading the plugin | 16:08 |
| dwt | james_w: http://paste.lisp.org/display/64878 | 16:10 |
| james_w | AttributeError: 'module' object has no attribute 'properties_handler_registry' | 16:10 |
| james_w | you are using a version of bzr-svn that is not compatible with bzr 1.5 | 16:10 |
| dwt | damn. | 16:11 |
| dwt | And I was extra carefull to take the stable branch | 16:11 |
| dwt | jelmer: Can you tell me which branch would be the right one to get for bzr 1.5? | 16:11 |
| jelmer | dwt, there's no branch matching bzr 1.5 | 16:11 |
| jelmer | dwt, you can use the tarball from the wiki page | 16:12 |
| dwt | ok... | 16:12 |
| dwt | I'l try that | 16:12 |
| jelmer | dwt, or revert back to tag:bzr-svn-0.4.10 in your current bzr-svn branch | 16:12 |
| dwt | That sounds much better | 16:12 |
| dwt | thanks | 16:12 |
| dwt | jelmer: As far as I can tell at that revision you are still using the official python bindings | 16:22 |
| jelmer | dwt: Yes, that's correct | 16:25 |
| dwt | Too bad, I really wanted to give your bindings a spin. | 16:26 |
| jelmer | dwt: You can still try, with bzr.dev | 16:27 |
| dwt | I'm a bit weary going to the trunk of bzr | 16:27 |
| dwt | I really want to give this plugin a workount | 16:27 |
| dwt | with first trying to replicate my workplace conditions | 16:27 |
| Peng_ | bzr.dev is kept pretty stable. | 16:28 |
| dwt | and then trying to switch my workplace | 16:28 |
| dwt | but for that I really need stable versions that many people have tested already. | 16:28 |
| luks | well, 1.6rc1 is out | 16:28 |
| dwt | luks: I am considering just waiting a week or two till it is out. | 16:29 |
| luks | not that is has been tested by as many people as 1.5, but at least you have a tarball | 16:29 |
| dwt | true | 16:29 |
| === doko_ is now known as doko | ||
| dwt | Well, after going back to tag:bzr-svn-0.4.10 and making the plugin | 16:34 |
| dwt | it seems to load perfectly | 16:34 |
| dwt | however running bzr selftest svn dies on the ninth test | 16:34 |
| dwt | jelmer: Does it make sense to look into this further | 16:35 |
| dwt | or should I just wait for bzr 1.6? | 16:35 |
| jelmer | dwt, what sort of version of subversion do you have installed? | 16:35 |
| dwt | 1.5 | 16:35 |
| jelmer | dwt, I guess I would wait for 1.6 | 16:35 |
| jelmer | (bzr 1.6) | 16:36 |
| dwt | sure | 16:36 |
| dwt | ok, I'l check back in here as soon as 1.6 hits my repository. :) | 16:36 |
| dwt | ok, thanks for the help and cu soon! | 16:41 |
| evanton | I'm getting an error when running "make docs" inside the unpacked source tarball of bzr-1.5 | 16:43 |
| evanton | http://pastebin.com/m762ada0c | 16:43 |
| jam | evanton: weird, I'm not seeing that here | 17:40 |
| jam | I wonder if it is a different version of rst2html | 17:40 |
| jam | evanton: ah, I think this is the rst2hmtl bug we had a workaround for | 17:41 |
| jam | specifically there is a '.' in the options | 17:41 |
| jam | which rst doesn't usually like | 17:41 |
| jam | if you look at our tools/rst2html.py | 17:41 |
| jam | there is a workaround in there | 17:41 |
| jam | but it is keyed on version | 17:41 |
| jam | evanton: you probably just need to expand the version range | 17:41 |
| jam | evanton: there should be a line like: if docutils.__version__ <= '0.4.1': | 17:42 |
| jam | Just change that to "if True:" or something like that | 17:42 |
| evanton | jam: do you want me to tell you the version of docutils I'm using? | 17:42 |
| jam | evanton: you can, but I'm 99% sure it is >0.4.1 | 17:42 |
| jam | :) | 17:42 |
| evanton | hold on | 17:42 |
| jam | I think we have a fix for that in the 1.6 branch | 17:42 |
| jam | In bzr.dev the line is "if True: # this is still required in the distutils trunk as-at June 2008." | 17:43 |
| evanton | $ rst2html.py --version | 17:43 |
| evanton | rst2html.py (Docutils 0.5 [snapshot 2008-04-24, r5542], Python 2.5.1, on linux2) | 17:43 |
| jam | evanton: so... yeah, just a problem with our workaround not being used for newer docutils, you can edit that line and it should work | 17:45 |
| jam | And 1.6 will have a fix for it | 17:45 |
| evanton | as I can see from the error, "make docs" is calling the rst2html.py that's included in the source tarball of bzr | 17:45 |
| evanton | let me try your suggestion | 17:45 |
| jam | evanton: we call that one, because of workarounds, etc that we needed to put in | 17:46 |
| jam | it shouldn't be calling the global rst2html | 17:46 |
| === andreas__ is now known as ahasenack | ||
| evanton | jam: seems like html files were generated, thanks for your help | 17:49 |
| evanton | now it complains about not finding dot, so it's time to google for that :) | 17:49 |
| evanton | will be back if will have any other questions | 17:49 |
| dato | evanton: dot is shipped with graphviz | 17:56 |
| evanton | suggestion: sticking the keyword "graphwiz" into that error message could help a newbie figure out what dot is, since googling for "dot" is irrelevant | 17:56 |
| evanton | dato: than's I've found it, will look at graphwiz now | 17:57 |
| evanton | s/than's/thanks, / | 17:57 |
| Jc2k | 'wg 20 | 17:57 |
| radix | evanton: it's "graphviz" not "graphwiz" | 17:57 |
| evanton | oh | 17:58 |
| evanton | I've misspelled it | 17:58 |
| rockstar | jelmer, hi | 18:49 |
| jelmer | rockstar, hi | 18:50 |
| rockstar | Could we chat about loggerhead's packaging needs? | 18:50 |
| jelmer | rockstar, yep, sounds good | 18:50 |
| jelmer | rockstar: afaik the only thing missing for a stock loggerhead package at the moment is loading the configuration from another location | 18:51 |
| rockstar | jelmer, yea. That would allow it to run daemonized. | 18:52 |
| rockstar | However, thumper was telling me that ./serve-branches knows about user dir traversal, and the start-loggerhead script apparently doesn't | 18:52 |
| rockstar | I thought I might take a look at that. | 18:52 |
| pickscrape | Where can I find documentation for the template language that loggerhead uses? | 18:53 |
| rockstar | pickscrape, the template engine is simpletal | 18:53 |
| pickscrape | This one? http://www.owlfish.com/software/simpleTAL/ | 18:53 |
| Peng_ | pickscrape: Yep. | 18:55 |
| jelmer | rockstar, ah, cool | 18:56 |
| jelmer | I guess the package could also use a init script | 18:56 |
| pickscrape | Ah, I think I see... I've been reading it wrong :) | 18:56 |
| rockstar | jelmer, we could just leverage the work from start-loggerhead and stop-loggerhead for init scripts | 18:57 |
| rockstar | I also have a default config that we'd like to load on installation and start of the server | 18:58 |
| asabil | is it possible to make a branch redirect to another branch ? | 19:00 |
| Peng_ | asabil: There are "branch references", but there's no way to create them through the CLI. | 19:00 |
| asabil | hmm, ok | 19:00 |
| rockstar | jelmer, do you have time to look into loading the configuration from another location? | 19:05 |
| jelmer | rockstar: Yeah, that'd make sense | 19:17 |
| === mw is now known as mw|food | ||
| wingo-tp | good afternoon! | 19:45 |
| luks | good evening! | 19:45 |
| wingo-tp | i come begging, hat in hand: lifeless, can you have a look at bug #239499? | 19:45 |
| ubottu | Launchpad bug 239499 in bzr "corrupt knit index on an old arch-imported bzr repo" [Medium,Confirmed] https://launchpad.net/bugs/239499 | 19:45 |
| * wingo-tp <- this guy is a drag, i know | 19:46 | |
| rockstar | wingo-tp, lifeless won't stir for another hour at least | 19:46 |
| jelmer | beuno, ping | 19:53 |
| jelmer | rockstar: I've added arguments to override the log folder, config file and pid file for loggerhead | 19:53 |
| jelmer | as well as an init script | 19:53 |
| beuno | jelmer, pong | 19:58 |
| jelmer | beuno: is there some place where loggerhead logs when in daemon mode? | 19:58 |
| jelmer | I had syntax errors but they didn't appear to be logged anywhere | 19:58 |
| beuno | jelmer, it tries to create a logs/ dir | 19:59 |
| beuno | and there should be a debug.log | 19:59 |
| beuno | of course, it does so in the same dir, which won't work well with an installation | 19:59 |
| beuno | we should change that | 19:59 |
| beuno | (make it log in the home dir maybe, ~/.loggerhead.log | 19:59 |
| beuno | mwhudson, thoughts? | 20:00 |
| james_w | somewhere under /var/log would be better if it's running as a daemon I think | 20:02 |
| beuno | james_w, I agree that's the ideal place, but won't we run into potention permission issues? | 20:03 |
| beuno | I'm not sure how all that works | 20:03 |
| beuno | AFAIK a regular user can't write in /var/log | 20:03 |
| james_w | if it's using an init script the you can create /var/log/loggerhead/ and chmod it, as the init script is running as root | 20:04 |
| james_w | or do it at package installation time | 20:04 |
| james_w | if loggerhead has a normal daemon mode then home dir may be a good idea, with a command line switch to specify somewhere else | 20:04 |
| wingo-tp | rockstar: ok, i'll pounce on him then :) | 20:05 |
| beuno | james_w, yeah, it has both. So maybe a switch will work best. jelmer? | 20:05 |
| jelmer | beuno, Just did the patch :-) | 20:05 |
| jelmer | beuno, I see what I was doing wrong now | 20:06 |
| jelmer | I had actually caused a syntax error in the code that dealt with the logging | 20:06 |
| beuno | jelmer, oh, very cool | 20:06 |
| beuno | ah, right | 20:06 |
| jelmer | https://code.edge.launchpad.net/~jelmer/loggerhead/pathargs/+merge/662 | 20:06 |
| * beuno branches | 20:07 | |
| beuno | jelmer, revision 202 thanks you for your continued contribution :) | 20:14 |
| jelmer | beuno, w00t, thanks! | 20:15 |
| rockstar | beuno, jelmer, the package at least should log to /var/log/loggerhead or something like that | 20:15 |
| jelmer | rockstar, Yeah, I've modified them to do that | 20:16 |
| === mw|food is now known as mw | ||
| jelmer | rockstar, that's why I added the -L option | 20:16 |
| rockstar | Ah. | 20:16 |
| jelmer | beuno, You seem to've missed a revision | 20:18 |
| jelmer | one that fixes the syntax errors | 20:18 |
| beuno | jelmer, odd, I branched and merged | 20:18 |
| beuno | jelmer, revno? | 20:18 |
| jelmer | beuno, 205 | 20:19 |
| jelmer | it's there in the original location, perhaps lp jsut didn't mirror it yet | 20:19 |
| jelmer | http://people.samba.org/bzr/jelmer/loggerhead/pathargs | 20:19 |
| beuno | jelmer, updated | 20:22 |
| jelmer | beuno, thanks! | 20:22 |
| beuno | jelmer, thank *you* :) | 20:24 |
| jelmer | beuno, while you're here... | 20:24 |
| jelmer | from loggerhead import release | 20:24 |
| jelmer | ImportError: cannot import name release | 20:24 |
| jelmer | it still worked in my own tree because I had the .pyc file around | 20:25 |
| jelmer | but the .py file appears to be gone | 20:25 |
| beuno | that's still around? | 20:26 |
| * beuno greps | 20:26 | |
| beuno | I thought I ahd removed it | 20:26 |
| jelmer | it's in start-loggerhead | 20:26 |
| jelmer | and stop-loggerhead | 20:26 |
| beuno | removed, committing | 20:27 |
| jelmer | beuno: release is still used | 20:33 |
| jelmer | start-loggerhead line 82 | 20:33 |
| jelmer | rockstar, beuno: other than that, the debian package seems to work fine now | 20:34 |
| jelmer | (configuration file in /etc/loggerhead.conf, logs in /var/log/loggerhead, init script in /etc/init.d/loggerhead) | 20:35 |
| rockstar | jelmer, The one thing we still need is for the daemon to understand userdir branches. | 20:35 |
| rockstar | I'm still trying to figure out exactly what that means. | 20:35 |
| rockstar | Ah, nevermind, it's quite obvious... :) | 20:36 |
| beuno | jelmer, hrm... did you merge trunk before working on that branch? | 20:36 |
| jelmer | beuno, yeah | 20:37 |
| beuno | I should stop drinking during the day then, I would of sworn I removed all of those | 20:38 |
| rockstar | beuno, start off by drinking less. | 20:39 |
| beuno | rockstar, right, one step at a time.. | 20:40 |
| rockstar | :) | 20:40 |
| beuno | jelmer, removed those too, grep promised me that iw as the last of em | 20:41 |
| beuno | s/iw/it | 20:41 |
| beuno | see, I can't even type anymore | 20:41 |
| jelmer | :-) | 20:42 |
| pickscrape | Is it easy to remove a branch that was accidentally pushed over the top of a shared repository? | 20:43 |
| pickscrape | It is confusing loggerhead :) | 20:43 |
| beuno | pickscrape, just deleting it will do it. Revision will remain in the shared repo though | 20:44 |
| beuno | won't be a problem, just take up space | 20:44 |
| pickscrape | Delete ~/.bzr/branch ? | 20:44 |
| pickscrape | I mean the branch was pushed *to* the shared repo directory, not under it. | 20:45 |
| james_w | yeah, make sure to get the "branch" bit :-) | 20:45 |
| pickscrape | :) | 20:46 |
| pickscrape | I'll try renaming it first | 20:46 |
| pickscrape | Worked a treat, thanks! | 20:47 |
| jelmer | rockstar, beuno: http://revu.ubuntuwire.com/details.py?package=loggerhead | 21:07 |
| beuno | jelmer, you're going to *kill* me | 21:07 |
| beuno | but I just landed a fix that makes it work with pre-bzr 1.6b3 versions | 21:08 |
| beuno | which should probably be in it, since hardy has 1.3 | 21:08 |
| beuno | jelmer, and, w00t! | 21:08 |
| beuno | jelmer, you're still lacking DD's to sponsor uploads, right? | 21:08 |
| jelmer | beuno, yes | 21:09 |
| beuno | jelmer, I'll forc^ask again today | 21:09 |
| mwhudson | hm | 21:09 |
| jelmer | beuno, at the moment for bzr-upload, loggerhead and bzr-search | 21:09 |
| mwhudson | is the scanner wedged again? :( | 21:09 |
| beuno | mwhudson, it is :/ | 21:09 |
| jelmer | beuno, Another bzr-upload upload would be nice | 21:09 |
| mwhudson | oh for fuck's sake | 21:10 |
| james_w | beuno: did you ever get to play with "upload --auto"? | 21:10 |
| beuno | jelmer, ok, so anything that has to do with me :p I'm meeting with the DD today, so I'll presure enough | 21:10 |
| jelmer | ah, cool | 21:10 |
| jelmer | beuno, are you @ debconf? | 21:10 |
| beuno | james_w, I handed it out to the user needing it, and haven't heard cursing, so I assume everything went ok :) | 21:11 |
| james_w | beuno: cool :-) | 21:11 |
| beuno | jelmer, I'm not. Starting with Canonical full time on monday, so that derrailed my plans a bit | 21:11 |
| jelmer | beuno, ah, cool, didn't know that :-) | 21:11 |
| jelmer | beuno, Congrats on your new job :-) | 21:11 |
| beuno | jelmer, heh, thanks. I'll make it "official" tomorrow, just did the formal bits today, so I haven't made it too public | 21:12 |
| beuno | it's been a rumor for a while not though :p | 21:12 |
| beuno | james_w, if everything goes as planned, we're going to be using bzr-upload at the office *much* more heavily, so it should get more love soon | 21:13 |
| james_w | beuno: cool | 21:13 |
| james_w | hey, congratulations beuno | 21:14 |
| beuno | james_w, thanks! I'm excited to get started | 21:14 |
| beuno | mwhudson, btw, is there anyway you can set LH's permissions to public by default? | 21:17 |
| TheEric | how do you get BZR to push new files? e.g. images in an image directory? | 21:23 |
| beuno | TheEric, you first have to version them with: bzr add | 21:24 |
| beuno | note that bzr add will add everything unversioned | 21:24 |
| beuno | if you only want a specific dir, bzr add directory/ | 21:24 |
| beuno | then, commit them | 21:24 |
| beuno | and push | 21:25 |
| jelmer | beuno, Hmm, loggerhead only supports local urls atm? | 21:25 |
| alex-weej | how do i undo a commit? | 21:26 |
| alex-weej | i used the wrong commit message | 21:26 |
| alex-weej | damn you -m ! | 21:26 |
| beuno | alex-weej, bzr uncommit | 21:26 |
| Jc2k | alex-weej: bzr uncommit | 21:26 |
| Jc2k | :) | 21:26 |
| beuno | jelmer, local branches? | 21:27 |
| jelmer | beuno, yeah | 21:27 |
| alex-weej | thanks :) | 21:27 |
| alex-weej | hi Jc2k :D | 21:27 |
| beuno | jelmer, did you update the bzr-upload package, or is it the same? | 21:27 |
| jelmer | beuno, it's the same | 21:27 |
| beuno | jelmer, IIRC, mwhudson uses http in LP for branches | 21:28 |
| jelmer | beuno, something went wrong during the upload | 21:28 |
| jelmer | beuno, ah, cool | 21:28 |
| jelmer | beuno, I was trying with SVN urls but that seems to cause weird errors while scanning for branches | 21:28 |
| beuno | jelmer, yes, I'll sit down with her and do it together so nothing goes wrong :) | 21:28 |
| TheEric | ah, excellent. I should've thought of the add bit. | 21:28 |
| Jc2k | hi alex-weej :P | 21:29 |
| jelmer | beuno, ah, it looks like it's the auto_publish_folder stuff that doesn't appear to work with remote urls | 21:29 |
| mwhudson | beuno: need an lp admin to do that; i think it's a good idea though | 21:30 |
| beuno | jelmer, the official policy is to eventually remove start/stop-loggerhead scripts, so that may be ery low priority | 21:31 |
| rockstar | beuno, why's that? | 21:32 |
| mwhudson | because loggerhead.conf is bonkers | 21:32 |
| beuno | rockstar, we *will* provide a way to do all the current magic, but with serve-branches | 21:33 |
| rockstar | beuno, ah, I see. My concern is that it needs to run as a daemon. | 21:33 |
| beuno | rockstar, absolutely, either serve-branches will be optionally work as a daemon, or we'll have a daemon script separately | 21:35 |
| beuno | mwhudson, you may know this. Where can I find a branch with a NULL revision in it? related to bug #254794 | 21:38 |
| ubottu | Launchpad bug 254794 in loggerhead "root directory view traceback" [High,Confirmed] https://launchpad.net/bugs/254794 | 21:38 |
| beuno | 5 bugs to go for 1.6 release :) | 21:39 |
| mwhudson | well | 21:39 |
| mwhudson | all branches have null: in them, in some sense | 21:39 |
| mwhudson | oh, maybe it's when you serve-branches in a directory that has a branch with no revisions at all in it? | 21:40 |
| mwhudson | bzr init foo | 21:40 |
| mwhudson | serve-branches . | 21:40 |
| * beuno tries | 21:40 | |
| mwhudson | ? | 21:40 |
| pickscrape | How do I find out from within a Command object's run() method if the user passed --verbose? | 21:41 |
| mwhudson | beuno: yeah, seems like it | 21:41 |
| beuno | mwhudson, I don't get a traceback, just No revisions! | 21:42 |
| mwhudson | beuno: run serve-branches from the directory _containing_ the branch | 21:42 |
| beuno | beuno@beuno-laptop:/tmp/test$ ~/bzr_devel/loggerhead/trunk/serve-branches . | 21:43 |
| mwhudson | branch.repository.get_revision(branch.last_revision()) | 21:43 |
| mwhudson | isn't going to work in such a branch | 21:43 |
| beuno | /tmp/test is the empty branch | 21:43 |
| mwhudson | beuno: so run it from /tmp | 21:43 |
| mwhudson | (i guess "containing" is ambiguous here :) | 21:43 |
| beuno | mwhudson, same thing, No revisions | 21:44 |
| beuno | oooh | 21:44 |
| beuno | wait | 21:44 |
| beuno | got it | 21:44 |
| beuno | hm | 21:45 |
| beuno | I get a different error though | 21:45 |
| beuno | pickscrape, gets "ReservedId: Reserved revision-id {null:}" | 21:45 |
| beuno | and I get "NoSuchRevision: KnitPackRepository('file:///tmp/test/.bzr/repository/') has no revision null:" | 21:45 |
| pickscrape | I had a sysadmin whining about that one today, saying 'bzr is broken' :) | 21:46 |
| mwhudson | i get the same as you | 21:46 |
| mwhudson | bzr version differences? | 21:47 |
| pickscrape | He hadn't read the email I'd sent out about it | 21:47 |
| mwhudson | pickscrape: it's always much more likely to be loggerhead :) | 21:47 |
| james_w | is vila on holiday? | 21:47 |
| pickscrape | mwhudson: well, loggerhead doesn't have 12k+ unit tests does it :) | 21:47 |
| mwhudson | pickscrape: no, and we should do something about that at some point | 21:48 |
| mwhudson | (well, 12k would be overkill for LH, i think...) | 21:48 |
| beuno | I'd love to focus on that in the next release cycle | 21:49 |
| pickscrape | I've started writing tests for diffstat. It's interesting, and I think I've even found a bug in doing it. | 21:49 |
| beuno | pickscrape, bug #254794 should be fixed now. Could you confirm it? | 22:27 |
| ubottu | Launchpad bug 254794 in loggerhead "root directory view traceback" [High,Fix committed] https://launchpad.net/bugs/254794 | 22:27 |
| pickscrape | beuno: on it | 22:30 |
| pickscrape | erm, how strange. I just tried to before updating to make sure I was checking properly and it's working now, which should be impossible... | 22:31 |
| mwhudson | i guess the problem branch has a revision in it now | 22:32 |
| pickscrape | Nope, it's still a plain directory | 22:32 |
| pickscrape | I did update to r201 earlier today though. I wonder if that fixed my problem... | 22:33 |
| beuno | pickscrape, it must have a dir with a .bzr in it | 22:33 |
| beuno | with no revisions | 22:33 |
| beuno | somewhere | 22:33 |
| pickscrape | I just checked, definitely no .bzr | 22:33 |
| beuno | pickscrape, in a directory inside the root one | 22:34 |
| beuno | so you're at /foo/bar | 22:34 |
| beuno | where you used to get the error | 22:34 |
| beuno | so /foo/bar/blah | 22:34 |
| beuno | has an empty branch in it | 22:35 |
| beuno | or it should | 22:35 |
| mwhudson | beuno: try:except: is pretty evil | 22:35 |
| beuno | and if it doesn't, it's still fixed, because I changed that part of the code :) | 22:35 |
| beuno | mwhudson, I know. But bzr 1.5/1.6 throw different exceptions | 22:35 |
| mwhudson | though mind you, i put a try:except: around branch.open, so i can't really talk | 22:35 |
| mwhudson | beuno: ugh | 22:35 |
| beuno | and I didn't even want to dig into 1.4/1.3 | 22:35 |
| pickscrape | Aha, I think I know what it is. I asked earlier about deleting a ~/.bzr/branch directory that was accidentally pushed over a shared repository | 22:36 |
| beuno | so I chose try: except: rather than 4 different possible exceptions | 22:36 |
| pickscrape | Now that it's removed, it's working. | 22:36 |
| pickscrape | I'll update now and try | 22:36 |
| beuno | mwhudson, but I'm open to doing it better if you can think of something :) | 22:36 |
| pickscrape | It still works | 22:37 |
| beuno | pickscrape, great, thanks! | 22:37 |
| beuno | I love instant feedback | 22:37 |
| beuno | bzr users rock :) | 22:38 |
| pickscrape | Our sysadmin will be a happy chappy now :) | 22:38 |
| beuno | I hate how unhelpful LH's logging is | 22:58 |
| beuno | I wonder what it would take to make it resemble bzr's one... | 22:59 |
| Peng_ | Did you mean to change LH's <title>s from "some/branch : changes" to "/some/branch : changes"? | 23:02 |
| beuno | no, whatever goes into debug.log | 23:03 |
| beuno | WARNING:simpleTALES.Context:Exception occurred evaluating python path, exception: name 'url' is not defined | 23:03 |
| beuno | I have *no* idea where that came from | 23:04 |
| === mw is now known as mw|brb | ||
| === Mathilda is now known as uws | ||
| === mw|brb is now known as mw | ||
| beuno | Peng_, re bug #247992 | 23:28 |
| ubottu | Launchpad bug 247992 in loggerhead "Visiting just "/download" or "/download/" redirects to a bad URL" [Undecided,New] https://launchpad.net/bugs/247992 | 23:28 |
| beuno | how is it that you end up in /download? | 23:28 |
| Necoro | hmm ... by the way - is there sourcecode highlighting support for loggerhead? | 23:29 |
| Necoro | and if yes: is there a reason, it isn't turned on LP? | 23:30 |
| beuno | Necoro, nope. But there may be if you file a bug requesting it :) | 23:30 |
| Necoro | I'll do when I'm bored ;) ... | 23:31 |
| beuno | good, I prefer exciting bugs | 23:32 |
| beuno | :p | 23:32 |
| Necoro | beuno: http://pygments.org/ =P | 23:33 |
| beuno | Necoro, oh, did I mention we *love* patches? | 23:34 |
| beuno | even boring ones! | 23:34 |
| beuno | either way, we'd have to make it optional. I don't want to add another dependency for this | 23:35 |
| Necoro | I hope, LH has some way of configuration =P | 23:35 |
| beuno | oh, codescanner just came back from the dead | 23:36 |
| Necoro | anyways ... time for bed ;) ... I'll see what I can do tomorrow ^^ | 23:37 |
| * beuno is off to a dinner | 23:44 | |
| lifeless | jam: if you want to talk reachability we could skype | 23:50 |
| jam | lifeless: sure, though I don't have long before the standup, and we're going on a walk after that (I guess I could skip the standup today) | 23:53 |
| lifeless | up to you - poolie said you were interested in what I'm thinking about is all | 23:55 |
| igc | morning | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
