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