| === r0bby is now known as robbyoconnor | ||
| nilg` | hi is there a way to rebase afterwards? | 06:31 |
|---|---|---|
| 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) | 06:34 |
| nilg` | OK, I think I've found a way to fix that but I would need a "cherrypick" rebase functionality, does that exist? | 07:29 |
| LarstiQ | nilg`: there is the rewrite plugin which has rebase, or you can use cherrypick with merge | 09:16 |
| 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:17 |
| LarstiQ | nilg`: also see 'append_revisions_only' in `bzr help config` for preventing exactly that case, if I'm right | 09:19 |
| 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:20 |
| * 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 | 09:27 | |
| 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 |
| ubot5 | Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] | 10:37 |
| iri | It's been around since 2010 - how to get it some attention? | 10:37 |
| * iri gently pings jelmer | 10:38 | |
| === yofel_ is now known as yofel | ||
| jelmer | iri: hi | 11:10 |
| 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. | 11:32 |
| LarstiQ | iri: https://bugs.launchpad.net/bzr/+bug/541626/comments/24 and comment 25 seem the most relevant to me | 13:45 |
| ubot5 | Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] | 13:45 |
| iri | hi LarstiQ | 13:45 |
| iri | So I'm not sure I understand the implications | 13:45 |
| iri | Is there a reasonable fix? | 13:46 |
| iri | Implement BTreeBuilder._find_ancestors() to return get_parent_map()? | 13:46 |
| 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:47 |
| LarstiQ | and bzrlib.index.GraphIndex._find_ancestors | 13:48 |
| * LarstiQ compares | 13:48 | |
| LarstiQ | right, they should have the same interface | 13:48 |
| 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:50 |
| 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:51 |
| 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:54 |
| iri | bzr trunk won't install into a virtualenv? :-s | 13:55 |
| 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:56 |
| LarstiQ | jelmer: can you reproduce bug 541626 already? | 13:57 |
| ubot5 | Launchpad bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] https://launchpad.net/bugs/541626 | 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 :-) | 13:57 |
| * LarstiQ keeps running into hurdles | 14:06 | |
| LarstiQ | iri: hmrf, ../codex doesn't exist | 14:11 |
| === sideffect is now known as sideffect_ | ||
| LarstiQ | so that github issue in fact does not contain enough to reproduce :/ | 14:12 |
| iri | I guess it is a branch? | 14:12 |
| iri | it looks like github screwed up the formatting of the post | 14:13 |
| === sideffect_ is now known as sideffect | ||
| iri | I don't think where the pull is from is important | 14:17 |
| 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:18 | |
| iri | k | 14:19 |
| iri | I'll try and reproduce | 14:19 |
| * LarstiQ tries termies test2.sh | 14:28 | |
| 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:29 |
| iri | I did git bzr push lp:my.username/+junk/test | 14:30 |
| iri | ah, got it with a minimal repository | 14:30 |
| iri | weird, | 14:35 |
| iri | can't do it now | 14:35 |
| LarstiQ | iri: yeah, "echo >> test; git add test; git commit -am "update"; git bzr push lp:~/+junk/test" worked fine for me | 14:37 |
| iri | got it | 14:39 |
| iri | http://pastebin.com/KCYs8JDL | 14:40 |
| iri | That reproduced it twice | 14:40 |
| iri | it might be more than necessary | 14:40 |
| iri | This was the minimum I was able to reproduce with : http://pastebin.com/WeJXKQgG | 14:46 |
| iri | LarstiQ: I commented on https://github.com/termie/git-bzr-ng/issues/38 with a complete script to reproduce | 14:52 |
| LarstiQ | iri: cheers! _now_ it blows up :) | 15:03 |
| * LarstiQ has dinner and will then followup | 15:03 | |
| iri | great, thanks :D | 15:04 |
| LarstiQ | hey beuno | 15:59 |
| LarstiQ | iri: I updated bug 541626, having a stab at _find_ancestors | 16:02 |
| ubot5 | Launchpad bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] https://launchpad.net/bugs/541626 | 16:02 |
| * iri peek | 16:03 | |
| iri | s | 16:03 |
| iri | :-) | 16:03 |
| beuno | heya LarstiQ! | 16:04 |
| 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:08 |
| * LarstiQ looks at the backtrace again | 16:09 | |
| iri | interesting | 16:09 |
| LarstiQ | which in fact terminates inside find_ancestry(), hmm | 16:11 |
| jelmer | hi iri, LarstiQ | 16:39 |
| iri | hi | 16:39 |
| LarstiQ | navond jelmer | 16:40 |
| 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:41 |
| LarstiQ | jelmer: but index comes from index_idx, index = enumerate(self._indices) and self._indices only contains BTreeGraphIndexs | 16:42 |
| * LarstiQ blinks | 16:42 | |
| vork | Has somebody been writing a __setattr__ method? :( | 16:43 |
| LarstiQ | vork: in the lazy_import machinery, but I wouldn't expect that here | 16:46 |
| vork | (I meant __getattr__). | 16:47 |
| LarstiQ | vork: hmm, versionedfile maybe | 16:48 |
| LarstiQ | vork: print style debugging seems to indicate self._indices gets mutated while we loop over it. | 17:05 |
| 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:11 |
| 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:12 |
| LarstiQ | jelmer: I'm currently trying to find out why a BTreeBuilder gets inserted in the list of indices at all | 17:13 |
| LarstiQ | jelmer: any ideas how that could happen? | 17:14 |
| 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:15 |
| 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:16 |
| LarstiQ | back to that _find_ancestors implementation then | 17:17 |
| iri | LarstiQ: I have to run, thanks for your help! | 17:55 |
| LarstiQ | doh | 17:57 |
| * LarstiQ just pushed up lp:~larstiq/bzr/bug541626 | 17:57 | |
| 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:58 |
| LarstiQ | vork: the implementation is more correct than the previous suggestion I think | 17:59 |
| 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:00 |
| 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:02 |
| 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:08 |
| 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:09 |
| * 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:10 |
| jelmer | LarstiQ: push only pushes the active branch | 18:11 |
| LarstiQ | jelmer: yeah | 18:13 |
| * LarstiQ calls it a day and goes back to math | 18:13 | |
| 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:14 |
| LarstiQ | jelmer: have fun :) | 18:15 |
| jelmer | aha :) | 18:15 |
| jelmer | you too :) | 18:15 |
| nilg` | thanks a lot LarstiQ | 18:33 |
| wilx | So, I have a trunk branch and 1.1.x branch from the trunk. | 20:46 |
| wilx | I am usually merging from the trunk to the 1.1.x branch. | 20:48 |
| 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:49 |
| mgrandi | so you are merging trunk to 1.1.x? | 20:50 |
| 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:51 |
| 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:52 |
| 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:54 |
| vork | Well it should be fine, bzr's supposed to adapt to your workflow, right? | 20:57 |
| 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:58 |
| 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. | 20:59 |
| 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:00 |
| 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:01 |
| wilx | Ok, merge it is. | 21:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!