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