[00:03] Peng_: Apparently! [00:07] The link to reverse cherrypicking in http://doc.bazaar-vcs.org/latest/en/user-guide/undoing_mistakes.html is broken [00:12] mwhudson: wb [00:13] * Peng_ pushes [00:16] How can I accept a list as an argument for a command? [00:17] mathepic: in a bzrlib.commands.Command subclass? [00:18] spiv: Yes, I'm trying to make remove-tree accept multiple trees as arguments [00:18] mathepic: something like takes_args = ['file*'] [00:18] see e.g. cmd_dd [00:18] er, [00:18] cmd_add [00:18] Thanks [00:18] (my 'a' key is becoming a bit dodgy) [00:19] And add a ? after the * if I want it to be optional, right? [00:23] It doesn't seem to work with optional... [00:24] No, just * [00:24] If you don't pass any, then the list will be empty :) [00:31] In my parameters for run, I have location_list=['.'] [00:31] But it still gives an error if I don't specify a directory [00:31] bzr: ERROR: exceptions.TypeError: 'NoneType' object is not iterable [00:32] Oh wait, it passes an empty list [00:32] So I need to check if its empty, and if its empty, assign ['. [00:33] Right. [00:34] Okay, got it. It works now. [00:40] Revision graphs contain lots of ints and bools, no? [00:41] Bools? Not off the top of my head, but ICBW [00:42] Eh. I don't know if Loggerhead's graph structure is the same as bzr's. [00:43] Anyway, it would be a great case for StaticTuple, but it has ints and bools. :( [00:52] There's are a bunch of diff-related tuples that include ints, too. [00:54] jam: It'd be awesome for Loggerhead if StaticTuples could include Python ints and bools. [01:02] * Peng_ /away! [01:06] LH doesn't have any interesting str-only tuples. :\ [01:09] Graph.iter_ancestry could use StaticTuples. [01:10] Peng_: patches welcome! [01:11] I think jam is choosing where to introduce it by profiling rather than inspection. [01:11] But if it fits, there's no reason not to use it. [01:26] lifeless: good morning === norly is now known as ejat [01:36] spiv: hai; internode outage ;) [01:36] :) [01:43] spiv: Yeah, that makes sense. I'm doing simple profiling ("scroll through Dozer output") and skimming through the code. Still, LH has a lot of tuples from iter_ancestry. === davidstrauss_ is now known as davidstrauss [05:15] spiv: bug 449923; I think its wishlist more than invalid - just a thought [05:15] Launchpad bug 449923 in bzr "bzr send should offer the --diff-options option" [Undecided,Invalid] https://launchpad.net/bugs/449923 [05:17] lifeless: yeah, good point === Adys_ is now known as Adys [06:39] hello all [06:39] spiv: thanks === Adys_ is now known as Adys [06:48] bialix: no worries, thanks for bringing it to my attention [06:49] I suspect the bug traffic is too high to see every sepearte bug report [06:49] *separate [06:52] spiv: I'm not sure I'll be able to work on fixing this bug in bzrlib until december or january... So I'll try to invent some workaround [06:54] bialix: I expect I'll get to it before December :) [06:54] spiv: I'll respect this [06:55] though the bug triggered by QBzr non-trivial usage [06:55] Yeah. [06:56] though abentley suggest using dicts, but anyway today it's our (qbzr) problem [06:58] hi bialix, spiv [06:58] hi igc [06:58] igc: re http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-svn-projects.html [06:58] is it now official? [06:58] in which sense? [06:59] bzr-migration-docs is a separate project to bzr core fwiw [06:59] but the core docs link to the latest copy of the migration docs [07:01] oh, I saw http://doc.bazaar-vcs.org/... URL and thought it's part of official documentation [07:02] it seems there is too much different branches with different docs, site etc. I've lost the track [07:04] bialix: it's meant to look like one set of doc :-) [07:04] bialix: behind the scenes though, I need to build different bits on different timelines [07:04] with different dependencies [07:05] migration is migration - it's not really tied to 2.0.1 vs 2.1.0b1 say [07:05] I'd like to link to your document in bzr-day blog. May I cal it semi-official tutorial/guide then? [07:05] it's more tied to bzr-fastexport patches [07:05] *call [07:05] yes [07:06] bialix: like the plugin guide, it is official documentation, just not "core" documentation [07:07] * igc off for some medical stuff - bbl [07:18] hey guys i did not have internet for a while, so i used bzr commit --local, now i got internet and repo has moved. I tried to commit to the new reposatry (via bind to it first) but it made such a mess [07:18] whats the best way to deal with --local? [07:18] i have now over 18 conflicts [07:18] 'bzr push' [07:18] oh [07:18] thats odd being the only developer [07:19] what did you do? [07:19] i used commit --local couple of times [07:19] right [07:19] and then what did you do, later? [07:19] then i did bzr commit ( when i got internet setup) [07:20] it said [07:20] no address [07:20] so i did bzr bind to new address [07:20] then i did bzr commit ( then i got message that i need torun bzr up) [07:20] i run bzr up [07:20] now every thing is confused [07:21] and i have 18 conflicts [07:21] and conflicts are crazy too: [07:22] conflicts in any vcs blow :( [07:22] bzr isn't too bad though [07:22] http://dpaste.com/107979/ [07:22] MTecknology: it's better than not having them [07:22] yup [07:22] the problem is that i am conflicting with myself === Kamping_Kaiser is now known as `6og [07:23] treeform: yeah, bzr up when you have local commits *and* uncommitted changes tends to give nasty double conflicts. [07:23] spiv: is there a way to undo [07:23] and do some thing better? [07:23] So.. I want to have a group of users that can access a bzr branch - what's the best way to handle that? [07:23] I tend to make sure "bzr st" is clean before doing pretty much anything important [07:24] well, before doing pretty much anything that might involve a merge [07:24] howly fuck bzr st is even crazier [07:24] treeform: so a good thing to do if you have local commits is make sure you have no uncommitted changes (i.e. shelve or commit your changes) before doing bzr up [07:24] i have hunders of moded, unkown, delted, undelete ... files [07:24] yeah, if you're already in weird merge territory "bzr st" is going to be pretty confusing too [07:24] err [07:25] that sounds excessive. Any idea what happened? [07:25] sometimes certain large tree reorganizations cause this [07:25] yes [07:25] how can i roll back that update? [07:25] without causing even more strife? [07:25] you can just revert, but that'll kill your existing local changes [07:25] yeah [07:25] I'm not sure if there's a sane way to preserve those at this point :( [07:26] You can do "bzr revert", but as mzz says that'll forget your uncommitted changes. [07:26] ill copy the folder first? [07:26] and copy it back? [07:26] that won't necessarily give helpful results, although I guess it's better than nothing [07:26] well i use all local changes? [07:26] lose* [07:27] I know this doesn't help at all with your problem now, but if "bzr st" was originally clean being able to just revert a merge that went wrong is extremely useful [07:27] Yeah, so copying the current mess, doing a revert, then doing an update into a clean tree is probably simplest. And then manually copy across any local changes from the copy. [07:27] yeah [07:27] I don't think you actually have better options, since your local changes are tangled into this confused merge now and bzr doesn't store enough information to untangle them [07:27] man thats sound like what reversion controll made to avoid [07:28] yes, and you can just revert *if* your original status was clean [07:28] so I tend to either commit or shelve local changes before doing something that'll involve a merge [07:28] I think https://bugs.launchpad.net/bzr/+bug/120970 is the relevant bug report, they may be others. [07:28] Launchpad bug 120970 in bzr ""bzr update" reports spurious conflicts when local commits added a directory." [Medium,Confirmed] [07:28] I need to learn how to shelf something [07:28] MTecknology: bzr help shelve :) [07:29] yeah me too [07:29] never sued shelve [07:29] It's pretty easy [07:29] used* [07:29] although I don't think I've dealt with unshelving onto a very different tree than what I shelved from using the new shelve yet [07:29] the old shelve stored changes as plain diffs, so I was always sure I'd be able to manually apply them if I confused shelve [07:29] i think fixing the conflicts might be eser then redoing everything [07:30] i did lots of stuff [07:30] (And also see http://doc.bazaar-vcs.org/latest/en/user-guide/shelving_changes.html) [07:30] if i fix all the conflicts i shoudl be good riht? [07:30] treeform: downside of that is that you're going to end up with your local changes and the merge being in the same commit [07:30] hi all [07:30] treeform: well [07:30] treeform: what i'd do first is revert the changes [07:30] treeform: the resulting history will be cleaner if you manage to revert, commit just the merge, then commit the local changes on top of that [07:30] but at this point it'll be painful no matter what you end up doing [07:31] Sorry to begin the day with bad news, but babune is fully *red*: as of revno 4750, not a single successful selftest, with default locale and extensions compiled, pass [07:31] the most disturbing is that this is the run that pqm is supposed to run, any info I may have missed that occurred during my night ? [07:32] the failures (6) are related to: TypeError: can only concatenate tuple (not "StaticTuple") to tuple [07:32] occurring in _commit_write_group [07:32] mzz, dash: so you say revert, and then copy all the files from the safe folder i just did? [07:33] but that does not take care all the files that i removed [07:33] treeform: no, don't copy [07:33] merge [07:33] jam, spiv, lifeless, igc: ^ [07:33] dash: resolve conflicts? [07:33] treeform: I'd back up the current tangled state somewhere, just in case, then revert, redo the merge (the one "bzr up" triggered), then reapply the local changes from the backup of the mess [07:33] i am merging v n-1 with version n .. its utter crap [07:33] vila: See what happens when you wake up early? :p [07:33] treeform: but that's just me, and I don't know exactly what state your tree is in [07:34] vila: huh [07:34] treeform: 'bzr vis' might help, maybe :) [07:34] so - handling groups with bzr? [07:34] what's a group [07:34] MTecknology: Well, I use... y'know. Groups :) [07:34] vila: that is weird [07:34] dash: i dont have it instaled [07:35] viz probably wouldn't help when you're in a twisted up state. [07:35] MTecknology: err, I haven't done this in ages, but I think the last time I did we used a separate user account on the server with the keys of the developers supposed to be able to push to it in authorized_keys [07:35] spiv: I haven't investigated yet, but yes that's very very weird [07:35] MTecknology: which gave those users access to quite a bit more than just bzr, but that wasn't an issue for us [07:35] treeform: Are you still sitting with the giant pile of conflicts? [07:35] yeah [07:35] and lost histry [07:35] OK. So you've got two sets of changes here. [07:36] mzz: sounds interesting [07:36] treeform: you really shouldn't be losing any history, but it's hard to reliably preserve uncommitted changes across something like this. That's why they're uncommitted, I guess [07:36] The ones you commit'd (--local), and the ones that were sitting uncommitted in the tree. [07:36] mzz: last time I used actual group accounts but I needed to miss with sticky bits [07:36] treeform: The former are still in your repo, so that's all recoverable. The later, unless you can puzzle them out of the mess you have, are gone. [07:36] vila: btw, it would be neat if babune used --subunit [07:36] MTecknology: yeah, if you rely on groups it'd take a bit of effort to keep permissions consistent (everything group-writable). This was easier for us. [07:37] * fullermd marks up another tick in the "get rid of fscking ci --local already" column... [07:37] mzz: thanks [07:37] fullermd: i dont want to loose stuff [07:37] but i think revert will cause even more pain [07:37] spiv: full agreement, I want to switch to hudson first though... or to anything that allow a better tracking of runs [07:37] then resolving 18 conflicts [07:37] MTecknology: but in this case everyone being able to do a full ssh login as that project user was a feature, allowing them to update the website and the like [07:37] ymmv and all that. [07:38] vila: so, I see that failure locally, and it disappears if I delete _static_tuple_c.so [07:38] vila: which suggests that PQM isn't building that extension :( [07:38] treeform: Well, unless you can sort out the big mess there, you're not going to get a hold of your uncommitted changes. And even sorted out, it's a big ugly knothole in history because of all the unrelated changes mixed in. [07:38] MTecknology: I'd expect the groups approach to also work, I just don't know the best approach to forcing bzr to use the right umask so everything stays group-writable [07:39] mzz: that's what the sticky bit was for [07:39] I wonder how LP handles it [07:39] yeah [07:39] treeform: The changes you _committed_ are fine, we can recover those easy. Presumably, you're committing often enough that the uncommitted bits are easy to redo, right? ;) [07:39] yes [07:39] treeform: I'd be pretty surprised if the revert loses any *committed* changes. It'll eat the uncommitted ones. [07:39] mzz: right [07:39] ok will resolve [07:40] o will revert* [07:40] its reverting... [07:40] spiv: how does LP handle teams? [07:40] MTecknology: LP doesn't use filesystem permissions at all, it handles all that internally [07:40] treeform: 'k. Do you have bzrtools installed? [07:40] oh [07:40] treeform: after the revert I'd manually delete any cruft left behind ("bzr st" is your friend here) [07:40] ok i reverted [07:40] ah, nvm, I'll stop interfering with the others helping out [07:41] MTecknology: you can take a look at the source these days :) [07:41] what do i do? [07:41] spiv: I will when I start trying to do some dev on it - but I've been lacking time [07:41] I just realized I spaced on an assignment.. [07:41] treeform: Have bzrtools so you have the 'heads' command, and run a 'bzr heads --dead-only'. [07:41] treeform: That'll list the head revs in the repo that aren't on the branch; one of them will be the head of your local changes. [07:42] (you'll have to look at timestamps and log messages to figure which one; should be easy to tell) [07:42] MTecknology: but briefly it implements a custom bzrlib.transport.Transport that a) translates paths from the user to how things are actually stored on disk, and b) does acceses control checks based on team membership [07:43] fullermd: isn't he already on that head if he reverted? [07:43] spiv: thanks, good to know [07:43] spiv: Sounds tricky [07:43] mzz: No, he's on the head of the 'remote' branch. [07:43] fullermd: I haven't commit --local'd anything recently, but I'd expect this to just do the right thing [07:43] urgh? [07:43] mzz: The update pivots over to that branch and stuffs your local commits as a pending merge. [07:43] that sounds like a misfeature [07:43] fullermd: getting bzr tools [07:44] treeform: Once you find it, grab the revid and run "bzr merge -rrevid:$WHATEVER ." [07:44] MTecknology: it's not too hard, actually. [07:44] MTecknology: you can basically do it all as a bzr plugin [07:44] heh [07:44] treeform: That'll set up a pending merge with those local changes; then you can check and commit it, and you'll be where you want to be, minus the uncommitted stuff. [07:44] mzz: You're too kind. [07:44] spiv: you can do tons of stuff as a bzr plugin, doesn't necessarily mean they're easy :P [07:44] mzz: :) [07:45] mzz: well, you can look at the code an judge for yourself ;) [07:45] Yeah. I mean, theoretically you write write a svn gateway as a bzr plugin, but who would... oh. [07:45] fullermd: where do i install bzrtools on windows? [07:45] Actually, the bzrlib.transport.pathfilter module in recent bzr would make this even easier. [07:45] treeform: Mmm. Dunno. Doesn't the windows installer come with bzrtools? [07:45] treeform: (try 'bzr help heads') [07:45] treeform: which installer did you use? [07:45] treeform: (for bzr itself, that is) [07:45] oh its there [07:45] but not bzr vis [07:45] ah, nvm then [07:46] chmod +s = :) ;; when used correctly [07:48] bzr merge --rrevid:me@centurion-20091012170842-puyjiezcx4dw6noc [07:48] bzr: ERROR: no such option: --rrevid:me@centurion-20091012170842-puyjiezcx4dw6noc [07:48] One dash [07:48] (and don't forget the " ." at the end; that's important) [07:49] same thing [07:49] dot or not [07:49] treeform: single - [07:49] oh ok [07:49] treeform: (it's the option -r, taking an argument of revid:... [07:50] its spinning [07:50] treeform: ("-r revid:..." also works. It's not the option --rrevid) [07:50] vila: [07:50] - all_missing.update([(prefix,) + key for key in missing]) [07:50] + all_missing.update([(prefix,) + tuple(key) for key in missing]) [07:50] vila: that seems to be an effective band-aid [07:50] Is it possible to have something like lp: instead of a site name? [07:51] fullermd: its done [07:51] bzr st is soo confused [07:51] MTecknology: lp: already works (it's builtin). You might want the "bookmarks" plugin for other sites. [07:51] treeform: Confused how? Just "a lot of stuff"? It should just be the changes from your local commits. [07:52] yes i guess it is [07:52] i was just not ready for 25 page report ;) [07:52] what is this > pending merge tips: (use -v to see all merge revisions) me 2009-10-12 fixed the errors from major renaming spree [07:52] mzz: yup - that plugin is what I was asking for :) [07:53] treeform: That's the head of the revs you're merging. [07:53] what do i do next [07:53] Check that everything looks right (no conflicts etc), then commit 'em. [07:53] treeform: basically local commits makes a temporary branch, and when you do "bzr update" it's bascially the same as "bzr merge" of the main branch with that temporary branch. [07:54] i see [07:54] treeform: so, your local commits show up as a pending merge. [07:55] but why did the uncommited stuff cause so much problem? [07:55] I need to install bzr on the server first.. huh.. [07:56] MTecknology: depends on what you're pushing over [07:56] MTecknology: you can do sftp pushes, for example. But installing bzr on the server may be preferable performance-wise. [07:57] ya [07:57] anyway - I'm getting permission errors but I'm in the group that has access for it [07:59] chmod 770 /bzr/test bzr push bzr+ssh://192.168.1.6/bzr/test [07:59] anything wrong with that? [08:00] spiv: +1, please land :-) [08:01] MTecknology: not offhand, no. ~/.bzr.log? [08:01] spiv: or tell me to land it, I really don't like having the test suite failing that way, so let's fix that first and then fix it best (with jam input) and let's address the root cause (not building extensions if that's it) [08:02] woah.. http://dpaste.com/107985/ [08:03] vila: go ahead and land it for me, I'm playing with making tuple + StaticTuple work [08:03] spiv: ok [08:03] vila: but I agree, the root bug is that PQM should not pass if that extension doesn't build [08:04] spiv: just running a full test suite to make sure [08:04] vila: ta [08:04] bzr: ERROR: Server sent an unexpected error: ('error', "'Bazaar repository format 2a (needs bzr 1.16 or later)\\n'") [08:05] so - I need to update my server? [08:05] MTecknology: that error is probably because you're trying to push a 2a format branch to a server that can't read 2a [08:05] so, yes [08:06] both client and server are Ubuntu 9.10 [08:06] MTecknology: what does 'bzr version' says ? [08:06] ooh... the server's 9.10 [08:06] 9.04* [08:07] I should upgrade it to 9.10 [08:07] MTecknology: if you just need a newer bzr: bzr 2.0 is in the bazaar ppa [08:07] MTecknology: I don't know by heart what bzr version are proposed by default to 9.04 and 9.10 so try 'bzr version' in both places [08:07] server - 1.13.1 [08:08] MTecknology: you can then look at https://launchpad.net/~bzr/+archive and foolow the instructions to update your source lists [08:08] I guess I just need to either upgrade the entire server or use a pp [08:08] ppa* [08:08] I like the server idea [08:08] MTecknology: you may be able to upgrade bzr only instead of the whole system, but you decide... [08:08] I thought the guy was installing 9.10 :P [08:09] thanks for all the help [08:09] I imagine that's what caused the other error too [08:12] "This session appears to be running under ssh. It is not recommended to perform a upgrade over ssh currently because in case of failure it is harder to recover." [08:12] :P === gdmfsob is now known as mishok13 [08:13] shower and sleep time - I'll catch you all later [08:15] spiv: sent to pqm [09:03] vila: I'm fine with you landing that revdwim patch from fullermd [09:04] vila: also, https://code.edge.launchpad.net/~vila/bzr/405745-http-hangs/+merge/13050 is approved. Can we land that one as well? [09:04] igc: ok for the dwim patch [09:05] igc: no, fixing bug #405745 makes the leaking tests more sensitive to a yet-to-fix other bug [09:05] Launchpad bug 405745 in bzr "blackbox.test_check.ChrootedCheckTests.test_check_missing_branch hangs on AIX" [Medium,In progress] https://launchpad.net/bugs/405745 [09:05] see my comment there [09:12] vila: what's the buildbot url again? [09:13] igc: can't remember, never use it myself :) [09:13] vila: I some a url with pretty pictures/tables I can reference :-) [09:13] showing our cross-platform testing [09:13] http://babune.ladeuil.net:26862/ [09:14] igc: the pretty pictures are planned after a switch to hudson so far... [09:15] igc: especially because tracking the overall behavior across the revisions is not that easy with buildbot, but I get that feeling progressively by using it daily [09:19] Been using Maven / Archiva / Hudson .... we've been having real headaches but I suspect that's because of the module graph we've been building [09:19] babune progressively recovers some green color ;) Thanks for the quik help spiv :) [09:27] vila: cool [09:27] vila: I'm just finishing for the day [09:27] vila: I just sent a patch to John for making tuple + StaticTuple work though [09:27] spiv: good, I wanted to give you some feedback before :) [09:27] great, I'll track that later today ! [09:28] vila: I'll leave it to jam to polish and merge if thinks its a good idea [09:28] sure [09:28] vila: (it's visible in a comment at https://code.edge.launchpad.net/~jameinel/bzr/2.1-static-tuple-btree-string-intern/+merge/13296 if you're curious) [09:29] vila: it makes the test pass without the bandaid though :) [09:31] Ok, have a good weekend everyone [09:31] s [09:31] spiv: sorry keyboard battery failure here, have a good weekend ! [09:32] :) [09:33] spare batteries to the rescue ! [09:35] igc: I seem to be outvoted on the 'keep going if it looks like a revno' thing; I was gonna wait a day or so for any more weigh-ins and then push up a change to stop searching there. [09:35] fullermd: ok [09:37] I still like it going ahead and keeping trying, but if the majority opinion is the other way, I won't kvetch too much about it. I don't use pure-numeric tags anyway ;) [09:41] fullermd, igc: what did I miss here ? [09:42] Oh, heck, you sided with me. Shucks, now it's even again. [09:42] * fullermd catches up on mail after writing stupidly long-winded PM posts... [09:43] I think the performance issue should be balanced by the time the user will spend understanding the error and typing the new command [09:44] performance and DWIM doesn't have to be compatible as long as an explicit way exists to disable dwim to get performance, and I think your approach is sound for that [09:45] Yeah, the only case where it (currently) adds a meaningful performance hit above the status quo, is if the user enters a revno that doesn't exist; it'll do more searching. If they keep using explicit revid:'s and such, they'll never need to hit those cases in the DWIM. [09:46] (well, there's trivial overhead from instantiating another class and calling some functions, but that's negligable) [09:46] fullermd: if you want to further improve your patch you can do so or let me land that one and build on top of it, your call, unless igc revert his "vila, go land it" message from some minutes ago [09:46] * vila nods to fullermd [09:47] igc: I suspect you missed some of the last messages right ? [09:47] igc1: even [09:47] Mod lifeless's larger concerns, the only thing is the whether to keep the fallback on "looked like a revno, but wasn't" or cut off the search then; votes seem about split on that. [09:47] * fullermd hopes his high school English teacher doesn't get a look at that 'sentence'... [09:48] yeah. if lifeless could shime in to say whether he strongly vetoed or is ok for a further submissions can clear that bit [09:48] but if you plan to tweak some more you can also address that even if I think it will be a yagni, [09:49] at least it would make it possible for someone else than you to try another DWIM approach [09:50] and DEIM, by experience, tends to evolve incrementally so what sounds perfect today may be more polished tomorrow [09:50] s/DEIM/DWIM/ [09:50] vila meant: and DWIM, by experience, tends to evolve incrementally so what sounds perfect today may be more polished tomorrow [09:50] Tak: wow ! Hurrah ! Someone can fix muy tupos ! WOnderfulk 1 [09:52] fullermd: all of that to say: you've been waiting with your proposal a bit too long to see it land, I think we can land the actual one and wait for improvements in another one OR, if you feel like it, you can address the concerns you feel like addressing and resubmit [09:53] * igc1 dinner [09:53] from babune, instant feedback, jaunty fully green, hardy and karmic coming along nicely [09:59] * fullermd polishes up another response to lifeless. [10:04] So, yeah, the only concern I have open is whether the bulk of opinion wants to stop the fallthru on revno-looking stuff. Opinion seems split, so either way. [10:35] fullermd: attributes on the revspec classes would do it easily without needing another registry or lots of cruft.IMO [10:35] fullermd: as for the exceptions; I hear standardising interfaces is useful :) [10:35] lifeless: agreed on both point, I was about to say roughly the same (attributes and exceptions) [10:36] :) [10:36] lifeless: Do you agree to land it as is and to file a bug for that requirements or do you want them implemented before that is landed ? (Given that fullermd implied he will not do them soon, I'd rather land that now) [10:37] Well, there's a limit to the standardizability... I mean, if RevisionSpec_date ever started raising errors.TagsNotSupported, I'd look a little squirrely at bzrlib... [10:37] Ditto NotBranchError, etc. [10:37] fullermd: they can inherit from a common exception [10:38] so, (NoSuchRevision, UnsupportedFeature, RevisionNotPresent) [10:38] I'm sure a lot could be achieved by rototilling how all the RevisionSpec_*'s work, but that's definitely in the "way more scope than I wanna get within 10 blocks of" area. [10:38] NotBranchError should bubble up [10:38] fullermd: or have an attribute list the raisable exceptions [10:38] +1 on ^ [10:38] lifeless: sorry, what are you referring to ? [10:38] Well, NotBranchError is somewhat special since branch: is the last thing tried, but it doesn't necessarily HAVE to be, in which case we'd need to catch it. [10:39] 20:36 < vila> fullermd: or have an attribute list the raisable exceptions [10:39] ok [10:40] Anyway, it's doable with more or less pain in various ways, probably. But it's not as simple as "slap it in, you're done", 's what I was aiming for. [10:43] Holy crud, it's almost 0500?? [10:44] wow, tiger slaves fails but leave a running selftest process that generates log in /tmp of ~3GB size.... triggering OSX warnings about boot disk almost full until I kill them 8-/ [10:45] Well, bzr can use a lot of resources. Selftest has to try overloading the system to make sure it can handle it :p [10:45] process leaks now... [10:45] yeah, but I'd like to get better control on that kind of experiment :D [10:47] I just freed 10GB on a 32GB partition... that should *never* occur or I will really become insane without any hope to cure that... [10:48] Cure? Why waste a good insanity? :p [10:49] Because it's good as long as I'm still enjoying it, if it goes too far, I may forget than I enjoy it, and *then* it would be wasted ! [10:50] from babune: gentoo back in green, waiting for freebsd[78], OSX failed because of yet another hidden aspect of the leaking tests [10:55] fullermd: well, there's insanity and there's insanity [10:55] some of it's not so great :-( [10:55]