| mwhudson | but it's actively bad, just poorly performant | 00:00 |
|---|---|---|
| mkanat | mwhudson: Yeah. | 00:00 |
| mwhudson | mkanat: i guess i'd say it's ok as it is | 00:00 |
| Peng | Race conditions and bug fixes that don't always work make me feel icky. | 00:00 |
| Peng | Objectively, it's an improvement over hte current situation, but.. | 00:00 |
| mwhudson | mkanat: maybe put a comment in? | 00:00 |
| mkanat | mwhudson: That seems reasonable. | 00:01 |
| mwhudson | or maybe try the extra lock and see how performance goes? | 00:01 |
| mkanat | mwhudson: Sure, I'll try the second lock. | 00:01 |
| mkanat | mwhudson: It has no noticeable effect on performance (within the margin of error of my tests). | 00:03 |
| Peng | Could Loggerhead still get killed by a bunch of different caches being built at once? | 00:04 |
| mkanat | Peng: That's what we're going to see. | 00:04 |
| mkanat | Peng: That problem didn't actually happen in the hang logs--it was always the building of a graph for the same project over and over. | 00:05 |
| Peng | Huh. | 00:05 |
| Peng | mkanat: Ah, I see what you wrote on the bug. | 00:06 |
| Peng | OK. | 00:06 |
| mkanat | Okay, pushed a new version. | 00:08 |
| mkanat | Hmm, the preview diff doesn't include my newly-pushed commit? | 00:09 |
| poolie | it takes a minute | 00:09 |
| poolie | to update | 00:09 |
| mkanat | Ah, okay. | 00:09 |
| poolie | minute==little while, not precisely a minute | 00:09 |
| mwhudson | the cronjob runs every minute now actually | 00:10 |
| Peng | This is getting excessively pedantic, but should the new lock use a try...finally too? :D | 00:10 |
| Peng | (The answer is probably no!) | 00:11 |
| mwhudson | i reviewed the branch | 00:11 |
| mkanat | Peng: Yeah, no. :-) | 00:11 |
| mwhudson | it's lunchtime though | 00:11 |
| mkanat | Peng: I don't think anything in there can throw an exception. | 00:11 |
| mwhudson | Peng: want to land if if you're happy with it? | 00:11 |
| mwhudson | mkanat: well anything _can_ fail (consider memoryerror) | 00:11 |
| mwhudson | but.... | 00:11 |
| mwhudson | oh no | 00:11 |
| Peng | Yeah. | 00:11 |
| Peng | Oh no? | 00:11 |
| mwhudson | hm | 00:12 |
| mwhudson | we have this thread killer in launchpad | 00:12 |
| mwhudson | so we should be really paranoid i think | 00:12 |
| Peng | Given the consequences (LH would basically die), paranoid sounds good to me. | 00:12 |
| mwhudson | i can't see why a thread would have only got this far in 300 seconds or whatever | 00:12 |
| mwhudson | but what Peng says | 00:12 |
| poolie | jam, does https://bugs.edge.launchpad.net/bzr/+bug/507040 suggest anything to you? | 00:13 |
| mkanat | mwhudson: Okay. | 00:14 |
| ubottu | Launchpad bug 507040 in bzr "NoSuchRevision during "bzr check"" [Medium,Confirmed] | 00:14 |
| Peng | With that change, I'd be happy to land it. | 00:14 |
| * mwhudson vanishes for a bit | 00:14 | |
| mwhudson | Peng: thanks | 00:14 |
| mkanat | Okay, pushed. | 00:15 |
| mkanat | AnnotateUI is still really slow. | 00:16 |
| mkanat | But everything else is fast. | 00:16 |
| mkanat | And "really slow" now is 11 seconds, not 120. | 00:16 |
| Peng | mkanat: Awesomesocks, thanks. | 00:16 |
| mkanat | 2x users = 5x time. | 00:18 |
| Peng | Pushing now. | 00:20 |
| mkanat | Peng: Once it's live, an easy way to test would be to open several tabs that would all build a revision graph cache at once, for one branch. | 00:22 |
| mkanat | Peng: That seems to be what people were doing that caused the hangs. | 00:22 |
| mkanat | Peng: It has to be on a huge branch though, like launchpad or bzr itself or mysql. | 00:23 |
| Peng | Mm. | 00:24 |
| Peng | It's totally _possible_ for someone to do the same thing to several different branches of LP or MySQL, just even less likely./ | 00:25 |
| mkanat | Peng: Yeah. And also, that's a level of concurrency that loggerhead should validly handle. | 00:26 |
| mkanat | Peng: Whereas buliding multiple revision graph caches for the same branch is something that's never necessary. | 00:26 |
| mkanat | Peng: If we see problems across multiple projects, then we can switch to a global semaphore around the per-branch lock. | 00:27 |
| mkanat | Peng: The problem then is that we have to make some judgement about how many caches it's OK to build simultaneously, which we can't really know, and that gets into needless configuration by the admin, and so on. | 00:27 |
| Peng | Plus, it would be a shame to block everyone building a little cache as well. | 00:29 |
| Peng | BBIAB -- Hopefully we didn't just blow anything up. | 00:33 |
| Peng | Yay, nothing exploded. | 01:05 |
| mkanat | Yay. :-) | 01:06 |
| mkanat | Now we see if the hangs keep happening. | 01:06 |
| jam | poolie: bug #507040 looks to me like a missing inventory that is expected to be there | 03:27 |
| ubottu | Launchpad bug 507040 in bzr "NoSuchRevision during "bzr check"" [Medium,Confirmed] https://launchpad.net/bugs/507040 | 03:27 |
| jam | which hints at a stacking issue | 03:27 |
| jam | but it isn't something I've specifically seen | 03:27 |
| === tchan1 is now known as tchan | ||
| === thumper is now known as the-watcher | ||
| magcius | Is there documentation about how bzr works internally? The object format... are full files stored or just deltas. | 03:54 |
| Peng | Both. | 03:54 |
| === the-watcher is now known as thumper | ||
| magcius | Peng, where? | 03:55 |
| Peng | Err, i was answering the second question. :P | 03:55 |
| Peng | It mainly uses deltas, but occasionally throws in a fulltext to keep performance up. | 03:55 |
| magcius | Oh. | 03:55 |
| spiv | magcius: there's some docs in the doc/developers directory | 03:56 |
| spiv | (or http://doc.bazaar.canonical.com/bzr.dev/developers/) | 03:56 |
| spiv | magcius: but they are far from complete on this sort of topic :/ | 03:57 |
| bvk | hi, how do i get combined diff (without using revision numbers) after some "local commits" in a "bzr checkout" directory? | 04:52 |
| spiv | Hmm, possibly "bzr diff :bound" ? | 04:56 |
| bvk | spiv: no, it didn't work :( | 04:58 |
| fullermd | You'd probably need something more like 'bzr diff -rancestor::bound..' I'd guess. | 05:05 |
| StevenK | spiv: Did you get the e-mail that contained my bzr logs? It was sent a while ago. | 05:10 |
| spiv | StevenK: hmm, I think so yes | 05:11 |
| scorp007 | when I make a merge directive, will it contain my log messages that I committed locally with? | 05:50 |
| scorp007 | or does the patch simply forget them and treat em all as one change? | 05:51 |
| bob2 | yes, no | 05:51 |
| scorp007 | oh, so from the merge directive, how can I see/extract the log messages? | 05:51 |
| scorp007 | will it automatically happen when I merge? | 05:51 |
| bob2 | yes | 05:51 |
| scorp007 | ah, great. Out of curiosity, is it possible to view them prior to that? | 05:52 |
| bob2 | don't know, sorry | 05:52 |
| scorp007 | ok, that's fine. Thanks | 05:53 |
| scorp007 | how can I temporarily set my HEAD to an older revision. (not revert, I don't want uncommitted changes) | 06:03 |
| scorp007 | sort of like a svn update -r<old revision> | 06:03 |
| RAOF | bzr branch -r<old revision> old-thing | 06:05 |
| RAOF | Sorry, “bzr branch -r<old revision> current-branch old-revision”. | 06:05 |
| scorp007 | won't that make a new branch? | 06:05 |
| poolie | scorp007: if you have a recent bzr 2.1, you can use update -r | 06:06 |
| scorp007 | otherwise I must make a new branch each time? | 06:06 |
| RAOF | poolie: Interesting. How does that handle allowing you to get back to your old branch? | 06:07 |
| poolie | raof, it only sets the working tree back to an old revision, it doesn't change the branch | 06:07 |
| poolie | so plain update will take you back to the tip | 06:07 |
| RAOF | Hm. That could be useful, yah. | 06:07 |
| poolie | so scorp's question is a bit contradictory: it fulfils the aspect of being like svn update | 06:08 |
| lifeless | poolie: the exit button in tribunal-view-subunit is greyed out for me. | 06:08 |
| poolie | yes :) | 06:08 |
| poolie | it is a placeholder for useful tb buttons | 06:08 |
| poolie | i saw your mail | 06:08 |
| lifeless | ok | 06:08 |
| lifeless | I wasn't sure if it was just me :( | 06:08 |
| lifeless | s/(/) | 06:08 |
| poolie | i don't think it's good for gui programs to default to reading stdin | 06:08 |
| poolie | cos it tends to make them just sit there waiting for stuff | 06:09 |
| scorp007 | poolie, I'm not sure I understand. | 06:09 |
| mneptok | lifeless: you should use that as the title for your memoirs. | 06:09 |
| poolie | i'd be happy to have it understand '-' as an argument though | 06:09 |
| lifeless | poolie: oh, ok. I did that because of the module docstring. | 06:09 |
| scorp007 | I made a new branch as a copy from my main one -- I want to simulate a merge using a merge directive | 06:09 |
| mneptok | s/(/) | 06:09 |
| scorp007 | but my copy is alreadt at the latest verison | 06:09 |
| lifeless | poolie: 'Reads a subunit stream from stdin ...' - I figured it was a bug I was fixing for you :) | 06:09 |
| poolie | heh | 06:10 |
| poolie | anyhow i'll look at merging it | 06:10 |
| lifeless | poolie: yeah, - would be better. | 06:10 |
| poolie | i'd like to eventually give it commands to open files and to run subprocesses | 06:11 |
| lifeless | poolie: what I /wanted/ was for no-args to not crash with an IndexError, and to put in the testrepository support | 06:11 |
| poolie | :-) | 06:11 |
| poolie | as another comment notes, reading from a pipe will suck a bit until it's done asynchronously | 06:11 |
| lifeless | I'm going to have dinner with scott, see you tomorrow | 06:11 |
| lifeless | poolie: if you want code to read from a pipe asynchronously in gtk | 06:11 |
| poolie | oh ok | 06:11 |
| poolie | say hi for me please | 06:11 |
| lifeless | poolie: see subunit2gtk - it has code to do that. | 06:12 |
| poolie | ok | 06:12 |
| lifeless | feel free to liberate and repurpose to your hearts desie | 06:12 |
| lifeless | s/ie/ire/ | 06:12 |
| lifeless | mneptok: econtext | 06:12 |
| poolie | k | 06:12 |
| * lifeless is gone | 06:13 | |
| poolie | thanks for the imports spiv | 07:12 |
| vila | hi all ! | 07:30 |
| poolie | hi vila | 07:39 |
| vila | hey poolie ! | 07:39 |
| _Andrew | Is there something like svn's propset in bzr? I want to insert the revision number into a file | 08:00 |
| poolie | _Andrew: http://wiki.bazaar.canonical.com/KeywordExpansion | 08:03 |
| poolie | vila, circular imports are hurting me :/ | 08:32 |
| vila | where ? | 08:32 |
| poolie | i want to set ui.ui_factory to be an instance of the TextUIFactory | 08:32 |
| poolie | but that's declared in a submodule of ui of course | 08:32 |
| vila | hmm, setting a global instance is always tricky, generally you need to involve a call somewhere to add some lazyness in the loop | 08:33 |
| vila | If you can't.... you need to rethink your design :D | 08:34 |
| poolie | mm | 08:35 |
| poolie | good night | 08:52 |
| bialix | heya bzr | 09:42 |
| vila | hi bialix | 09:48 |
| bialix | hi vila | 09:48 |
| quicksilver | vila: I'm fairly sure my solution worked. I have pushed the clean branch to our repository. | 09:51 |
| quicksilver | vila: it seems to merge cleanly with other related branches, which is the main test. | 09:51 |
| quicksilver | (if I'd done it wrong, merges would be expected to cause conflicts) | 09:51 |
| vila | http://instantrimshot.com/ | 09:51 |
| quicksilver | vila: I'm just writing up a report for the mailing list, although I have plenty of work to do so I might not email it for a day or two. | 09:51 |
| vila | quicksilver: great ! as long it comes in, I'm happy | 09:52 |
| bob2 | f/win29 | 09:52 |
| bob2 | bah | 09:52 |
| === loxs_wrk is now known as loxs | ||
| === mrevell is now known as mrevell-lunch | ||
| jkprg_ | hi! I want to implement central shared repository. How could I prevent someone will delete the repository? Thx | 13:01 |
| === jkprg_ is now known as jkprg | ||
| === gnomefreak is now known as thunderstrck | ||
| === thunderstrck is now known as gnomefreak | ||
| === gnomefreak is now known as gnomefreak76 | ||
| === gnomefreak76 is now known as gnomefreak | ||
| === gnomefreak is now known as gnomefreak76 | ||
| === gnomefreak76 is now known as gnomefreak | ||
| === mrevell-lunch is now known as mrevell | ||
| davertron | hi guys, if i have a branch with a working tree, and i want to create a "central" branch with no working tree from that branch, how do i do that? | 14:19 |
| jam | davertron: 'bzr push' or 'bzr branch --no-tree" | 14:21 |
| davertron | bzr: ERROR: no such option: --no-tree | 14:21 |
| Toksyuryel | What version of bzr are you using? | 14:22 |
| davertron | i'm using 1.12 | 14:22 |
| davertron | maybe too old? | 14:22 |
| Toksyuryel | Ancient | 14:22 |
| davertron | figures | 14:22 |
| wundo | Hi, right now I have an SVN repository with tons of data (and over 5k revisions), I'm willing to change to BZR, but I'm not sure how to deal with access control. Could someone give me some guidance please? | 14:37 |
| rubbs | wundo: really the only way to deal with access control is to do it at the system level. | 14:38 |
| rubbs | wundo: due to the distributed nature of DVCS, commit-access isn't as much of an issue at the repo level (since everyone gets their own repo). | 14:39 |
| rubbs | so the only way to really stop write access is to do so at the system level. | 14:39 |
| wundo | I'm willing to use bzr with a centralized workflow... And I'm willing to prevent people from reading certain directories too, not only writing. | 14:40 |
| quicksilver | I don't think bzr works well with people only having access to certain directories? | 14:41 |
| quicksilver | in my experience you always get a whole branch. | 14:42 |
| rubbs | exactly | 14:42 |
| rubbs | if you're looking for per-directory/per-file permissions, you'd have to split up the repo | 14:42 |
| rubbs | bzr doesn't allow for partial checkouts | 14:42 |
| wundo | hmm... | 14:43 |
| MvG | Hi! Do I see this correctly that there is no "commit --amend" for bzr, as there is for git, and that I'd have to uncommit and commit manually to get a similar effect? | 14:44 |
| MvG | If so, would you agree that this would be a nice feature to have, should be feasible, and would warrant a request for enhancement in lp? | 14:44 |
| rubbs | MvG: you are correct there is no commit --amend | 14:45 |
| rubbs | there has been debate IIRC about that feature. | 14:45 |
| wundo | another question, most of the people work from our office, is possible to have an local mirror from the central repository where the people can commit/checkout their code without using our internet connection? | 14:46 |
| rubbs | yes | 14:47 |
| rubbs | this is how bzr was designed | 14:47 |
| rubbs | they each can have their own repo as a copy of the "central" branch | 14:47 |
| MvG | rubbs: There was some discussion back in 2007 for editing the comment: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/21558 | 14:48 |
| wundo | I mean, there are 5 people in our LAN, but our internet connection is off... assuming user A has new changes he wants to share it to user B. Could he commit to a local server from which user B can checkout and when the internet is back on the local server seamless synchronizes with the external server? | 14:50 |
| rubbs | MvG: I am not a dev... but as I recall the biggest problem with doing an amend is that changing history at all can screw up with some other people's things. | 14:50 |
| rubbs | wundo: yes | 14:50 |
| rubbs | wundo: you can push and pull to different locations | 14:50 |
| MvG | rubbs: As can uncommit, and it's still there, and I'm glad it is. Rule is, once you pushed something, then changing it can cause divergence. Nothing new there. | 14:50 |
| wundo | rubbs: any how to setup it available? | 14:51 |
| rubbs | wundo: when you branch from the central repo,bzr would remember that repo, but you could tell it to pull, push , or merge from another one quite easily. | 14:51 |
| rubbs | wundo: http://doc.bazaar.canonical.com/bzr.2.0/en/ | 14:51 |
| rubbs | check them out that might help | 14:51 |
| rubbs | MvG: good point | 14:52 |
| rubbs | MvG: you could try requesting it again. | 14:52 |
| MvG | Will do so. | 14:52 |
| rubbs | wundo: if you are looking for a pseudo-centralized workflow check out this: http://doc.bazaar.canonical.com/bzr.2.0/en/tutorials/centralized_workflow.html | 14:53 |
| quicksilver | uncommit loses the commit message though I think? | 14:53 |
| quicksilver | minor disadvantage of it. | 14:53 |
| rubbs | quicksilver: yes, it does... that's why he want's an ammend. | 14:54 |
| rubbs | amend* | 14:54 |
| * quicksilver nods | 14:54 | |
| jam | morning vila, rubbs and quicksilver | 14:54 |
| quicksilver | morning jam. | 14:54 |
| jam | quicksilver: I thought there was a hook that preserved uncommit | 14:54 |
| jam | check with vila / qbzr | 14:54 |
| vila | mornign jam | 14:54 |
| quicksilver | you're more likely to be right than me jam ;) | 14:54 |
| quicksilver | the very very long message I'm writing to the bzr mailing list does mention this point as an aside. | 14:54 |
| jam | I don't think 'bzr commit' defaults to reusing it, but certainly "bzr qcommit" can remember something | 14:55 |
| vila | AFAIK both bzr-gtk and qbzr saves commit/uncommit messages in branch.conf | 14:55 |
| rubbs | Morning | 14:55 |
| === salgado is now known as salgado-lunch | ||
| rubbs | MvG: wundo: I have to go to a meeting, but others here can help if you have any other questions. | 14:56 |
| vila | another trick is to have a qlog running around and copy/paste from there | 14:56 |
| wundo | thanks rubbs | 14:56 |
| wundo | still is not an one hour decision to change a whole company VCS :P | 14:57 |
| wundo | I will probably be here when you come back... | 14:57 |
| MvG | I'm also copy and pasting from console output, but that's not nice. Writing a lp whishlist item for commit --amend just now. | 14:57 |
| vila | MvG: search for duplicates instead and click the affects me too button instead | 15:01 |
| vila | MvG: I'm 80% sure this has been reported | 15:01 |
| MvG | vila: I did search, and found nothing. | 15:01 |
| vila | ok, thks for trying :D | 15:02 |
| MvG | Problem is, it's kind of difficult to find suitable terms for it. | 15:02 |
| MvG | Does lp do a full text search? | 15:02 |
| vila | when you file a bug, lp does a pretty good search, details available at #laundpad-dev :) | 15:04 |
| phinze_ | hey folks, does anybody have a second to look at this 8 lines of error and tell me if this might be a fluke... http://gist.github.com/277228 | 15:10 |
| === phinze_ is now known as phinze | ||
| doctormo | Using bzrlib, What's the best way to check if a local working tree has commits which are not pushed (assuming push_location is set) | 15:12 |
| jam | anyone know if John Whitley hangs out on IRC? | 15:14 |
| jam | phinze: that looks like a really low-level failure | 15:15 |
| jam | as it means "import os" is failing | 15:15 |
| jam | do you have a "posix.py" file somewhere in your path? | 15:15 |
| phinze | that's what i figured -- we run bzr every minute in a cron job and that came up once last night -- so there is much room for flukes | 15:15 |
| jam | (some platforms accidentally set things up to include the current working dir in the python search path.) | 15:16 |
| jam | phinze: could the system have been updating itself? | 15:16 |
| phinze | python -> 'import posix' works fine | 15:16 |
| phinze | jam: mmm good thought | 15:16 |
| vila | it doesn't help that '' in PYTHON_PATH also means add current directory | 15:17 |
| phinze | might want to see what other cron jobs run on our build server and pause all the bzr activity for that time | 15:17 |
| jam | doctormo: last_local_rev = wt.branch.last_revision(); push_url = wt.branch.get_push_location(); push_branch = bzrlib.branch.Branch.open(push_url); push_last_rev = push_branch.last_revision() | 15:17 |
| phinze | so, tentative conclusion is -- not really bzr's job to handle that sort of error? | 15:18 |
| jam | if last_local_rev == push_last_rev: then you know there is nothing to do | 15:18 |
| jam | otherwise you may have local changes, or remote may have changes | 15:18 |
| jam | you can use graph = wt.branch.repository.get_graph(push_branch.repository) | 15:18 |
| doctormo | jam: I see, what if we assume that remote doesn't have changes. | 15:18 |
| vila | phinze: so far, the occurrences have been rare enough that the bug hasn't been fixed (there is one I can't remember the # just now ) | 15:19 |
| jam | graph.find_difference() if you care about both sides | 15:19 |
| jam | or | 15:19 |
| doctormo | jam: See what would be good is to be able to say "Have there been any commits after the last push command" | 15:19 |
| jam | graph.find_unique_ancestors(local_rev, [push_rev]) | 15:19 |
| jam | doctormo: well, if the local revision is different than remote | 15:19 |
| jam | and nobody else updates remote | 15:19 |
| jam | then yes | 15:19 |
| jam | there must be something to push | 15:19 |
| phinze | vila: sounds good -- initial bug searches for the text of my error weren't yielding much | 15:19 |
| phinze | at the end of the day i'm not too worried either | 15:20 |
| doctormo | jam: OK, if that's the only way, I just want to avoid remote requests if I can. | 15:20 |
| jam | doctormo: if you are writing your own stuf | 15:20 |
| jam | you can save the revision at push time | 15:20 |
| === CardinalXiminez_ is now known as CardinalFang | ||
| jam | using something like a "post_branch_tip_changed" hook | 15:20 |
| jam | however, *bzr* does not track that | 15:21 |
| jam | it doesn't save a 'this branch was pushed at this revision' anywhere | 15:21 |
| jam | I think there is also a post_push hook, if you just wanted to trap that | 15:21 |
| doctormo | I see, then perhaps I should do a bit of code to track and then fall back on discrepency | 15:21 |
| MvG | vila: https://bugs.launchpad.net/bzr/+bug/507529 | 15:33 |
| quicksilver | Is there a command-line way to get the nearest common ancestor of two branches? | 15:36 |
| vila | quicksilver: 'bzr merge --preview --show-base' may not be the pretiest, but from command-line... it's the only way I can think of | 15:39 |
| vila | there was an approximate command in bzrtools at one point but I'm pretty sure it's not up to date | 15:40 |
| DaffyDuck_` | I want to set up a few potential complicated ignore-rules. Anyone here proficient in ignores with regular expressions? | 15:41 |
| quicksilver | vila: Hmm. Bzr is very clever but it's a bit hard to get the information out of it sometimes. I suppose you're expected to use bzrlib. | 15:42 |
| quicksilver | vila: do any of the visualisation tools help you visualise the relationship between a bunch of branches? | 15:42 |
| vila | quicksilver: bug filing time ! :D | 15:43 |
| DaffyDuck_` | I have an /src directory in a project which contains lots of files and directories. I want to ignore everything in there, with a few (something like 10) exceptions, which I want to track. | 15:43 |
| vila | qlog accepts seveal branches as input like : bzr qlog b1 b2 b3 | 15:43 |
| vila | quicksilver: it then display special tags for the tips and doing a very good job at displaying the multiple heads | 15:43 |
| quicksilver | vila: but still shows you all the revisions doesn't it? | 15:43 |
| vila | quicksilver: if the branches diverge a lot it becomes harder to track though | 15:44 |
| MvG | What are ghosts? | 15:44 |
| MvG | Is there some kind of document (wiki page, source file, mailing thread) that I could read to get an idea about what ghosts are and how different parts of bzrlib deal with them, i.e. which parts take care of them themselves and which expect the caller to deal with them? Or could you tell me in a few lines here? | 15:44 |
| MvG | Might be important to get support for them into trac-bzr one day, I'm not sure. | 15:44 |
| vila | quicksilver: qlog default to masking most of the merged revisions but you can then open the ones marked with a '+' | 15:44 |
| vila | an close the ones marked with a '-', obvious when you use, akward to describe :) | 15:45 |
| quicksilver | vila: sure. The thing is all I want is an overview which shows branches and all of their nearest common ancestors. | 15:46 |
| quicksilver | vila: so I can see what branched from where, when. | 15:46 |
| quicksilver | I don't want ot see individual revs at all | 15:47 |
| vila | then definitely give a try to bzr qlog **/* or whatever | 15:47 |
| vila | that's the closest I can think of | 15:47 |
| vila | you will see the revs but one line for each but that's the best we have to present a *graph* with multiple heads so far | 15:48 |
| quicksilver | vila: *nod* | 15:49 |
| MvG | DaffyDuck_`: Simply ignore the whole dir and add the files you want to track. Ignore only affects untracked files; once you told bzr about the ones you are interested in, it will track them. | 15:49 |
| quicksilver | vila: I don't really like GUI toolkits. | 15:49 |
| quicksilver | vila: I was thinking of something a bit more elegant like a .dot file or a PDF file or something :) | 15:49 |
| vila | quicksilver: I use almost no GUI myself *except* qlog | 15:49 |
| MvG | quicksilver: You want to write a bzr plugin generating dot output? | 15:50 |
| jam | vila: giving qlog a repo will do everything underneath, I don't know about a plain dir | 15:50 |
| quicksilver | MvG: no, I want someone else to :P | 15:50 |
| jam | quicksilver: there is also "graph-ancestry" from bzrtools | 15:50 |
| vila | quicksilver: I've played with .dot files and intend to replay with one day.... when time permits | 15:50 |
| MvG | quicksilver: You want to pay someone else to... doesn't matter, still no time... | 15:50 |
| jam | which does generate DOT output | 15:50 |
| jam | or PNG (generated from DOT), etc | 15:50 |
| quicksilver | jam: that looks promising :) | 15:51 |
| vila | quicksilver: how many revisions in your repo ? (all revisions not only the mainline ones) | 15:51 |
| jam | I think it can also take a revision range | 15:51 |
| quicksilver | vila: 2000 or so? I'm not sure | 15:51 |
| jam | You may have to tweak it if you want specific information | 15:51 |
| vila | last time I played I started with graph-ancestry but my graph was too big but it was a decent starting point | 15:52 |
| jam | I think it handles 2 branches, but not more than that | 15:52 |
| jam | vila: I think it now supports giving a range of revisions so you don't have to graph the whole thing | 15:52 |
| quicksilver | ah, right. So not quite what I'm after but definitely thinking in the right direction. | 15:52 |
| jam | quicksilver: IME dot doesn't like graphs with more than ~100 revs | 15:52 |
| jam | 100 nodes | 15:52 |
| quicksilver | jam: I only want a node per 'most-recent-ancestor' really | 15:52 |
| vila | from memory I'd say 2000 will blow away graph-ancestry (or give you a result you can't really use) | 15:52 |
| vila | jam: qlog or graph-ancestry ? | 15:53 |
| quicksilver | so I'm talking 20 branches and 20 MRAs at most, I think. | 15:53 |
| jam | I tried using it with a 100k object graph... and after 8 hours an 2GB of memory... it still hadn't finished formatting to -Tplain | 15:53 |
| jam | vila: graph-ancestry | 15:53 |
| jam | dot itself doesn't handle lots of nodes very well | 15:53 |
| jam | it would probably be better with revision graphs, since there is less cross-linking and no cycles | 15:53 |
| jam | unlike object reference graphs | 15:54 |
| quicksilver | well something else to think about next time I have free time... | 15:55 |
| quicksilver | not immediately clear how you find the right set of MRAs either | 15:55 |
| quicksilver | although I'm sure it should be clear. | 15:56 |
| === beuno is now known as beuno-lunch | ||
| === raimue is now known as Raim | ||
| === salgado-lunch is now known as salgado | ||
| === beuno-lunch is now known as beuno | ||
| quicksilver | can loggerhead cope with multiple bzr branches or is that a launchpad feature? | 17:09 |
| quicksilver | when I say 'cope with' I mean have some idea of the relationship between, I suppose. | 17:09 |
| beuno | quicksilver, what do you mean by a relationship? | 17:12 |
| quicksilver | well the fact that one branch is a branch of the other | 17:12 |
| quicksilver | they're not just two unrelated lumps of code. | 17:12 |
| beuno | so, the loggerhead instance running on Launchpad is the same one as trunk (minus some glue) | 17:13 |
| quicksilver | beuno: I'm not quite clear how much of what I look at is generated by launchpad and how much by loggerhead | 17:17 |
| quicksilver | beuno: for example : https://code.launchpad.net/loggerhead | 17:17 |
| quicksilver | beuno: is that page launchpad or loggerhead? | 17:18 |
| beuno | quicksilver, launchpad | 17:19 |
| * quicksilver nods | 17:19 | |
| quicksilver | beuno: but this one is loggerhead: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/files I presume? | 17:20 |
| beuno | quicksilver, correct | 17:20 |
| beuno | anything UI under http://bazaar.launchpad.net is loggerhead | 17:20 |
| beuno | I suspect that what you want isn't part of loggerhead, but it may not be too hard to do | 17:20 |
| * quicksilver nods | 17:21 | |
| quicksilver | loggerhead looks like a 'branch inspector' so it inspects one branch at a time. | 17:21 |
| beuno | yes it does | 17:22 |
| beuno | within a directory | 17:22 |
| beuno | but you can infer some relationship with commid revids and parent URLs | 17:22 |
| beuno | launchpad is different, because it stuffs everything into a DB :) | 17:22 |
| * quicksilver nods | 17:23 | |
| jkprg | hi. how to protect shared (centralized) repository against deleting or corrupting? | 17:59 |
| Peng | Don't give people write access to it. | 18:01 |
| Peng | Seriously, though. If you use stacked branches, that's a viable solution. | 18:01 |
| jkprg | Peng: Stacked branches? I have to read about it | 18:02 |
| Peng | That's what Launchpad does, FYI. | 18:06 |
| Peng | Stacking policy, too. | 18:06 |
| jkprg | Peng: Is there no need to have write access to whole shared repository to push changes? | 18:08 |
| Peng | jkprg: If you use stacked branches, it's not necessary. | 18:08 |
| jam | jkprg: one option is that you also only need read access to existing objects | 18:10 |
| jam | so once a transfer finishes, you could mark all files in .bzr/repository/packs and indices as readonly | 18:10 |
| jam | (note that new ones will get created, old ones get moved to obsolete_packs and eventually deleted...) | 18:11 |
| === vxnick_ is now known as vxnick | ||
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| === vxnick_ is now known as vxnick | ||
| guilhembi | jam: hello! thanks for the explanation about "bzr log" order constraints; I understand (1), but not (2): | 20:05 |
| guilhembi | "2) We also output a revision after the last revision which did not have it in | 20:05 |
| guilhembi | the ancestry. | 20:05 |
| guilhembi | what is "it"? | 20:05 |
| === salgado is now known as salgado-afk | ||
| jam | guilhembi: hi | 20:27 |
| jam | so if you have revs A B C. | 20:27 |
| jam | If B is in the ancestry of C, but not in the ancestry of A | 20:27 |
| jam | then B will appear in the log output between A & C | 20:27 |
| jam | if you go back to the graph I put up on the bug | 20:27 |
| jam | I detailed the difference between that an just 'topological' | 20:28 |
| guilhembi | jam: I promised I read it, I saw "(2) says that C E G" | 20:29 |
| guilhembi | but I cannot parse (2) | 20:29 |
| guilhembi | could (2) mean: a revision is always after the last revision which didn't have it in its ancestry... | 20:30 |
| guilhembi | could (2) mean: a revision is always after the last revision which isn't a child of it? | 20:30 |
| guilhembi | No, that wouldn't imply that "that C E G has to come after F ". | 20:31 |
| jam | C has to come after F because F does not have C in the ancestry | 20:32 |
| jam | is that an easier way to see it? | 20:32 |
| jam | A revision X will appear in the log after all revisions which do not contain X in their ancestry | 20:33 |
| guilhembi | jam: but I could also say "F has to come after C because C does not have F in its ancestry"...? | 20:33 |
| jam | guilhembi: left ancestry first :) | 20:33 |
| jam | something has to come first | 20:34 |
| jam | let me think of a way to word it | 20:34 |
| guilhembi | jam: I'm grateful for the current effort to phrase that! | 20:34 |
| jam | back in a sec | 20:35 |
| jam | a revision X will appear before any child revision Y (topological), further if Y's left-hand parent (Z) does not contain X, then X will appear between Z and Y in the output | 20:53 |
| jam | guilhembi: how's that? | 20:53 |
| * guilhembi reads and reads again | 20:56 | |
| guilhembi | jam: "a revision X will appear before any child revision Y" | 20:56 |
| guilhembi | no, children appear first (newest revision on top) | 20:56 |
| jam | guilhembi: I always draw time downwards (--forward) | 20:57 |
| jam | you can reverse the statement | 20:57 |
| jam | a revision X will appear after any child revision Y (topological), further if Y's left-hand parent (Z) does not contain X, then X will appear between Y and Z in the output | 20:57 |
| jam | Note that the graphs in the bug report are also directed that way, in case you had some confusion there as well | 20:58 |
| jam | A is the *first* commit | 20:58 |
| guilhembi | yes, I had understood graphs in the proper way. Re-reading the new sentence now... | 21:01 |
| guilhembi | Testing that sentence on various examples posted in the bug report... | 21:03 |
| guilhembi | matches your A B D F C E G H example... | 21:04 |
| lifeless | moin | 21:04 |
| guilhembi | matches the example for which I had posted a postscript file... | 21:09 |
| guilhembi | jam: your explanation looks quite good. However I'm not sure it adresses defining the initial set of nodes on which the rules apply (from the bug report): | 21:10 |
| guilhembi | <quote> | 21:10 |
| guilhembi | if you have this graph: | 21:11 |
| guilhembi | A | 21:11 |
| guilhembi | | \ | 21:11 |
| guilhembi | B C | 21:11 |
| guilhembi | | / | 21:11 |
| guilhembi | D | 21:11 |
| guilhembi | then "bzr log -rB..D -n0" shows | 21:11 |
| guilhembi | D | 21:11 |
| guilhembi | C | 21:11 |
| guilhembi | B | 21:11 |
| guilhembi | but "bzr log -rC..D -n0" shows | 21:11 |
| guilhembi | D | 21:11 |
| guilhembi | C | 21:11 |
| guilhembi | See, it's assymetric: the "mainline" property of the starting point of the -r range, influences how many revisions you see (3 versus 2). | 21:11 |
| guilhembi | </quote> | 21:11 |
| guilhembi | (A is the first revision). | 21:11 |
| guilhembi | ? | 21:11 |
| guilhembi | I'm not sure this is covered by the "left-hand" piece of your explanation. | 21:12 |
| guilhembi | Depends on what graph subset this piece applies. | 21:12 |
| guilhembi | Apparently it's not "all nodes on all paths from X to Y" (for -rX..Y), as for -rB..D it would mean B,D (only those two nodes are on the paths), | 21:14 |
| guilhembi | and "bzr log -n0 -rB..D" also shows C. | 21:14 |
| guilhembi | guilhembi: I'm off to bed and that will log me out. If you like, you can reply in the bug report or to my mail. Thanks for the help and patience! | 21:15 |
| guilhembi | jam: I'm off to bed and that will log me out. If you like, you can reply in the bug report or to my mail. Thanks for the help and patience! | 21:15 |
| * guilhembi talks to himself, thus is tired | 21:15 | |
| === ubottu is now known as ubott2 | ||
| guilhembi | jam: In other words: the bug report is maybe more about "what set of nodes do I see and how does -n0 influence that?", rather than "in what order do I see those nodes?". I understand that the order has to be non-trivial for humans, because it's a serialized graph; but the set could be interest for humans. | 21:35 |
| guilhembi | good night | 21:35 |
| jam | guilhembi: night. if you take the serialized order and then just start and stop, then I think it works out | 21:36 |
| jam | your graph orders to "A B C D" given my rules | 21:36 |
| jam | (or D C B A) | 21:36 |
| guilhembi | jam: ah, ok, looks good then. | 21:36 |
| guilhembi | jam: I'll think more about it. Bye and thanks again. | 21:36 |
| guilhembi | jam: ah, and also, the influence of -n0... | 21:37 |
| guilhembi | see you later. | 21:37 |
| jam | morning lifeless | 21:39 |
| jam | lifeless, do you know if spiv is officially on parent leave now? | 21:40 |
| jam | he mentioned he was "likely going" this week | 21:40 |
| jam | but I didn't get a "I have a new baby" email. | 21:40 |
| lifeless | jam: they are overdue I think | 21:46 |
| lifeless | jam: I haven't heard a pop,squall yet. | 21:46 |
| thumper | lifeless: hey | 21:47 |
| thumper | lifeless: when are you arriving in wellington? | 21:47 |
| lifeless | tomorrow 2pm | 21:48 |
| lifeless | jml: btw 'testr failing' works now. | 21:48 |
| thumper | lifeless: bumped into pia this morning and she was asking if you were here yet | 21:48 |
| lifeless | heh | 21:48 |
| lifeless | I'm fairly sure she can see on tripit. | 21:49 |
| lifeless | all this web2 stuff ... | 21:49 |
| thumper | i have some kudos to hand out to all you guys | 21:49 |
| lifeless | nice! what flavour? | 21:49 |
| thumper | I was going to wait for poolie to give the report though | 21:49 |
| thumper | that way, I won't have to repeat myself again | 21:50 |
| * lifeless summons poolie | 21:50 | |
| thumper | lifeless: nice kudos | 21:50 |
| lifeless | ... | 21:50 |
| lifeless | nope didn't work | 21:50 |
| * mneptok pulls on his full-head latex Martin Pool mask | 21:51 | |
| lifeless | mneptok: 'ew' | 21:51 |
| mneptok | one moment. can't find my panty hose and nipple-clamps. | 21:52 |
| mneptok | attention everyone! we are rechristening the project "Bizarre Revision Control" | 21:52 |
| lifeless | mneptok: you are aware that we have minors in this channel ? :) | 21:52 |
| lifeless | And I don't mean the birds. | 21:52 |
| Peng | Right. You better wear pasties under those nipple clamps. | 21:53 |
| mneptok | "Even the ravens are calling my name," thought Caw. | 21:53 |
| mwhudson | mneptok: btw | 21:53 |
| mwhudson | mneptok: have you seen http://uncyclopedia.wikia.com/wiki/Ubuntu recenty? | 21:53 |
| mneptok | mwhudson: ? | 21:53 |
| mneptok | mwhudson: is my picture removed? | 21:53 |
| mwhudson | mneptok: no | 21:54 |
| mneptok | oh good. | 21:54 |
| mneptok | that's been there for *ages* | 21:54 |
| mwhudson | mneptok: did you add it, by any chance? | 21:54 |
| mneptok | no. | 21:54 |
| lifeless | mwhudson: lol | 21:54 |
| mwhudson | i edited the caption | 21:54 |
| mneptok | the actual caption is "My hair is luxurious. Touch it." | 21:55 |
| mwhudson | mneptok: it's a wiki! | 21:55 |
| lifeless | thumper: go here: https://code.edge.launchpad.net/~subunit/subunit/trunk . click on '1 branch proposed for merging'. | 21:56 |
| lifeless | thumper: I think this is my #1 code complaint at the moment. | 21:56 |
| jam | lifeless: ouch | 21:57 |
| thumper | lifeless: but if I fix that, you'll just get another #1 code complaint | 21:57 |
| jam | you can select "needs review" on that page, though | 21:57 |
| thumper | lifeless: is there a bug for that? | 21:57 |
| thumper | it is trivial | 21:57 |
| mneptok | mwhudson: OK, OK. i done it. | 21:58 |
| jam | of course: https://code.edge.launchpad.net/~bzr-pqm/bzr/bzr.dev/+merges has 320 results on it | 21:58 |
| lifeless | thumper: there is a bug for it | 21:58 |
| lifeless | thumper: and you even commented on it :) | 21:58 |
| thumper | lifeless: I was hoping you'd give me a number | 21:58 |
| mwhudson | mneptok: :-) | 21:58 |
| mwhudson | thanks | 21:58 |
| * bigjools waves at mneptok | 22:00 | |
| mneptok | bigjools: ahoyhoy | 22:01 |
| * mneptok tootles off to run some errands | 22:02 | |
| thumper | lifeless: when does poolie normally turn up? | 22:08 |
| lifeless | before now | 22:09 |
| lifeless | why don't you put your news in a bufer | 22:09 |
| lifeless | and paste it ;) | 22:09 |
| lifeless | thumper: bug 490139 | 22:11 |
| ubottu | Launchpad bug 490139 in launchpad-code "'X branches proposed for merging' goes +merges not +activereviews on branch page" [Undecided,New] https://launchpad.net/bugs/490139 | 22:11 |
| lifeless | thumper: I was wrong, Aaron has commented on it, not you. | 22:13 |
| === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://bazaar.canonical.com/ | http://irclogs.ubuntu.com/ | Patch pilot: jam | bzr 2.1.0b4 and 2.0.3 released | ||
| poolie | hi all | 22:15 |
| thumper | Firstly a big kudos to all bzr devs, with extra to jelmer | 22:18 |
| thumper | last night we were at a local pug meeting where most non-lp devs used git | 22:18 |
| thumper | we gave an on the fly demo of bzr (pushing to lp and code reviews) | 22:18 |
| thumper | the question was asked about a nice gui | 22:18 |
| thumper | we said "bzr explorer is awesome" | 22:18 |
| thumper | the question came - "does it have a pluggable back end?" | 22:18 |
| thumper | we said "bzr is a pluggable back end" | 22:19 |
| thumper | we decided that with bzr-git installed, bzr explorer should work on a git repo | 22:19 |
| thumper | so I did a git clone of one of their local works | 22:19 |
| thumper | installed bzr-git from the repos and (bzr explorer) | 22:19 |
| thumper | died due to me using bzr-nightly ppa | 22:19 |
| thumper | jelmer got the latest and greatest dulwich and bzr-git on my laptop | 22:19 |
| thumper | went into the git repo and did "bzr explorer" | 22:19 |
| thumper | it worked!!! | 22:19 |
| thumper | it was a great smug moment | 22:19 |
| * thumper hands out kudos to bzr devs | 22:19 | |
| mwhudson | it was also a 300 meg git repo with 15000 revisions | 22:19 |
| mwhudson | and it was pretty fast | 22:19 |
| bigjools | I was very surprised at how fast it was | 22:20 |
| lifeless | thumper: yeah that kind of thing is real nice | 22:21 |
| lifeless | thumper: I remember doing a lightning talk @ europython, showing bzr-hg (written that afternoon) doing bzr-viz | 22:22 |
| lifeless | thumper: is there a secondly? | 22:24 |
| thumper | no | 22:24 |
| thumper | it was just the start of the message | 22:24 |
| thumper | there was another thing | 22:24 |
| thumper | but it was more LP related | 22:25 |
| thumper | I think our bzr demo helped though | 22:25 |
| thumper | this was at catalyst | 22:25 |
| AfC | I've been using bzr-git to track GTK and GLib. Updating (pulling) is not what I'd call fast, and it seems to be really CPU intensive. But it does work (given that I can use git+ssh://, since git:// doesn't) which is really nice. | 22:28 |
| mwhudson | what we did in explorer only really tested the revision graph stuff | 22:30 |
| jelmer | AfC, what about git:// doesn't work? | 22:30 |
| AfC | jelmer: it crashed, if I remember correctly. | 22:30 |
| lifeless | mwhudson: same as viz :P | 22:31 |
| mwhudson | right | 22:31 |
| lifeless | mwhudson: but ssh, don't tell em | 22:31 |
| mwhudson | we didn't :-) | 22:31 |
| jelmer | AfC: If you can still reproduce, please file a bug. I'm pretty sure most of the crash bugs are gone now | 22:31 |
| AfC | jelmer: [your VCS tools use the same ID-for-foreign-revision mapping mechanism regardless of protocol, right? So given I have a more or less up to date git+ssh:// checkout, I can bzr pull git:// without causing cats and dogs to sleep together. right?] | 22:32 |
| AfC | jelmer: I was using whatever is in the bzr PPA as of, oh, 2 weeks ago? | 22:33 |
| jelmer | AfC: Yes | 22:33 |
| jelmer | AfC: Ah, I think we haven't updated that in a while | 22:33 |
| AfC | jelmer: do you want me to try and reproduce, or do you want me to wait for you to publish a new package? | 22:33 |
| AfC | jelmer: [ready to try right now with $whatever is installed if you want | 22:35 |
| AfC | haha | 22:36 |
| AfC | bzr: ERROR: This operation is not supported by the Git smart server protocol. | 22:36 |
| AfC | that should be | 22:36 |
| AfC | bzr: ERROR: This operation is not supported by the Git not-so-smart server protocol. | 22:36 |
| AfC | (`bzr missing`) | 22:36 |
| jelmer | AfC: I don't think there is anybody updating the bzr-git ppa packages | 22:36 |
| AfC | jelmer: uh, I'm talking about "deb http://ppa.launchpad.net/bzr/ppa/ubuntu karmic main", which I thought was the one we all agreed [after months of email debate] would be the best place to get releases of the current Bazaar ecosystem | 22:38 |
| jam | AfC: according to jelmer, you can only fetch over the git protocol | 22:39 |
| AfC | is that not [no longer, not again] correct? | 22:39 |
| jam | you can't do stuff like log/ compare etc | 22:39 |
| AfC | jam: sure; not critiquing anyone for that (well, other than Git) | 22:39 |
| spiv | jam: still no baby :) | 22:39 |
| jelmer | AfC: I'm not involved in the PPA packaging, but I think only the core set of plugins is packaged there | 22:40 |
| jam | spiv: well probably your wife is :( | 22:41 |
| jam | spiv: anyway, mostly I wanted to check if we should be landing your patches | 22:41 |
| jam | you have 2 mostly-approved ones right now | 22:42 |
| spiv | jam: not yet :) | 22:42 |
| spiv | Yeah, I'll do those now. | 22:42 |
| AfC | jelmer: uh, oh. I thought we had agreed that bzr-$VCS was in that category. | 22:42 |
| AfC | ie the ENDLESS debacles with bzr-svn not working with bzr releases. | 22:42 |
| jam | AfC: atm only bzr-svn is | 22:42 |
| maxb | Has anyone ever set up some system to automatically back up bzr branches when changes are pushed? | 22:43 |
| lifeless | maxb: the autopush plugin? | 22:43 |
| maxb | Will that only catch tip changes? In a perfect world I'd want to catch things like tag changes without a tip change | 22:44 |
| maxb | Though I imagine it might need something like launchpad's custom sftp/ssh server for that | 22:45 |
| spiv | maxb: hmm, probably. I'm not sure if we have a hook point for tag changes, but if not we should fix that. | 22:45 |
| spiv | maxb: FWIW, http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/backup.html suggests the automirror plugin | 22:45 |
| AfC | jam: perhaps someone in the Bazaar team might consider adding bzr-git to that PPA, then. | 22:46 |
| maxb | right... hmm, I'd want it asynchronous from user's pushes | 22:46 |
| jam | AfC: well, until recently bzr-git was quite alpha state, if Jelmer feels it is ready to be in 'production' then we can consider it | 22:48 |
| jam | of course, we'd need someone willing to actually do the packaging | 22:48 |
| maxb | Also I need to come up with some way to make it work for new branches, without manual configuration for each branch | 22:48 |
| AfC | jam: sure. | 22:49 |
| AfC | jam: (but consider people are *using* it out of Karmic, so maybe we can just take "in production" as read) | 22:50 |
| spiv | maxb: hmm, it *might* try to use locations.conf too | 22:51 |
| spiv | maxb: if not that's probably fairly easy to fix. | 22:51 |
| poolie | jam, hi | 22:51 |
| poolie | about https://code.launchpad.net/~mbp/bzr/499637-default-uifactory/+merge/17358 | 22:51 |
| poolie | there are two stages | 22:52 |
| poolie | the first is making SilentUIFactory still be silent and not error if you try to make_output_stream | 22:52 |
| poolie | the second is defaulting to text output if you do no special initialization | 22:52 |
| poolie | which i think would be reasonable | 22:52 |
| poolie | but is a bit blocked by the circular import problem | 22:52 |
| === oubiwann_ is now known as oubiwann | ||
| jam | poolie: I think no progress bars, etc is reasonable without configuration | 23:03 |
| jam | for interactive mode, etc. | 23:03 |
| jam | I don't know, I feel like we have a bit of a "bzrlib.actually_make_things_work()" issue | 23:03 |
| jam | load_plugins, trace.enable_default_logging, install_bzr_command_hooks,... | 23:03 |
| jam | make_ui_factory() | 23:04 |
| jam | If we had a standard function for plugins to call to set up bzrlib as though it was a command-line client | 23:05 |
| jam | that might be the best thing | 23:05 |
| jam | and then put whatever we need to in there | 23:05 |
| jam | instead of telling people ad-hoc that "In 2.1 you need to call these functions to get set up." | 23:05 |
| mwhudson | jam: load_plugins()! | 23:05 |
| poolie | that would avoid the problems of doing it at import time | 23:06 |
| jam | poolie: right, and unless we are going to do the rest of them at "import" time, then I think it makes sense to have a helper function | 23:06 |
| poolie | i wonder if one size fits all? | 23:06 |
| jam | poolie: pass it flags | 23:06 |
| jam | with **kwargs so it is forward & backward compatible | 23:06 |
| jam | when I debug in interactive mode, I generally copy & paste "from bzrlib import branch, trace, ui; trace.enable_default_logging(), ui.ui_factory = ui.make_ui_factory..." | 23:07 |
| jam | as the first line | 23:07 |
| jam | I do wish it was a bit easier | 23:07 |
| poolie | then they could say plugins=False | 23:07 |
| poolie | for examlpe | 23:08 |
| jam | poolie: right | 23:08 |
| poolie | wfm | 23:08 |
| poolie | kwargs, or maybe a dict of options? | 23:08 |
| jam | poolie: kwargs is easier to type | 23:08 |
| jam | but either is ok | 23:08 |
| poolie | but it's a kind of one-shot thing | 23:08 |
| jam | I can always do "foo(dict(a=1,b=2))" :) | 23:08 |
| poolie | i kind of like to keep it as an escape valve | 23:08 |
| poolie | right | 23:08 |
| jam | anyway, time for me to go | 23:09 |
| poolie | k | 23:09 |
| jam | maybe I'll see you later | 23:09 |
| poolie | please send a patch pilot wrapup around the end of your week? | 23:09 |
| === jkprg_ is now known as jkprg | ||
| jelmer | spiv: awesome to finally see the per-file-merge happening | 23:26 |
| spiv | jelmer: :) | 23:27 |
| poolie | hi spiv, jelmer | 23:28 |
| jelmer | hi poolie | 23:28 |
| poolie | lifeless, jml, what's the best place to talk about tribunal-subunit? istm maybe on the overall testtools-dev list? | 23:28 |
| spiv | poolie: or possibly testing-in-python? | 23:29 |
| poolie | mm | 23:29 |
| poolie | i wonder if detailed conversation there would be too intrusive though | 23:29 |
| spiv | poolie: well, so long as you make some noise about tribunal-subunit on t-i-p at some point, I think it'll be worth advertising :) | 23:31 |
| lifeless | poolie: subunit dev has all the relevant people I thik | 23:53 |
| lifeless | poolie: testing-in-python would be good from the wider-audience perspective | 23:54 |
| lifeless | poolie: I don't think there is a testtools-dev specific list, last I saw the list for testtools is testing-in-python | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!