[00:09] what would be the bzr equivalent of 'git show' [00:10] bzr diff -c asdfasdf [00:10] for the common case [00:13] bob2: I want to see the state of one particular file for a revision [00:13] i did not know about -c though, thanks :) [00:14] bzr cat -c asdfsd filename [00:17] Bugs like bug 745083 are why I wanted to have catch-all try/excepts around calls to hooks on plugins. [00:17] Launchpad bug 745083 in Bazaar "UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', 'math range error') during commit" [Undecided,Incomplete] https://launchpad.net/bugs/745083 [00:18] bob2: its bzr cat -r not -c, thanks :) [00:19] oops [00:19] Yes, it would be a bit weird if 'bzr cat' took a revision range :) [01:31] I just had a stuck lock on lp. bzr help break-lock makes it sound like it is not safe if you don't first kill the process, but I can't do that on lp. Is it safe, or not? [01:47] psusi: the process that matters isn't the one on lp, but the client that took out the lock [01:48] psusi: so if it's a stale lock because e.g. your connection dropped out while pushing to launchpad, then it's your own lock for a (local) process that's already failed, and you can break it completely safely. [01:48] psusi: the lock info bzr shows you should help you see who took the lock out [01:51] spiv, ohh... well I took it out, but on the lp server... I thought that meant that the bzr process running on the server is what was holding the lock, and it either is hung, or did not remove the lock when it died [01:52] it lists a pid, which I took to be a pid on the server, not a local one [01:56] psusi: in a sense the lock was created by the server process, but it's entirely on behalf of your local process [01:57] (The pid is a pid from the server) [01:57] spiv, right, but it is the server process that creates and clears the lock, so don't I need to be sure that process is dead? [02:00] in fact, whether the process hung or somehow exited without clearing the lock is a bug isn't it? even if I drop connection or ctrl-c my local bzr, the server side should clean up the lock before exiting shouldn't it? [02:04] psusi: the lock lifetime is controlled by the client [02:05] psusi: it can be legitimate for a client to lock and disconnect without unlocking [02:05] (although that would be very unusual) [02:06] psusi: the smart server protocol is stateless between requests, so the fact the connection went away doesn't imply that any locks that were taken should be dropped. [02:16] hrm... that's weird [02:16] why is it stateless? I would think the protocol should be transaction based [02:20] Partly so it can be carried over HTTP smoothly. [02:23] why is http at all incompatible with a transaction based protocol? send request, get reply is how http works... seems perfectly suited for a transaction [02:27] And that's what we do. [02:28] "Take lock" is one of those requests. [02:29] The problem really is that we take multiple requests for things that in principle could be done in single requests. [02:29] If you're curious about the sort of requests being made, add -Dhpss to your command line and look at the extra logging that adds to ~/.bzr.log [04:26] So, I occasionally have an issue where revisions being imported from my external(tfs) repository end up as dead heads in the repository. [04:27] I've tracked down and eliminated most of bugs in bzr-tfs that cause these. [04:28] However, I have a (very large) existing repository where I need to splice in a single revision where it belongs in the branch history. [04:33] I might be able to get away with merging it into the current branch, the plugin just follows the LHS currently as it only imports a single branch. [04:34] What's the preferred method for dealing with dead heads in a way that won't affect the LHS ancestry? [04:35] ignore them? [04:36] Most of the time I can get away with that, but not in this instance. [04:37] I was thinking about trying to actually insert it into the revision graph for the branch, but worried that might have evil side effects. [04:39] If I actually corrupt the repository I'm looking at working the whole weekend to re-import the trunk. Don't want that. [04:40] Make a backup copy first? [04:41] ScottK: I can do that, I was just hoping someone had an informed opinion before I started doing open-heart repository surgery. :) [04:42] My informed opinion is take a backup no matter what anyone says here about what your odds of success are. [04:42] About the bzr part, no idea. [04:51] I don't understand how or why "splice in a single revision where it belongs in the branch history" is related to having dead heads in your repository. [04:52] Or why you can't just ignore the dead heads? By definition they have no impact of the ancestry, LHS or otherwise, of a branch. [04:53] I think I must be misunderstanding what you're asking. [04:54] spiv: so the actual revision graph is r1->r2->r3; the bug in the import process created the graph r1->r3 and r2 ends up as a dead head. [04:55] spiv: I'm in the position where I want to correct the revision graph by hand. [04:55] I could re-run the (now fixed) import process but that's a days-long affair. [04:56] Well, all you can do there is generate a new r3', with a new revision ID, with the contents of r3 and a parent of r2. [04:57] In other words, a merge, yes? [04:58] No, just a regular descendant. [04:59] i.e. r3' would have a parent list of [r2] to match the graph you desire. [04:59] Merges create revisions with more than one parent. [04:59] hooray [04:59] * poolie is reconnected [05:00] poolie: hurrah! [05:00] only over 3G, but usable 3G [05:00] vodafone was atrocious [05:02] Oh, I see the difference. That ends up rebuilding the whole branch after r3 as well, though. Still, it's at least viable. [05:03] i wonder if bzr push will be tolerable [05:03] jbowtie: yes, it's rebasing [05:04] Oh! I never understood what rebasing was before! Now I get it! [05:06] So maybe bzr-rewrite will solve my problem. Thanks, this was extremely helpful. [05:08] jbowtie: glad I could help :) [05:08] wow, even lp and bzr are quite usable [05:08] that's a remarkable improvement [05:08] heh :) [06:13] spiv were you going to file a bug about, um [06:14] oh, explaining the likely hook or plugin for an error [06:14] and something else too? [06:15] The 'recent event' dict [06:33] "bzr merge -r b..a branch" (a < b) may result in unresolvable conflict on changed files between revisions a and b. Is this desired? [06:40] echo-area: what do you mean by "unresolvable conflict"? [06:42] spiv: I tried many ways, all of them failed to resolve the conflicts. [06:42] From bzr's perspective all conflicts are resolvable, in the extreme by discarding the conflicting changes entirely with e.g. "bzr revert ." [06:42] echo-area: can you pastebin the output of the bzr merge, or of 'bzr conflicts'? [06:49] spiv: The only way to resolve is by reverting all changes, and avoiding use of bzr merge. A moment please, I'll show you bzr conflicts [06:51] spiv: http://pastebin.com/4X4g2RSM [06:52] spiv: Problem is that, file1 was added in revision 1, and bzr merge -r 1..0 tries to delete file1. [06:53] The conflict comes from revision 3, in which revision file1 was changed [06:53] (IMHO) [06:54] The only way to achieve what I want is to manually remove file1. While in larger context this is not that handy [06:57] echo-area: revert is not the only way to resolve that conflict [06:58] spiv: What is the other possible way? [06:58] echo-area: it's certainly a conflict if the selected revisions attempt to modify a deleted file. [06:59] echo-area: it's up to you what you think is the right resolution: the most common choice I think is to ignore the changes to the deleted file. [06:59] spiv: I tried that. Paste come in a minute. [07:00] In which case deleting that file1.THIS file and doing 'bzr resolve file1' or maybe 'bzr resolve file1.THIS' should work. [07:00] Or even just 'bzr resolved --all' [07:00] There's also 'bzr resolve --take-this' and 'bzr resolve --take-other', which you may find useful. [07:02] 'bzr resolve --all' is evil, it just deletes all known conflicts without any attempt to resolve them, it should be used as a last resort only (think throwing sea water on nuclear plants) [07:03] * vila almost there [07:03] vila: if that's what it takes to stop a meltdown… ;) [07:06] spiv: Hm. Delete file1 and bzr resolve file1 worked. Why does "bzr resolve" not work in that context? [07:07] 'bzr resolve' only detects when you've resolved text conflicts (i.e. removed the <<<<<<< etc markers from a file) [07:08] I think it'd probably be good to make it detect when contents conflicts like yours are resolved too. File a bug :) [07:08] echo-area: 'bzr resolve' doesn't *yet* work in this context, as spiv said, only text conflicts are automatically resolved [07:08] FWIW, "bzr help resolve" does explicitly say to use 'bzr resolve FILE' for contents conflicts, but I agree it's not very intuitive. [07:09] echo-area: 'bzr help conflict-types' gives a summary of what is supported so far [07:12] Okay. I was unaware of various conflict types until now. [07:13] Yes, the distinction between "contents conflict" and "text conflict" is something you're unlikely to grok just by seeing the words in your terminal occasionally. [07:13] echo-area: yeah, that's a bug, the conflicts should be better explained and these explanations should be easier to discover [07:13] spiv: But the bzr I'm using (2.3.1) does not explicit refer "content conflict" in bzr help resolve [07:14] echo-area: 'bzr help conflict-types' does [07:14] Maybe "contents conflict" should be called "existential conflict" ;) [07:14] echo-area: ah right, yes, in trunk too [07:14] 'content' is this context refers to an internal pov and is misleading for users [07:14] echo-area: my mistake, although you could argue it implicitly suggests that. [07:14] vila: Reading that. I was replying to spiv's message [07:15] echo-area: sure, no worries [07:16] Maybe we can make an explicit note on this in the user guide. I'll try to make a patch later [07:16] echo-area: highly welcome ! [07:17] echo-area: that'd be wonderful, thank you [07:17] echo-area: see also http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution for what is cooking in this area [07:17] Okay [07:20] hmm, yeah, re-reading that, 'content conflict' may be better understood if it was named 'tree shape conflict' [07:22] that is, the merged trees disagree about an object kind: deleted, file, dir, symlink [07:23] vila: or "file kind conflict"? [07:23] vila: that's a bit less jargony [07:27] vila: or, hmm [07:27] vila: file/dir/symlink, that's "kind conflict", but deleted vs. modified is "status conflict"? [07:28] vila: I think that's pretty consistent both with our internal terminology and the terms we expose to users at other times. [07:30] valentine : under his shower, will coming soon :) [07:35] :-D [07:36] spiv: well, IMHO, what is consistent is that most of our users are saying: 'wtf is a content conflict' :-) [07:37] but yeah, separating kind conflict and status conflict seems like a good idea [07:37] vila: hehe [07:38] vila: ok, I'll file a bug [07:38] the main issue is in the implementation which is hard to modify (see url above for some explanations) [07:41] *nod* [07:45] vila: filed https://bugs.launchpad.net/bzr/+bug/745491, please elaborate or disagree as you see fit :) [07:45] Ubuntu bug 745491 in Bazaar "“Contents conflict” is unclear to users, replace with “kind conflict” and “status conflict”" [High,Confirmed] [07:46] echo-area: you may be interested in that proposal too (bug 745491), I'd be interested to hear if you think it would have helped you [07:46] Launchpad bug 745491 in Bazaar "“Contents conflict” is unclear to users, replace with “kind conflict” and “status conflict”" [High,Confirmed] https://launchpad.net/bugs/745491 [07:46] ubot5: yes yes we know [07:46] spiv: Okay, I'll follow that. [07:47] * jelmer waves [07:49] spiv: done [07:49] jelmer: \o/ feeling better ? [07:50] vila: yup, thanks [07:51] vila: do you know if we're mumbling this morning? [07:51] jelmer: no, but given that poolie uses a 3G connection, I doubt he can mumble [07:51] ah, good point [07:52] jelmer, vila: yes [07:52] jelmer, vila: but skype, and we call poolie on pots [07:52] * spiv -> afk [07:53] * vila has no skype setup :-/ [07:57] * jelmer dusts off his skype setup [07:59] xb [08:02] * vila finally remembered his skype login [08:37] * jelmer waves to poolie [08:39] vila: for when do you have b2 planned? [08:40] jelmer: I keep the release dates up to date on lp, so: 2011-04-28 from https://launchpad.net/bzr/2.4 [08:41] well, I *try* to keep them up-to-date ;) [08:41] jelmer, maxb : the ppa:bzr/beta needs love ;) [08:41] oh wait, I already said that in the topic ;-D [08:46] yeah [08:46] vila: thanks [08:46] I was actually just contemplating my notional compatibility layer for painless dh_python2 rebuilds for older series [08:47] I think I've got an idea which should work: [08:48] Rebuild python-defaults with 2.6.6-3really2.6.4-0ubuntu1 etc. versions, whilst adding a Depends: python-backport-helper [08:48] Create a new package python-backport-helper which Depends: python-support, python-central, and installs a fake dh_python2 [08:49] Embed a table in the p-b-h package which maps sourcepackagenames to pysupport or pycentral following what they currently do, to avoid unnecessary transitions [08:49] I think I'll have a go at implementing what I just said at lunch today [09:41] I have a project directory like /home/jo-erlend/devel/Projectname where my sourcecode resides. This thing about branches, how does that work? Should I move my files into a subdirectory like ~/devel/Project/trunk and work on the code from there and push to ~/devel/Project/1.0 when I reach the first major version, for instance? [09:42] as you can understand, I'm quite the beginner with this VCS thing. :) [09:48] jo-erlend: In Bazaar, branches are modelled as separate directories on disk. So, yes, a .../trunk directory is a very reasonable thing to have if you expect to have multiple project branches side by side. However, marking versions seldom merits a whole new branch - there is a separate concept of tags for that. [09:49] You can always branch from a tag later, if there is a need to create a maintenance branch for a released version [09:50] oh, ok. Then a tag is just a way to emphasize a commit? [09:53] tags have a danger on bzr at the moment, you can't push them if you delete them. === mr-russ1 is now known as mr-russ [09:54] I didn't really understand that. [09:54] jo-erlend: I would setup a shared-repository in ~/devel/Projectname and create a branch called trunk under that. [09:54] jo-erlend: are you going to have a central storage location for your code, or just work from your home directory? [09:55] it's just me for now, but I'd like to be able to invite others later, if they're interested. [09:56] I just added the following to bzr 2.4 docs. http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/simple-setups.html?highlight=ssh%20restrict#using-a-restricted-ssh-account-to-host-multiple-users-and-repositories [09:57] that's how I have a setup others can use. [09:57] but to start with a single branch setup. [09:57] in your code folder, bzr init [09:57] bzr add [09:57] bzr commit [09:57] .. code away ... [09:57] bzr commit [09:57] and you are using the revision control. [09:58] hi mr-russ [09:59] hi poolie. [09:59] semi disturbingly, I'm starting to feel part of the family. [10:00] just to work out how and if I could work for canonical... Not programming python though. I know zero python. [10:00] mr-russ: hmm. I'm reading a "mini-tutorial" on doc.bazaar.c-c and it sais something about a "saved parent location". Where is that set? [10:03] perhaps that's just the location I branched from? [10:14] you don't need a parent, or saved parent. [10:17] But it is where you branched from. [10:18] knowing python helps [10:18] but, ubuntu.com/employment :) [10:19] jelmer, hi? [10:19] o/ Riddell [10:19] ok. bzr stores diffs for text files, yes? What about binaries and other stuff that can't be diffed, does it make copies of those? [10:19] hi all [10:19] jo-erlend, they're all stored using a binary diff format [10:19] at that level, it doesn't care if they're text or not [10:23] hmm. Ok. So if I wanted, I could set my whole home directory under version control so I could skip back if I did something stupid? [10:26] yes. [10:27] yep [10:27] but, a specific backup tool may be better [10:27] i like duplicity and rdiff-backup [10:29] poolie: hi [10:29] hey, jelmer [10:30] i was just wondering if you had registered sessions for bzr at uds [10:30] not yet, I saw Alisons email earlier but hadn't figured out how to name the blueprints etc yet [10:30] mm [10:31] there is some scheme but i don't remember it, and for that matter it may have changed [10:31] dholbach could probably help [10:31] I'll ask him - thanks for the reminder. [10:32] np, thanks for doing it [10:44] jelmer, can i just ask your bzr-colo recipe to build for maverick too? [10:45] well, i _can_; will it break things though? [10:45] poolie: I'm not sure if it will work, as it uses dh_python2 [10:46] poolie: dh_python2 is only available on natty I think, and we've disabled most other builds for maverick because the debian packages require dh_python2 at the moment. maxb has a plan on how to deal with this. [10:46] ah, ok [10:46] i should upgrade my laptop soon anyhow [10:47] jam: hey, I've got an updated patch for Twisted, just running tests again before I push [10:48] I intend to try to put that plan into practice today [10:48] jam: it adds a noVars param Failure, so you still get tracebacks with files, line numbers and lines, but skips the locals and globals work. It's about 10x faster rather than 16x on my crude benchmark, but is probably a good compromise. [10:49] jam: stripping tracebacks entirely in maybeDeferred was starting to have wider test suite fallout in Twisted, mainly in Trial, but tracebacks are clearly desireable there :) [10:49] jam: it's actually overall faster at running Twisted's tests than my original patch, presumably because it does fix maybeDeferred too [10:54] jam: woah [10:54] jam: I think I just saw that intermittent push issue you had, where the client spends ages doing get_parent_map rather than pushing [10:55] Wow, that's weird, it's getting NotStacked back for my branch from the lp smart server [10:56] But http://bazaar.launchpad.net/~spiv/twisted/deferred-no-failure-tracebacks-by-default/.bzr/branch/branch.conf looks pretty stacked to me! [10:57] Oh, no, I just can't read a -Dhpss log, ignore me. [10:57] I don't know why it's not working, though. [10:58] bug pls :) [10:58] * spiv works around it for right now [10:58] poolie: yeah, definitely [10:59] spiv: it was 'bzr branch lp:a-stacked-branch' rather than getting the dev focus first [11:01] spiv: I was just starting to write some test cases, and found a few more edges [11:02] like "deferred.errback()" defaults to fail=None ,which calls Failure(none), which would also create a traceback [11:02] etc [11:02] spiv: so I'm happy to wait for wherever you want to leave off [11:02] I was a bit surprised to see "twisted.test.test_defer" rather than "twisted.internet.test.test_defer" [11:03] jam: see my update to http://twistedmatrix.com/trac/ticket/5011 [11:04] jam: partly that's because originally there was only twisted.test, so old stuff tends to be tested in there [11:04] sure [11:04] I think the 16x vs 10x matches what I saw [11:04] jam: and partly because defer.py really belongs in twisted.python not twisted.internet [11:04] where commenting out __getstate__ had a good benefit [11:04] but there was almost as much to be gained by not walking the frames in the first place [11:05] spiv: in which case Failure could depend on it :) [11:05] I found on my crude benchmark I could squeeze out a few more percent by aggressively avoiding repeated x.y in Failure.__init__, etc. [11:05] Which is a good sign, it suggests it's fast enough now for that sort of thing to be significant :) [11:05] sure [11:06] jam: it would still be backwards, layering-wise [11:06] well, it is a debug flag [11:06] which should probably sit a lot higher than Deferred.debug [11:06] Well, capturing more info in Deferreds is different to capturing more info everywhere [11:07] spiv: not if you are writing real twisted code :) [11:07] Failures are sometimes used entirely outside the context of Deferreds [11:07] since Deferreds are everywhere [11:07] e.g. the 'reason' param of connectionLost [11:07] Deferreds only provide a way to do one-shot async calls [11:08] spiv: where, again, it doesn't really make sense to include a traceback [11:08] jam: I agree [11:08] jam: I don't think capturing that info is a good default [11:08] But it's been the default for probably most of the lifetime of Twisted [11:08] Which is over a decade old now [11:09] So I think changing that default probably needs to be done cautiously to make sure it doesn't break people's code; Twisted is much pickier about backwards compatibility than most projects. [11:10] * spiv -> dinner [11:10] i wonder if we have any overall data on connection time [11:11] poolie: define overall data? [11:11] (we might have some information in the access logs, etc., but I'm not really sure what you are looking for) [11:12] sorry, i meant, connection time 3 months ago vs now [11:12] to lp [11:12] poolie: you mean other than the bzr ping graphs? [11:12] ideally something measured from the real world [11:12] i wonder if i filed that bug long enough ago to be useful [11:13] * jam really is pleased with perf boost to lpstats [11:13] poolie: I wonder about just enabling 'debug_flags = hpss' on production, since the logs I've looked at give some really nice debug info [11:13] might be too big of a flood for real world, though [11:19] poolie: https://lpstats.canonical.com/graphs/CodehostingPerformance/20100331/20110331/ [11:19] definitely shows it has been trending down recently [11:19] well very short term back up [11:19] but quite a bit down from last may [11:20] jam: and less variable too, which is nice [11:24] don't know if there's a very distinct trend [11:24] i guess if you said "the worst experienced lag" that's gone from 7 to 4 [11:24] in what, seconds? really seconds? [11:25] poolie: yes, really 7+s just to get an ssh connection [11:25] that's remarkable [11:26] i would have guessed more of it was rtt [11:26] so what else did we get done this calendar year that was good? [11:27] time bzr missing bzr://... 0m3.042s [11:27] poolie: If I can get this rolled out into production: https://lpstats.canonical.com/graphs/CodehostingPerformanceStaging/20110101/20110331/ [11:27] time bzr missing bzr+ssh://... 0m6.747s [11:28] AfC: 'time ssh /bin/false' ? [11:29] jam: 0m3.357s as expected [11:29] AfC: this is with openssh on both sides? [11:29] yes [11:29] One interesting bit is that the twisted ssh service can actually connect faster than openssh [11:30] not sure the specific reasons [11:30] I know at one point ssh switched the default to do reverse dns lookups [11:30] and that made it a *lot* slower when the source didn't have a dns entry [11:30] because it would wait 2s to timeout, etc. [11:31] mm [11:31] it would be horrible if that's live [11:31] AfC: http://ubuntuforums.org/showthread.php?t=445677 [11:31] probably not [11:31] "UseDNS no" [11:31] Also "GSSAPIAuthentication No" [11:32] so it doesn't try to look up kerberos credentials [11:32] jam: yeah, I'm across that one [11:35] (wasn't complaining, just offering a few data points; I have bzr: and bzr+ssh: on the same trees) [11:37] AfC, poolie: "time ssh localhost /bin/false" is about 800-900ms here [11:38] really? 0.310 ± 0.040 here [11:39] Using '-v' seems to say the bulk of the time is right after: http://ubuntuforums.org/showthread.php?t=445677 [11:39] ugh [11:39] debug1: Entering interactive session. [11:39] At least, that is where the terminal hangs for a bit before going to the next message [11:39] poolie: earlier this year we installed python-gmpy on the codehosting server, speeding up Twisted's SSH crypto [11:40] spiv: after we fixed it not to bork the rest of the system :) [11:40] well, afterwards we fixed it :) [11:41] poolie: this is the list you are compiling for s-tatik? [11:42] yup [11:42] poolie: loggerhead is now mostly actively maintained [11:43] poolie: package importer improvements. Quite a few big "100 packages no longer failing" etc. [11:44] looking here: http://package-import.ubuntu.com/status/ [11:44] I see we're down to 476 failures, from a peak of ~3k [11:45] in mid January [11:45] AfC: well, technically that is a VM, since I don't yet run opensshd on my laptop directly. [11:46] → zzz [11:56] poolie: my 'iter_entries_by_dir' change makes 'bzr co --lightweight gcc-linaro' go from 3m48s down to 1m5s on Ubuntu for me. [11:56] poolie: spiv's change to make 'fetch' transfer the revisions associated with tags [11:57] nice [12:21] when I try to bzr init in a directory on an ntfs partition mounted on linux I get a ERROR: Transport error: [Errno 1] Operation not permitted [12:21] it is mounted in latest ubuntu with fuse [12:21] so I can't use bzr over an smb mounted drive OR on a locally mounted ntfs drive === hunger_ is now known as hunger [12:25] thrope: I think the number of system calls the fuse smb file system allows is pretty limited. [12:25] Have you tried with the kernel one? [12:25] no [12:25] don't want to mess about with it really - just using standard ubuntu settings [12:26] just surprised to find another not that unusual situation where bzr fails completely and ungracefully [12:27] there's a bug for it, which may have a workaround [12:27] but, really it's a fuse bug [12:28] thrope, https://bugs.launchpad.net/bzr/+bug/190725 [12:29] Ubuntu bug 190725 in Bazaar "Bzr can't init branch on ntfs-3g filesystem" [Medium,Confirmed] [12:42] Did I see that correctly that one can write python scripts using a bazaar repo very easily? [12:43] night all [12:43] idky: yep, it's fairly easy [12:43] g'night poolie [12:44] jelmer: hmm, that is another thing that makes me tend to bzr instead of git ... why are these decisions so hard? :) [12:46] and is there a way to put the output of diff or cdiff into a pager automatically? [12:46] idky: there's a bzr-pager plugin that can do that [12:58] hey [12:58] I think this bug is fixed [12:58] https://bugs.launchpad.net/bzr/+bug/301472 [12:58] Ubuntu bug 301472 in Bazaar "need a way to uninstall a hook" [Low,Confirmed] [12:58] is it fixed? [13:00] hmm. maybe not. [13:01] what a pity [13:03] hmm [13:03] I'm hacking on hooks at the moment, might as well have a look at that one too [13:04] jml: would that help you? [13:05] jelmer: yeah, but only a little. there's a legacy monkey patch in lp/codehosting/__init__ that I'd like to remove. [13:05] (I had thought I could because it said "bzr 1.14" in the comments, but now I'm confused) [13:09] jml: I don't see any other way to uninstall hooks. Perhaps a patch was proposed but it never made it in? [13:09] Anyway, I'll have a look at adding an uninstall function. [13:09] jelmer: I think in bzr 1.13, Branch.hooks was a list, not a HookPoint [13:09] jelmer: so the way to remove hooks was to call 'remove' on that list. [13:10] and when we upgraded, we did the monkey-patch presumably to avoid the break in API as well as provide the now-missing functionality. [13:10] ahh [13:15] Our test suite resets hook registrations between tests [13:20] jam: I'd love to know why my second pushes to lp:~spiv/twisted/* branches are repushing all of history! [13:21] i.e. push new branch, stacked and fine. Commit again, push: find all the ancestry missing and push it all. [13:22] * spiv tries with bzr 2.3 [13:22] That worked. Regression :( [13:26] spiv: ouch. I wonder if it is something with the lp: redirect biting us again? [13:28] jam: not sure, and it's too late in my night for me to find out [13:28] jam: https://bugs.launchpad.net/bzr/+bug/745664 [13:28] Ubuntu bug 745664 in Bazaar "Incremental push to stacked branch on LP walks all of history" [Critical,Confirmed] [13:41] jml: https://code.launchpad.net/~jelmer/bzr/uninstall-hook/+merge/55527 [15:28] it looks as if Twisted can't use bzr-svn to maintain a mirror any more [15:28] because it requires more than 600MB of memory to do a pull [15:28] and they don't have that much on their servers [15:28] jml: Whoa; is the tree really that big? [15:28] and this is just an incremental pull? [15:29] jelmer: the history is pretty old [15:29] jelmer: not sure about the tree size... [15:29] /usr/bin/bzr svn-import -v --incremental [15:29] ah, svn-import [15:29] should they be doing something else? [15:30] oh, I guess that's a multi-branch thing [15:30] I was thinking bzr pull. there's a known issue with svn-import and memory usage that I still need to look into [15:30] perhaps this is a good excuse to.. [15:32] jelmer: is there a bug number that I can point the Twisted folk at? === deryck is now known as deryck[lunch] [15:35] jml: bug 516999 IIRC [15:35] Launchpad bug 516999 in Bazaar Subversion Plugin ""Finding branches" step takes waaay too much memory" [High,Triaged] https://launchpad.net/bugs/516999 [15:35] jelmer: thanks. [16:06] vila: hi [16:06] jelmer: pong ;) [16:06] vila: just looking at your devnote on configuration files [16:07] * vila nods and fix more typos :) [16:07] vila: some of the bullet points at the bottom don't seem to be formatted properly [16:07] jelmer: I fixed some, try refreshing ? [16:08] argh, silly me, looking at my local copy ;-/ [16:08] Under "user facing concepts" [16:08] and under "stack examples" [16:08] ah :) [16:09] vila: the sheer number of configuration files worries me a bit [16:09] jelmer: yup, fixed both [16:10] jelmer: well, have a look at the number of IOs we do today then ;) [16:10]