| CaMason | hi guys. I'm trying to revert to a previous revision, but I'm getting ERROR: [Error 2] The system cannot find the file specified | 00:33 |
|---|---|---|
| CaMason | This is on Windows | 00:33 |
| CaMason | which I figure is a problem with the case of the file | 00:33 |
| lifeless | there should be a full backtrace in your bzr.log | 00:34 |
| CaMason | I have a feeling my earlier experiment with cygwin was causing some conflicts | 00:36 |
| thumper | abentley: ping | 00:44 |
| thumper | abentley: I have a question about preview trees | 00:45 |
| abentley | thumper: pong | 00:45 |
| thumper | abentley: and getting dependent branches working with lp:mad | 00:45 |
| lifeless | CaMason: well maybe; happy to help - pastebin the full exception as a starting point though | 00:45 |
| * thumper drew a face for lp:mad last night | 00:45 | |
| thumper | abentley: I know you were working on that area of preview trees, but I don't know if it landed in trunk | 00:46 |
| abentley | thumper: I'm pretty sure it did. You can generate a preview tree from a preview tree, which is what you need to do. | 00:47 |
| thumper | abentley: all the code is on lp now :) | 00:48 |
| thumper | yay | 00:48 |
| fallenpegasus | is tailor the current best practice for converting a hg project to bzr? it seems pretty heavyweight | 00:53 |
| lifeless | jelmer: I'm a little confused why you needed InterBranch to make update_revisions work right for you | 00:55 |
| lifeless | jelmer: not that InterBranch is bad; it just seems like it doesn't add anything for bzr svn | 00:55 |
| jelmer | lifeless: bzr-git can't return revno's for remote branches | 01:01 |
| jelmer | lifeless, since git doesn't expose the revision graph | 01:01 |
| jelmer | (not without fetching the actual revisions, anyway) | 01:01 |
| jelmer | lifeless, for bzr-svn it's just a performance improvement, since calculating the revno for a remote svn revision is more expensive than calculating it for the revision once it's been fetched into the local bzr branch | 01:02 |
| thumper | jelmer: has bzr-git been frozen for rev-ids? | 01:02 |
| thumper | jelmer: we are looking to use it soon | 01:02 |
| jelmer | thumper: yes | 01:02 |
| jelmer | thumper: This was actually one of the requirements for actually making bzr-git work with a vanilla bzr | 01:03 |
| jelmer | s/This/This patch/ | 01:03 |
| thumper | jelmer: cool | 01:04 |
| thumper | jelmer: have you done a "release" of bzr-git? | 01:04 |
| lifeless | jelmer: ah | 01:04 |
| lifeless | thanks | 01:04 |
| jelmer | thumper, no, was waiting for this patch to land :-) | 01:05 |
| jelmer | thumper, I'll do one at around the same time as bzr 1.13 | 01:05 |
| thumper | jelmer: what patch does it need? | 01:06 |
| thumper | jelmer: and will it be ready for next week? | 01:06 |
| jelmer | thumper, the patch it needs landed 5 minutes ago :-) | 01:07 |
| thumper | jelmer: cool, so bzr-git needs bzr 1.13? | 01:07 |
| jelmer | thumper, yep | 01:08 |
| thumper | what's the date for 1.13 rc? | 01:08 |
| jelmer | thumper, Martin's original announcement said march 6, but I'm not sure if that's still true | 01:09 |
| lifeless | thumper: got some sort of rush? | 01:12 |
| thumper | lifeless: we are sprinting next week on integrating this into lp | 01:12 |
| jelmer | thumper, I should point out that bzr-git isn't ready for imports of e.g. the linux kernel yet | 01:13 |
| thumper | jelmer: what is it ready for? | 01:14 |
| jml | bzr init-repo --1.9 --no-trees ~/repos/<proj>; bzr branch lp:<proj> ~/repos/<proj>/trunk; mkdir ~/src/<proj>; bzr co --lightweight ~/repos/<proj>/trunk ~/src/<proj>/trunk | 01:14 |
| thumper | jelmer: and what are the limitations? | 01:14 |
| jml | someone please write a computer program to do that for me. | 01:14 |
| lifeless | jml: jamesh already did | 01:14 |
| jelmer | thumper, it hasn't been optimized for performance | 01:15 |
| jelmer | thumper, I've used it for moderately sized projects, e.g. couple of hundred revisions, couple of hundred files | 01:15 |
| lifeless | does it round trip yet? | 01:16 |
| lifeless | are there conversion logic bumps in the pipeline? | 01:16 |
| jml | lifeless: what's it called? | 01:16 |
| jelmer | lifeless: no, it doesn't roundtrip yet | 01:16 |
| jml | lifeless: how can I use it? | 01:16 |
| lifeless | jml: gnome-somethjing-or-other | 01:16 |
| jelmer | lifeless, roundtripping is nontrivial | 01:16 |
| lifeless | jelmer: I'm sure :P | 01:16 |
| thumper | lifeless: that is something else I think | 01:16 |
| jelmer | lifeless, in other words - yes, there are mapping bumps ahead | 01:17 |
| thumper | jml: don't forget the additions to the locations config for cbranch :) | 01:17 |
| lifeless | jelmer: I'm just alarmed that thumper might throw it onto LP suddenly :P | 01:17 |
| jml | thumper: I don't need to worry about that. | 01:17 |
| thumper | jml: my thoughts would be a bzrtools command | 01:17 |
| jml | thumper: I have some magic in my locations.conf that takes care of it. | 01:18 |
| thumper | jml: I'd like your magic | 01:18 |
| jml | thumper: http://paste.ubuntu.com/123098/ | 01:18 |
| thumper | lifeless: my push to LP to an existing stacked branch is borked | 01:19 |
| thumper | lifeless: is this expected? | 01:19 |
| thumper | lifeless: I'm using the bzr from the nightly ppa | 01:19 |
| jml | thumper: the only thing I have to specify per-project is the submit branch | 01:19 |
| lifeless | thumper: details | 01:19 |
| thumper | lifeless: by borked I mean nothing output for over 8 minutes | 01:19 |
| jml | thumper: one day, I'll figure out a way of getting bzr to default to ~/repos/<proj>/trunk | 01:19 |
| lifeless | yes, its working fine | 01:19 |
| lifeless | thumper: ^ | 01:19 |
| lifeless | thumper: just no progress bar | 01:19 |
| thumper | lifeless: why is it taking so long? | 01:20 |
| thumper | lifeless: it is one or two new revisions | 01:20 |
| thumper | lifeless: to an existing stacked branch | 01:20 |
| lifeless | thumper: well, depending on which nightly build you have | 01:20 |
| lifeless | you may be running into one of a couple of bugs we found | 01:20 |
| lifeless | where fixing X broke/regressed Y | 01:21 |
| thumper | lifeless: should I kill it or just wait? | 01:21 |
| lifeless | what revno is your bzr | 01:21 |
| thumper | I have 1.13~bzr8.10-40041-1 installed | 01:22 |
| lifeless | man, how to turn that into a revno | 01:23 |
| thumper | sorry, 4041 | 01:23 |
| thumper | I think that is the revno isn't it? | 01:23 |
| thumper | too many zeros | 01:23 |
| lifeless | ok | 01:24 |
| lifeless | in which case you're missing 4043 | 01:24 |
| lifeless | and it will take an hour | 01:24 |
| thumper | that I am | 01:24 |
| thumper | an hour? | 01:24 |
| thumper | geez | 01:24 |
| lifeless | una hora per favour | 01:24 |
| thumper | should I care what it is doint? | 01:24 |
| thumper | it isn't sending heaps of revisions is it? | 01:24 |
| lifeless | no | 01:25 |
| lifeless | or yes | 01:25 |
| lifeless | depending on your point of view | 01:25 |
| thumper | lifeless: man, you are so helpful | 01:25 |
| lifeless | it was a bug, its fixed :) | 01:25 |
| lifeless | how much more helpful do you want? | 01:25 |
| thumper | lifeless: can you give me unlimited cosmic power? | 01:28 |
| lifeless | thumper: sorry, no | 01:28 |
| * fullermd can only dispense terrestrial power. | 01:28 | |
| lifeless | thumper: its not inserting unnecessary revisions into the brnach | 01:31 |
| lifeless | thumper: its just calculating a bunch of stuf it doesn't need | 01:31 |
| lifeless | so that it can avoid calculating something it does need :P | 01:32 |
| garyvdm | Who can I ask questions relating to expected performance of graph methods? | 01:34 |
| garyvdm | I'm looking at the profile data for a particular use case in qbzr | 01:35 |
| garyvdm | In qlog | 01:35 |
| garyvdm | The data is not what I expected. | 01:35 |
| garyvdm | I've looking at a branch that has a pending merge. | 01:36 |
| lifeless | me, john, the list are all good candidates | 01:36 |
| lifeless | aaron too | 01:36 |
| garyvdm | qlog uses graph.find_unique_ancestors to figure out which revisions are part of the pending merge, and which are part of the rest of the branch. | 01:37 |
| garyvdm | The cost of graph.find_unique_ancestors is higher than the cost of graph.iter_ancestry | 01:38 |
| garyvdm | Lifeless: is that normal | 01:39 |
| lifeless | doesn't sound normal, but it could be a bug :P | 01:39 |
| lifeless | bzr st got changed to not show a similar thing, I don't recall if someone looked into the cost of the calculation, or not | 01:40 |
| garyvdm | Ok - I'll investigate. | 01:41 |
| mtaylor | lifeless: bzr-hg? | 01:46 |
| mtaylor | lifeless: AttributeError: 'HgBzrDirFormat' object has no attribute '_workingtree_format' | 01:46 |
| lifeless | mtaylor: doing a selftest? | 01:50 |
| mtaylor | lifeless: a friend is trying to migrate some stuff from hg to bzr | 01:50 |
| mtaylor | lifeless: is there a better way than cd ~/.bazaar/plugins ; bzr branch lp:bzr-hg bzr_hg ? | 01:51 |
| lifeless | fast-export is probably the best route at the moment | 01:51 |
| lifeless | jelmer is doing bzr-hg dev at the moemnt | 01:51 |
| mtaylor | is fast-export written up somewhere sensible? | 01:52 |
| lifeless | jelmer: btw, I asked before, but why isn't your stuff in the trunk of bzr-hg and bzr-git ? | 01:52 |
| lifeless | mtaylor: http://bazaar-vcs.org/BzrFastImport | 01:52 |
| mtaylor | lifeless: rock. thakns! | 01:53 |
| lifeless | spiv: you've been very quiet today | 01:58 |
| jam | lifeless: for the bug you brought up earlier. I think your new fetch cycle wil have fixed it, but there definitely was a bug there in the past | 02:06 |
| spiv | lifeless: yeah. I spent more time looking at/writing up my xfce thoughts than I expected. | 02:06 |
| spiv | lifeless: it just occurred to me, btw, that I do in a sense have two unfinished branches lying around | 02:07 |
| spiv | lifeless: smart protocol traffic reporting, and /~/ support for bzr+ssh | 02:07 |
| lifeless | jam: I don't deny the bug :) in fact I checked carefully that it wouldn't regress | 02:08 |
| lifeless | jam: which was easy as you wrote a test for it :> | 02:08 |
| lifeless | jam: there is a merge request up for a patch rolling back just part of the changes you ade | 02:08 |
| lifeless | *made* | 02:08 |
| jelmer | lifeless, I'm not sure why it's not in the trunk :-) | 02:08 |
| lifeless | jelmer: push man, push | 02:08 |
| jelmer | lifeless, I guess it's mainly that I'm not used to pushing to launchpad and the trunks are in launchpad | 02:09 |
| fullermd | Oh, jeez. I'd given up hoping for bzr+ssh:/~/ | 02:09 |
| jelmer | time to fix the bzr-jelmer plugin :-P | 02:09 |
| lifeless | jelmer: please do push them; lp isn't evil. Honestly. | 02:09 |
| jam | lifeless: your patch had no revisions, BB:resubmit | 02:09 |
| lifeless | jam: grah | 02:09 |
| jam | there *was* a bundle there, but it was empty | 02:09 |
| jam | I assume you forgot a submit branch/ used the local branch | 02:10 |
| lifeless | jam: I did branch dev new; merge -r y..x .; commit; send | 02:10 |
| lifeless | the merge changed the submit branch :( | 02:10 |
| spiv | lifeless: also, I think we should add some more remember_remote_is_before((1, 13)) in remote.py, and corresponding if _is_remote_before guards to skip straight to fallbacks, for the sake of minimising impact when talking to older servers. | 02:10 |
| lifeless | jam: -> list | 02:11 |
| lifeless | spiv: I think that makes sense, I'd like to put that on the 'after protocol freeze' list | 02:11 |
| lifeless | spiv: ack on the two branches | 02:11 |
| spiv | lifeless: agreed about 'after freeze' | 02:11 |
| lifeless | the smart protocol traffic reporting - why didn't that land again ? | 02:11 |
| spiv | I think it should probably borrow vila's work for http traffic reporting, but I didn't make time to look closely enough in time for the release. | 02:12 |
| spiv | IIRC, he decorates the underlying socket object with a traffic reporter, which sounds like it would work well for smart media too. | 02:13 |
| lifeless | indeed | 02:14 |
| spiv | Oh, and I suspect that if my patch landed as is with vila's patch already integrated, then smart http traffic would probably have been reported twice... | 02:14 |
| spiv | We didn't need to make hpss look even worse than reality! ;) | 02:14 |
| lifeless | very true | 02:15 |
| jam | spiv: far from it, it would look like you were getting amazing download speeds | 02:15 |
| lifeless | I've nearly finished find repository v3 | 02:15 |
| lifeless | which will ensure that we always have a network name | 02:15 |
| spiv | jam: yeah, but then the release that fixes the bug would look like it was half the speed ;) | 02:16 |
| lifeless | allowing PackToRemote to check compatibility without _ensure_real | 02:16 |
| spiv | Hooray | 02:16 |
| lifeless | that + moving fetch_order and uses_deletas to format | 02:16 |
| lifeless | will avoid real repo at all for push I *think* | 02:16 |
| lifeless | the patch jam is looking at is a prereq for that stack of changes | 02:16 |
| jam | lifeless: so I don't think you fix is 'complete' just from the bugs I noticed in the code | 02:21 |
| jam | lifeless: the issue is when 'buffered=True' | 02:21 |
| jam | the code has | 02:21 |
| jam | if not buffered: self.index.add_records() | 02:21 |
| jam | however later on it unilaterally does | 02:21 |
| jam | added_keys = [record.key] | 02:21 |
| jam | while added_keys: | 02:21 |
| jam | ... | 02:21 |
| jam | which assumes that it successfully added the key | 02:22 |
| jam | and anything that depends on it can be added | 02:22 |
| jam | Look at the last example: https://bugs.edge.launchpad.net/bzr/+bug/304841/comments/5 | 02:22 |
| ubottu | Ubuntu bug 304841 in bzr "bzr push raises RevisionNotPresent" [Critical,Fix released] | 02:22 |
| jam | In case that helps | 02:22 |
| jam | If we get 'E' before 'D', then E gets buffered, when D comes in, we still haven't seen 'C', but since D shows up, we think we can insert E | 02:23 |
| lifeless | jam: thats deliberate | 02:23 |
| jam | lifeless: It is deliberate to record the entry "E" even though you would fail to extract it? | 02:23 |
| lifeless | jam: yes | 02:23 |
| jam | I don't understand | 02:24 |
| lifeless | jam: there are comments about this, but let me try explaining | 02:24 |
| jam | Given that you intentionally don't record *D* | 02:24 |
| lifeless | there are two index implementations | 02:24 |
| lifeless | Kndx and Pack | 02:24 |
| jam | # Add any records whose basis parent is now available. | 02:24 |
| jam | I see that, but that isn't really enough info | 02:24 |
| lifeless | so there are two loops | 02:25 |
| lifeless | there is a loop over the stream | 02:25 |
| lifeless | and the logic in there is 'if the compression parent is available just add it' | 02:25 |
| lifeless | if its not, buffer it | 02:25 |
| lifeless | if its buffered its not in the index and its children (and their children etc) will also be buffered | 02:25 |
| jam | lifeless: except the children that *were* buffered | 02:26 |
| jam | get inserted *at that time* | 02:26 |
| jam | *when* the entry is buffered | 02:26 |
| lifeless | jam: huh | 02:26 |
| jam | The 'added_keys = [record.key]" is *outside* the 'if not buffered" check | 02:27 |
| lifeless | oh, you are suggesting we need a | 02:27 |
| lifeless | if buffered: | 02:27 |
| lifeless | at that point? That makes sense to me | 02:27 |
| jam | lifeless: well, 'if not buffered', but yes | 02:27 |
| jam | lifeless: and you need to move the 'buffered' variable higher in scope | 02:27 |
| lifeless | yeah | 02:27 |
| jam | so that all paths have ti | 02:27 |
| lifeless | let me do that | 02:27 |
| jam | it | 02:27 |
| jam | I think with that | 02:27 |
| jam | the fix is complete | 02:28 |
| jam | I just did 'topological' because it was easier to 'get stuff working' | 02:28 |
| lifeless | http://paste.ubuntu.com/123109/ | 02:28 |
| jam | and would hide any other bugs that were latent to get the release out | 02:28 |
| jam | lifeless: seems fine, you could reduce the indenting slightly by just setting 'added_keys = []', but I would approve that patch | 02:29 |
| lifeless | so this wouldn't affect pack repositories at all | 02:29 |
| lifeless | only .knit | 02:29 |
| jam | no, it effects packs | 02:29 |
| jam | when stacked | 02:29 |
| lifeless | but its good not to break them :) | 02:29 |
| jam | and getting 'unordered' streams | 02:29 |
| jam | well, assuming you don't actually get the complete stream | 02:29 |
| lifeless | how does it affect packs? | 02:29 |
| lifeless | if you don't get the complete stream, thats an issue :) | 02:30 |
| jam | ... I guess you mean the index won't become visible? | 02:30 |
| jam | if all the gaps weren't filled in? | 02:30 |
| lifeless | yes, it will fail atomically | 02:30 |
| jam | lifeless: It *did* trigger bugs with stacking | 02:30 |
| jam | because of trying to extract a fulltext | 02:30 |
| jam | but the delta-chain wasn't complete | 02:30 |
| jam | I *think* that code is fixed | 02:30 |
| lifeless | ah, with an adapter | 02:30 |
| jam | by properly looking at 'compression_parent' | 02:30 |
| jam | rather than missing(parents) | 02:30 |
| lifeless | ok, if you're happy I'll commit this and push to pqm | 02:31 |
| jam | lifeless: go ahead | 02:32 |
| lifeless | thanks | 02:33 |
| jam | lifeless: so i'm still a little concerned that stacking + 'unordered' fetching will cause problems with trying to expand texts, but perhaps with your new two-pass logic it will be ok | 02:35 |
| lifeless | we do topological for conversion push | 02:36 |
| lifeless | so the reason we do expansion of texts with stacking was to get the delta closure in | 02:36 |
| lifeless | jam: the two-pass logic should avoid that though with a newer server | 02:37 |
| lifeless | it passes the acceptance test you wrote | 02:37 |
| jam | lifeless: with the other fix, I can't think of a way to break it, but let me think about it for a bit | 02:40 |
| jam | lifeless: it should be fine | 02:43 |
| lifeless | jam: cool; if its not I'll fix it :) | 02:44 |
| ia | hello. could you tell me, please, If i use latest version of bzr, which contains "push" bug (https://bugs.launchpad.net/bzr/+bug/295350), then does exist some way to push branches in such version of bzr? | 02:52 |
| ubottu | Ubuntu bug 295350 in bzr "Push fails with Revision {set([('null:',)])} not present in "KnitVersionedFiles" [Critical,Confirmed] | 02:52 |
| lifeless | ia: are you encountering that bug ? | 02:53 |
| lifeless | ia: because it was fixed in 1.10, just the report wasn't updated | 02:54 |
| lifeless | (the log shows that it was fixed) | 02:54 |
| lifeless | And I've updated the bug to record that | 02:54 |
| jam | lifeless: it is occurring now with bzr.dev and rich-root repos | 02:57 |
| jam | lifeless: I sent a bug report to the ML and spiv said he was going to look at it today | 02:57 |
| ia | lifeless: hmmm, very intresting - i use bzr from "nightly builds" repo (latest version - 1.13dev) and I've just would like to push(from desktop) in my branch(to LP), but I've got error message. I've googled it and found the same bug at LP. So, now i'm here ) In those bug report you can find my comment - it's the last one. | 02:57 |
| lifeless | ia: you definitely don't have that bug | 02:58 |
| lifeless | ia: what package version do you have? | 02:58 |
| ia | lifeless: 1.13dev | 02:59 |
| lifeless | ia: 'dpkg -l bzr' | 02:59 |
| lifeless | ia: will give the *package* version | 02:59 |
| lifeless | jam: pushing to stacked rich root repos from plain repos? | 02:59 |
| jam | lifeless: "bzr init-repo --1.9-rich-root bzr+ssh://new-repo; cd ~/.bazaar/plugins/svn; bzr push bzr+ssh://new-repo/svn" | 03:00 |
| ia | lifeless: 1.13~bzr8.10-4 | 03:00 |
| jam | lifeless: no stacking | 03:00 |
| lifeless | ia: thats not the full version string | 03:01 |
| lifeless | ia: please show the full version string | 03:01 |
| ia | lifeless: 1.13~bzr8.10-4041-1 | 03:03 |
| lifeless | thank you :) | 03:03 |
| chx | oh 1.13 already?? | 03:03 |
| chx | i thought 1.12 just got out | 03:03 |
| lifeless | chx: we're working on 1.13 at the moment | 03:03 |
| chx | ah ok | 03:04 |
| ia | lifeless: sorry - i just didn't get it instantly :-) | 03:04 |
| jam | chx: there is a ppa with nightly builds | 03:04 |
| lifeless | ia: I think you're suffering bug 334187 | 03:05 |
| ubottu | Launchpad bug 334187 in bzr "RemoteBranch.revision_history broken when stacking" [Undecided,Fix committed] https://launchpad.net/bugs/334187 | 03:05 |
| lifeless | ia: a fix is landing at th emoment | 03:05 |
| lifeless | ia: the symptoms look similar, but they are quite different bugs; in future I suggest that you file a new bug rather than commenting on an existing one, unless you've dug into the code and checked the entire backtrace is identical | 03:06 |
| lifeless | ia: alternatively, you may be suffering a new bug we haven't seen yet, or possibly the issue jam is reporting with rich root branches | 03:07 |
| lifeless | ia: can you please do 'bzr info -v' in your branch that you're having trouble pushing | 03:07 |
| lifeless | jam: is there a bug for this? | 03:07 |
| jam | lifeless: not yet, I started on the mailing list to bring up discusion | 03:08 |
| lifeless | ia: can you please do 'bzr info -v' in your branch that you're having trouble pushing | 03:15 |
| ia | lifeless: oh, thanks for advice about bugreporting. And you're right - problem not in bzr, but in branch; i've just tested "push" with another branch - it works fine. And here bzr info -v : http://paste.ubuntu.com/123114/ - it's a branch of bzr-gtk, which I would like to upload (with tiny changes) to my branch at LP. | 03:16 |
| lifeless | ia: is it a new branch? | 03:17 |
| lifeless | ia: ok, when you push a new branch to launchpad it tries to stack; | 03:21 |
| lifeless | ia: thats what this bug is about; you'll need a new build to fix the bug | 03:22 |
| ia | lifeless: well, i've registred branch at LP, made "bzr branch lp:bzr-gtk", made changes, commited it, and now when I run "bzr push lp:~iaz/bzr-gtk/cosmetic" i get error - http://paste.ubuntu.com/123119/ | 03:23 |
| lifeless | ia: or, if you have a copy of bzr.dev yourself, you can just update from it | 03:23 |
| lifeless | and then use that copy to push | 03:23 |
| lifeless | ia: can you look in ~/.bzr.log | 03:23 |
| lifeless | ia: there should be a full backtrace; if you could pastebin that that would be good | 03:24 |
| ia | lifeless: I guess, that this - http://paste.ubuntu.com/123120/ - log for last try of "push" | 03:27 |
| lifeless | jam: does http://paste.ubuntu.com/123120/ match what you're seeing | 03:28 |
| lifeless | ia: thats intersting, and new | 03:28 |
| lifeless | ia: please install a 1.12 full release | 03:28 |
| lifeless | ia: I'll file a new bug for this problem you're seeing | 03:28 |
| jam | lifeless: yes | 03:30 |
| jam | iter_lines_added_or_present_in_keys triggering a problem with ('null:',) | 03:30 |
| lifeless | jam: that looks like a bug in the what-to-copy logic to me | 03:30 |
| lifeless | spiv: are you looking at this? | 03:31 |
| ia | lifeless: eeem, what, i've clashed with some new unknown problem? ) | 03:31 |
| jam | lifeless: judging by the backtrace, I would guess somehow NULL_REVISION snuck into the 'revisions' field of the 'data_to_fetch' | 03:31 |
| lifeless | ia: yes, you've found a new bug | 03:31 |
| lifeless | jam: yes, thats what I'm thinking | 03:32 |
| spiv | lifeless: not right at the moment; I'm currently thinking it's time for lunch... | 03:34 |
| lifeless | spiv: I'm guesing we're not pairing today :P | 03:34 |
| spiv | lifeless: No :P | 03:36 |
| spiv | lifeless: what can I say, I'm a (busy) slacker ;) | 03:36 |
| spiv | We definitely should tomorrow though. | 03:36 |
| ia | lifeless: ok. well, however, I will be very appreciate, that if you'll file new bug about this, you'll highlight me and send link to this bug. And thanks for response and help. | 03:44 |
| lifeless | ia: already filed | 03:44 |
| lifeless | ia: bug 334666 | 03:45 |
| ubottu | Launchpad bug 334666 in bzr "error pushing new bzr-gtk branch to launchpad" [High,Confirmed] https://launchpad.net/bugs/334666 | 03:45 |
| jam | lifeless: how fixed are you about inserting the 'label:' and 'sha1:' lines into the group compressed text | 03:56 |
| jam | I just did a quick test removing them | 03:56 |
| lifeless | jam: sha1: I'm not attached to at all | 03:57 |
| jam | and the text sizes dropped from 621 kB compressed down to 482kB | 03:57 |
| jam | or ~30% overhead from those 2 lines | 03:57 |
| lifeless | label: we have to store somewhere | 03:57 |
| jam | lifeless: sure, atm we store it in the index | 03:57 |
| lifeless | I'll mull on this | 03:58 |
| jam | I can understand wanting it in the text | 03:58 |
| jam | I haven't finished a conversion with a bigger repo | 03:58 |
| pasc | i/wi1 | 03:58 |
| pasc | gah | 03:58 |
| jam | lifeless: so texts for bzrtools in 1.9 == 1.2MB, in GC .6MB, with label & sha1 stripped .48MB | 03:59 |
| lifeless | jam: hmm _find_modes is a round trip on just opening a RemoteRepository | 03:59 |
| jam | lifeless: arguably it should be returned as part of BzrDir.open()... | 04:00 |
| lifeless | jam: or deferred until a write is desired | 04:00 |
| jam | either way | 04:00 |
| jam | the former means you don't have an extra round trip when you *do* want to write | 04:01 |
| lifeless | the latter means you don't have an extra round trip at all for pull | 04:01 |
| lifeless | and its the same as the former when you do write | 04:01 |
| lifeless | (because, mode probing is a stat that bzrdir.open doesn't do) | 04:02 |
| abpend | Anyone here? | 04:15 |
| lifeless | abpend: generally, just ask your question | 04:18 |
| abpend | Alright, then. Does anyone know if any work is being done on getting nested tree support into bzr? | 04:20 |
| abpend | Googling around, it looks like there are periodic discussions every year or two, but I'm not sure if that's just talk or indicative of something actually happening. | 04:21 |
| lifeless | spiv: new merge request up | 04:25 |
| lifeless | abpend: I believe abentley will be focusing on it soon | 04:26 |
| abpend | lifeless: good to know. We've just started using bzr at work, and that'd be a much-appreciated feature. | 04:31 |
| spiv | lifeless: I'll take a look | 04:31 |
| thumper | abpend: can you say which work? | 04:38 |
| abpend | thumper: I work for a small web development firm in Washington, DC called Community IT Innovators... so far, it's just one development group, and we're just giving it a go, but so far, we've been pretty impressed. Everybody else is still using CVS. | 04:39 |
| thumper | abpend: I think you'll like it | 04:41 |
| thumper | abpend: I came primarly from svn (and other biggies like perforce and clear case) | 04:42 |
| lifeless | jam: interesting commit there | 04:42 |
| lifeless | spiv: just shout if you want to chat about causes there | 04:43 |
| jam | lifeless: too sleepy to continue, but yeah, I'm curious where it will get to | 04:55 |
| spiv | lifeless: I don't actually see where in the patch the server will send the network_name? | 05:02 |
| lifeless | spiv: very interesting... neither do I :P | 05:03 |
| lifeless | spiv: let me, uhm, fix | 05:04 |
| spiv | lifeless: :) | 05:04 |
| spiv | lifeless: the change to transport/remote.py looks reasonable, but I'm curious about what prompted it | 05:06 |
| lifeless | the client wasn't preserved | 05:06 |
| lifeless | so the stub test ended up trying to do a real op | 05:06 |
| spiv | Interesting that nothing else had bumped into that issue before this... | 05:08 |
| lifeless | I think this is the first deliberately recording a real_repo invocation | 05:08 |
| spiv | Oh, right, I just noticed that. | 05:09 |
| spiv | Makes sense. | 05:09 |
| lifeless | spiv: yeah tests breaking all over. | 05:09 |
| lifeless | update coming | 05:09 |
| spiv | lifeless: :) | 05:09 |
| lifeless | ERROR: bzrdir_implementations.test_bzrdir.TestBzrDir.test_sprout_bzrdir_repository(RemoteBzrDirFormat-v2) | 05:20 |
| lifeless | Received bad protocol version marker: '\n' | 05:20 |
| lifeless | spiv: *hate* that | 05:20 |
| spiv | Hmm. | 05:21 |
| lifeless | spiv: we can make a findV3 request on the old protocol, but can't answer it | 05:21 |
| spiv | Perhaps the v2 (and v1) encoder should check for \n in args, and raise a better exception? | 05:21 |
| lifeless | spiv: I'd like it to be unknown method on a v2 or before stream :( | 05:22 |
| lifeless | File "/home/robertc/source/baz/RemoteRepository._format/bzrlib/smart/medium.py", line 202, in serve | 05:22 |
| lifeless | server_protocol = self._build_protocol() | 05:22 |
| lifeless | spiv: where would be a good place to put this chceck | 05:23 |
| spiv | Ah, in the response. Tricksy. | 05:24 |
| spiv | Yeah, it would be good to have it unknown in earlier protocol versions. At the moment the client is responsible for not trying new verbs on old protocols via _is_remote_before | 05:24 |
| lifeless | spiv: so I can do it two ways | 05:25 |
| lifeless | a min_version=3 on the register side | 05:25 |
| lifeless | or in the dispatch or something like that | 05:25 |
| lifeless | or a heuristic in the response encoder | 05:25 |
| lifeless | I prefer the former (avoids having work done then error late; which would suck for mutating methods) | 05:25 |
| spiv | I'm not sure what you have in mind for a heuristic in the response encoder, but it doesn't sound like a good idea to either. | 05:26 |
| spiv | So, there's a commands registry in request.py | 05:27 |
| spiv | Currently that registry is always passed into the SmartServerRequestHandler | 05:27 |
| lifeless | the heuristic would be \n in the args :P | 05:28 |
| spiv | Which is kicked off via _get_protocol_factory_for_bytes | 05:28 |
| spiv | Ugh, yeah, let's not do that :P | 05:29 |
| lifeless | hey, you proposed it ;) | 05:29 |
| spiv | I thought we were talking client-side :P | 05:29 |
| spiv | _get_protocol_factory_for_bytes already dispatches to different factories depending on protocol version (that's what it's for) | 05:30 |
| lifeless | spiv: ok | 05:30 |
| lifeless | so we could make it active on the request | 05:30 |
| spiv | e.g. b/s/protocol's build_server_protocol_three passes in commands=request.request_handlers | 05:30 |
| lifeless | or passive | 05:30 |
| lifeless | or in the registry | 05:30 |
| spiv | So we could make those not all pass the same request_handlers | 05:31 |
| lifeless | I think a passive attribute on the request is enough | 05:31 |
| lifeless | None = any | 05:31 |
| lifeless | 1/2/3 is a minimum | 05:31 |
| spiv | (Also, it would be good if there were a way to vary the request_handlers by server instance, rather than having those factories hard-coded to use the global request_handlers) | 05:31 |
| spiv | That seems reasonable. Just an extra arg on the registration API. | 05:32 |
| spiv | You don't need to do all this to solve your immediate problem, though... | 05:32 |
| spiv | You could just do the _is_remote_before check in open_repo_v3, and if it fails raise UnknownSmartMethod without even touching the network. | 05:33 |
| spiv | I don't mind if you want to fix this now, though. | 05:34 |
| lifeless | it will fail to work | 05:34 |
| lifeless | if the remote version isn't established | 05:34 |
| lifeless | and that needs a known-higher not a known-lower | 05:34 |
| spiv | No, it will work. | 05:34 |
| spiv | Because if the protocol is v2 then _remember_remote_is_before((1,6)) has already been called on the medium for you. | 05:35 |
| lifeless | ah | 05:35 |
| spiv | So _is_remote_before((1,13)) will be False | 05:35 |
| spiv | Other things already rely on this :) | 05:35 |
| lifeless | ok, I'll do that | 05:37 |
| lifeless | spiv: any insight on the push null: issue? | 05:40 |
| lifeless | spiv: ok the next giltch | 05:44 |
| lifeless | spiv: RemoteBranch(...real_branch) is triggering the assert real_repository is already set | 05:46 |
| lifeless | ok, seems good | 06:01 |
| lifeless | spiv: I'll wrap this real_repository elimination up tomorrow | 06:09 |
| lifeless | night all | 06:09 |
| spiv | lifeless: g'night | 06:10 |
| spiv | lifeless: regarding the push null: issue, for some reason the searcher from _walk_to_common_revisions is including null: in its result | 06:11 |
| spiv | And nothing after that point filters it out. | 06:11 |
| spiv | I don't quite get why it only happens on some pushes to new branches, rather than all. | 06:12 |
| === Spaz is now known as Mr-T | ||
| === Mr-T is now known as Spaz | ||
| lifeless | spiv: stacked branches shouldn't reach null: though | 06:23 |
| lifeless | spiv: perhaps, its *non* stacked new branches with old servers? | 06:23 |
| spiv | lifeless: I've got a reproduction with a non-stacked branch, current server | 06:27 |
| spiv | Possibly due to a non-lefthand null: parent in the history. | 06:27 |
| spiv | pushing bzr-svn -r100 reproduces it. | 06:28 |
| lifeless | that would make sense | 06:28 |
| spiv | If I add parents_of_found.discard(revision.NULL_REVISION) to _do_query in the searcher, it works. | 06:28 |
| spiv | I also bumped into a trivial bug in the insert_stream server code; if the stream is empty, the thread is never started, so self.insert_ok is never set. That causes some mess in the .bzr.log. | 06:30 |
| spiv | (and of course we try empty streams fairly often atm ;) | 06:31 |
| lifeless | spiv: ah! I saw that once but had no reproduction | 06:31 |
| lifeless | spiv: null: is legitimate in the core graph code | 06:32 |
| lifeless | I suggest post-filtering | 06:32 |
| * spiv nods | 06:38 | |
| poolie | spiv, lifeless, i've just hit that too | 07:00 |
| poolie | i think this is bug 3217654 | 07:06 |
| ubottu | Error: Launchpad bug 3217654 could not be found | 07:06 |
| poolie | bug 317654 | 07:06 |
| ubottu | Launchpad bug 317654 in bzr "error about null revision not present pushing to server" [High,Confirmed] https://launchpad.net/bugs/317654 | 07:06 |
| lifeless | poolie: bug 334666 is definitely it :) | 07:10 |
| ubottu | Launchpad bug 334666 in bzr "error pushing new bzr-gtk branch to launchpad" [High,Confirmed] https://launchpad.net/bugs/334666 | 07:10 |
| lifeless | poolie: because its the bug I filed to track it | 07:10 |
| poolie | well, are they perhaps dupes? | 07:13 |
| lifeless | possibly | 07:13 |
| lifeless | I've said so in 317654 | 07:13 |
| lifeless | we know the cause for 334666 | 07:13 |
| vila | hi all | 07:16 |
| poolie | hi vila | 07:17 |
| jml | what's the bzr nightly ppa team? | 07:19 |
| poolie | ~bzr-nightly-ppa :) | 07:19 |
| jml | thanks. | 07:21 |
| jml | (why isn't the fingerprint on the page any more) | 07:21 |
| === chx is now known as chx_sleeping | ||
| jml | File "/home/jml/.bazaar/plugins/svn/branch.py", line 31, in <module> | 07:23 |
| jml | from bzrlib.branch import ( | 07:23 |
| jml | ImportError: cannot import name InterBranch | 07:23 |
| jml | which bzr-svn should I be using with bzr nightly? | 07:23 |
| lifeless | jml: an older one | 07:27 |
| lifeless | jml: that landed today | 07:27 |
| lifeless | jml: generally I'd say either use all packaged, or none-packaged, for bzr&plugins | 07:27 |
| jml | lifeless: it's kind of scary that a day's lag can make such a difference | 07:28 |
| lifeless | jml: jelmer added a dependency on a new feature in bzr | 07:29 |
| lifeless | jml: I think its great that he did so so promptly | 07:29 |
| * jml should have just made a checkout of bzr | 07:30 | |
| lifeless | jml: if you're running from a checkout of bzr-svn, definitely. | 07:35 |
| jml | lifeless: well, the progress bar said it downloaded 900MB+ of data | 07:36 |
| lifeless | poolie: are you sure its the same bug ? | 07:37 |
| jml | lifeless: and it's not like I'll be doing dev on this machine, so a checkout would have been fine | 07:37 |
| poolie | fairly sure | 07:37 |
| * jml runs bzr svn-import --incremental svn+ssh://svn.twistedmatrix.com/svn/Twisted Twisted | 07:37 | |
| poolie | is there anything that indicates they're different? | 07:37 |
| lifeless | poolie: well, its odd that its suddenly happening to everyone | 07:38 |
| lifeless | poolie: its the same symptoms as a bug reported in 1.10 for isntance | 07:38 |
| lifeless | which is what ia brought up | 07:38 |
| * lifeless tends to be very cautious about dups | 07:39 | |
| lifeless | anyhow | 07:39 |
| lifeless | I finished a hour back :P | 07:39 |
| poolie | an inactive bug that might or might not be a dupe is not helping anyone | 07:40 |
| lifeless | poolie: true, but I didn't suggest leaving it in active | 07:40 |
| poolie | if we dupe it, and then later that guy comes back and says its not fixed at least we'll have more information | 07:40 |
| jml | actually, you know what, | 07:40 |
| jml | let's run that in a screen session | 07:40 |
| lifeless | screen is a great invention | 07:41 |
| poolie | i wish it allowed multiuser in ubuntu by defautl | 07:41 |
| lifeless | spiv: btw if you're not finished, doing a review of my updated patch we were discussing earlier would be a great help to me as I start earlier than thee :) | 07:59 |
| spiv | lifeless: yeah, I can do that. | 08:11 |
| lifeless | spiv: cool. thanks | 08:14 |
| lifeless | poolie: possibly bzr.dev has changed to tickle that bug | 08:14 |
| poolie | maybe | 08:17 |
| lifeless | or possibly none of us were pushing unstacked branches of bzr to lp | 08:18 |
| lifeless | (which raises the question of why we're getting unstacked branches of bzr on lp) | 08:18 |
| lifeless | [or if it does happen with stacked, then the data is definitely quite recent] | 08:18 |
| vila | lifeless: bzrlib.tests.test_pack_repository.TestSmartServerAutopack.test_autopack_or_streaming_rpc_is_used_when_using_hpss, when run in bbc, alwats reports 0 autopack calls (and fails for dev5, but that's another point) | 08:24 |
| lifeless | vila: its failing? | 08:25 |
| lifeless | vila: oh, I know why | 08:25 |
| vila | lifeless: I thought you may be interested as it may mean PackRepository.autopack is not covered anymore | 08:25 |
| lifeless | vila: its PackToRemote | 08:25 |
| lifeless | which is on the cards to delete | 08:25 |
| lifeless | ignore that for now, though if you want to fix it you _might_ find that extending PackToRemote to match bbc formats works | 08:26 |
| vila | lifeless: I'm tracking progress in bzr.dev, so if it's going to be fixed, I'll go fix another failing test :) | 08:27 |
| lifeless | vila: its on the slate to be fixed, yes | 08:27 |
| lifeless | need to delete that class which requires a generic 'sync your state with the remote server' method | 08:27 |
| vila | lifeless: ok, then the first remark still stands, is it expected that PackRepository.autopack is not called anymore ? | 08:28 |
| lifeless | vila: expected? no | 08:29 |
| lifeless | I doubt its a recent reression though, due to where it was gooked in | 08:29 |
| lifeless | *hooked* in | 08:29 |
| vila | lifeless: Well, under its previous incarnation (with a slightly different name, PackRepository.autopack *was* called, even if not for dev5 | 08:30 |
| lifeless | vila: oh sorry misread your question | 08:31 |
| lifeless | yes, autopack is never called on current servers | 08:31 |
| lifeless | they don't need it | 08:31 |
| vila | by 'current' you mean they only used it after 1.12 but not in bzr.dev anymore ? | 08:32 |
| lifeless | bzr.dev->bzr.dev uses insert_record_stream | 08:33 |
| lifeless | bzr.dev->0.>whateveraddedautopack< uses autopack | 08:33 |
| vila | lifeless: ok | 08:34 |
| lifeless | because insert_record_stream does the write group in the servers context a round trip for autopacking isn't needed - the remote instance iwll have locally autopacked if needed | 08:35 |
| === Spaz_ is now known as Spaz | ||
| === mark1 is now known as markh | ||
| vila | mthaddon, spm, herb: PQM struck again by the rare-enough-to-let-you-think-it-s-finally-fixed-that-time bug :-/ Help ? Please ? | 11:06 |
| LarstiQ | vila: ai | 11:08 |
| vila | LarstiQ: Hey ! | 11:08 |
| LarstiQ | vila: heya :) | 11:08 |
| LarstiQ | vila: are you the only one triggering that pqm bug? | 11:11 |
| vila | LarstiQ: It seems so :-) Evidence points to me using lp: URLs | 11:11 |
| vila | But it happens once in ~20 submissions, sometimes several times a week, sometimes not during a month... | 11:12 |
| LarstiQ | irritating | 11:12 |
| lifeless | vila: there is a patch | 11:13 |
| lifeless | vila: I think it needs review | 11:13 |
| vila | lifeless: ??? Against bzr ? pqm ? | 11:13 |
| lifeless | pqm I think, possibly bzr-email | 11:13 |
| LarstiQ | jelmer: is there a better way to check if rebasing didn't do any weird things (the conflicts surprised me) other than "for i in $(seq a b); do bzr diff -c $i > left.$i.diff; done" for left and right and comparing the diffs? | 11:14 |
| vila | lifeless: ok, thanks, I'll research that | 11:14 |
| === mark1 is now known as markh | ||
| igc | night all | 11:39 |
| vila | igc: night Ian | 11:42 |
| lampliter | I think I see what I need to do but I could use confirmation. What I think I need to do is found in section 6.2 .5 of the user documentation. What I'm doing is I have branch A committed to launch pad and I want to merge those changes into branch B. | 11:48 |
| lampliter | I suspect I need to pull the changes from launch pad and merge if there are any differences then commit the conflicts that are fixed | 11:49 |
| lampliter | I'll also think I might need to push branch a before I do anything | 11:50 |
| lampliter | interesting. It looks like the documentation is off because the pull seemed to merge | 11:53 |
| LarstiQ | lampliter: excuse me? | 11:58 |
| Stanlin | help | 13:05 |
| Stanlin | what is the zend channel in freenode ? | 13:05 |
| Stanlin1 | whos bazaar for windows developer? | 13:56 |
| barry | jelmer: ping | 14:12 |
| jsled | howdy. We have a centralized/distributed repo; there's the shared central repo, but individual devs also have local (pristine and dirty) branches. Our build just moved (bzr tag --force …) a release tag, and now devs are seeing "Conflicting tags: «moved tag name»" on pulls, and neither a pull nor a merge is "correcting" things. | 14:19 |
| jsled | Is our only recourse `bzr pull --overwrite`? | 14:19 |
| LarstiQ | no. | 14:19 |
| * LarstiQ looks at tags | 14:19 | |
| ronny | yo LarstiQ | 14:20 |
| ronny | sup? | 14:20 |
| LarstiQ | hey ronny | 14:20 |
| LarstiQ | ronny: doing some rebase dancing on stuff that needs to go back into svn, sigh. | 14:20 |
| LarstiQ | ronny: but otherwise good :) | 14:20 |
| LarstiQ | ronny: you? | 14:20 |
| ronny | LarstiQ: lacking time and sanity | 14:21 |
| ronny | hacking on gtk things recently | 14:21 |
| LarstiQ | ronny: what kind of gtk things? | 14:22 |
| ronny | trying to put together a lib that supplies pygtk with developer oriented debugging things | 14:22 |
| ronny | like ui tracebacks, debugging consoles in widgets | 14:22 |
| LarstiQ | nice | 14:22 |
| ronny | LarstiQ: http://picasaweb.google.com/ronny.pfannschmidt/Pida#5305371513427638034 | 14:23 |
| ronny | oh, i just noticed i shouldnt leave the captions in ;P | 14:23 |
| LarstiQ | jsled: hmmm, I can't find anything else | 14:25 |
| LarstiQ | jsled: (well, handling .bzr/branch/tags manually, but eh) | 14:25 |
| LarstiQ | jsled: there is bzrlib.tag.BasicTags._reconcile_tags(), but it is only used in the overwrite case | 14:26 |
| LarstiQ | ronny: that seems to suggest clicking on the backtrace will do stack walking? | 14:26 |
| jsled | LarstiQ: okay, thanks. | 14:28 |
| ronny | LarstiQ: next step is opening a console window within the stack frame on double click | 14:28 |
| ronny | i want to reuse soething else, but i have to wait for an ok to go lgpl instead of gpl | 14:29 |
| vila | mthaddon, spm, herb: PQM struck again by the rare-enough-to-let-you-think-it-s-finally-fixed-that-time bug :-/ Help ? Please ? | 14:31 |
| herb | vila: checking on it. | 14:32 |
| vila | herb: thanks | 14:32 |
| herb | vila: should be good to go. | 14:36 |
| vila | herb: yup, great, thanks | 14:37 |
| jam | morning barry | 14:45 |
| barry | jam: hi. will you be around in about 1h15 ? i have some additional questions for you, but i have some meetings coming up | 14:46 |
| jam | barry: sure | 14:47 |
| jam | morning vila | 14:47 |
| vila | morning jam :) | 14:47 |
| jam | vila: so am I right that brisbane-core now passes all tests except the autopack/streaming one? | 14:56 |
| jam | I think we can just change the "is_compatible" check | 14:56 |
| jam | to remove the "supports | 14:56 |
| jam | if not 'supports_chk' | 14:56 |
| vila | jam: not quite, I have still some failures due to known bugs (at least one specific to 64 bits) | 14:57 |
| jam | vila: I'm pretty sure my last run had exactly 5 failures | 14:58 |
| jam | though that is --no-plugins, etc | 14:58 |
| vila | jam: regarding bzrlib.tests.test_pack_repository.TestSmartServerAutopack.test_autopack_or_streaming_rpc_is_used_when_using_hpss, I talked with lifeless this morning and he said he will fix some related problem, so we can wait for bzr.dev | 14:59 |
| vila | jam: re-running (I should somehow archive my last runs somewhere :) | 14:59 |
| jam | vila: yeah, I read through that. I still think we can just get rid of the 'not fmt.supports_chks' and have it 'just work'. | 15:00 |
| jam | Mostly because I did the work to get streaming working | 15:00 |
| jam | which is really all it should have needed | 15:00 |
| vila | I'll check that then (lifeless proposed it too) | 15:00 |
| Tak | if I had uncommitted changes in part of a checkout, and I unthinkingly did `bzr revert -rblah` from the checkout root, is there a way to back that out? | 15:23 |
| garyvdm | Tak: there may be .~n~ files in your directory | 15:25 |
| Tak | heh | 15:25 |
| garyvdm | Tak: In some cases when bzr overwrites a file in your working directory - it creates a backup. The name of this back up file will be <the name of your file>.~1~ or .~2~ ect.. | 15:27 |
| Tak | yeah, I know | 15:28 |
| Tak | probably easier to remerge from the original source than to manually recopy the backups | 15:28 |
| Tak | I guess I was looking for `bzr undo` ;-) | 15:28 |
| vila | jam: commenting out the 'and not fmt.supports_chks' make the tests error out in an ugly way, even after fixing obvious typos (http://paste.ubuntu.com/123379/ wth ? untested ?) | 15:33 |
| vila | jam: rats, get rid of the import pdb before trying ./bzr selftest -s bt.test_pack_repository.TestSmartServerAutopack.test_autopack_or_streaming_rpc_is_used_when_using_hpss | 15:34 |
| jam | vila: well to start with, 'fulltext_network_to_record' looks like a bug in bzr.dev that we should fix anyway | 15:35 |
| cody-somerville | How do I make it so that bzr will never mangle the revision number - only add? | 15:40 |
| cody-somerville | I understand this is a branch setting. | 15:40 |
| vila | jam: yeah or at least report to spiv and lifeless | 15:40 |
| beuno | cody-somerville, IIRC, append_only = true in ~/.bazaar/locations.conf | 15:41 |
| jam | beuno: "append_revision_only" | 15:41 |
| jam | sorry | 15:41 |
| jam | "append_revisions_only" | 15:41 |
| jam | cody-somerville: you should also be able to set it in .bzr/branch/branch.conf inside the branch itself | 15:42 |
| vila | jam: with http://paste.ubuntu.com/123385/, tests are passing (not the [] pair in fulltext_network_to_record | 15:45 |
| vila | jam: so, obviously untested code, which raises the question: is it expected to convert to fulltext ? | 15:45 |
| jam | vila: so there is a new issue with a "network stream" record versus the "text you put on disk" bytes | 15:46 |
| jam | Obviously nothing was using the 'fulltext' record yet | 15:47 |
| jam | for the network stream | 15:47 |
| vila | jam: yeah we agree | 15:47 |
| vila | jam: fix sent to ML | 15:51 |
| === picturesque is now known as domas | ||
| jam | vila: I think the patch should be against bzr.dev, probably with a direct test of that function | 15:52 |
| vila | jam: patch *is* against bzr.dev. I have not hte slightest idea about what this function is doing :-) I call that 'blind debugging' :) | 15:53 |
| jam | vila: I know what it is doing, just not why it wasn't tested before | 15:54 |
| vila | jam: but I'm sure lifeless will add the proper tests :) | 15:54 |
| jam | I saw that it came in a bit late | 15:54 |
| jam | I just saw you claim it as a "bbc:MERGE" which didn't make as much sense to me | 15:54 |
| jam | my guess is this code is meant to be used | 15:54 |
| jam | when the source repo sends a 'fulltext' stream | 15:54 |
| jam | over the RPC | 15:54 |
| vila | ha sorry, I forgot to remove that, I wanted to leave only the [Attn lifeless] | 15:54 |
| jam | as pack repos don't do that | 15:55 |
| jam | but chk does because it was easiest to write things that way | 15:55 |
| jam | GC repos do as well | 15:55 |
| vila | jam: so forget that [bbc:MERGE], that wasn't a request, I'll merge it as is and wait for conflicts with further modifications by lifeless. Or do you want me to add a FIXME-bbc above the # no fmt.support_chks ? | 15:59 |
| jam | vila: I was suggesting that we fix the code in bzr.dev, and then bring that back into bbc | 16:00 |
| vila | jam: but lifeless said InterPackToRemotePack will be removed, so I don't think if it's worth it | 16:00 |
| jam | I think it is worth having a clean test suite for now | 16:00 |
| jam | as we can then send things through pqm, etc | 16:00 |
| vila | jam: right, I did the fix against bzr.dev and I'm merging it into bbc right now | 16:00 |
| garyvdm | Is there a equivalent to commit's --local option for pull? | 16:17 |
| garyvdm | Ah - bug 194716 | 16:19 |
| ubottu | Launchpad bug 194716 in bzr "bzr pull should support --local" [Medium,Triaged] https://launchpad.net/bugs/194716 | 16:19 |
| jelmer | barry, pong | 16:24 |
| barry | jelmer: hi. i was looking at the bzr branches on python.org and i think we have a problem, but i'm not sure | 16:39 |
| barry | jelmer: bzr info on the 2.5 branch is http://people.ubuntu.com/~andrew/python/branches/release25-maint | 16:40 |
| barry | jelmer: but i want to change that to http://svn.python.org/projects/python/branches/release25-maint | 16:40 |
| barry | jelmer: can i just do a 'bzr pull --remember' or will that mess things up (either for the branch or for clients of the branch) | 16:41 |
| jelmer | barry, no, that should work ok | 16:41 |
| barry | jelmer: as long as i use the old v3 mapping, right? | 16:41 |
| jelmer | barry, yeah | 16:42 |
| jelmer | barry, if you use the v4 mapping it'll just give you a "Branches Diverged" error | 16:42 |
| barry | jelmer: cool, thanks. i'm planning on setting up a cron that just does the `bzr pull` in each of the 4 or 5 directories we care about | 16:42 |
| barry | jelmer: cool | 16:43 |
| evarlast | how can I do the opposite of push? | 16:53 |
| jelmer | evarlast, pull? | 16:53 |
| evarlast | oops. | 16:53 |
| Tak | unpush? | 16:53 |
| evarlast | that was a think-o. its like a typo, only my brain was the problem. | 16:54 |
| evarlast | how can I do the opposite of split? | 16:54 |
| evarlast | I have two entirely unrelated branches. I would like to move branch B into branch A/B while keeping history. | 16:54 |
| Tak | incidentally, is there any reason a `bzr undo` couldn't be implemented? | 16:54 |
| jelmer | evarlast, the opposite of split would be join | 17:01 |
| radix | Tak: you mean like "revert"? or, say, "uncommit"? | 17:01 |
| evarlast | jelmer: thank you. | 17:02 |
| evarlast | jelmer: I'll file a bug for docs. there should be a see also: join on the bzr help split output ;) | 17:02 |
| james_w | Tak: I believe it is something that Aaron wants, and is slowly adding things that would allow it to happen | 17:07 |
| james_w | Tak: it's a way from being ubiquitous though | 17:07 |
| evarlast | can anyone help me with join? I successfully upgraded to a rich-root format. I try bzr join ../B, and it says Not A Branch /home/me/placewithAandB. I copy B into A thinking it will join in place. I run bzr join B and it says bzr: ERROR: Cannot join O2SensorDiagCalSyn. Trees have the same root | 17:18 |
| === montywi|zzz is now known as mpntywi | ||
| === chx_sleeping is now known as chx | ||
| evarlast | oh wow, no join documentation in the user-reference :( | 17:28 |
| jelmer | evarlast, the tree you'd like to join already ahs to be in place | 17:29 |
| evarlast | ok, so it is in place and I get "Cannot join B. Trees have the same root" | 17:36 |
| evarlast | but B isn't a dir known to the branch at . | 17:37 |
| === mpntywi is now known as montywi | ||
| evarlast | oh, interesting. I did it on all new branches and it worked fine. | 17:40 |
| Tak | radix: I mean something like uncommit that doesn't care what the last command was | 17:40 |
| evarlast | I need to upgrade the format of B too, not just A, I'll bet. | 17:40 |
| === beuno_ is now known as beuno | ||
| evarlast | damn, nope, still the same error. | 17:41 |
| evarlast | it works on all fresh branches, but not these two branches. | 17:41 |
| evarlast | bzr: ERROR: Cannot join ... Trees have the same root | 17:44 |
| evarlast | but they don't!!! | 17:44 |
| rocky | hm, does the smart server have any type of user access control? | 17:47 |
| evarlast | rocky: the bzr serve does not. | 17:47 |
| evarlast | rocky: when running one through apache, use apache Access control. Same is true of SSH | 17:47 |
| rocky | gotcha | 17:48 |
| rocky | i'm looking for something a little more flexible like mod_svn | 17:48 |
| rocky | with it's authz files | 17:49 |
| evarlast | rocky: yes, see the manual. | 17:53 |
| evarlast | there is a fastcgi option that is well documented. | 17:54 |
| evarlast | google around and find a small modification to that will make it work very well with mod_wsgi | 17:54 |
| evarlast | and you can use apache auth. | 17:54 |
| evarlast | it is very nice. | 17:54 |
| evarlast | Active Directory auth integration and all :) | 17:54 |
| fbond | Does anyone know if trac-bzr supports using multiple bzr branches with a single trac installation? | 17:56 |
| evarlast | I'm so confused as to why my trees have the same root. | 18:00 |
| === thumper_laptop is now known as thumper | ||
| === beuno_ is now known as beuno | ||
| evarlast | looks similar to this unanswered question: https://answers.edge.launchpad.net/bzr/+question/46922 | 18:42 |
| evarlast | answer was answered here 8 months ago: http://bzr.arbash-meinel.com/irc_log/bzr/2008/06/bzr-2008-06-07 | 18:45 |
| evarlast | I'll blog post my solution, which will hopefully make it more googlable. | 18:45 |
| evarlast | new question, how can i change my root id from 'TREE_ROOT' | 18:49 |
| rockstar | jelmer, ping | 19:01 |
| jelmer | rockstar, pong | 19:02 |
| jam | barry: ping | 19:10 |
| barry | jam: otp... | 19:10 |
| jam | k | 19:11 |
| jam | just wanted to see about possibly setting up the http + smart server | 19:11 |
| rocky | hrm, i'm currently building a wsgi app that wraps the http smart server wsgi app ... is there anyway i can peek at the request info to see what sort of operation is being done (read or write) and to what branch and/or path? | 19:22 |
| barry | jam: ping | 19:39 |
| jam | hey barry | 19:39 |
| barry | jam: hi. smart server! | 19:39 |
| rocky | ok another question, does the "bzr serve" server for bzr 1.12 use smart server protocol one or some other protocol? | 19:41 |
| jam | rocky: smart server protocol | 19:41 |
| jam | but certainly not wrapped in http calls | 19:42 |
| rocky | jam: no, i'm asking which version of the smart server protocol is it using? | 19:42 |
| rocky | or is there only "one" version at this point? | 19:42 |
| jam | in general we don't have a separate versioning of the protocol, just more/less functions available | 19:43 |
| rocky | jam: also i'm not sure what your last comment meant about not being wrapped | 19:43 |
| jam | I don't think 1.12 has anything different from 1.11 | 19:43 |
| jam | rocky: the smart server protocol is a series of requests and responses | 19:44 |
| jam | you can 'tunnel' that through an HTTP POST session | 19:44 |
| jam | 'bzr serve' doesn't handle an HTTP POST | 19:44 |
| rocky | oh yeah i forgot | 19:45 |
| rocky | basically i'm working on ClueBzrServer with is a simple http server that serves up bzr smart protocol over http via the bzr smart wsgi app | 19:45 |
| rocky | and i'm trying to add basic read/write security | 19:45 |
| rocky | but i really need to peek at what command is being requested to determine security | 19:45 |
| rocky | and i'm having difficulty doing that | 19:45 |
| rocky | i'm seeing references to ProtocolOne classes and ProtocolThree ... hence my question about protocol versions | 19:46 |
| vila | jam: down to 1 failure, 1 error on bbc, one is the symlink/dirstate/64bits and I think you can't see it the other is about AssertionError: these files contain an assert statement and should not: | 19:46 |
| vila | /home/vila/src/bzr/experimental/brisbane-core/bzrlib/chk_map.py | 19:46 |
| jam | ProtocolX is about how the bytes are encoded on the wire. ProtocolThree has been used for a while | 19:46 |
| jam | vila: yeah, there are a lot of asserts there | 19:46 |
| vila | jam: Can you have a look ? There are less than 10 asserts, are you confident enough to remove at least some and I'll handle the others | 19:47 |
| jam | it is a heck of a lot more convenient for prototyping/debugging | 19:47 |
| jam | vila: I'm not sure if I can guarantee not to introduce more... | 19:47 |
| vila | lol | 19:47 |
| jam | if ...: raise AssertionError is ok for production code | 19:47 |
| jam | but sucks when trying to get stuff done | 19:47 |
| rocky | jam: so any hints on how i might peek to see what command is being issued if i'm inside SmartWSGIApp ? | 19:47 |
| vila | well, long ago, when I was C++ing, I used assertions a lot, but now in bzr, I think there are 3 kinds of assertions: | 19:48 |
| vila | 1) The ones you can write tests for | 19:48 |
| vila | 2) The one you left in production with if ..: AssertionError | 19:49 |
| vila | 3) the ones you put during prototyping because... because | 19:49 |
| vila | jam: Can you delete the 3) kind ? :-) | 19:49 |
| jam | vila: I'm not sure I'm done prototyping | 19:51 |
| jam | i can probably take a look at it | 19:51 |
| vila | jam: well, like me, you want a *passing* test suite, and using assert forbids that :-) | 19:52 |
| jam | rocky: My recommendation would be to look at how 'bzrlib/transport/http/wsgi.py' is doing it | 19:52 |
| jam | and then change things based on whether the user is authenticated or not | 19:52 |
| rocky | jam: that's where my rabbit hold began :) | 19:53 |
| jam | rocky: why does it matter what request is made? | 19:53 |
| rocky | jam: i can easily restrict user access, but i need to restrict based on what commands are being used... like anonymous should be able to read but not write | 19:53 |
| jam | rocky: right, so anonymous gets the readonly+ server | 19:53 |
| jam | and authenticated gets the other | 19:53 |
| jam | rocky: See 'make_app()' | 19:54 |
| rocky | but i need to make user1 be able to write and user2 only read | 19:54 |
| rocky | and i want user3 to be able to write to some branches/paths but not others | 19:54 |
| rocky | so using separate apps doesn't really help with all those use cases | 19:55 |
| rocky | and i'm quite familiar with make_app() atm ;) | 19:55 |
| jam | rocky: what you probably want is something along the lines of: https://blueprints.edge.launchpad.net/bzr/+spec/acl-transport | 19:56 |
| jam | which isn't written yet | 19:56 |
| rocky | lol | 19:56 |
| jam | though I'm happy to work with someone who wants to implement it | 19:56 |
| rocky | sounds like what i'm writing actually :) | 19:56 |
| rocky | well, i'm much higher level | 19:56 |
| rocky | but maybe that's my problem, i need to be hooking in a the transport level to make these decisions, not on the wsgi level (too high) | 19:57 |
| jam | rocky: so at the intermediate level, you can look around line 160 | 19:57 |
| jam | where it does | 19:57 |
| jam | smart_protocol_request = self.make_request( | 19:57 |
| jam | transport, out_buffer.write, request_data_bytes, adjusted_rcp) | 19:57 |
| rocky | yep... that's where i have my pdb stuck atm :) | 19:57 |
| jam | so... (a) you could only support ProtocolThree | 19:58 |
| jam | rather than trying to support all possible bzr clients | 19:58 |
| jam | we've been at 3 since bzr 1.6 | 19:59 |
| rocky | yeah i don't care about old clients atm | 19:59 |
| rocky | it's looking like i'd have to stuff my own transport in there that is aware of my security/acl rules and raises errors when security authorization isn't met | 20:01 |
| rocky | hm | 20:01 |
| fullermd | I tend to think ACLage pretty much requires shutting off VFS methods wholesale. Certainly can't do much while they're being actively used by clients. | 20:02 |
| fullermd | I mean, once you have write at all, you can use them to scribble over any existing data in the repository to your heart's content. | 20:02 |
| rocky | but if i'm inside the transport what difference does it make about the vfs methods? i can restrict as necessary | 20:06 |
| * rocky realizes he doesn't have a lot of experience with bzr transports atm | 20:06 | |
| thumper | morning, morning | 20:06 |
| fullermd | Well, but restricting "as necessary" to prevent bad stuff would be enough to prevent it from doing its actual job as well. | 20:08 |
| rocky | jam: do tranports have to be registered? or can they simply be used by instantiating them and passing them to the appropriate places? | 20:10 |
| jam | rocky: you should be able to create them and then pass them around | 20:10 |
| jam | as long as nothing needs to call 'get_transport()' | 20:10 |
| rocky | because i'm considering writing my own transport that wraps ChrootTransport and doing what make_app does but make sure my transport gets used instead | 20:11 |
| jam | rocky: sounds right | 20:13 |
| jam | make_app() just uses get_transport() to be easy, so constructing it yourself should be fine | 20:13 |
| rocky | yeah, basically i won't be able to use make_app() verbatim anymore but i can make my equiv factory function that does the same but uses my transport | 20:14 |
| rocky | i wish make_app() had a transport=None arg that fell back to get_transport when transport wasn't specified :) | 20:14 |
| barry | jam: brettcannon 's here to talk about cpo in a few minutes | 20:16 |
| jam | rocky: you could always register it, and then set your "local_url" to whatever you want | 20:16 |
| jam | or 'root' | 20:16 |
| jam | sorry | 20:16 |
| jam | make_app(root='myacl:///') | 20:17 |
| rocky | interesting | 20:17 |
| brettcannon | barry: OK, I'm ready; running a checkout now to see what kind of timing I am getting right now. | 20:33 |
| barry | brettcannon: i'm still running my update puller. you're using trunk right? | 20:34 |
| brettcannon | Yep. | 20:34 |
| barry | k | 20:34 |
| === barry is now known as barry-afk | ||
| jam | brettcannon: are you still around? | 21:09 |
| brettcannon | jam: Yep, I'm still here. | 21:09 |
| jam | I was wondering if you had ssh access to code.python.org, so we could see what impact using a smart server would have | 21:10 |
| brettcannon | I have the same ssh access any core developer does under the pythondev account. | 21:10 |
| jam | brettcannon: good enough. | 21:10 |
| jam | The performance of bzr+http should at least be comparable to bzr+ssh | 21:10 |
| jam | and should be faster than plain http | 21:11 |
| brettcannon | OK. | 21:11 |
| brettcannon | Is the server up? | 21:11 |
| jam | brettcannon: well, I can go to the web server: http://code.python.org/python/trunk/ | 21:14 |
| brettcannon | jam: I meant the smart server. | 21:14 |
| jam | brettcannon: as long as bzr is installed and in the path on the remote machine | 21:14 |
| jam | it should 'just work' | 21:14 |
| brettcannon | bzr: ERROR: Generic bzr smart protocol error: Invalid http response for http://code.python.org/python/trunk/.bzr/smart: Unable to handle http code 404: Not Found | 21:16 |
| brettcannon | And that was with ``bzr branch bzr+http://code.python.org/python/trunk bzr``. | 21:16 |
| jam | brettcannon: we don't have 'bzr+http' installed. I was asking you to use 'bzr+ssh' | 21:18 |
| jam | to let us know ~ what you would see if we set up bzr+http | 21:18 |
| brettcannon | Ah, OK. | 21:18 |
| brettcannon | jam: Didn't work either. | 21:20 |
| brettcannon | Server does not understand Bazaar network protocol 3, reconnecting. (Upgrade the server to avoid this.) | 21:20 |
| brettcannon | bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) | 21:20 |
| brettcannon | HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x14220b0> | 21:20 |
| brettcannon | jam: But I am more worried about non-committers getting a decent checkout time than core committers. | 21:20 |
| jam | brettcannon: right. I just haven't taken the time to set up bzr+http, and performance should be on par with bzr+ssh | 21:20 |
| jam | barry-afk: let us know when you get back | 21:21 |
| jam | brettcannon: you can set up bzr+http to be 'anonymous' read-only access | 21:21 |
| brettcannon | jam: OK. | 21:21 |
| jam | brettcannon: it looks like it didn't find bzr on the server | 21:21 |
| brettcannon | jam: Figures. =) | 21:21 |
| jam | can you do "ssh host; bzr --version" ? | 21:21 |
| jam | barry said that he had 1.12 installed | 21:22 |
| jam | I would have assumed it installed in /usr/bin, which is why it doesn't make sense that it wasn't found | 21:22 |
| brettcannon | I don't have that kind of ssh access to code.python.org. | 21:22 |
| jam | so what access *do* you have? | 21:22 |
| brettcannon | I can do checkouts over SSH through the pythondev account, but that's basically it; Barry is the one with shell access. | 21:23 |
| brettcannon | I am just the guinea pig who keeps getting slow checkout times compared to everyone else. | 21:24 |
| jam | brettcannon: yeah, I'm hoping we can sort out why | 21:24 |
| jam | I think we need to hear from barry how things are set up | 21:24 |
| jam | are you doing "bzr branch bzr+ssh://pythondev@.../" ? | 21:24 |
| brettcannon | jam: OK | 21:25 |
| brettcannon | jam: bzr branch -Dhpss bzr+ssh://pythondev@code.python.org/python/trunk bzr | 21:34 |
| jam | brettcannon: Did that work? | 21:37 |
| jam | -Dhpss isn't strictly necessary, but it might be interesting to see what it logs | 21:37 |
| brettcannon | jam: No. | 21:37 |
| brettcannon | Server does not understand Bazaar network protocol 3, reconnecting. (Upgrade the server to avoid this.) | 21:37 |
| brettcannon | bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) | 21:37 |
| brettcannon | HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x14220b0> | 21:37 |
| brettcannon | jam: I'll be back a few minutes; need to grab lunch and bring it back to my desk. | 21:39 |
| * mwhudson suspects a python gc bug!? | 21:41 | |
| === barry-afk is now known as barry | ||
| barry | jam: did brett leave? | 21:43 |
| jam | barry: for a bit. he said he had to go grab lunch | 21:44 |
| barry | jam: k. what did we decided about smart server? | 21:44 |
| jam | barry: he wasn't able to branch using bzr+ssh | 21:45 |
| jam | do you know why that would be? | 21:45 |
| barry | jam: nope. i do it all the time | 21:46 |
| barry | jam: was he doing bzr+ssh://pythonbzr@ ? | 21:47 |
| barry | jam: pythondev@ is for svn | 21:47 |
| mwhudson | arararargh | 21:48 |
| mwhudson | LockableFiles has a reference to the transport and has a __del__ | 21:48 |
| jam | barry: he was using "pythondev" it would seem | 21:49 |
| jam | so does he just need a different user? | 21:49 |
| lifeless | mwhudson: cycles >< | 21:49 |
| barry | jam: yes, i think so | 21:49 |
| mwhudson | lifeless: yes | 21:49 |
| jam | barry: just as a point of reference, can you "time bzr branch http://code.python.org/python/trunk" versus "bzr+ssh://.../trunk" ? | 21:49 |
| jam | and then time it again with '--stacked' ? | 21:50 |
| barry | jam: sure | 21:50 |
| jam | that is what I'd like to see from brett, but perhaps you'll have an easier time getting it to work | 21:50 |
| jam | (of course, *his* connection is the one we care about) | 21:50 |
| jam | barry: what is weird is that he seemed to be getting *some* sort of error for 'pythondev', but not a very clear one. | 21:51 |
| barry | jam: pythondev should be harded coded to speak svn. weird | 21:51 |
| jam | barry: probably is, and that is the problem | 21:52 |
| jam | it spoke 'svn' back to the bzr client | 21:52 |
| jam | which then said "server doesn't understand bzr protocol 3" | 21:52 |
| jam | and then closed the connection | 21:52 |
| barry | that makes sense | 21:52 |
| jam | (that *was* the problem) | 21:52 |
| barry | pythonbzr is hard coded to speak bzr, but uses the same keys (and is generated at the same time as pythondev) | 21:53 |
| poolie | hello world | 21:55 |
| brettcannon | barry: jam: I'm back | 21:55 |
| jam | hi brettcannon | 21:55 |
| barry | brettcannon: hi. you want pythonbzr@ :) | 21:55 |
| brettcannon | barry: No. =) | 21:56 |
| jam | hi poolie | 21:56 |
| barry | brettcannon: well, if you want to speak bzr to code.py.org | 21:56 |
| brettcannon | barry: Ah, as in you set that account up. Thought you were trying to give me some SSH account and thus more responsibility. | 21:57 |
| barry | brettcannon: right! bzr+ssh will only work against pythonbzr. svn+ssh will only work against pythondev | 21:57 |
| brettcannon | barry: That did it. | 21:58 |
| barry | cool | 21:59 |
| brettcannon | barry: OK, so bzr+ssh took 14 minutes. | 22:16 |
| barry | brettcannon, jam http took 12m12 and bzr+ssh took 14m9 | 22:19 |
| barry | that was without stacking | 22:19 |
| brettcannon | ditto | 22:19 |
| barry | brettcannon, jam i'm running it again w/ --stacked | 22:25 |
| jam | barry: running sequentially, not concurrently, right? | 22:26 |
| barry | jam: right! i still don't trust my router | 22:26 |
| barry | jam: e.g. i /know/ i'm taking probably a 30% hit on throughput since i "upgraded" the firmware | 22:26 |
| barry | not to mention the instability | 22:27 |
| brettcannon | barry, jam http checkout took 9:34; shaves five minutes off compared to home. | 22:30 |
| brettcannon | Still wonder if there is something special about my machine or just the way bzr does things as my hg checkout is more than halved from school compared to home instead of by a third as for bzr. | 22:31 |
| barry | brettcannon: well, one thing is for sure. when i bypass my router and talk directly to my modem, i get much better performance. i'm planning on downgrading the firmware back to the previous version this weekend to see if i can recapture the better performance | 22:35 |
| barry | brettcannon, jam http + --stacked was 15m32! | 22:35 |
| barry | brettcannon, jam where it was something like 3m55s bypassing my router | 22:36 |
| barry | so i don't know what to make of that | 22:36 |
| * barry is trying bzr+ssh --stacked now | 22:36 | |
| jam | barry: this is with bzr.dev, right? | 22:37 |
| barry | jam: ah shit, not | 22:37 |
| * barry slams C-c | 22:37 | |
| jml | jelmer: at some point, the progress bar for bzr svn-import gets stuck, it seems: e.g. [#| ] copying revision 777/7694 | 22:44 |
| jml | oh no, it's turning | 22:44 |
| jml | jelmer: never mind me. | 22:44 |
| mwhudson | can someone triage https://bugs.edge.launchpad.net/bzr/+bug/335180 ? | 22:44 |
| ubottu | Ubuntu bug 335180 in bzr "LockableFiles.__del__ creates uncollectable garbage including connected sockets" [Undecided,New] | 22:44 |
| jelmer | jml: :-) | 22:45 |
| jml | this bug is also easy enough to triage: https://bugs.edge.launchpad.net/bzr/+bug/335182 | 22:45 |
| ubottu | Ubuntu bug 335182 in bzr "break-lock does not accept upper-case 'Y' as 'yes'" [Undecided,New] | 22:45 |
| jml | jelmer: my svn-import of Twisted has been running all night and is still not finished | 22:46 |
| jelmer | jml, which bzr-svn version/ | 22:46 |
| jelmer | ? | 22:46 |
| brettcannon | barry, jam: 6:48 on http stacked. | 22:46 |
| jml | jelmer: whatever lp:bzr-svn was yesterday :) | 22:46 |
| jelmer | jml: Hmm | 22:47 |
| jml | jelmer: Twisted is a big repo with a lot of branches and a long history, so I'm not *too* worried, just as long as the updates don't take as long. | 22:47 |
| jelmer | jml: Hmm, still | 22:48 |
| jml | jelmer: yeah :) | 22:48 |
| jelmer | jml: OOo took less than a day in total.. | 22:49 |
| spiv | jelmer: from Australia? :) | 22:49 |
| jelmer | spiv, ah | 22:49 |
| jml | spiv: this isn't from Australia | 22:49 |
| jml | it's from my linode box | 22:49 |
| spiv | jml: hmm. Keep an eye on the memory consumption... | 22:49 |
| spiv | jml: also, you may find svnadmin dump on wolfwood and then importing from that to be faster... | 22:50 |
| spiv | jml: or, just be patient :) | 22:50 |
| jml | spiv: huh, interesting. | 22:50 |
| jml | spiv: it has graphs for CPU, Disk IO and Network, but not memory | 22:50 |
| spiv | jml: I find "vmstat 1" is practically the same thing ;) | 22:50 |
| jml | spiv: if I type that into firefox I just get a google search page :P | 22:51 |
| * mwhudson hits jml | 22:51 | |
| mwhudson | the bzr-gtk tests are spamming dialog boxes at me :( | 22:53 |
| jml | tsk tsk | 22:54 |
| jml | there are ways of writing tests to avoid that. | 22:54 |
| mwhudson | yes, "using bzrlib.tests.TestCase" being the main one | 22:55 |
| jml | well. | 22:55 |
| jml | mwhudson: also the tests for tribunal create GTK+ windows and avoid spamming the screen with them. | 22:55 |
| barry | brettcannon, jam 4m17 http --stacked | 22:56 |
| barry | jelmer: did you ever ppa the bzr-svn that had the fix for the svn-import problem i was seeing yesterday? | 22:58 |
| barry | jelmer: bzr pull on an svn hosted branch is not an option. it takes hours just to do a pull | 22:59 |
| lifeless | spiv: so I need to leave here late avo to get to the city, so if you'recoming over I highly commend earlier to you | 23:00 |
| barry | jam: bzr+ssh --stacked in 3m52s | 23:01 |
| jelmer | barry: No, I haven't reproduced the problem yet | 23:01 |
| barry | jam: i need to leave now for a while. can you please related those numbers to brett if/when he gets back | 23:02 |
| jelmer | barry: Whoa, hours? | 23:02 |
| barry | jelmer: yeah | 23:02 |
| jelmer | barry, it's less than a minute here.. | 23:02 |
| barry | jelmer: is there maybe a cache i'm not utilizing? | 23:02 |
| spiv | lifeless: ok | 23:02 |
| lifeless | spiv: right now, I have a little quirk your input would be great on | 23:02 |
| jelmer | barry, no, it's just a performance regression in 0.5.0 that's fixed in 0.5.2 | 23:03 |
| barry | jelmer: i'm sorry, but i need to go out for a few hours now. i'll try to ping you tomorrow for details. | 23:03 |
| lifeless | File "/home/robertc/source/baz/RemoteRepository._format/bzrlib/smart/request.py", line 279, in _call_converting_errors | 23:03 |
| lifeless | return callable(*args, **kwargs) | 23:03 |
| lifeless | File "/home/robertc/source/baz/RemoteRepository._format/bzrlib/smart/repository.py", line 444, in do_chunk | 23:03 |
| lifeless | for record in stream.read(): | 23:03 |
| lifeless | File "/home/robertc/source/baz/RemoteRepository._format/bzrlib/versionedfile.py", line 1529, in read | 23:03 |
| barry | jelmer: ah! okay cool. i'll try to figure out a way to get 0.5.2 on that box tomorrow | 23:03 |
| lifeless | for record in self._kind_factory[storage_kind]( | 23:03 |
| barry | jelmer: thanks! | 23:03 |
| lifeless | KeyError: '' | 23:03 |
| barry | jam: thanks! | 23:03 |
| barry | see y'all tomorrow | 23:03 |
| lifeless | spiv: (its getting a zero-length byte string out of the pack sent on the wire) | 23:03 |
| === barry is now known as barry-away | ||
| jelmer | barry-away, np | 23:03 |
| spiv | lifeless: so the record_bytes starts with a \n? | 23:06 |
| lifeless | spiv: I guess | 23:06 |
| spiv | lifeless: the decoder logic looks sane (although the error reporting could be better I suppose), so I'd suspect an encoding issue. | 23:07 |
| spiv | lifeless: sticking a print(body_stream_chunk) in do_chunk would probably help | 23:07 |
| spiv | Er, | 23:07 |
| spiv | print repr(body_stream_chunk) :) | 23:07 |
| lifeless | (Pdb) print repr(bytes) | 23:08 |
| lifeless | '' | 23:08 |
| lifeless | spiv: we get some nested packs here, a little odd | 23:12 |
| spiv | That does sound odd. | 23:12 |
| spiv | Also, I have no idea which 'bytes' variable you show in that pdb snippet... | 23:12 |
| lifeless | the one that should contain the record stream record | 23:13 |
| lifeless | which is the body of the pack record from the stream | 23:13 |
| lifeless | (Pdb) print repr(body_stream_chunk) | 23:14 |
| lifeless | 'B0\ntexts\n\n' | 23:14 |
| lifeless | (Pdb) c | 23:14 |
| lifeless | > /home/robertc/source/baz/RemoteRepository._format/bzrlib/smart/repository.py(432)do_chunk() | 23:14 |
| lifeless | -> self.stream_decoder.accept_bytes(body_stream_chunk) | 23:14 |
| lifeless | ERROR: branch_implementations.test_branch.TestBranch.test_clone_partial(RemoteBranchFormat-default) | 23:14 |
| lifeless | Error received from smart server: ('error', "''") | 23:14 |
| lifeless | ok, understood and fixed | 23:16 |
| lifeless | (though its a bug that we're hitting the broken case) | 23:16 |
| spiv | The sender was encoding some sort of dud text record? | 23:16 |
| lifeless | we're sending a delta-closure | 23:16 |
| lifeless | which means transcoding | 23:16 |
| lifeless | that code path is just broken atm | 23:17 |
| spiv | Oh, hmm. | 23:17 |
| lifeless | @@ -1500,7 +1477,11 @@ | 23:17 |
| lifeless | serialised = record_to_fulltext_bytes(record) | 23:17 |
| lifeless | else: | 23:17 |
| lifeless | serialised = record.get_bytes_as(record.storage_kind) | 23:17 |
| lifeless | - pack_writer.add_bytes_record(serialised, [(substream_type,)]) | 23:17 |
| lifeless | + if serialised: | 23:17 |
| lifeless | + # Some streams embed the whole stream into the wire | 23:17 |
| lifeless | + # representation of the first record, which means that | 23:17 |
| lifeless | + # later records have no wire representation: we skip them. | 23:17 |
| lifeless | + pack_writer.add_bytes_record(serialised, [(substream_type,)]) | 23:17 |
| lifeless | fixes the symptoms | 23:17 |
| lifeless | but I need to find why its flagging that as True | 23:17 |
| spiv | Well, LazyKnitContentFactory explicitly can return '' from record.get_bytes_as(record.storage_kind) | 23:21 |
| lifeless | yes | 23:21 |
| spiv | And this is a RemoteBranchFormat test, so it makes sense that the source stream would have a LazyKnitContentFactory record... | 23:21 |
| lifeless | thats the point | 23:21 |
| lifeless | not if we're not transcoding | 23:22 |
| lifeless | LazyKCF only turns up when include_delta_closure=True | 23:22 |
| lifeless | ok, should all be good now | 23:27 |
| lifeless | spiv: down to 23 hpss calls | 23:27 |
| spiv | lifeless: sweet | 23:30 |
| garyvdm | hi bialix: Check out http://garyvdm.googlepages.com/revision-selector.png | 23:30 |
| * spiv prepares to wander off | 23:30 | |
| bialix | garyvdm: WOW | 23:31 |
| garyvdm | Work in progress... | 23:31 |
| bialix | you're wizard of log | 23:31 |
| garyvdm | lol | 23:31 |
| bialix | gary, did you see progress bar in qbzr with bzr 1.12? | 23:32 |
| poolie | sweet | 23:32 |
| garyvdm | bialix: Let me test - I normally use the command line for pull/push etc. | 23:33 |
| garyvdm | Hi poolie | 23:34 |
| bialix | I don't see pb neither in command line nor qbzr @win32 | 23:34 |
| lifeless | full tests running, then this branch is up for landing too | 23:35 |
| garyvdm | bialix: pb working fine for me in command line and qbzr on ubuntu. I'll test on win32 tomorrow for you. | 23:36 |
| bialix | well, I guess it's the bug | 23:36 |
| bialix | at least one more windows user confirm it | 23:37 |
| garyvdm | bialix: Your mail brought out some usefull information. It's just gone off topic though. | 23:39 |
| bialix | you mean bzr-gtk vs qbzr? | 23:40 |
| garyvdm | yes | 23:40 |
| garyvdm | bialix: You we asking about adding things like push, pull, revert, tag to qlog | 23:40 |
| bialix | yep | 23:40 |
| garyvdm | I've been thinking about it. | 23:40 |
| bialix | generally it's easy | 23:41 |
| bialix | unless we playing with multiple branches at once | 23:41 |
| bialix | there things becomes tricky for me | 23:41 |
| garyvdm | For push, pull - if you've got more than one branch - it's not important which branch you push/pull from, just get a branch that has the revision. | 23:41 |
| bialix | tag | 23:42 |
| garyvdm | To get such a branch - just get the revision, and then rev.branch | 23:42 |
| bialix | if there is more than 1 branch? | 23:42 |
| garyvdm | For revert, and tag - what I think we should do is show a sub-menu with the branches that have the revision | 23:43 |
| garyvdm | and for revert - only those that have a working tree. | 23:43 |
| bialix | oh, I finally understand your desire to have revert | 23:44 |
| bialix | revert to revision? | 23:44 |
| garyvdm | Ah-ha | 23:44 |
| bialix | ok | 23:44 |
| bialix | maybe we should make such submenu all the time? | 23:45 |
| garyvdm | all though - these days I use "bzr pull . --overwrite -r ..." more | 23:45 |
| bialix | it's just like uncommit | 23:46 |
| bialix | uncommit to revision in qlog? | 23:46 |
| NfNitLoop | sshing from my g1. geek heaven. :) | 23:47 |
| garyvdm | Rr submenu all the time - Na - the most common use case is log from tbzr - and that will only ever have one branch | 23:47 |
| garyvdm | uncommit to revision in qlog? why not? | 23:47 |
| bialix | I mean uncommit instead of revert | 23:47 |
| garyvdm | Why not both? | 23:48 |
| bialix | revert is really rare | 23:48 |
| bialix | I have no objections to both | 23:48 |
| garyvdm | If the user has open more than one branch - but choses a revision that is only one branch - we should show the sub menu. | 23:49 |
| bialix | gary, today I've thought about qbzr future. I'm planning to start writing some user docs soon | 23:50 |
| garyvdm | Ok | 23:50 |
| bialix | also, I think we should switch to usual version number scheme: 0.10.0, 0.11.0 and so on | 23:50 |
| garyvdm | Ok | 23:51 |
| bialix | in the June 2008 I want to release 1.0 as is | 23:51 |
| bialix | but your magic on qlog changed everything | 23:51 |
| garyvdm | ha ha | 23:51 |
| bialix | I don;t think we have to release 1.0 after 0.9.9 | 23:51 |
| bialix | no, it's really magic, I'm just too busy to dive so deep into qt tricks. | 23:52 |
| bialix | I don;t wrote nothing really serious yet | 23:53 |
| garyvdm | A big issue is selftest. I'm a unit test noob. I see the value in writing unit tests - but it's a very daunting task. | 23:53 |
| bialix | I found unit-testing very nice thing | 23:54 |
| bialix | and I like it | 23:54 |
| bialix | I'll try to figure out how to write it for some trivial cases | 23:54 |
| bialix | I want to say big THANKS to poolie and lifeless | 23:55 |
| bialix | and jam of course | 23:55 |
| poolie | (: | 23:55 |
| bialix | I've learned everything I know about unit-tests from bzr | 23:55 |
| garyvdm | I keep on saying to myself - ok - you've got to write unit tests for qlog - and then I end up implementing new features... | 23:56 |
| garyvdm | bialix: you need to put pressure on me to get it done :-) | 23:56 |
| garyvdm | Unit tests for LogGraphProvider should be easy. | 23:57 |
| bialix | I'm fine with new features unless we don;t have too much regressions | 23:57 |
| garyvdm | I want to be able to add new features and not worry about regressions. Test should help in that area. | 23:57 |
| bialix | but I can return to latest working release if things going wrong | 23:58 |
| bialix | yes, they should | 23:58 |
| bialix | we have toooooooo many features to test all of 'em every time manually | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
