[00:06] <maxb> vila: OOI, was it intentional to omit the leading 'bzr-' from the tag name for 2.6b2?
[00:31] <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:33] <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:46] <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:47] <spiv> That's true.  But then you can find dead heads with 'bzr heads --dead-only'.
[00:48] <spiv> There's no reliable record of which branch that dead head was originally created on, though.
[00:51] <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:52] <bob2> sure, the repo is a big bag of revisions, a "branch" is just a pointer at a particular rev
[00:54] <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:55] <bob2> that's a different question to what you asked earlier
[00:55] <bob2> bzr log somerev..somebranch I guess
[00:57] <seany> ah yes that'll do the job, thanks
[00:58] <seany> essentially grabs the subsequence from somerev which is ill-defined if it didn't belong to the branch in the first place
[00:59] <bob2> s/illdefined/defined as empty/ :)
[01:00] <seany> well it errors :P doesn't just return an empty log
[01:01] <seany> bob2: is there a way of deducing which revision 'killed' a dead revision?
[01:02] <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:03] <spiv> seany: bzr doesn't record that data
[01:03] <seany> thanks
[01:04] <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:05] <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:06] <seany> ah yes true
[01:08] <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:09] <seany> a dead head is a revision that's childless and not part of any branches?
[01:31] <bob2> yes
[08:43] <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
[09:11] <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:46] <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:47] <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:48] <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:51] <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
[10:02] <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
[11:02] <jml> how can I tell which release a particular revno of bzr is in?
[11:03] <mgz> jml: compare <http://packages.ubuntu.com/search?keywords=bzr&searchon=names&suite=all> with `bzr tags lp:bzr`?
[11:04] <jml> mgz: thanks.
[12:04] <jelmer> vila, mgz: I've put up a mp for the missing chk root reference issue
[12:05] <jelmer> there is 'bzr reconcile --canonicalize-chks' which fixes it, courtesy of spiv
[12:05] <jelmer> I had completely forgotten about that
[12:06] <jelmer> unfortunately it seems dead slow on the gcc repo
[12:08] <vila> approved, mention it in the bug report so they can try it for themselves
[12:13] <vila> jelmer: dead slow as in ? hours ? days ?
[12:16] <jelmer> vila: it's taken 2 hours to process the first 55 out of 115544 inventories
[12:17] <vila> :-/
[12:17] <mgz> heh
[12:22] <fullermd> Well, if you go by the book, hours can seem like days.
[12:25] <jelmer> fullermd: what is this "the book
[12:25] <jelmer> " you're talking about?
[12:28] <fullermd> Mostly a collection of numbskull ideas that worked.
[12:28] <jelmer> fullermd: ISBN?
[12:29] <fullermd> 0-671-21833-6
[12:40] <jelmer> vila: ... and thakns for the review
[12:42] <vila> don't mention it, I wonder how many bugs / import failures can be addressed this way...
[12:53] <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:54] <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 ;)
[13:07] <jml> vila: hello
[13:08] <jml> vila: welcome back
[13:08] <vila> thanks
[13:10] <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:11]  * 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:13] <vila> 8-/
[13:16] <vila> jml: the relevant revno is 6488 if you used an earlier trunk... you were doomed
[13:17] <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:29] <vila> jml: there is a test that should have failed for udd... (two even)
[13:32] <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:33] <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
[14:22] <jelmer> vila: yeah, this isn't going to work.. still not at rev 100 yet
[17:09] <mnn> hi, I've found the culprit with the sftp: https://bugs.launchpad.net/bzr/+bug/1027529
[17:09] <mnn> it could be possible, if server does not support moving files to just copy file and delete original, right?
[17:24] <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:25] <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:26] <mnn> yes, I've already crawled through the bazaar's code and paramiko's too
[17:29] <mnn> so I've pinpointed location, where the exception is thrown without any meaningful information
[17:29] <vila> great !
[17:30] <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:31]  * vila checks
[17:32] <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:33] <vila> mnn: alternatively, a specific exception (class in errors.py) can be created if needed
[17:34] <mnn> true
[18:18] <mnn> vila: so, I was thinking something like TransportOperationNotSupported exception
[18:18] <mnn> with argument operation
[18:19] <mnn> however operations within sftp.py itself, call _translate_io_exception() and they only provide more_info... not name of the operation itself
[18:57] <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:58] <mnn> well in theory any operation could fail, but only handful wouldn't be supported
[19:56] <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'
[22:05] <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:06] <jelmer> maxb: go ahead
[22:06] <maxb> thanks
[22:10] <maxb> pushed
[22:34] <mnn> vila: something like this?
[22:34] <mnn> http://pastebin.com/RV70HTC9
[23:22] <thumper> hi folks
[23:22] <thumper> before I get into doing this complicated cherry pick branch
[23:23] <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:24] <thumper> and I'm hoping that I'm not going to have to do this manually