| beuno | mwhudson, I have to run off for a while. I need to run some errands I've been putting off. I'll read the backlog when I get back, and finish up the cleaner-url patch. FWIW, it's in: lp:~beuno/loggerhead/zpt.cleaner_urls | 00:02 |
|---|---|---|
| mwhudson | beuno: okidoke | 00:02 |
| mwhudson | i should do some non-loggerhead stuff too | 00:02 |
| igc | morning | 00:03 |
| Peng | jelmer: If you haven't gotten an answer, you can use 'hg export' to create a patch-like file.. Not sure about the email part. The patchbomb extension, perhaps. | 00:06 |
| jelmer | Peng, hg doesn't have a bundle-like format that preserves vcs metadata? | 00:08 |
| Peng | jelmer: 'hg export' does. | 00:08 |
| Peng | jelmer: The git diff format can store binary data. | 00:09 |
| Peng | jelmer: Mangled line endings can cause problems though. | 00:09 |
| jelmer | Peng, ah, thanks | 00:11 |
| === mark1 is now known as markh | ||
| lifeless | igc: where is your stacked loom again ? | 00:47 |
| jml | abentley, lifeless: do you know if https://bugs.edge.launchpad.net/bzr-loom/+bug/201613 is now fixed? | 00:50 |
| ubottu | Launchpad bug 201613 in bzr-loom "pushing looms does not work properly" [Critical,Triaged] | 00:50 |
| jml | the associated branch is 'trunk', so... | 00:50 |
| jml | also, what's BzrDir.clone expected to do when the associated bzrdir is for a loom? | 00:52 |
| abentley | jml: I know that a hacky fix was applied, so it should be better, but not perfect. The wrong hook will fire. | 00:54 |
| abentley | I don't know why BzrDir.clone would do anything different when the associated bzrdir is for a loom. | 00:55 |
| lifeless | jml: as abentley says | 00:55 |
| lifeless | jml: works, wrong hook. | 00:55 |
| jml | ahh ok. | 00:57 |
| stefanv | hey guys, I have a question about workflow. I'd appreciate it if you could point me in the right direction. Whilst developing a feature in a new branch, it is useful to keep up to date with the latest changes made in "trunk". Why does bzr force you to merge, even if a pull wouldn't have resulted in a conflict? This makes many merges appear in the revision log. Is there a workaround, or am I missing the point? | 01:01 |
| stefanv | For example, if I'm working on project/somedir/*, and the project changes project/otherdir in trunk, that would require a merge from my side. But I'd be quite happy to just rebase my branch on theirs... | 01:02 |
| stefanv | instead of merging, I would then again be able to pull | 01:02 |
| stefanv | If this is all crazy-talk, just point me to the right FAQ, please... | 01:03 |
| lifeless | stefanv: so this is a whole-tree vs partial-tree thing | 01:03 |
| lifeless | stefanv: in CVS each file has its own timeline, so you can 'pull'(update there) and it has to relevance to other files | 01:04 |
| lifeless | stefanv: the same goes for SVN | 01:04 |
| lifeless | stefanv: darcs doesn't really have a timeline, which is why a similar thing works there | 01:04 |
| lifeless | stefanv: for whole-tree systems, like bzr, hg, monotone, git, it doesn't matter which files you edit - concurrent activity requires some action to resolve. | 01:05 |
| lifeless | stefanv: there are different low level tools that can be used, they basically boil down to either /rewrite history/ or /merge the activity/ | 01:05 |
| stefanv | lifeless: the problem is that we see many merge entries in our logs, which seem kind of unnecessary.. we would have been happy to just base the branches off the new trunk, if possible | 01:05 |
| lifeless | rewriting history is problematic - it turns tested code into untested code, it makes collaboration much harder | 01:06 |
| spiv | Rewriting history just to get an arguably nicer presentation seems like overkill to me :) | 01:06 |
| stefanv | spiv: it worries the developers when they see so many merge messages, but maybe that is just a mental block we need to get over. the idea of a "merge" is still somewhat severe, coming from SVN. | 01:07 |
| stefanv | lifeless: thank you for the detailed answer. | 01:07 |
| stefanv | if merges could take place without conflicts, though, why merge instead of just pulling? | 01:08 |
| spiv | Because pull is a way to update a mirror of a branch. | 01:09 |
| spiv | But if you have a branch with independent changes, it's not a mirror, so it cannot have the same history. | 01:09 |
| stefanv | Ah, that makes sense. | 01:09 |
| spiv | If your branch has no new commits in it, then you can use pull. But then it's not a very interesting feature branch either :) | 01:10 |
| stefanv | Doesn't hg fast-forward? | 01:10 |
| stefanv | spiv: true :) | 01:10 |
| lifeless | stefanv: 'merge --pull' does what 'fast-forward' does | 01:10 |
| lifeless | stefanv: which we put in for folk that enjoy that particular workflow | 01:11 |
| lifeless | stefanv: with respect to merges - merging is what happens when concurrent development takes place | 01:11 |
| lifeless | stefanv: and bzr can't tell that "standard_includes.h" is unable to cause a test failure in "uses_standard_includes.c" | 01:11 |
| lifeless | stefanv: which is why we don't commit it automatically (though you can definitely write a wrapper script if you wanted to) | 01:12 |
| stefanv | lifeless: shouldn't the developer take the responsibility of only merging valid changes in? | 01:13 |
| stefanv | lifeless: bzr can't really protect against that, either way | 01:13 |
| lifeless | right | 01:15 |
| lifeless | all a merge record in the history means is that a developer has done that | 01:15 |
| stefanv | lifeless: is there a way for a developer to hide all those merge records? | 01:15 |
| stefanv | lifeless: i.e. if he wants to say "here is my new feature, but you guys really don't need to know about successful merge attempts"? | 01:15 |
| stefanv | lifeless: or should we just use the --short option for logs? | 01:16 |
| lifeless | It is possible to write a plugin to hide them from e.g. log. They do have semantic value to bzr (to make merge work correctly for instance) | 01:16 |
| stefanv | Launchpad doesn't have a very detailed log display, unfortunately. | 01:16 |
| spiv | stefanv: out of interest, what does e.g. http://bazaar.launchpad.net/~bzr/bzr/trunk/changes lack that you'd like to have? | 01:17 |
| stefanv | Oh, that's fine. | 01:18 |
| === kiko is now known as kiko-zzz | ||
| stefanv | I'm referring to the one displayed on the code page. | 01:18 |
| spiv | Oh, right. | 01:18 |
| spiv | thumper: ^ | 01:19 |
| stefanv | It basically comes down to this: we need to be more careful about labelling merges with mainline. | 01:19 |
| stefanv | We need to include something like "Merge in MrX's changes to the build machinery." -- to give credit to the developer | 01:19 |
| stefanv | Instead of relying on his name appearing in the "changelog". | 01:19 |
| thumper | hello | 01:19 |
| stefanv | spiv: https://code.launchpad.net/~vcs-imports/libs/main | 01:20 |
| stefanv | spiv: revisions have a tendency not to appear in that display :) | 01:20 |
| mwhudson | yes, we'd like that to be better | 01:20 |
| poolie | beuno: are you still here? | 01:21 |
| stefanv | mwhudson: if you could implement the snazzy display we see on a tool like olive, that would kick serious ass | 01:22 |
| mwhudson | indeed | 01:22 |
| mwhudson | that sounds like an .... interesting ... challenge | 01:23 |
| stefanv | we've moved IPython onto Launchpad... so we're in it for the long haul | 01:23 |
| mwhudson | one we may even be able to do, but it's a considerable amount of work | 01:23 |
| spiv | stefanv: Commits with multiple authors (because it's a merge of many revisions) could be displayed much better by Launchpad. I think there's work towards doing that, actually. | 01:23 |
| stefanv | spiv: that's great news | 01:24 |
| spiv | mwhudson: it shouldn't be *too* hard. </handwave> | 01:24 |
| LarstiQ | stefanv: of course, bzr log will still show you all those revisions. | 01:24 |
| LarstiQ | stefanv: and if you're merging dev in a feature branch, those revisions will allready be credited earlier on | 01:24 |
| lifeless | LarstiQ: yes, but web uis are more interactive, FSVO inter | 01:24 |
| LarstiQ | lifeless: I agree the trunk log page is really bad | 01:25 |
| mwhudson | spiv: no, that shouldn't be | 01:25 |
| mwhudson | though i don't think we have enough data in the launchpad db to make a merge sort trivial | 01:26 |
| LarstiQ | lifeless: recently lots of people have been complaining that their revisions get lost in merges. Not sure why that plays up now. | 01:26 |
| === bigdo2 is now known as bigdog | ||
| ToyKeeper | About the pull vs merge issue, hg handles it with multiple heads... you can pull even if diverged, but the changes go to a different head. | 01:34 |
| ToyKeeper | I'm not sure whether that's possible in bzr, or if it's even a good idea. | 01:35 |
| spiv | ToyKeeper: well, that's just keeping a separate branch | 01:35 |
| spiv | (in bzr terms) | 01:35 |
| lifeless | and in hg terms too :) | 01:38 |
| stefanv | when are those heads merged? | 01:39 |
| lifeless | in hg, when you do 'hg merge' | 01:39 |
| lifeless | (which you normally do immediately) | 01:40 |
| stefanv | right... and only then is it really useful... | 01:40 |
| ToyKeeper | It can basically let you switch between various branches, in the same directory... work on one head for a while, then a different head, without changing directories. | 01:43 |
| ToyKeeper | I get the impression hg has the feature because git has it, but it seems conceptually simpler to have different directories for different lines of development. | 01:45 |
| stefanv | Yes, that sounds like a potential source of confusion. | 01:45 |
| ToyKeeper | I suppose it would be nice for large projects, to avoid having two copies of history, but both bzr and hg have other ways to do that. | 01:50 |
| spiv | It's also nice to avoid rebuilding large working trees. | 01:51 |
| spiv | And some tools (eclipse is one I think?) also prefer the absolute path not to change, so to work with those tools it can be more convenient to change one tree in place rather than have many trees. | 01:52 |
| spiv | So we have "bzr switch" | 01:52 |
| ToyKeeper | It'd be nice if launchpad merge requests used a merge directive instead of a branch. | 01:53 |
| spiv | thumper: ^ | 01:54 |
| thumper | ToyKeeper: hello | 01:54 |
| ToyKeeper | It seems expensive to use O(project history) space for those instead of O(patch). | 01:54 |
| thumper | ToyKeeper: we have plans, cunning plans | 01:54 |
| ToyKeeper | :) | 01:54 |
| thumper | ToyKeeper: with the new stacking, space will be O(patch) | 01:54 |
| LarstiQ | thumper: when does that roll out? | 01:55 |
| thumper | ToyKeeper: but also we are considering being able to email Launchpad a merge directive :-) | 01:55 |
| thumper | LarstiQ: we are hoping RSN | 01:55 |
| ToyKeeper | At first I was sure I was doing it wrong. :) | 01:55 |
| thumper | LarstiQ: planned release is 1.2.6 | 01:56 |
| ToyKeeper | Wow, that's much sooner than I thought it'd be. | 01:56 |
| thumper | ToyKeeper: it is something we have been looking at for a while | 01:56 |
| mwhudson | speaking of stacking | 01:57 |
| lifeless | Pieter: done | 01:57 |
| LarstiQ | thumper: I know it has been discussed much longer. | 01:57 |
| thumper | LarstiQ: that it has | 01:57 |
| thumper | LarstiQ: I think we started talking about it seriously in October last year | 01:57 |
| LarstiQ | thumper: oooh, 1.2.5 is current. Cool! | 01:57 |
| mwhudson | can someone explain briefly to me the connection between the branches that igc has been sending to the list and the big bundle lifeless sent yesterday? | 01:57 |
| lifeless | "big bundle" heh heh heh | 01:58 |
| lifeless | ig1: where is your stacked loom again ? | 02:01 |
| ig1 | lifeless: http://people.ubuntu.com/~ianc/bzr/shallow-branch/ | 02:02 |
| stefanv | is there a way to apply a bundle, but to assume that the base is the current tree, instead of the one it came from? | 02:02 |
| === ig1 is now known as igc | ||
| lifeless | stefanv: why? doesn't merge do what you want/ | 02:19 |
| beuno | poolie, back | 02:19 |
| lifeless | beuno: I fixed the huge-numbers-of-files things before work this morning | 02:25 |
| beuno | lifeless, you're going too fast, I can't keep up :p | 02:25 |
| * beuno pulls again | 02:25 | |
| lifeless | spiv: is there a bzr-svn python trunk in packs around? | 02:25 |
| beuno | lifeless, I have one locally | 02:25 |
| beuno | igc passed it on to me in the sprint | 02:25 |
| beuno | want me to try and index that? | 02:25 |
| lifeless | L | 02:25 |
| lifeless | LWhatever we decide, I think we should at least file a bug for it | 02:25 |
| lifeless | and maybe add some FIXME here and there, so that a newcomer will | 02:25 |
| lifeless | have a hint or two about what is the way we want things to be | 02:25 |
| lifeless | done and don't get puzzled by finding several different ways in | 02:25 |
| lifeless | bah, copy n paste garh | 02:25 |
| lifeless | beuno: yes | 02:25 |
| spiv | lifeless: http://code.python.org/python/ | 02:26 |
| spiv | (docs at http://www.python.org/dev/bazaar/ should you need them) | 02:26 |
| beuno | lifeless, I get: ImportError: No module named transport | 02:28 |
| lifeless | beuno: argh | 02:29 |
| lifeless | beuno: pushing a replacement revision now | 02:29 |
| beuno | and indexing... | 02:36 |
| beuno | ah, random progress bars! | 02:38 |
| lifeless | thats the inventory walk | 02:38 |
| beuno | ~200mb sustained ram usage | 02:39 |
| beuno | that's as much as it takes to just render a 36k diff with LH :) | 02:40 |
| lifeless | what are you indexing ? | 02:42 |
| beuno | python tree | 02:42 |
| lifeless | interesting; mine is at 585 :P | 02:42 |
| beuno | I haven't passed 201 RES at any point | 02:42 |
| beuno | it sure likes CPU though :) | 02:44 |
| lifeless | are you running 64-bit or 32 ? | 02:45 |
| beuno | 32 | 02:45 |
| lifeless | I'm on 64 | 02:45 |
| lifeless | I suspect thats the difference | 02:45 |
| beuno | yeah | 02:45 |
| beuno | it just jumped to 218 | 02:45 |
| beuno | but it's not that much of a memory hog | 02:46 |
| lifeless | well it finished | 02:46 |
| lifeless | its tunable easily | 02:46 |
| lifeless | dynamic tuning is harder, because python | 02:46 |
| lifeless | time bzr search Andrew Bennetts | 02:47 |
| lifeless | File id '3801@6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:Misc%2FACKS', revision 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:46995'. Summary: 'No summaries yet.' | 02:47 |
| lifeless | Revision id 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:39595'. Summary: 'Patches #1298449 and #1298499: Add some missing checks for error' | 02:47 |
| lifeless | File id '3801@6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:Misc%2FACKS', revision 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:39595'. Summary: 'No summaries yet.' | 02:47 |
| lifeless | real 0m1.412s | 02:47 |
| lifeless | user 0m0.736s | 02:47 |
| * lifeless goes back to merging big branches | 02:47 | |
| lifeless | sys 0m0.096s | 02:47 |
| lifeless | oh, I must say, that having written a search engine now, my respect for evolution-- | 02:48 |
| beuno | beuno@beuno-laptop:~/bzr_devel/test_repos/python$ time bzr index | 02:49 |
| beuno | real10m42.939s | 02:49 |
| beuno | user10m9.302s | 02:49 |
| beuno | sys0m3.868s | 02:49 |
| lifeless | 4 seconds to search a similar corpus, *in C* | 02:49 |
| * mwhudson wonders about spotlight hooks on os x... | 02:49 | |
| beuno | lifeless, 0.5 to search random terms on the python tree. *very* cool :) | 02:50 |
| * beuno goes tackle the nice-url LH branch | 02:50 | |
| === bigdo2 is now known as bigdog | ||
| === rockstar_ is now known as rockstar | ||
| mwhudson | beuno: so i think bits and pieces from paste will probably be sufficient to make a wsgi app version of loggerhead | 03:26 |
| mwhudson | i think what's in loggerhead will become two wsgi apps though | 03:26 |
| mwhudson | one that displays a single branch (replacing BranchView in the current code) | 03:27 |
| mwhudson | and another that has a browse branches view and dispatches branches to the former app as defined by loggerhead.conf | 03:28 |
| mwhudson | (for compatibility if nothing else) | 03:28 |
| beuno | sounds sensible | 03:28 |
| beuno | I'll look into what it will take to replace cherrypy for paste's bits, unless you where planning on doing that | 03:29 |
| mwhudson | except aaaaaaaaaaaaargh | 03:29 |
| mwhudson | oh, hm | 03:29 |
| * beuno hides | 03:30 | |
| mwhudson | oh phew | 03:30 |
| mwhudson | i thought for a moment there that paste shared cherrypy's insanity about %2F's in urls | 03:30 |
| beuno | ah, that would close a bug we have laying around | 03:31 |
| mwhudson | indeed | 03:31 |
| mwhudson | that bug is one of the two reasons i want to get rid of cherrypy | 03:31 |
| mwhudson | (it breaks browsing bzr-svn imports) | 03:31 |
| mwhudson | (although the cleaner-urls branch will help there too) | 03:32 |
| beuno | ah, right, I hadn't thought of that | 03:32 |
| mwhudson | the other is that there's no way of distinguishing _ and . in urls | 03:32 |
| mwhudson | so if someone registers branches called foo.bar and foo_bar in launchpad, you'll only be able to browse code to one of them | 03:32 |
| beuno | that sounds stupid. That's cherrypy screwing up? | 03:33 |
| mwhudson | yes | 03:33 |
| lifeless | its a feature! | 03:33 |
| mwhudson | the %2f thing is probably stupider fwiw | 03:33 |
| lifeless | %2f is at least a standard | 03:33 |
| beuno | yeah, . _ is odd | 03:34 |
| beuno | why would it think it's the same???? | 03:34 |
| lifeless | or do I not understand the discussion :P | 03:34 |
| mwhudson | lifeless: no, that foo%2fbar is the same as foo/bar makes sense | 03:34 |
| mwhudson | lifeless: however with cherrypy foo%252Fbar is the same, too | 03:34 |
| lifeless | oh! | 03:35 |
| lifeless | hmm | 03:35 |
| mwhudson | beuno: cherrpy replaces . with _ because it does url traversal with getattr | 03:35 |
| lifeless | try %252f%25.%25. | 03:35 |
| beuno | ah, ew | 03:35 |
| lifeless | (and escape dot, forgotten the asc() value | 03:35 |
| lifeless | try %252f%2546%2546 | 03:36 |
| lifeless | see if you can escape :) | 03:36 |
| lifeless | (double escaping is a great way to have bugs) | 03:36 |
| lifeless | so . and _ for traversal its nuts | 03:37 |
| AfC | Out of curiosity, why does URL escaping have to be user visible at all? | 03:37 |
| lifeless | if you are going to escape, escape properly | 03:37 |
| mwhudson | lifeless: doesn't seem to work | 03:37 |
| * AfC is presently doing a `bzr push` and I must admit that seeing | 03:37 | |
| mwhudson | lifeless: but i don't really want to think about it | 03:37 |
| lifeless | mwhudson: minor relief; I'd want to look at the code though TBH | 03:37 |
| AfC | Using saved location: bzr+ssh://afcowie@master.gnome.org/home/users/afcowie/public_html/bzr/gtk%2B/trunk/ | 03:37 |
| AfC | seems ... less than ideal | 03:38 |
| lifeless | AfC: in the general case a url can be in any encoding | 03:38 |
| lifeless | AfC: e.g. that could be in big5 | 03:38 |
| mwhudson | lifeless: the code is like this: | 03:38 |
| mwhudson | # Decode any leftover %2F in the virtual_path atoms. | 03:38 |
| mwhudson | virtual_path = [x.replace("%2F", "/") for x in virtual_path] | 03:38 |
| AfC | Um, if you say so. | 03:38 |
| lifeless | AfC: the short story is, its a bug in std66 | 03:38 |
| lifeless | they could have said 'its utf8', instead they recommend that providers (e.g. your server) use utf8, but consumers are told 'it is opaque' | 03:39 |
| AfC | All I know is I wrote "gtk+" and know that the directory I am in is named "gtk+" and the one I am pushing to is named "gtk+". | 03:39 |
| lifeless | I'm kind of surprised + is being escaped, offhand | 03:40 |
| lifeless | I'd need to check the BNF | 03:40 |
| lifeless | AfC: thats because you're on linux going to linux, and all the systems are running locales whose language is one where + maps to 2B. | 03:41 |
| lifeless | AfC: it can easily get extremely feral | 03:41 |
| AfC | still don't know why %2B has to be shown to a user. | 03:42 |
| lifeless | the options are: | 03:42 |
| lifeless | - the url (7-bit data, safe to present) | 03:42 |
| lifeless | - the decoded url (8-bit data, unknown encoding) | 03:43 |
| mwhudson | while i'm whinging about loggerhead, why in the world is http://bazaar.launchpad.net/~mwhudson/pydoctor/dev/changes/1111 a 500? | 03:43 |
| lifeless | - use heuristics on the decoded url to get a unicode string) | 03:43 |
| * mwhudson goes off to do more useful things | 03:43 | |
| lifeless | running full tests on this merged stacked branch now, first thread | 03:44 |
| AfC | My locale is en_CA.UTF-8. That should be more than sufficient to present characters like ' ', '+', and '~'. | 03:44 |
| lifeless | but its not your locale that the url is it | 03:45 |
| lifeless | is *in* | 03:45 |
| lifeless | its in the locale of the process of the remote server | 03:45 |
| AfC | Just seems it would make for a nicer UI for mere humans. Bazaar likes to be good at that sort of thing, so I hear. | 03:45 |
| lifeless | *at best* | 03:45 |
| lifeless | indeed, and I raised this on the http wg list | 03:45 |
| lifeless | backwards compatibility I hear | 03:45 |
| lifeless | AfC: I'm saying I would like to do better, but we also try to be correct, and there is a tension here - some things are harder than others | 03:47 |
| lifeless | mtaylor: ping | 04:00 |
| beuno | mwhudson, sent the clean-urls patch | 04:17 |
| beuno | at some point, I'd like to fit in a good week or two of work to just cook up tests | 04:17 |
| mwhudson | ah yes | 04:18 |
| mwhudson | that would be really really nice :) | 04:18 |
| beuno | for which, btw, we have one failing in trunk | 04:19 |
| mwhudson | ah dammit | 04:19 |
| mwhudson | it's the diff truncation one isn't it? | 04:19 |
| beuno | yes :) | 04:19 |
| beuno | aaaand, I'm off for today | 04:23 |
| lifeless | beuno: gnight | 04:24 |
| beuno | mwhudson, let me know if you need any changes to the clean-urls patch. I'll check back in a few hours | 04:24 |
| mwhudson | beuno: the navigation links still use ugly urls | 04:25 |
| mwhudson | but i like it :) | 04:25 |
| beuno | lifeless, night! I've been thinking of several ways to tackle the re-indexing problem, so I may give it another shot if I get my hands on some free time | 04:25 |
| beuno | mwhudson, argh, I forgot to pass that on from my first branch | 04:26 |
| beuno | I *really* need to clean up my LH branches | 04:26 |
| lifeless | beuno: yah, my lunch at the moment | 04:26 |
| lifeless | beuno: I'm actually just about to do it once I finish putting everything into single packs | 04:26 |
| beuno | lifeless, ah, cool. I'll keep my eye on it, and use that time to get it workin in LH :) | 04:27 |
| mwhudson | beuno: and clicking the 'browse files' link in the annotate view breaks | 04:27 |
| lifeless | beuno: I'd love to have bzr-gtk/bzr-eclipse/loggerhead start having use of it | 04:27 |
| lifeless | beuno: users -> drive interfaces | 04:27 |
| * igc lunch | 04:28 | |
| beuno | mwhudson, that's odd. I didn't touch that... let me poke at it | 04:28 |
| beuno | ah, that's why it breaks. I didn't touch it :) | 04:29 |
| mwhudson | you took the clear=1 out | 04:29 |
| beuno | yeap | 04:30 |
| beuno | I'll do another pass at changes against trunk | 04:31 |
| * Verterok looking if eclipse have a extension point for the search actions | 04:31 | |
| mwhudson | beuno: but thanks heaps for doing this :) | 04:32 |
| beuno | mwhudson, glad to | 04:32 |
| beuno | I hate the way we handle URLs though | 04:32 |
| beuno | we shouldn't have to explicitly have to tell it not to drag the values... | 04:33 |
| mwhudson | yes | 04:36 |
| Verterok | lifeless: as far I can see, bzr-search integration into bzr-eclipse don't look too difficult :D | 04:37 |
| lifeless | Verterok: cool | 04:37 |
| beuno | mwhudson, sent the patch with the fixed clear=1. I'll get the navigation links working tomorrow, as my patch doesn't apply cleanly, and I'm already 20 minutes late :) | 04:38 |
| * beuno waves at Verterok | 04:38 | |
| Verterok | if I can get some spare time, I'ld try to get a working prototype | 04:38 |
| * beuno -> out | 04:39 | |
| mwhudson | beuno: bye | 04:40 |
| Verterok | g'nigth beuno | 04:40 |
| lifeless | Verterok: that would be pretty damn cool :) | 04:41 |
| Verterok | lifeless: indeed :) | 04:42 |
| Verterok | I'll try to do it as an extension to bzr-eclipse...so it 'll be completely optional | 04:43 |
| lifeless | yeah, thats a good idea ;) | 04:43 |
| Verterok | and 'll make my life a lot easier than trying to include it in bzr-eclipse :) | 04:45 |
| poolie | lifeless, spiv, i'm going to talk to spiv then jump into reviews | 05:10 |
| poolie | starting with spiv's resubmitted test patch then the big mutha | 05:10 |
| mwhudson | lifeless: do you want to hear about some typos in BUGS in bzr-search? | 05:15 |
| mwhudson | "does not component components." and "does not component components." | 05:16 |
| mwhudson | no | 05:16 |
| mwhudson | "requires nearly 200B of memory" | 05:16 |
| lifeless | is MB mega bytes or bits. I forget, continuously | 05:16 |
| mwhudson | bytes, according to teh wiki | 05:17 |
| lifeless | anyhow thanks done and pushed | 05:23 |
| lifeless | poolie: igc: the "Development1" patch is the one that needs to change to support stacking on VersionedFiles | 05:23 |
| igc | thanks lifeless | 05:25 |
| lifeless | (and thus the one I would hesitate to land until thats done) | 05:25 |
| lifeless | I'm writing the mail I promised now | 05:25 |
| poolie | lifeless: easy mnemonic: "B" is bigger than "b" | 05:45 |
| lifeless | I'll try | 05:46 |
| lifeless | :) | 05:46 |
| Peng | Re Loggerhead templates, what about Jinja? Or Jinja2? It's not tree-based, but it is supposed to be fast. | 06:47 |
| Peng | mwhudson_: Eek, lp:loggerhead doesn't use packs? | 06:49 |
| mwhudson_ | Peng: no, haven't got around to upgrading it | 06:50 |
| lifeless | mwhudson_: bzr upgrade sftp:// do it now :P | 06:50 |
| mwhudson_ | jinja made my eyes bleed on an 0.1 s impression | 06:51 |
| mwhudson_ | lifeless: on *my* connection after 17:30 ? | 06:51 |
| lifeless | yeah, its a small branch | 06:51 |
| * Peng just spent almost 5 minutes pulling new revisions over http. :P | 06:51 | |
| lifeless | kick it off and forget about it | 06:51 |
| mwhudson_ | Peng: one of them was huge i suspect | 06:51 |
| mwhudson_ | the zpt-templating merge merged over 100 revisions | 06:52 |
| lifeless | or better yet, screen + devpad | 06:52 |
| mwhudson_ | lifeless/Peng: done | 06:56 |
| Peng | :) | 06:58 |
| Peng | Also, my copy had a few inconsistent parents that reconcile can fix. | 07:01 |
| mwhudson_ | Peng: i reconciled trunk too, thanks for the pointer | 07:05 |
| Peng | :) | 07:07 |
| mwhudson_ | (from a machine in the data centre :)) | 07:07 |
| === mwhudson_ is now known as mwhudson | ||
| Peng | Heh, that's cheating. :P | 07:09 |
| poolie | i'm reading igc's "Development1 format" | 07:13 |
| lifeless | poolie: thats the one I'm now editing | 07:14 |
| lifeless | poolie: its the one that has to change | 07:14 |
| Verterok | lifeless: just a quick hack, but is a proof that can be done :-) http://guille.beuno.com.ar/images/bzr-eclipse-search-fullscreen.png | 07:14 |
| lifeless | Verterok: oh man, that rocks | 07:15 |
| lifeless | Verterok: would you prefer to do hit summaries yourself? | 07:17 |
| lifeless | Verterok: e.g. do you want a minimal output of just the keys, or do you want the humanesque output it generates at the moment | 07:17 |
| AfC | Verterok: *nice* | 07:18 |
| AfC | Verterok: excellent place to put it. | 07:18 |
| AfC | I told you about those slanty tabs, though :) | 07:18 |
| lifeless | btw, at my lunch I stabilised the disk format | 07:18 |
| lifeless | its now unlikely to change until major feature changes - like extreme scaling work, or phrase searching, that sort of thing | 07:19 |
| Verterok | lifeless: I was planning to write a xml output so I can integrate it more easy | 07:19 |
| lifeless | Verterok: that would be lovely. I'd be delighted to include that in the plugin | 07:19 |
| lifeless | Verterok: either as a separate command or an option | 07:19 |
| Verterok | lifeless: great. so, that's my next step | 07:20 |
| lifeless | I'm calling it a day for /work/. been paging back in stacking and my mind has melted | 07:21 |
| Verterok | lifeless: I'll draft an xml format and send it to the list | 07:22 |
| lifeless | cool | 07:22 |
| lifeless | I would suspect that only returning the document keys is most appropriate | 07:22 |
| lifeless | your existing bindings for getting file texts and revisions and so on should be more than adequate to generate summaries in eclipse itself | 07:22 |
| lifeless | but you know more than me about that; so please feel free to specify what you'd like most:) | 07:23 |
| Verterok | actually, the current bindings call bzr | 07:23 |
| Verterok | but the upcoming xmlrpc service that should be a lot easier | 07:24 |
| Verterok | s/but/but with/ | 07:24 |
| lifeless | exactly | 07:24 |
| Verterok | lifeless: keys == revid, I'm right? | 07:30 |
| lifeless | Verterok: see DESIGN | 07:31 |
| lifeless | Verterok: ('f', FILEID, REVID) for instance | 07:31 |
| Verterok | ok, thanks! | 07:31 |
| lifeless | is a file hit at a particular revision id | 07:31 |
| lifeless | ('r', '', REVID) is a revision hit | 07:31 |
| === gour is now known as gour_away | ||
| Verterok | I'm slowly getting it :) thanks | 07:32 |
| Verterok | I'm off for today | 07:34 |
| * Verterok heading to bed | 07:34 | |
| Verterok | seeya | 07:34 |
| lifeless | night | 07:36 |
| === mwhudson__ is now known as mwhudson | ||
| uniscript | hi there | 09:35 |
| uniscript | I have two repos: A & B with email interaction only. A is at rev 3, B was at rev 3 but now is at rev 7. How do I create a bundle to update A to rev 7 from B without access to A? | 09:35 |
| * igc dinner | 09:36 | |
| uniscript | cd B && bzr bundle . -r 3..7 ; doesn't cut it because there is nothing much in the bundle since bzr says: well I have the files why put them in the bundle? | 09:38 |
| lifeless | Kinnison: have you seen bzr-search? | 09:46 |
| Kinnison | lifeless: I've not, is this your new indexy thingy for bzr? If so, what is it meant to do? | 09:48 |
| Kinnison | (I saw your blog posting about databases but unfortunately couldn't come up with anything useful) | 09:48 |
| lifeless | Kinnison: https://launchpad.net/bzr-search | 09:49 |
| lifeless | Kinnison: enjoy | 09:49 |
| * Kinnison has been following the threads about stacked branches with interest | 09:50 | |
| Kinnison | Hmm, bzr-search looks amusing, but I can't think of anything particular to do with it right now | 09:50 |
| * Kinnison writes it on his white-board to think about | 09:51 | |
| uniscript | sounds interesting, where might I find a summary on stacked branches and where things are up to? | 09:51 |
| lifeless | Kinnison: its a replacement for bzr log --message, bzr grep, amongst other things | 09:51 |
| lifeless | Kinnison: also annotate | 09:51 |
| lifeless | Kinnison: I've been thinking about the annotation problem for a bit, and I think annotate is just a very crude search | 09:52 |
| Kinnison | hmm, I guess | 09:52 |
| * Kinnison needs coffee before he can think about this in detail | 09:52 | |
| lifeless | :) | 09:52 |
| * Kinnison goes to see if the machine has finished making black heaven | 09:52 | |
| Kinnison | lifeless: any specific bzr requirements for the plugin? | 09:58 |
| lifeless | nah | 09:58 |
| lifeless | I mean, I've only tested with .dev, but its darn generic | 09:58 |
| * Kinnison will update his .dev anyway | 09:58 | |
| Kinnison | coo, branching from launchpad requires SSH | 09:59 |
| * Kinnison removes the air-gap firewall from between his PC and his SSH keys to try again | 10:01 | |
| lifeless | nah, its just because it knows you | 10:01 |
| lifeless | if it didn't it would do http | 10:01 |
| Kinnison | pity it doesn't either fallback | 10:02 |
| Kinnison | s/either/ | 10:02 |
| lifeless | I believe there is now a bug open | 10:02 |
| Kinnison | heh | 10:02 |
| * Kinnison wonders why his key hasn't mounted | 10:02 | |
| lifeless | not enough ponies | 10:03 |
| Kinnison | it's as though hal is not responding | 10:03 |
| fog | Hi, I have a little problem with "bundle"... | 10:11 |
| fog | I have the branch of a friend locally (call it X) and i merged from him into my branch (call it Y) | 10:11 |
| fog | then I did some changes to my branch, now I want to send him the changes... | 10:11 |
| fog | sincerely from the docs I don't understand what the submit and public branches are... :( | 10:12 |
| Kinnison | lifeless: I've decided that my best bet for trying this search tool on a respectable codebase is to make a branch of one of our projects at work | 10:12 |
| Kinnison | lifeless: so bzr-svn is currently amusing itself with our svn server | 10:12 |
| james_w | fog: you probably want "bzr send ../X" | 10:14 |
| james_w | the submit branch is the branch that you are wanting to submit your changes to | 10:14 |
| james_w | the optional public branch is a public location where your branch can be accessed if the other person would like to merge from that instead | 10:15 |
| james_w | (or it allows you to do --no-bundle) | 10:15 |
| fog | james_w: ah.. I understand. thank you very much. | 10:17 |
| fog | james_w: mm.. why bundle bundles my shelved changes? | 10:17 |
| lifeless | Kinnison: ok | 10:18 |
| lifeless | fog: you have committed them I think :P | 10:18 |
| james_w | hi lifeless | 10:18 |
| fog | lifeless: nope, I just shlved them. | 10:19 |
| james_w | send doesn't use the working tree, so that would be very strange. | 10:19 |
| fog | james_w: something is not working.. because I forgot to commit my changes but they appear in the bundle (togheter with the shelved ones...) | 10:20 |
| fog | ok, let me restart with a clean tree... | 10:20 |
| Pieter | lifeless: I'll check it out then :) | 10:21 |
| Pieter | if I've done a bzr pull, how can I get a log showing only the changes that were pulled? | 10:22 |
| fog | james_w: ok, I branched my fried branch, copied the modified files,commited and sent. it worked, thanks. | 10:23 |
| === gour_away is now known as gour | ||
| lifeless | Pieter: after the pull no; you can do 'bzr missing' before the pull, or note the revision number before you pull and do log -r $number.. | 10:25 |
| Pieter | hmm, too bad | 10:25 |
| lifeless | something for us to improve on | 10:26 |
| lifeless | its actually a little tricky :/ | 10:26 |
| lifeless | hmm, I should teach commit-notify to include all the changes in a gui window | 10:34 |
| lifeless | spiv: lets talk tomorrow about the tuple keyspace | 10:35 |
| Pieter | lifeless: it's done already | 10:46 |
| Pieter | nice | 10:46 |
| lifeless | Pieter: cool | 10:50 |
| lifeless | Pieter: now try searching :) | 10:50 |
| Pieter | I did.. it's pretty fast :) | 10:50 |
| lifeless | pure python FTW | 10:51 |
| === gour is now known as gour|away | ||
| lifeless | Pieter: cool, well it works and is fast :) not much more to say really, except that I love feature requests, ui tweaks, and patches :) | 11:03 |
| Pieter | lifeless: it'd be nice to see the context a string is found in :) | 11:08 |
| lifeless | yeah a summary | 11:10 |
| lifeless | I have some plumbing to do | 11:10 |
| lifeless | I want the core of the system to be really robust | 11:11 |
| lifeless | fire n forget level | 11:11 |
| lifeless | then I'll look at that; unless someone beats me to it | 11:12 |
| lifeless | be good to do hits on deletes too, but our deltas don't record that (they are not reversible deltas) | 11:13 |
| lifeless | one of the reasons its half decent at indexing is not doing diffs | 11:14 |
| Pieter | dato: if you're trying to export a parentless commit for the same branch, it's easier to just do a "reset refs/heads/branch" than creating a temporary branch | 11:24 |
| Pieter | (in bzr-fast-export) | 11:24 |
| * lifeless kills npviewer.bin again | 12:30 | |
| jelmer | lifeless: did you see my reply about pqm? | 12:50 |
| lifeless | jelmer: yes, and its moving now | 12:50 |
| jelmer | lifeless: cool | 12:51 |
| jelmer | lifeless: is there any branch with your versionedfile API changes available ? | 12:53 |
| jelmer | lifeless: in particular the removed API functions, so I can make sure the rebase, svn and remove-revisions plugins keep working for 1.6 | 12:53 |
| lifeless | jelmer: yes,the one in the bundle header | 12:53 |
| lifeless | I'm pushing it again to be sure now | 12:54 |
| Kinnison | lifeless: should I expect a progress bar from 'bzr index' ? | 12:54 |
| Kinnison | lifeless: 'cos it's sat not showing me anything, having pegged one of my CPUs | 12:54 |
| lifeless | Kinnison: no, UI comes lastish | 12:55 |
| Kinnison | kay | 12:55 |
| Kinnison | oooh, done now | 12:55 |
| Kinnison | that was actually quite quick, for indexing this codebase over 6000 revs | 12:55 |
| Kinnison | but the search output is perhaps not as nice as it could be | 12:56 |
| * Kinnison picks his way through some results | 12:56 | |
| lifeless | yes | 12:56 |
| lifeless | there are two big problems with searching | 12:56 |
| lifeless | well three | 12:56 |
| lifeless | selecting good results | 12:56 |
| lifeless | selecting a good number to show | 12:56 |
| Kinnison | nod. | 12:57 |
| lifeless | oh yeah, and showing the results nicely | 12:57 |
| james_w | I'm halfway through a merge, and I want to find out what the remaining changes in my working tree are compared to the branch that I just merged, is there a way to do that? | 12:57 |
| Kinnison | File id '3720@507b4074-7016-0410-bdd2-fba35d1e0378:import%2Fable%2Ftrunk:core%2Fsystem%2Fmachine%2Fvr1000%2Fvr1000.c', revision 'svn-v3-trunk2:507b4074-7016-0410-bdd2-fba35d1e0378:projects%2Fable%2Ftrunk:11722'. Summary: 'No summaries yet.' | 12:57 |
| Kinnison | that's *so* not a useful result | 12:57 |
| lifeless | I don't claim that this does any of them :P | 12:57 |
| Kinnison | and yet, does tell me what I would need in order to look | 12:57 |
| lifeless | Kinnison: yah, index.py if you want to improve the output | 12:57 |
| lifeless | (the display I mean, I'm not asking for folk to solve the really hard bits for me) | 12:58 |
| Kinnison | heh, it's 13:00 and today I've done exactly 20 minutes of the work I was meant to so-far | 12:58 |
| * Kinnison had a potential-customer-based-diversion :-( | 12:58 | |
| james_w | ah, bzr diff --old other-branch, seems to be what I want. | 12:58 |
| lifeless | Kinnison: well, that means this diversion can keep you entirely distracted | 13:00 |
| Kinnison | such a wonderful offer | 13:01 |
| Kinnison | :-) | 13:01 |
| === Mez is now known as Mez|DPC | ||
| mtaylor | lifeless: dude. even just removing the .bzr/bzr-search dir to try your new patch is taking FOR EVER | 14:59 |
| ricardokirkner | hi everyone | 15:27 |
| ricardokirkner | how can I debug the bzr+http protocol? | 15:40 |
| ricardokirkner | I am getting some errors, and I want to find out exactly where this is happening in the code | 15:40 |
| mtaylor | ricardokirkner: I'm guessing tcpdump isn't the answer you're looking for | 15:41 |
| ricardokirkner | no, actually I want to find out what part of the bzr code is responsible for handling the bzr+http protocol, so I can set a breakpoint there and go step by step until I find the line that is causing the problem | 15:42 |
| ricardokirkner | I think the smart/server.py file is responsible for bzr:// protocol, does it also handle bzr+http? | 15:42 |
| james_w | ricardokirkner: yeah, I think so | 15:49 |
| james_w | adding -Dhpss to the command line will print more information to your ~/.bzr.log | 15:49 |
| Peng | Wait...bzr with https doesn't verify SSL certs, does it? | 15:49 |
| ricardokirkner | yes, I did that, but it didn't give me useful information | 15:50 |
| ricardokirkner | maybe you know what might be happening... I am getting an error response | 15:50 |
| Peng | You could -Dhttp too. | 15:50 |
| ricardokirkner | 'module' has no attribute 'ElementTree' | 15:50 |
| Peng | Um. | 15:50 |
| Peng | From which side? | 15:50 |
| Peng | And, that's not supposed to happen. | 15:50 |
| james_w | ricardokirkner: ah, that sounds like the module is being replaced by another from somewhere else. | 15:50 |
| ricardokirkner | I am using python2.4 here, maybe this might be because I have elementtree and cElementTree installed? | 15:51 |
| ricardokirkner | the strange thing is.. this happens only when using the smart server over http | 15:53 |
| ricardokirkner | but not when using the smart server directly | 15:53 |
| === ja2 is now known as j1 | ||
| === j1 is now known as jam | ||
| ricardokirkner | and, when using over http, this happens only when I access a second repository (it works ok with the first repository hit, regardless of which one it is, but breaks with the second, regardless of which) | 15:54 |
| james_w | yeah, from your description it sounded like apache was swapping somehthing around | 15:54 |
| ricardokirkner | james_w, so maybe apache is modifying the PYTHONPATH variable? that might be the reason? | 15:54 |
| james_w | something like that | 15:55 |
| james_w | or even possibly playing around with the loaded modules | 15:55 |
| james_w | I'm not familiar with apache and python though, what method are you using for running the python? | 15:55 |
| james_w | (mod_python, fastcgi, etc.) | 15:56 |
| ricardokirkner | the server is running several trac instances, so I guess it's using mod_python... originally I was using mod_python for my bzr wsgi interface, but according to some issues with that I tried to use mod_wsgi directly (which is what I am using now) | 15:59 |
| james_w | is there something you can turn on in python to get debugging info about imports? | 16:00 |
| jam | james_w: well there is "bzr --profile-imports" :) | 16:00 |
| james_w | hi jam | 16:00 |
| jam | there is a script 'profile_imports.py' in the bzr source tree | 16:00 |
| jam | you could adapt that if you want | 16:00 |
| james_w | is there any chance that lazy_import could be messing with this? | 16:01 |
| jam | I don't really know about working on it with apache, etc | 16:01 |
| jam | lazy_import is only used explicitly | 16:01 |
| jam | it doesn't cause other things to be lazily imported | 16:01 |
| jam | so it is unlikely, though always possible | 16:01 |
| ricardokirkner | I just turned mod_python off in the web server, and bzr started working, so this is a compatibility issue with mod_python somehow | 16:02 |
| ricardokirkner | ups | 16:03 |
| ricardokirkner | not | 16:03 |
| ricardokirkner | still broken | 16:03 |
| ricardokirkner | ok, this is absolutely beyond me... the error is hapenning at the line with | 16:30 |
| ricardokirkner | elementtree.ElementTree._escape_attrib = _escape_attrib | 16:30 |
| ricardokirkner | just before that line I did log the elementtree.__file__ and elementtree.__path__ values | 16:30 |
| ricardokirkner | and on both calls (the one that works, and the one that don't) it returns exactly the same value | 16:31 |
| james_w | ricardokirkner: can you add a log of dir(elementtree) as well please? | 16:34 |
| ricardokirkner | yes, just wait a second | 16:34 |
| jam | ricardokirkner: it could easily be that one of them didn't import "elementtree.ElementTree" | 16:37 |
| jam | which is actually a module IIRC | 16:37 |
| ricardokirkner | ok... now I found a difference I didn't saw before | 16:37 |
| jam | the class is actually. elementtree.ElementTree.ElementTree | 16:37 |
| ricardokirkner | the first time (the one it works) it outputs as __path__ /usr/lib/python2.4/site-packages/elementtreeElementPath | 16:38 |
| ricardokirkner | while the second time it outputs /usr/lib/python2.4/site-packages/elementtree__builtins__ | 16:38 |
| fredreichbier | elementtree is xml.etree.ElemenTree afaik for python2.5 | 16:38 |
| fredreichbier | *Element | 16:38 |
| ricardokirkner | the __file__ variable is always the same | 16:38 |
| jam | ricardokirkner: i think the file is based on the .pyc file | 16:38 |
| jam | which may have been pre-computed in a different directory | 16:38 |
| ricardokirkner | yes | 16:38 |
| jam | so if I compile a file and then move the .pyc it remembers the old path | 16:39 |
| ricardokirkner | mhhh.... are you suggesting I should remove the .pyc file and let it be regenerated? | 16:40 |
| ricardokirkner | ok, again... the previous was incorrectly pasted together | 16:42 |
| ricardokirkner | in both cases I get both __file__ and __path__ to be the same | 16:42 |
| ricardokirkner | but.. in the first case, dir(elementtree) outputs ElementPath and ElementTree while in the second case it doesn't | 16:43 |
| ricardokirkner | now. how can that be? | 16:43 |
| jam | ricardokirkner: because they are sub-modules that aren't imported yet | 16:45 |
| jam | they are *not* classes that are in the 'elementtree' file | 16:45 |
| ricardokirkner | but I am executing the same line at the same point in execution time | 16:46 |
| jam | someone needs to do "import elementtree.ElementTree" first | 16:46 |
| jam | ricardokirkner: it sounds like it is a race with something else that is doing the import for you | 16:46 |
| ricardokirkner | mhhh | 16:46 |
| === kiko is now known as kiko-fud | ||
| jam | !paste | 16:47 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 16:47 |
| jam | ricardokirkner: you might try this: | 16:47 |
| jam | http://paste.ubuntu.com/19664/ | 16:47 |
| jam | it looks like we have our own possible import race | 16:48 |
| ricardokirkner | jam, I did something like that, and it appears to have worked.. but on that issue | 16:48 |
| ricardokirkner | after importing the parts from cElementTree | 16:49 |
| jam | depending on if cElementTree imports elementtree.ElementTree | 16:49 |
| ricardokirkner | shouldn't it be importing cElementTree as elementtree | 16:49 |
| ricardokirkner | instead of importing of elementtree? | 16:49 |
| jam | ricardokirkner: no, they don't have the same objects | 16:49 |
| jam | in the past, cElementTree used specific objects out of elementtree.ElementTree | 16:49 |
| jam | (like elementtree.ElementTree.ElementTree) | 16:50 |
| ricardokirkner | jam, what I did is http://paste.ubuntu.com/19666/ | 16:51 |
| ricardokirkner | can you tell me what is wrong with that ? | 16:51 |
| jam | ricardokirkner: the second "from elementtree import ..." is importing from the *real* elementtree | 16:51 |
| jam | cElementTree doesn't have a sub-module ElementTree | 16:51 |
| jam | it has a *class* ElementTree | 16:51 |
| jam | ricardokirkner: elementtree's disk layout is a bit.... psyco | 16:52 |
| jam | there is a class... called ElementTree | 16:52 |
| jam | available as either | 16:52 |
| jam | cElementTree.ElementTree | 16:52 |
| jam | *or* | 16:52 |
| jam | as elementtree.ElementTree.ElementTree | 16:52 |
| ricardokirkner | but, if I imported cElementTree as elementtree, after that, referencing elementtree shouldn't be pointing to cElementTree , actually hiding the old elementtree? | 16:52 |
| jam | ricardokirkner: no | 16:52 |
| jam | the *local variable* is pointing there | 16:53 |
| jam | but "from XXXX import YYYY" doesn't look at local variables | 16:53 |
| jam | it looks at "sys.modules" | 16:53 |
| jam | which contains the "real" names | 16:53 |
| jam | the patching you see later on | 16:53 |
| ricardokirkner | jam, alright, that was confusing for me, but if you say so, I will take your word on that until I can look into it a bit further to grasp why that is so | 16:54 |
| jam | is also touching the *module* 'elementtree.ElementTree' not the class "elementtree.ElementTree.ElementTree" | 16:54 |
| jam | so doing "import cElementTree as elementtree" doesn't give us the module where we expect to find it | 16:54 |
| jam | http://paste.ubuntu.com/19664/ is all you should need to do | 16:54 |
| ricardokirkner | so, forcing the import of elementtree.ElementTree after importing elementtree could be an option, right? (I mean, this isn't so bad as not be considered as a patch for next release?) | 16:55 |
| jam | ricardokirkner: I was going to submit it right now | 16:55 |
| jam | for review | 16:55 |
| ricardokirkner | ok, then I am applying it right now, so I can get back to work :-) | 16:55 |
| ricardokirkner | thank you very much | 16:55 |
| ricardokirkner | it was kind of hard to trace for me, so the help is very much appreciated | 16:56 |
| jam | I'm happy to help when I can | 17:01 |
| === kiko-fud is now known as kiko | ||
| wingo-tp | good day. i seem to be experiencing the KnitCorrupt bug from https://bugs.launchpad.net/bzr/+bug/234748, when running bzr check or bzr upgrade, but it is still there even with newest bzr. bzr reconcile fails also | 17:19 |
| wingo-tp | has that fix actually been merged to bzr.dev? | 17:19 |
| ubottu | Launchpad bug 234748 in bzr "Knit inventory corrupt in bzr.dev with bzr.dev r3452 (KnitCorrupt)" [High,Fix released] | 17:19 |
| wingo-tp | it seems that it has... | 17:20 |
| vila | jam: ping, bzr-commits disagree with that bzr revno http://bzr.arbash-meinel.com/branches/bzr/1.6-dev/annotation/ says >-/ | 17:20 |
| vila | I wanted to have a look but it seems that you don't push there ? How come the bzr-commit mails can diverge ? | 17:21 |
| vila | jam: I'm more interested in looking into your stuff that understanding the divergence, so a push or a correct url will be enough :) | 17:21 |
| jam | vila: I don't automatically push anymore, but I'll do a push right now | 17:22 |
| vila | jam: thks | 17:22 |
| jam | there is a small bug I need to commit a fix for, give me a sec | 17:23 |
| vila | a whole minute even... | 17:24 |
| wingo-tp | ahem. does anyone know what might be up with the KnitCorrupt thing/ | 17:33 |
| wingo-tp | ? | 17:33 |
| jam | vila: 2 bits, I'll be doing the real work on the 'annotation' branch | 17:34 |
| jam | but you may want to grab annotation_policy_cmd | 17:34 |
| jam | because it exposes 'bzr annotate --policy=XXX' | 17:35 |
| jam | wingo-tp: there are different variations on what causes KnitCorrupt to be raised | 17:35 |
| jam | sometimes it is genuine disk corruption | 17:35 |
| jam | the specific case listed in that bug has been fixed | 17:35 |
| jam | Do you know if that is what you are experiencing? | 17:35 |
| vila | jam: for a start, I want to have a look at the tests adaptation/application since lifeless said he want to get rid of all classes | 17:36 |
| wingo-tp | jam: i pulled from bzr today, so if that bug is fixed, it is not the bug that i am experiencing | 17:36 |
| wingo-tp | disk corruption would be the badness | 17:36 |
| jam | wingo-tp: are you seeing "Knit *inventory* corrupt" | 17:36 |
| jam | or just "Knit Corrupt" ? | 17:36 |
| jam | (do you have the traceback to paste)? | 17:36 |
| jam | !past | 17:36 |
| ubottu | Factoid past not found | 17:36 |
| jam | !paste | 17:36 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 17:36 |
| wingo-tp | i do have it, /me goes to pastebin | 17:37 |
| wingo-tp | http://paste.ubuntu.com/19674/ | 17:38 |
| jam | wingo-tp: any chance you would have had 2 conversions of the arch tree | 17:39 |
| jam | possibly with one of them having more history than the other? | 17:39 |
| wingo-tp | perhaps it had something to do with the fact that it was imported from arch a long time ago, but i have upgraded it since -- i first saw this error when trying to upgrade to ricj-root-packs | 17:39 |
| wingo-tp | jam: this is possible, i suppose | 17:39 |
| jam | wingo-tp: so what it *could* be, is that at one point you did a conversion with a different amount of history | 17:40 |
| jam | which caused the "last-modified" fields in the inventories to differ | 17:40 |
| jam | at some point after that, the branches were merged together | 17:40 |
| jam | and they didn't notice that the inventories they were referencing had a different text | 17:41 |
| jam | and so they pulled across a delta which technically only applies to the *other* base | 17:41 |
| jam | and thus when applied to this base, the sha-1 doesn't match | 17:41 |
| jam | I would have thought you would encounter the error sooner rather than later | 17:41 |
| jam | I probably can hack something together as a workaround, but a real fix is probably a bit involved. | 17:42 |
| wingo-tp | odd.. i mean, i can bzr log all of the branches in this repo | 17:42 |
| jam | wingo-tp: we don't need inventories to do 'bzr log' | 17:42 |
| jam | just revisions | 17:42 |
| jam | different place | 17:42 |
| wingo-tp | ok | 17:42 |
| jam | if you did "bzr log --verbose" | 17:42 |
| jam | Then you would probably get the failure | 17:42 |
| wingo-tp | indeed i do get the failure | 17:43 |
| wingo-tp | after a merge with another arch branch | 17:43 |
| jam | wingo-tp: is this a recent conversion? | 17:43 |
| wingo-tp | no it is not | 17:43 |
| wingo-tp | about august 2006 | 17:43 |
| jam | wingo-tp: is this a recent merge of that other branch, though? | 17:44 |
| wingo-tp | jam: nope | 17:44 |
| jam | the guile-gnome-pkg--release--0--base-0 branch? | 17:44 |
| wingo-tp | no, i completely left arch around august of 2006 | 17:44 |
| jam | I'm talking mostly about a branch derived from that revision | 17:44 |
| jam | not merging that revision specifically | 17:44 |
| wingo-tp | and have not done merges from other branches that hadn't been forked off of this one | 17:44 |
| wingo-tp | i guess what you are saying is possible, but i don't think so. | 17:45 |
| jam | wingo-tp: I'm just trying to figure out why you are hitting it *now* rather than earlier | 17:46 |
| wingo-tp | jam: well, i've never run bzr check before | 17:46 |
| jam | do you have any idea of things that have been happening recenty? | 17:46 |
| jam | oh, well I suppose that might do it | 17:46 |
| wingo-tp | so if a previous bzr upgrade happened and did not run bzr check... | 17:46 |
| jam | if you never access that revision, it wouldn't ever find it broken | 17:46 |
| wingo-tp | that very well could be | 17:46 |
| jam | specifically, we check sha1 sum whenever we extract the full text | 17:46 |
| jam | but you may have never needed to do that | 17:46 |
| wingo-tp | right | 17:46 |
| jam | I'm guessing you have a very small few nodes that are effected | 17:47 |
| jam | and it is restricted to a specific local part of ancestry | 17:48 |
| jam | wingo-tp: how high of a priority is this for you, as in, does it block something you are trying to do? | 17:48 |
| jam | I don't have a lot of time to write a workaround right now, unless you really need it | 17:49 |
| jam | wingo-tp: but I *would* ask you to submit a new bug | 17:49 |
| jam | if you can, link to the branch that shows the problem | 17:49 |
| wingo-tp | jam: i can wait a while, i think; | 17:50 |
| wingo-tp | how do you think this will affect people who have checkouts of this branch? they will have to re-pull, no? will all the sha1's be different, like in git? | 17:50 |
| wingo-tp | it's http://arch.gna.org/guile-gnome/bzr/pkg/ | 17:51 |
| jam | wingo-tp: only a few local sha1s will be changed | 17:51 |
| jam | I'm not sure how we would be able to propagate that to everyone | 17:51 |
| jam | it shouldn't change the whole ancestry | 17:51 |
| wingo-tp | i should just tell everyone to branch again, no? | 17:51 |
| jam | wingo-tp: they would have to clear out any repository that they have | 17:52 |
| wingo-tp | ok | 17:52 |
| jam | It is probably easier to just have them all run whatever fix I come up with | 17:52 |
| wingo-tp | (thanks for looking at this, btw) | 17:52 |
| jam | anyway, time for me to go to lunch | 17:54 |
| wingo-tp | bug #239499 | 18:00 |
| ubottu | Launchpad bug 239499 in bzr "corrupt knit index on an old arch-imported bzr repo" [Undecided,New] https://launchpad.net/bugs/239499 | 18:00 |
| wingo-tp | tx much! | 18:00 |
| Tsmith | hey | 18:02 |
| Tsmith | I have a main trunk/ and a branches/tsmith; I want the changes in trunk/ to be applied to tsmith/ how do i do this? | 18:03 |
| james_w | hi | 18:04 |
| james_w | do this: | 18:04 |
| james_w | cd branches/tsmith | 18:04 |
| Tsmith | k | 18:04 |
| james_w | bzr merge ../trunk | 18:04 |
| james_w | resolve any conflicts | 18:04 |
| james_w | bzr resolve | 18:04 |
| james_w | bzr commit | 18:04 |
| Tsmith | 6: tsmith 2008-06-12 Merge with trunk -r4. | 18:06 |
| Tsmith | 5: tsmith 2008-06-12 Change file perms to 0664 and ownership to tsmith:users. | 18:06 |
| Tsmith | is that right? | 18:06 |
| Tsmith | does each branch have a unique -r #? | 18:06 |
| Tsmith | bzr is so friggin awesome :O | 18:08 |
| pickscrape | OT: Would I be right in thinking that https://bugs.launchpad.net/php is the correct place to report bugs that only affect php on ubuntu? | 18:15 |
| Tsmith | hey what does bzr switch do? | 18:16 |
| Tsmith | or better: where's the doc? :p | 18:16 |
| pickscrape | Tsmith: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#switch | 18:18 |
| Tsmith | great stuff | 18:18 |
| james_w | pickscrape: https://bugs.launchpad.net/ubuntu/+source/php5 | 18:21 |
| james_w | Tsmith: each branch doesn't have unique revision numbers, however, they do have unique revision ids | 18:22 |
| james_w | Tsmith: if you do bzr log --show-ids in your branches/tsmith branch then you will see the unique ids that they are assigned | 18:22 |
| Tsmith | ahhhh | 18:22 |
| james_w | you will also see the revisions from the trunk that you did not have before the merge indented under the merge commit, indicating that they were merged in there. | 18:23 |
| james_w | you will also see that they have a three digit revision number. | 18:23 |
| Leonidas | is there a way to mark a branch as "merged, please don't try to merge again"? | 18:23 |
| pickscrape | james_w: thanks. So it's the *ubuntu* project, not the PHP one. | 18:24 |
| Tsmith | revno: 3.1.1 | 18:24 |
| james_w | this means that you have the same revision on trunk and your branch, they have the same revision id which means they are the same. They have different revision numbers though. | 18:24 |
| james_w | so if you want to talk about a specific revision then either use its revision id, or use the revision number *and* the branch in which it has that number. | 18:25 |
| james_w | pickscrape: yup. | 18:25 |
| james_w | Leonidas: nope, but if you try and merge again it will tell you that there is nothing to do. | 18:26 |
| jelmer | james_w: hi | 18:26 |
| pickscrape | james_w: how would I browse there? In other words, how should I have found that myself? | 18:26 |
| Leonidas | james_w: yeah, thats probably good enough. | 18:26 |
| pickscrape | (Sorry for the continued OT) | 18:26 |
| jelmer | james_w: did you see my patch that added support for +bzr in bzr-builddeb? | 18:26 |
| james_w | hi jelmer | 18:27 |
| Tsmith | i'm sorry to bug you guys so much, but I wwould like to now push my local repository to my server. What do i do so that only the bzr repository and not all the files in it are on the server? | 18:27 |
| james_w | jelmer: yup, thanks for sending it, I shouldn't have missed it. I'll merge it tomorrow. | 18:27 |
| james_w | pickscrape: I'm not sure, if you knew you wanted to file a bug against Ubuntu then starting at the Ubuntu project may have been right. Launchpad isn't all about Ubuntu. | 18:28 |
| james_w | pickscrape: though these projects that are there but not used by the upstreams do confuse matters somewhat. | 18:29 |
| jelmer | james_w: cool, thanks | 18:29 |
| james_w | Tsmith: that will happen by default. Normally people ask why it doesn't happen the other way round :-) | 18:29 |
| james_w | Tsmith: do you have bzr installed on the server? | 18:30 |
| Tsmith | yes | 18:30 |
| james_w | Tsmith: cool, "bzr push bzr+ssh://server/location/on/server" should get you what you want. | 18:30 |
| james_w | Tsmith: though you may want to set up a revision storage area there first which will make it more efficient to push multiple branches. | 18:31 |
| Tsmith | that'w hat i want | 18:31 |
| james_w | Tsmith: (as an aside, I'm not sure if you are aware, but bzr doesn't care what you call your branches, so you don't need trunk/ and branches/ you can call them not-trunk/ and tsmiths-not-a-branch/ if you like) | 18:32 |
| Tsmith | yeah | 18:32 |
| james_w | ok, to do that then you need the "bzr init-repo" command. | 18:32 |
| james_w | bzr init-repo --no-trees bzr+ssh://server/location/for/repo/ | 18:32 |
| Tsmith | got it! | 18:32 |
| james_w | this creates a "shared repo". shared isn't about multiple users, it's about sharing revision storage between branches for efficiency. | 18:33 |
| james_w | now, any branch that you push below /location/for/repo/ on your server will store it's revisions there, so when you push a new branch it will only have to push any revisions that aren't already there, which should be a lot less work. | 18:34 |
| james_w | you may wish to set one up on your local machine as well, as it makes things like branching quicker, as well as reducing disk space usage. | 18:34 |
| Tsmith | k | 18:34 |
| james_w | if you do that then don't use --no-trees, as you do want the branches to have working trees, so you can actually get some work done. | 18:35 |
| Tsmith | i have a dummy question | 18:35 |
| Tsmith | i have a local repo w/ two branches | 18:35 |
| james_w | doing that in your existing area won't make the existing branches use the shared storage though, I can explain how to get around this if you like. | 18:35 |
| Tsmith | i have pushed the main repo successfully, after following your instructions. do i now need to push the branches too? | 18:35 |
| james_w | you ran "bzr push" while in trunk/? | 18:36 |
| Tsmith | yes | 18:36 |
| james_w | ok, so you pushed the trunk *branch* up | 18:37 |
| Tsmith | yes that's right | 18:37 |
| james_w | bzr works on branches, not on repos | 18:37 |
| Tsmith | k | 18:37 |
| james_w | so you have only pushed the revisions that are needed for trunk, if you want your branches to be available on the server as well then you need to push them separately. | 18:37 |
| Tsmith | k | 18:38 |
| === BasicPRO_ is now known as BasicOSX | ||
| === mw is now known as mw|food | ||
| Tsmith | is there the oposite of .bzr/ignore? i only want to show *.php *.inc, etc. | 19:29 |
| Peng | Using a complicated regexp perhaps? | 19:32 |
| === bigdo2 is now known as bigdog | ||
| === BasicPRO is now known as BasicOSX | ||
| mtaylor | Tsmith: just don't add anything but the *.php and *.inc in the first place? | 19:57 |
| mtaylor | Tsmith: like "find . -type f -name '*.php' | xargs -n1 bzr add" or something? | 19:57 |
| Tsmith | lol bzr status shows a massive list ;p | 19:58 |
| Tsmith | i found the solution: | 19:58 |
| Tsmith | .bzrignore in the trunk's root | 19:58 |
| mpt | I have an obscure question about conflict resolution that isn't covered in <http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#conflicts-types> | 20:02 |
| mpt | What should I do when I have both a path conflict and a contents conflict for the same file? | 20:03 |
| mpt | Which should I resolve first? | 20:03 |
| tolstoy | Folks: When I do a "push" to a local directory, I get the whole file tree. Is there a way to suppress that? | 20:51 |
| tolstoy | We're using a server as a "source-of-truth" and I'd like to be able to properly create repos without the trees even if working locally. | 20:52 |
| tolstoy | bzr remove-tree fixed it, I guess. | 21:02 |
| james_w | tolstoy: yep, that will fix it. To create a shared repository that does this by default use the --no-trees option to init-repo | 21:08 |
| tolstoy | Okay. Odd that "push" removed trees only when it's a remote file system. Then again, I guess that makes sense. | 21:09 |
| james_w | tolstoy: yeah, it's hard to do it remotely so it doesn't | 21:09 |
| james_w | the inconsistency with local push could be removed I guess, but so many people wonder what's wrong when remote push doesn't create/update a working tree that we should probably do it when we can. | 21:10 |
| james_w | mpt: I'm not sure how you can have both types at once. | 21:10 |
| james_w | mpt: I imagine you have to resolve both at the same time, in that you can only call "bzr resolve" when both are fixed. | 21:11 |
| mpt | james_w, it was a criss-cross | 21:11 |
| james_w | mpt: in terms of doing it you probably want to move the correct file in to place first, and then fix the content. | 21:11 |
| mpt | ok | 21:11 |
| mpt | We have a maximum branch length, so I thought I'd be clever and pull some revisions out of this branch and merge them into mainline, and then merge mainline back into this branch | 21:12 |
| mpt | (a maximum branch length for code review purposes, I mean) | 21:13 |
| mpt | ... But I forgot that I'd renamed the files in this branch, in a revision *after* the one I merged into mainline. | 21:13 |
| === mwhudson_ is now known as mwhudson | ||
| pickscrape | Is there any plan in place for allowing partial working copies? | 21:15 |
| lamont | is it normal for bzr visualise to say 'AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'" ?? | 21:16 |
| lamont | that's bzr 1.6~beta2-1 and bzrtools 1.6.0-1, fwiw | 21:16 |
| james_w | pickscrape: at the last sprint we talked about a way that would let you do that and a few other things, but I don't think anyone's got anywhere near implementation. | 21:17 |
| james_w | lamont: hi, what's your version of bzr-gtk? | 21:17 |
| lamont | 0.93.0-1. | 21:17 |
| lamont | I bet that's it, eh? | 21:17 |
| james_w | yeah, that's too old | 21:17 |
| pickscrape | james_w: thanks, good to know it is at least in mind. That's one thing I know I'll get a few complaint about when we switch :) | 21:17 |
| lamont | 0.94.0-1 is new enough? (latest intrepid) | 21:18 |
| james_w | pickscrape: yeah, though we're even further off limiting the amount of repository data you need for a partial working tree. | 21:18 |
| Tsmith | hey bzr up -r4 filename doesn't work. is there a way to update a file to a particular -r? | 21:18 |
| james_w | pickscrape: so it would at least allow you to ignore parts of the tree you didn't care about, but wouldn't reduce the time to branch | 21:19 |
| james_w | lamont: I don't think it will be, we should really get that updated. | 21:19 |
| pickscrape | james_w: I'm not actually bothered about that. It's mainly so people can just 'checkout' the bits they actually care about with regard to the work they're currently doing. | 21:19 |
| pickscrape | They'll all be using shared repositories anyway, so they'll have the lot regardless. | 21:20 |
| lamont | james_w: pretty please... :-) | 21:20 |
| pickscrape | But I understand that in the more general use case limiting revision size would also be nice :) | 21:20 |
| james_w | lamont: I don't think there's been a release to update to though. | 21:20 |
| lamont | james_w: yeah... 0.94.0 according to http://bazaar-vcs.org/bzr-gtk?action=show&redirect=BzrGtk | 21:21 |
| james_w | lamont: if you can confirm whether 0.94 works I would appreciate it. | 21:21 |
| james_w | pickscrape: yeah, I think that's why a lot of people want it, but it can be done in separate stages at least. | 21:21 |
| * lamont builds bzr-gtk_0.94.0-1~hardy1 | 21:22 | |
| james_w | pickscrape: I wouldn't want it to lead people to mix projects in one branch though. | 21:22 |
| pickscrape | At the moment we do it in svk by doing svk co -N and then svk revert -R on each subdirectory we want | 21:22 |
| james_w | pickscrape: we can have nested trees for allowing people to grab a related set of branches. | 21:22 |
| Tsmith | omg | 21:24 |
| Tsmith | is bzr up -rrev not supported? :o | 21:24 |
| james_w | Tsmith: nope, sorry, missed your question. | 21:24 |
| james_w | you probably want "bzr revert -rrev filename" | 21:25 |
| pickscrape | james_w: Hmmm... nested trees... I'll have to have a look at that. | 21:26 |
| james_w | beuno: hi, you around? | 21:27 |
| lamont | james_w: bzr-gtk 0.94.0-1 is love | 21:31 |
| james_w | lamont: ah, great, thanks | 21:32 |
| beuno | james_w, hey, yeah | 21:32 |
| james_w | beuno: unping :-) | 21:32 |
| beuno | james_w, cool :) | 21:32 |
| beuno | hi anyway | 21:32 |
| james_w | hi, how are you? | 21:33 |
| beuno | pretty good. Knee deep un loggerhead code. Yourself? | 21:33 |
| james_w | good thanks. | 21:35 |
| tolstoy | beuno: Loggerhead? Is that being updated since the ancient stuff at the website? | 21:40 |
| james_w | tolstoy: there was a release recently, at which website are you looking? | 21:40 |
| tolstoy | Hm. I'm looking for it now. | 21:40 |
| tolstoy | I last looked some weeks ago. | 21:40 |
| james_w | the maintainer has changed, and I don't know if that has left an old website around. | 21:40 |
| tolstoy | What's the "new" one? | 21:41 |
| beuno | tolstoy, we updated trunk yesterday | 21:42 |
| tolstoy | https://launchpad.net/loggerhead? | 21:42 |
| tolstoy | http://www.lag.net/loggerhead/ | 21:42 |
| tolstoy | Ah, that's the home page I've seen before. | 21:43 |
| beuno | tolstoy, launchpad, yes | 21:43 |
| tolstoy | So if I want to use it, I should just "bzr" it? | 21:43 |
| beuno | we hope to release a new version in a while | 21:43 |
| beuno | yeap | 21:43 |
| tolstoy | Sounds good. | 21:43 |
| tolstoy | I've got the unpleasant task of trying to configure it to "view" multiple branches of multiple projects. | 21:43 |
| beuno | tolstoy, let me know if I can help you with that :) | 21:44 |
| tolstoy | Will do. | 21:44 |
| tolstoy | Er, I'll see if I can find a mailing list for it. | 21:44 |
| tolstoy | Are you Michael Hudson? | 21:45 |
| tolstoy | Ah, Martin. Okay. | 21:46 |
| * mwhudson bounces | 21:52 | |
| beuno | tolstoy, that's Michael Hudson ^ :) | 21:55 |
| beuno | mornin mwhudson :) | 21:55 |
| mwhudson | hello | 21:55 |
| mwhudson | beuno: so i'm increasingly of the opinion that paste provides enough bits to build the server side of loggerhead | 21:56 |
| beuno | mwhudson, glad to hear that | 21:56 |
| beuno | it seemed to me that it's used for enough use cases that it should fit ours | 21:56 |
| mwhudson | yeah | 21:57 |
| mwhudson | and it's use-the-bits-you-need approach, while a bit confusing, means that we don't get lumbered with things like stupid url mangling (for example) | 21:57 |
| mwhudson | i think paste + simpletal is a reasonably nice small set of dependencies too | 21:58 |
| beuno | yes, absolutely | 21:58 |
| mwhudson | i can see how this would let me write a plugin | 21:58 |
| beuno | they both have nice packages too | 21:58 |
| mwhudson | hm, not sure instantly how to run a paste server in the background | 22:01 |
| mwhudson | i'm sure there's something for that though | 22:02 |
| beuno | well, I was thinking of looking into how pylons uses it for that part | 22:03 |
| thumper | mwhudson: paste? | 22:10 |
| mwhudson | thumper: http://pythonpaste.org/ | 22:12 |
| thumper | mwhudson: to replace turbogears and cherrypy? | 22:12 |
| mwhudson | yeah | 22:13 |
| Tsmith | hi | 22:30 |
| Tsmith | how can you tell where a .bzr repo is pulling from? | 22:31 |
| Peng | Tsmith: You mean a branch. And, "bzr info". | 22:31 |
| Peng | Also, if you run "bzr pull", it gives it. :P | 22:31 |
| Tsmith | tahsnkf ro bzr infoo ;) | 22:32 |
| Tsmith | so if you do bzr co bzr+ssh://, bzr behaves almost exactly like svn, in that when you commit, you can up on another system with the same co, but if you bzr branch, you have to do pull from the bzr+ssh:// to get the updates | 22:36 |
| Peng | If you use a branch, yeah, you have to push/pull. | 22:37 |
| lifeless | moin | 23:01 |
| lifeless | mtaylor: yes ext3 is remarkably slow about delete in that case :) | 23:01 |
| pickscrape | Would anyone be able to point me in the right direction with solving this: 'KnitPackRepository' object has no attribute 'get_revision_graph' (from trac-bzr) | 23:02 |
| lifeless | pickscrape: that was an old api, which was O(history) | 23:02 |
| lifeless | pickscrape: these days you would do g = repository.get_graph(), and then make whatever graph queries you need | 23:02 |
| pickscrape | lifeless: seems that trac-bzr is still using it. Thanks for point me at that, I'll have a look at fixing it. | 23:03 |
| lifeless | np | 23:04 |
| === mw|food is now known as mw | ||
| === tro|| is now known as tro | ||
| === Mez|DPC is now known as mez | ||
| === mez is now known as Mez|DPC | ||
| pickscrape | lifeless: trac-bzr was using the output from get_revision_graph as input for tsort.merge_sort, but it's not liking what comes out of get_graph. I've tried get_graph().iter_ancestry(), to no avail. Any clues? | 23:30 |
| lifeless | iter_ancestry yields tuples | 23:31 |
| lifeless | key, values | 23:31 |
| lifeless | values is None sometimes, when there is a ghost | 23:31 |
| lifeless | so filter those out and you should be fine | 23:31 |
| lifeless | for revid, parents in iter_ancestry: | 23:31 |
| lifeless | if parents is not None: | 23:31 |
| lifeless | parent_map[revid] = parents | 23:32 |
| lifeless | then feed parent_map to tsort.merge_sort | 23:32 |
| pickscrape | lifeless: thanks, I'll give that a go. Not sure how I've got ghosts in my repos though, they're pretty small. | 23:33 |
| lifeless | well, you may not need the filtering, others will | 23:33 |
| pickscrape | Yes, I really meant that might not explain why it's not working for me already | 23:33 |
| lifeless | pickscrape: fair enough | 23:33 |
| lifeless | mtaylor: hi | 23:34 |
| mtaylor | hi lifeless | 23:34 |
| lifeless | mtaylor: yes, ext3 finds deletes of massive trees problematic :) | 23:34 |
| mtaylor | the rm was killing my box earlier for that reason, so I stopped it | 23:34 |
| mtaylor | I'm going to re-run it tonight while I sleep | 23:34 |
| lifeless | you can just mv .bzr/bzr-search delete-me | 23:34 |
| lifeless | bzr index | 23:34 |
| mtaylor | lifeless: good point | 23:36 |
| mtaylor | I did index a smaller project quite quickly | 23:36 |
| mtaylor | I get this now: | 23:36 |
| mtaylor | $ bzr search SF_ReadRangeNo | 23:36 |
| mtaylor | File id 'ndbscanoperation.jav-20070517181935-98huwjarzuh25b30-25', revision 'mtaylor@mysql.com-20071120023241-84qiaykyp2sv70yk'. Summary: 'No summaries yet.' | 23:36 |
| lifeless | cool | 23:36 |
| lifeless | need to do a summary of why it hit though | 23:37 |
| lifeless | the file_id, revision_id tuple can be used to get the tree: | 23:37 |
| lifeless | revtree = repository.revision_tree(revision_id) | 23:37 |
| lifeless | file_contnet = revtree.get_lines(file_id) | 23:37 |
| lifeless | path = revtree.id2path(file_id) | 23:38 |
| lifeless | or we can get the bytes without the file via repository.iter_file_bytes | 23:38 |
| mtaylor | neat | 23:38 |
| lifeless | then its simply a case of repeating the index on that file and choosing a part of it to display | 23:39 |
| lifeless | we might want to store such coordinates in the index to handle big files better | 23:39 |
| mtaylor | ok. running a new index on mysql... and going to bed... | 23:40 |
| lifeless | gnight, and thanks for guinea pigging this | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
