[00:06] vila: OOI, was it intentional to omit the leading 'bzr-' from the tag name for 2.6b2? [00:31] is it possible to show all revisions that used once to belong to a branch? bzr heads doesn't show it for some reason.. [00:33] seany: what do you mean by "used once to belong to a branch", exactly? How is it different to the output of "bzr log"? [00:46] spiv: for example if the revision is a dead head, it will not show in the bzr log [00:46] (correct me if i'm wrong here :> ) [00:47] That's true. But then you can find dead heads with 'bzr heads --dead-only'. [00:48] There's no reliable record of which branch that dead head was originally created on, though. [00:51] spiv: thanks -- another confusing thing for me has been with shared repo's.. it seems that I can pull out a rev by specifying a revid even if that rev doesn't belong to that branch.. [00:52] sure, the repo is a big bag of revisions, a "branch" is just a pointer at a particular rev [00:54] bob2: so is there no easy way of figuring out if a given revid belongs to a branch? [00:54] i guess i could grep through.. [00:55] that's a different question to what you asked earlier [00:55] bzr log somerev..somebranch I guess [00:57] ah yes that'll do the job, thanks [00:58] essentially grabs the subsequence from somerev which is ill-defined if it didn't belong to the branch in the first place [00:59] s/illdefined/defined as empty/ :) [01:00] well it errors :P doesn't just return an empty log [01:01] bob2: is there a way of deducing which revision 'killed' a dead revision? [01:02] don't even know what that means [01:02] well say if it was overwritten [01:02] that's not how things work [01:02] or time of uncommit? [01:03] seany: bzr doesn't record that data [01:03] thanks [01:04] seany: when you uncommit, it just updates the branch to say "the latest revision of this branch is now X" [01:04] It doesn't also keep a history-of-the-history [01:04] ah alright, just thought there could be some kind of meta history [01:04] but waht if it was altered [01:05] It would certainly be useful sometimes, but also confusing, especially if people start demanding features to manipulate and edit the meta-history [01:05] you need infinite-meta-history [01:05] You'd then need a meta-meta-history :) [01:05] You can sometimes reconstruct that by hand by looking at your ~/.bzr.log [01:06] ah yes true [01:08] a particular dead revision does not come up when i run bzr heads --dead-only [01:08] (unless i'm not getting the concept of dead heads properly..) [01:08] sounds like it's not dead or not present then [01:09] a dead head is a revision that's childless and not part of any branches? [01:31] yes === iBasic is now known as BasicOSX [08:43] jelmer: Hi, I've pushed a minor new upstream merge and a fix to a malformed patch to pkg-bazaar/bzr/2.6/; just pinging you as a reminder to pull before working on it next [09:11] maxb: please just use ~bzr for versions - if we use ~+ now, I don't think we can't switch back to ~bzr, safe specific tricks with ~ [09:46] jelmer: 2.6.0~+beta2+bzr6666 ? :-) [09:46] maxb: I would rather switch it around - 2.6.0~beta2+bzr6666 [09:46] euhm [09:46] maxb: I would rather switch it around - 2.6.0~bzr6666+beta2 [09:47] Ah, my implication was different [09:47] I was suggesting that a future post-beta2 pre-beta2 snapshot would be represented as 2.6.0~beta2+bzrXXXX [09:48] or rather 2.6.0~+beta2+bzrXXXX [09:48] in short, having two different versioning schemes is a pain.. I would rather stick to the one that always works [09:48] Can do, though it's slightly less informative [09:51] I guess it mostly depends on how much you expect to be uploading non-beta-release snapshots to unstable for the rest of the 2.6.0 cycle [10:02] maxb: it's been fairly common so far [10:02] maxb: the upstream-2.6.0~+beta2 tag seems to be missing, btw [11:02] how can I tell which release a particular revno of bzr is in? [11:03] jml: compare with `bzr tags lp:bzr`? [11:04] mgz: thanks. [12:04] vila, mgz: I've put up a mp for the missing chk root reference issue [12:05] there is 'bzr reconcile --canonicalize-chks' which fixes it, courtesy of spiv [12:05] I had completely forgotten about that [12:06] unfortunately it seems dead slow on the gcc repo [12:08] approved, mention it in the bug report so they can try it for themselves [12:13] jelmer: dead slow as in ? hours ? days ? [12:16] vila: it's taken 2 hours to process the first 55 out of 115544 inventories [12:17] :-/ [12:17] heh [12:22] Well, if you go by the book, hours can seem like days. [12:25] fullermd: what is this "the book [12:25] " you're talking about? [12:28] Mostly a collection of numbskull ideas that worked. [12:28] fullermd: ISBN? [12:29] 0-671-21833-6 [12:40] vila: ... and thakns for the review [12:42] don't mention it, I wonder how many bugs / import failures can be addressed this way... [12:53] vila: depends on how much patience people have :) [12:53] I don't think it will fix any import failures, just people having problems with merge [12:54] yeah couldn't find import failures, dunno why I thought this was triggered there... may be they occurred long ago and have been fixed since then [12:54] or it's just my memory playing tricks ;) [13:07] vila: hello [13:08] vila: welcome back [13:08] thanks [13:10] vila: fwiw, we had issues with our udd & config expansion with an old bzr. The 'if bzrlib.version < (2,6)' was being evaluated as false for trunk r6468 (2, 6, 0, 'dev', 1), which meant we weren't getting config expansion... [13:10] vila: I'm pretty sure we've resolved it by switching to a more recent bzr though [13:11] * jml has very poor visibility into our production system [13:11] vila: so, no action required from you, but I thought you might be interested. [13:13] 8-/ [13:16] jml: the relevant revno is 6488 if you used an earlier trunk... you were doomed [13:17] vila: yeah, thanks. I figured that out eventually :) [13:17] revno 6468 was too old [13:17] vila: on the plus side, bzr made it really easy to find the relevant changes :) [13:29] jml: there is a test that should have failed for udd... (two even) [13:32] vila: interesting. I don't know exactly how running tests integrates with our deployment process. udd is somewhat non-standard. [13:32] yeah, and it's not part of deployment to run tests, just mentioning, no worries [13:33] or more to the point, it would be nice that running tests becomes part of deployment :) [13:33] even if only a subset of the test suite or a dedicated one is needed [14:22] vila: yeah, this isn't going to work.. still not at rev 100 yet === zyga is now known as zyga-afk === deryck is now known as deryck[lunch] [17:09] hi, I've found the culprit with the sftp: https://bugs.launchpad.net/bzr/+bug/1027529 [17:09] Ubuntu bug 1027529 in Bazaar "Cannot push/operate on SFTP; no useful error message" [Undecided,Invalid] [17:09] it could be possible, if server does not support moving files to just copy file and delete original, right? [17:24] mnn: it would be nice to emit some more meaningful message, the bug is pretty terse about what additional info could be obtained from the server which would allow a fix that will relay this additional info [17:25] mnn: copy + delete is not on the agenda until we get a better understanding of what is going on. Keep in mind that the rename is probably already part of a "create tmp file/rename over existing file" dance [17:26] yes, I've already crawled through the bazaar's code and paramiko's too [17:29] so I've pinpointed location, where the exception is thrown without any meaningful information [17:29] great ! [17:30] bzrlib/transport/sftp.py - line _after_ this one: [17:30] if e.args == ('Operation unsupported',): [17:30] so basically more_info could be passed into TransportNotPossible() right? [17:31] * vila checks [17:32] hmm, yeah, you can use the orig_error parameter probably [17:32] mnn: sry, family time here, I may be back later, if not, comment on the bug [17:33] mnn: alternatively, a specific exception (class in errors.py) can be created if needed [17:34] true === deryck[lunch] is now known as deryck [18:18] vila: so, I was thinking something like TransportOperationNotSupported exception [18:18] with argument operation [18:19] however operations within sftp.py itself, call _translate_io_exception() and they only provide more_info... not name of the operation itself [18:57] mnn: yup, you probably want to catch the exception at a higher level (depending on how many higher level calls fail, but so far, you found one right ?) [18:58] well in theory any operation could fail, but only handful wouldn't be supported [19:56] Hmm, is it known that lp:bzrtools is currently incompatible with bzr.dev? [19:56] AttributeError: 'CHKInventoryRepository' object has no attribute 'get_ancestry' [22:05] jelmer: Hi. Your changes to pkg-bazaar/bzr/2.6/ include a bzr-builddeb malfunction reverting the branch content back to 2.6b2 from the snapshot you imported. Do you mind if I uncommit that and replay the debian/changelog changes on top of the clean snapshot merge? [22:06] maxb: go ahead [22:06] thanks [22:10] pushed [22:34] vila: something like this? [22:34] http://pastebin.com/RV70HTC9 [23:22] hi folks [23:22] before I get into doing this complicated cherry pick branch [23:23] I wanted to check that bzr is going to do what I think it is going to do [23:23] if I do a cherry pick merge like... bzr merge ../trunk -r1234..1235 [23:23] it still uses the file ids? [23:23] just after release, we had a massive code reorg [23:24] and I'm hoping that I'm not going to have to do this manually === mlh_ is now known as mlh