maxbvila: OOI, was it intentional to omit the leading 'bzr-' from the tag name for 2.6b2?00:06
seanyis 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
spivseany: 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
seanyspiv: for example if the revision is a dead head, it will not show in the bzr log00:46
seany(correct me if i'm wrong here :> )00:46
spivThat's true.  But then you can find dead heads with 'bzr heads --dead-only'.00:47
spivThere's no reliable record of which branch that dead head was originally created on, though.00:48
seanyspiv: 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
bob2sure, the repo is a big bag of revisions, a "branch" is just a pointer at a particular rev00:52
seanybob2: so is there no easy way of figuring out if a given revid belongs to a branch?00:54
seanyi guess i could grep through..00:54
bob2that's a different question to what you asked earlier00:55
bob2bzr log somerev..somebranch I guess00:55
seanyah yes that'll do the job, thanks00:57
seanyessentially grabs the subsequence from somerev which is ill-defined if it didn't belong to the branch in the first place00:58
bob2s/illdefined/defined as empty/ :)00:59
seanywell it errors :P doesn't just return an empty log01:00
seanybob2: is there a way of deducing which revision 'killed' a dead revision?01:01
bob2don't even know what that means01:02
seanywell say if it was overwritten01:02
bob2that's not how things work01:02
seanyor time of uncommit?01:02
spivseany: bzr doesn't record that data01:03
spivseany: when you uncommit, it just updates the branch to say "the latest revision of this branch is now X"01:04
spivIt doesn't also keep a history-of-the-history01:04
seanyah alright, just thought there could be some kind of meta history01:04
bob2but waht if it was altered01:04
spivIt would certainly be useful sometimes, but also confusing, especially if people start demanding features to manipulate and edit the meta-history01:05
bob2you need infinite-meta-history01:05
spivYou'd then need a meta-meta-history :)01:05
spivYou can sometimes reconstruct that by hand by looking at your ~/.bzr.log01:05
seanyah yes true01:06
seanya particular dead revision does not come up when i run bzr heads --dead-only01:08
seany(unless i'm not getting the concept of dead heads properly..)01:08
bob2sounds like it's not dead or not present then01:08
seanya dead head is a revision that's childless and not part of any branches?01:09
=== iBasic is now known as BasicOSX
maxbjelmer: 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 next08:43
jelmermaxb: 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
maxbjelmer: 2.6.0~+beta2+bzr6666 ? :-)09:46
jelmermaxb: I would rather switch it around - 2.6.0~beta2+bzr666609:46
jelmermaxb: I would rather switch it around - 2.6.0~bzr6666+beta209:46
maxbAh, my implication was different09:47
maxbI was suggesting that a future post-beta2 pre-beta2 snapshot would be represented as 2.6.0~beta2+bzrXXXX09:47
maxbor rather 2.6.0~+beta2+bzrXXXX09:48
jelmerin short, having two different versioning schemes is a pain.. I would rather stick to the one that always works09:48
maxbCan do, though it's slightly less informative09:48
maxbI 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 cycle09:51
jelmermaxb: it's been fairly common so far10:02
jelmermaxb: the upstream-2.6.0~+beta2 tag seems to be missing, btw10:02
jmlhow can I tell which release a particular revno of bzr is in?11:02
mgzjml: compare <http://packages.ubuntu.com/search?keywords=bzr&searchon=names&suite=all> with `bzr tags lp:bzr`?11:03
jmlmgz: thanks.11:04
jelmervila, mgz: I've put up a mp for the missing chk root reference issue12:04
jelmerthere is 'bzr reconcile --canonicalize-chks' which fixes it, courtesy of spiv12:05
jelmerI had completely forgotten about that12:05
jelmerunfortunately it seems dead slow on the gcc repo12:06
vilaapproved, mention it in the bug report so they can try it for themselves12:08
vilajelmer: dead slow as in ? hours ? days ?12:13
jelmervila: it's taken 2 hours to process the first 55 out of 115544 inventories12:16
fullermdWell, if you go by the book, hours can seem like days.12:22
jelmerfullermd: what is this "the book12:25
jelmer" you're talking about?12:25
fullermdMostly a collection of numbskull ideas that worked.12:28
jelmerfullermd: ISBN?12:28
jelmervila: ... and thakns for the review12:40
viladon't mention it, I wonder how many bugs / import failures can be addressed this way...12:42
jelmervila: depends on how much patience people have :)12:53
jelmerI don't think it will fix any import failures, just people having problems with merge12:53
vilayeah couldn't find import failures, dunno why I thought this was triggered there... may be they occurred long ago and have been fixed since then12:54
vilaor it's just my memory playing tricks ;)12:54
jmlvila: hello13:07
jmlvila: welcome back13:08
jmlvila: 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
jmlvila: I'm pretty sure we've resolved it by switching to a more recent bzr though13:10
* jml has very poor visibility into our production system13:11
jmlvila: so, no action required from you, but I thought you might be interested.13:11
vilajml: the relevant revno is 6488 if you used an earlier trunk... you were doomed13:16
jmlvila: yeah, thanks. I figured that out eventually :)13:17
vilarevno 6468 was too old13:17
jmlvila: on the plus side, bzr made it really easy to find the relevant changes :)13:17
vilajml: there is a test that should have failed for udd... (two even)13:29
jmlvila: interesting. I don't know exactly how running tests integrates with our deployment process. udd is somewhat non-standard.13:32
vilayeah, and it's not part of deployment to run tests, just mentioning, no worries13:32
vilaor more to the point, it would be nice that running tests becomes part of deployment :)13:33
vilaeven if only a subset of the test suite or a dedicated one is needed13:33
jelmervila: yeah, this isn't going to work.. still not at rev 100 yet14:22
=== zyga is now known as zyga-afk
=== deryck is now known as deryck[lunch]
mnnhi, I've found the culprit with the sftp: https://bugs.launchpad.net/bzr/+bug/102752917:09
ubot5Ubuntu bug 1027529 in Bazaar "Cannot push/operate on SFTP; no useful error message" [Undecided,Invalid]17:09
mnnit could be possible, if server does not support moving files to just copy file and delete original, right?17:09
vilamnn: 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 info17:24
vilamnn: 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" dance17:25
mnnyes, I've already crawled through the bazaar's code and paramiko's too17:26
mnnso I've pinpointed location, where the exception is thrown without any meaningful information17:29
vilagreat !17:29
mnnbzrlib/transport/sftp.py - line _after_ this one:17:30
mnnif e.args == ('Operation unsupported',):17:30
mnnso basically more_info could be passed into TransportNotPossible() right?17:30
* vila checks17:31
vilahmm, yeah, you can use the orig_error parameter probably17:32
vilamnn: sry, family time here, I may be back later, if not, comment on the bug17:32
vilamnn: alternatively, a specific exception (class in errors.py) can be created if needed17:33
=== deryck[lunch] is now known as deryck
mnnvila: so, I was thinking something like TransportOperationNotSupported exception18:18
mnnwith argument operation18:18
mnnhowever operations within sftp.py itself, call _translate_io_exception() and they only provide more_info... not name of the operation itself18:19
vilamnn: 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
mnnwell in theory any operation could fail, but only handful wouldn't be supported18:58
maxbHmm, is it known that lp:bzrtools is currently incompatible with bzr.dev?19:56
maxbAttributeError: 'CHKInventoryRepository' object has no attribute 'get_ancestry'19:56
maxbjelmer: 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
jelmermaxb: go ahead22:06
mnnvila: something like this?22:34
thumperhi folks23:22
thumperbefore I get into doing this complicated cherry pick branch23:22
thumperI wanted to check that bzr is going to do what I think it is going to do23:23
thumperif I do a cherry pick merge like... bzr merge ../trunk -r1234..123523:23
thumperit still uses the file ids?23:23
thumperjust after release, we had a massive code reorg23:23
thumperand I'm hoping that I'm not going to have to do this manually23:24
=== mlh_ is now known as mlh

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!