=== r0bby is now known as robbyoconnor [06:31] hi is there a way to rebase afterwards? [06:34] a guy has a done a merge and the revision numbers are messed up we want to backtrack that and do a rebase instead, is there any simple way to do that (cause in the mean time other people have committed stuff) [07:29] OK, I think I've found a way to fix that but I would need a "cherrypick" rebase functionality, does that exist? [09:16] nilg`: there is the rewrite plugin which has rebase, or you can use cherrypick with merge [09:17] nilg`: but it sounds simpler [09:17] nilg`: did he merge trunk into a feature branch, and then push that branch on top of trunk? [09:19] nilg`: also see 'append_revisions_only' in `bzr help config` for preventing exactly that case, if I'm right [09:20] nilg`: for now you could `bzr uncommit` the merge revision, merge feature into trunk instead of the other way around, and push that [09:27] * maxb attempts to stop the jubany udd importer importing the same packages many times over, so it can actually catch up with quantal opening this weekend [10:37] This bug is causing significant issues and doesn't seem to have anyone assigned to it: https://bugs.launchpad.net/bzr/+bug/541626 [10:37] Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] [10:37] It's been around since 2010 - how to get it some attention? [10:38] * iri gently pings jelmer === yofel_ is now known as yofel [11:10] iri: hi [11:32] hi jelmer. I'm going to appear and disappear a bit over the few hours. If there is any way I can help crack the bug, let me know. I'm good with python but not a bzr user unfortunately. [13:45] iri: https://bugs.launchpad.net/bzr/+bug/541626/comments/24 and comment 25 seem the most relevant to me [13:45] Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] [13:45] hi LarstiQ [13:45] So I'm not sure I understand the implications [13:46] Is there a reasonable fix? [13:46] Implement BTreeBuilder._find_ancestors() to return get_parent_map()? [13:47] iri: implementing the same api in my reading [13:47] iri: that's a start :) [13:47] there is bzrlib.btree_index.BTreeGraphIndex._find_ancestors [13:48] and bzrlib.index.GraphIndex._find_ancestors [13:48] * LarstiQ compares [13:48] right, they should have the same interface [13:50] BTreeBuilder also seems to live in bbzrlib.btree_index [13:50] Just setting up the trunk version ow [13:50] s/ow/now/ [13:50] iri: mind you, I don't really know the bug or what to do about it, but I'm a bit familiar with the bzr codebase [13:51] I'm just frustrated because it's preventing me from working with git [13:51] * LarstiQ nods [13:51] tests live in bzrlib/tests/test_{btree_,}index.py [13:54] I don't understand enough about what has gone wrong to write a test for it [13:54] I can provide access to the broken repository if needed [13:55] bzr trunk won't install into a virtualenv? :-s [13:56] oh, seems that just pip was having trouble with it "python setup.py install" worked [13:56] iri: no idea, but I run it from source [13:57] jelmer: can you reproduce bug 541626 already? [13:57] Launchpad bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] https://launchpad.net/bugs/541626 [13:57] iri: I'm going to try the recipe in https://github.com/termie/git-bzr-ng/issues/38 [13:57] thanks :-) [14:06] * LarstiQ keeps running into hurdles [14:11] iri: hmrf, ../codex doesn't exist === sideffect is now known as sideffect_ [14:12] so that github issue in fact does not contain enough to reproduce :/ [14:12] I guess it is a branch? [14:13] it looks like github screwed up the formatting of the post === sideffect_ is now known as sideffect [14:17] I don't think where the pull is from is important [14:18] iri: I'm a git novice so I have trouble guessing at what to do [14:18] * LarstiQ runs down to change the laundry [14:19] k [14:19] I'll try and reproduce [14:28] * LarstiQ tries termies test2.sh [14:29] I can't seem to reproduce with a clean repository, but I can with the one in the git issue [14:29] It seems sufficient once you have the git repository to "echo >> test; git add test; git commit -am "update"; git bzr push" [14:29] uh, where push is to some repository you created [14:30] I did git bzr push lp:my.username/+junk/test [14:30] ah, got it with a minimal repository [14:35] weird, [14:35] can't do it now [14:37] iri: yeah, "echo >> test; git add test; git commit -am "update"; git bzr push lp:~/+junk/test" worked fine for me [14:39] got it [14:40] http://pastebin.com/KCYs8JDL [14:40] That reproduced it twice [14:40] it might be more than necessary [14:46] This was the minimum I was able to reproduce with : http://pastebin.com/WeJXKQgG [14:52] LarstiQ: I commented on https://github.com/termie/git-bzr-ng/issues/38 with a complete script to reproduce [15:03] iri: cheers! _now_ it blows up :) [15:03] * LarstiQ has dinner and will then followup [15:04] great, thanks :D [15:59] hey beuno [16:02] iri: I updated bug 541626, having a stab at _find_ancestors [16:02] Launchpad bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] https://launchpad.net/bugs/541626 [16:03] * iri peek [16:03] s [16:03] :-) [16:04] heya LarstiQ! [16:08] iri: hmm, BTreeBuilder has a find_ancestry(), and BTreeGraphIndex's _find_ancestors docstring mentions: 'It is unlikely that you want to call this directly. See "CombinedGraphIndex.find_ancestry()" for a more appropriate API.' [16:08] iri: so perhaps something is using the wrong api there [16:08] beuno: :) [16:09] * LarstiQ looks at the backtrace again [16:09] interesting [16:11] which in fact terminates inside find_ancestry(), hmm [16:39] hi iri, LarstiQ [16:39] hi [16:40] navond jelmer [16:41] jelmer: I have a pdb session where this thing goes wrong. It tries index._find_ancestors which results in the AttributeError, so far so good [16:42] jelmer: but index comes from index_idx, index = enumerate(self._indices) and self._indices only contains BTreeGraphIndexs [16:42] * LarstiQ blinks [16:43] Has somebody been writing a __setattr__ method? :( [16:46] vork: in the lazy_import machinery, but I wouldn't expect that here [16:47] (I meant __getattr__). [16:48] vork: hmm, versionedfile maybe [17:05] vork: print style debugging seems to indicate self._indices gets mutated while we loop over it. [17:11] iri: I'm no longer working on that bug, it only seems to affect fastexport as far as I can tell. [17:11] Looks like LarstiQ is having a good crack at it [17:11] jelmer: and through it things that depend on it, like git-bzr-ng [17:11] I was just wanting to raise some interest in it [17:11] And you were the last person to be assigned to it, so I wanted to know why it had been left alone [17:12] iri: I'll have to go back to my studies soon, but I'll try to get to a point where someone else could pick it up (or me somewhere in the future) [17:12] iri: mostly just lack of time, and the fact that it only affected bzr-fastexport [17:12] Thanks LarstiQ [17:13] jelmer: I'm currently trying to find out why a BTreeBuilder gets inserted in the list of indices at all [17:14] jelmer: any ideas how that could happen? [17:15] LarstiQ: IIRC because we're writing to a new pack? [17:15] jelmer: ah hmm. How do I see if that is going on? [17:16] LarstiQ: sorry, no idea. I never did much with the lower layers of the code [17:16] jelmer: np [17:16] well [17:17] back to that _find_ancestors implementation then [17:55] LarstiQ: I have to run, thanks for your help! [17:57] doh [17:57] * LarstiQ just pushed up lp:~larstiq/bzr/bug541626 [17:58] LarstiQ: Fixed it? [17:58] vork: fsvo "fixed" [17:58] fsvo=? [17:58] vork: the script that crashes no longer does [17:58] vork: "for some value of" [17:58] Oh, for some v...yeah, just worked it out. [17:59] vork: the implementation is more correct than the previous suggestion I think [18:00] vork: but I don't really know what I'm doing [18:00] vork: you're welcome to try and see if anything goes horribly wrong ;) [18:02] jelmer: pushing to launchpad from a development-colo branch doesn't work, is there a workaround that doesn't involve first pushing to a 2a branch? [18:02] jelmer: and, should I file a bug on that or does that come down to "it's a development format, wontfix"? [18:08] LarstiQ: thre's no longer any reason to use development-colo, it's been merged into 2a [18:08] really? [18:08] I missed that happening :) [18:09] LarstiQ: I would indeed say it's a development format so we shouldn't allow it on launchpad [18:09] LarstiQ: yep, that happened before 2.5.0 [18:09] LarstiQ: the only difference between those two formats is their format strin g:) [18:09] jelmer: yeah, the friction in my mind came from considering pushing one branch as, well, being one branch [18:09] jelmer: I remember the discussion at the time [18:10] * LarstiQ upgraded his bzr.dev copy to 2a ;) [18:10] LarstiQ: we don't really support colocated branches on lp yet, at least it doesn't display them [18:10] * LarstiQ nods [18:10] jelmer: I didn't want repo-push, just push. If that makes sense. [18:11] LarstiQ: push only pushes the active branch [18:13] jelmer: yeah [18:13] * LarstiQ calls it a day and goes back to math [18:14] jam: I'll try to bug you somewhere during the week for some guidance [18:14] LarstiQ: ttyl [18:14] jelmer: hf [18:14] hf? [18:14] high five? [18:15] jelmer: have fun :) [18:15] aha :) [18:15] you too :) [18:33] thanks a lot LarstiQ [20:46] So, I have a trunk branch and 1.1.x branch from the trunk. [20:48] I am usually merging from the trunk to the 1.1.x branch. [20:49] But I have also now made some changes on 1.1.x and I would like to have them on trunk as well. [20:49] Now, do I cherry pick/apply diff from 1.1.x revision to trunk or should I just merge from 1.1.x to trunk? [20:49] Is there any danger in doing it both ways? [20:50] so you are merging trunk to 1.1.x? [20:51] Usually. [20:51] so [20:51] But now I want to also do it the other way around. [20:51] you can 'shelve' the changes in the 1.1.x branch [20:51] merge trunk -> 1.1.x [20:51] and then unshelve the changes, and then merge them again [20:51] Uhm, no. There are tens of revisions on 1.1.x from the branch point. [20:52] oh [20:52] so they are commited? [20:52] then the merge will just take care of that [20:52] Basically, is merging between two branches both ways anyhow dangerous? [20:52] It's not dangerous _technically_. But it's probably not what you want, unless you intend both branches to converge to the same contents. [20:54] Well, I have branched for 1.1.x release too early. I tried to be disciplined and make any necessary changes first on trunk and then merging them to 1.1.x. Unfortunately, I was not so disciplined all the time so I need some 1.1.x changes on trunk as well. [20:57] Well it should be fine, bzr's supposed to adapt to your workflow, right? [20:58] If you want trunk to have everything 1.1.x has, merging 1.1.x->trunk will work fine. If not, it's not such a great idea. [20:59] Especially if you're doing trunk->1.1.x merges too. [20:59] Yes, at this point I do need all of that. [21:00] You want all the changes? In that case, there's no question; just merge. [21:00] It sounds from your description almost like you're working toward 1.1.x on trunk, in which case having a separate branch seems a little unnecessary. [21:01] The usual case is more that you make 1.1.x, and then trunk goes on with changes you won't want 'till 1.2.x or 2.0.x (or 11.x, if you're Sun) [21:02] Ok, merge it is.