[00:29] <igc> morning
[00:35] <poolie> hi spiv! igc!
[00:59] <igc> hi poolie, spiv, jelmer, lifeless
[01:00] <igc> lifeless, poolie: has anything changed in the PQM setup recently?
[01:00] <igc> I'm getting "ender not authorised to commit to branch http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/ "
[01:01] <lifeless> igc: I haven't asked for any config changes
[01:01] <igc> lifeless, poolie: is that the right branch for 2.1 submits?
[01:01] <lifeless> igc: that is a release branch, which may have a different commit group; have you submitted to 2.1 before?
[01:01] <igc> *s*ender
[01:01] <igc> lifeless: maybe not
[01:01] <lifeless> spm: ^ please check igc is inthe release manager group in the pqm config
[01:02] <spm> igc: yup; you're in the RM group
[01:03]  * spm checks logs...
[01:03] <igc> spm: hmm
[01:04] <spm> igc: how long ago did you submit?
[01:05] <igc> spm: around 11.30pm last night
[01:05] <spm> igc: we need to chat about your working hours... ;-)
[01:05] <igc> spm: http://pastebin.com/EGv3bFy8
[01:05] <igc> spm: :-)
[01:07] <spm> igc: should that be to 'bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1' vs http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/ ?
[01:08] <lifeless> spm: I don't think so, isn't there a mapping section
[01:08] <lifeless> ?
[01:08]  * lifeless really needs to make this totally painless
[01:08] <lifeless> well
[01:08] <lifeless> anyone can do that. lp:pqm. kthanks
[01:09] <poolie> igc that branch looks right to me
[01:09] <spm> [/home/pqm/archives/thelove/bzr/2.1]
[01:09] <spm> publish_to=bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1
[01:09] <spm> published_at=http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1
[01:09] <spm> lifeless: yeah...
[01:09] <poolie> it may need no trailing slash?
[01:09] <poolie> it's incredibly finicky
[01:09] <lifeless> I suspect that that is it
[01:09] <igc> ok, I'll try with no trailing slash
[01:26] <igc> spm, lifeless: that's looking better thanks. Failing now due to a text conflict in NEWS which is much better
[01:26] <spm> heh, for values of "better" :-)
[01:35] <poolie> spm, can you review tuolumne changes at all?
[01:36] <spm> poolie: sure can, I gather that's a review request of your recent one.
[01:37] <bjp> is nested branches the best way to handle multiple branches taht depend on the same branch?
[01:37] <bjp> like multiple programs using a shared library
[01:38] <spm> poolie: *comments*!!!! I'm inclined to auto-approve +1 on that basis alone! ;-)
[01:38] <poolie> spm, yes, :)
[01:38] <igc> poolie: any chance of some 2 minute reviews soon on the 2 trivial patches I submitted yesterday?
[01:38] <poolie> some chance :)
[01:38] <igc> poolie: I want to build a fresh set of CHM files for 2.1 and those patches would be nice
[01:39] <poolie> sure
[01:39] <igc> poolie: one is desktop-link, the other is drop-analytics
[01:39] <igc> poolie: thanks
[01:39] <poolie> igc, sphinx's setup is a bit of a rats' nest
[01:39] <poolie> i love the results
[01:40] <igc> poolie: the desktop link one adds "Desktop Guide" into "Related Links" and moves Developer Docs to the top of the 2nd column fwiw
[01:40] <poolie> yep, i can read it
[01:40] <poolie> i just don't like changing it
[01:41] <igc> poolie: just saving you from running sphinxx to see the results :-)
[01:42] <poolie> +1 on both
[01:42] <poolie> thanks
[01:46] <poolie> spiv, you may have noticed our cup brimmeth over
[01:47] <spiv> :)
[01:48] <spiv> I'll see what I can do.
[01:49] <thumper> what was the name of the plugin that gives general author stats for a branch?
[01:49] <Peng> bzr-stats, IIRC?
[01:53] <thumper> Peng: ta
[02:24] <spiv> poolie: would you like to give a second review to https://code.edge.launchpad.net/~parthm/bzr/138600/+merge/19471 (and its backport to 2.1, https://code.edge.launchpad.net/~parthm/bzr/138600-2.1-mkdir-should-fail-on-invalid-parent/+merge/20199)?  It's short.
[02:50] <marv> so I did a "bzr branch http://svn.digium.com/svn/asterisk/branches/1.4 asterisk-1.4", and it seemed to mostly work, but most of the tags (if i do bzr tags) show their revision as "???", even ones i know are on the 1.4 branch, like 1.4.29
[02:53]  * igc lunch
[02:56] <marv> which is somewhat disappointing because for the most part i'd like to branch off of a certain tag, and then when upstream makes a new release merge in up to the next tag
[02:58] <spiv> marv: that means that your branch doesn't include the revision referred to by the tag
[02:58] <spiv> marv: if you use 'bzr svn-import' to import all the branches and tags, then those revisions should be present in the resulting bzr repo.
[02:59] <spiv> marv: you can always "bzr branch" directly from the relevant svn tag, of course.
[03:00] <spiv> marv: (and if you do it in a shared repository, whether made by 'bzr init-repo' or 'bzr svn-import', it will be much faster to do so than the first fetch from SVN)
[03:08] <marv> but i can still pull new changes from svn after I do an svn-import?
[03:08] <spiv> marv: yep
[03:09] <spiv> marv: just "bzr pull" in an individual branch, or you can re-run 'bzr svn-import' to update the whole set.
[03:09] <marv> I don't really want to run commands like 'bzr branch svn-url' too often, they probably don't appreciate that load on their svn server
[03:13] <spiv> marv: if you do in in a shared repo, most of the data will already have been converted when you make the first branch, so the load should be fairly low.
[03:13] <spiv> Not as cheap as the equivalent SVN command, but not ridiculously larger either.
[03:18] <marv> ah i see now. looks like the tag was modified after it was tagged
[03:30] <marv> guess that makes their tags not really tags
[03:30] <marv> subversion might be a little too free form some times
[03:33] <poolie> spiv, ok
[03:35] <poolie> spiv, parthm, i think we're still finding our way as far as risk/reward for stable updates
[03:35] <poolie> to me this is not a very severe bug
[03:36] <poolie> so worth fixing but perhaps not worth taking the risk of breaking the stable branch
[03:36] <poolie> even if that risk is not very high in absolute terms
[03:36] <poolie> what do you think?
[03:39] <spiv> poolie: I don't feel strongly either way about this change
[03:40] <spiv> poolie: which is probably an argument against the backport :)
[03:44] <poolie> probably
[03:45] <poolie> we should work out how to articulate the line
[03:45] <poolie> for me it should be closer to "prevents you getting stuff done" than "a bit annoying"
[03:45] <poolie> after all we don't backport performance things, generally
[03:45] <poolie> and many of them may have a larger user impact than this bug
[04:05] <spiv> "user impact" is a difficult to quantify concept.
[04:06] <spiv> For instance, I don't think I've ever used 'bzr mkdir', so for me the benefit of this patch would be zero.
[04:06] <spiv> But if there are users that use it daily, then that's a different story.
[04:07] <spiv> In this instance, I don't really have a good idea of where this feature lies in the spectrum of "literally no-one cares" to "some users use it every day".
[04:09] <spiv> With many features it's easier to judge; I think we have a reasonably good idea that e.g. ftp support is used a lot by a small minority (and against a wide variety of servers).
[04:12] <spiv> Anyway, for the mkdir patch, it certainly isn't in the "prevents you getting stuff done" category.
[04:12] <spiv> Or even close to it.
[04:14] <spiv> I'm not sure that performance improvements make a good comparison though, because they are often more wide-ranging patches.  Although they are interesting in that one person's annoying performance may be another's unusable performance.
[04:36] <poolie> that's true
[04:36] <poolie> both parts are true but particluarly that they tend to be more intrusive
[04:44] <spiv> On a completely different topic: http://exogen.github.com/nose-achievements/
[04:45] <spm> poolie: have done a couple of minor fixes (really. minor.) and result set is here: https://pastebin.canonical.com/28557/ if you would like to sanity check the numbers?
[04:46] <poolie> that's cute
[04:48] <poolie> spm it's a bit gross (but not at all your fault) that this is mixing things about bzr on launchpad with things about the bzr project
[04:48] <poolie> is it too gross?
[04:48] <poolie> should we s/bzr/bzrproject/ in my methods, or something like that
[04:49] <spm> poolie: not to my mind. (being gross as in). I think it's fine as is; I'd only advise doing the separation if that'll make stuff easier for you?
[04:50] <poolie> i think it will avoid confusion and it's probably better done now than later
[04:50] <poolie> the numbers look plausible
[04:50] <poolie> thanks for reviewing/fixing it
[04:52] <spm> sounds like a plan; just doing the review write up now which mentions the fixes needed.
[04:55] <poolie> spm so do you want to do these tweaks or should i?
[04:55] <poolie> to be clear, with the renaming, i'm just talking about renaming it in the self.store calls
[04:57] <spm> poolie: probably best if you do it; then it stays in the same branch/merge proposal (I think....)??
[05:00] <poolie> mm
[05:00] <poolie> no, you can just merge your branch with the changes
[05:00] <poolie> lp will see the common ancestry
[05:01] <spm> ha. I just *run* LP, I don't know how to use it. :-D
[05:03] <poolie> so...
[05:03] <poolie> maybe you should do it, for practice? :)
[05:04] <spm> sssh. :-) is pushing atm...
[05:54] <spiv> poolie: I see you are filling in commit messages on your merge proposals... does that mean you have a tool to turn a mp into a pqm request?
[05:54] <spiv> Oh,
[05:54] <poolie> i do :)
[05:54] <spiv> I just saw the mail :)
[05:54] <poolie> it's a bit crude but better than doing it by hand
[05:55] <lifeless> poolie: what are you doing for \n ?
[05:56] <poolie> in pqm?
[05:56] <lifeless> yeha
[05:56] <lifeless> I mean, commit -> mp is fairly lossless
[05:56] <poolie> replacing it with spaces and ennui
[06:08] <poolie> spiv, i agree about 'almost ready' etc
[06:15] <igc> bbl
[07:21] <vila> hi all !
[07:28] <GaryvdM> Hi vila
[07:28] <GaryvdM> Hi all
[07:29] <GaryvdM> Is there a way to make pqm use ssl for the smtp server?
[07:29] <GaryvdM> *bzr-pqm
[07:30] <GaryvdM> So that I can use the gmail smtp server
[07:33] <lifeless> yes
[07:33] <lifeless> bzr help configuration / bzr help email
[07:33] <lifeless> one of those docs the options I think
[07:36] <GaryvdM> Thank lifeless
[07:40] <GaryvdM> Ah - Using the smtp.gmail.com:465 (ssl) does not work, but smtp.gmail.com:587 (TLS) does
[07:45] <fullermd> Port 465 is totally on my "die-already" list   :p
[07:47] <spm> fullermd: it's a long shot; but could you add ports 135-139 inclusive for me on that list? no reason....
[07:49] <fullermd> Oh, those are long since dead to me.
[07:53] <GaryvdM> Hi bialix
[07:53] <bialix> Hi GaryvdM !!!
[07:54]  * spiv calls it a day
[07:54] <vila> spiv: have a nice evening and say hello to Vincent and his mother from me :)
[07:55] <vila> s/from/for/ ?
[08:19] <thumper> what is the easiest way to get the local user from the bzr config?
[08:19] <thumper> using bzrlib
[08:20] <lifeless> look at builtins.py
[08:20] <lifeless> cmd_whoami
[08:20] <thumper> ack
[08:21] <GaryvdM> thumper:
[08:21] <GaryvdM>         config = self.tree.branch.get_config()
[08:22] <GaryvdM>         self.default_author = config.username()
[08:22] <spiv> vila: both "from" and "for" are ok I think, but "for" is the more common choice for that phrase.
[08:22] <vila> spiv: ack ;)
[08:24] <thumper> is there an easy way to extract out the "Eric the Viking" and "eric@vikings.net" from "Eric the Viking <eric@vikings.net>" easily with the config or do I need regex?
[08:25] <lifeless> thumper: use the email parsing module if you need to do that
[08:25] <spiv> There's bzrlib.config.parse_username
[08:25] <vila> thumper: look into config.py
[08:26] <spiv> But... *shudder*.  I'd be inclined to use a proper email parser, like lifeless suggests.
[08:26]  * thumper looks at what launchpad uses
[08:27] <mwhudson> there's something in the email package for it
[08:27] <thumper> email.Utils.parseaddr
[08:27] <thumper> awesome
[08:28] <lifeless> I thik we have our own one because we get weird shit
[08:41]  * bialix waves hi all
[08:45] <igc> hi bialix
[08:45]  * igc dinner
[08:46] <bialix> hi igc, bon appetit
[08:52] <GaryvdM> bialix: for rev 1207 in qbzr trunk. I'm not sure how it looks on windows.
[08:53] <bialix> I can check
[08:53]  * bialix pulling
[08:53] <GaryvdM> bialix: Please let me know if it is not good.
[08:53] <GaryvdM> To see the change, do bzr update -r -2 ; bzr qcommit
[08:54] <bialix> not so fast
[08:59] <bialix> GaryvdM: I don't see anyhing new in qcommit dialog
[08:59] <bialix> GaryvdM: I don't see anything new in qcommit dialog
[08:59] <bialix> I've did: bzr update -r-2; bzr qcommit
[08:59] <bialix> and have usual qcommit dialog
[09:00] <GaryvdM> bialix: press ok
[09:00] <bialix> ok, I see now
[09:00] <bialix> it's a bit too big
[09:00] <bialix> IMO
[09:00]  * bialix preparing screenshot
[09:01] <bialix> I would prefer smaller icon
[09:01] <GaryvdM> Yes - need to resize the icon.
[09:02] <bialix> GaryvdM: http://imagebin.ca/view/2kq8NvOq.html
[09:02] <GaryvdM> bialix: Thanks
[09:03] <GaryvdM> I was hoping that the background would be tool tip yellow
[09:03] <bialix> also I have suggestion about text: IMO better: "...To commit, update the working tree first."
[09:04] <bialix> GaryvdM: there is no tooltip
[09:04] <GaryvdM> I wanted the background of the frame to be yellow.
[09:05] <bialix> ah
[09:05] <bialix> understand
[09:06] <GaryvdM> I also need to make the frame and the textbox the same width.
[09:07] <GaryvdM> Ah - just need to make the textboxes colspan = 2
[09:42] <ahorden> hi, I am setting up a shared resporatory and so far everything works, we can do a push pull checkout commit and worked out of the box with no effort, problem is if I ssh into the centeral server and check the location of the shared resporatory bzr log works fine but there are no files in any of our branches? any ideas? I did a bzr init-repo --no-trees sftp:// and then a bzr init on the indevidual projects. Any ideas why the cent
[09:42] <ahorden> eral server does not keep the files inside the rsporatory?
[09:42] <bob2> that's waht --no-trees does
[09:42] <bob2> and is fine
[09:45] <ahorden> ah thanks bob2, I over looked that, the problem is the server is for development so on a push I wanted the changes to go live, any way I can revert away from --no-trees no I have a running setup?
[09:45] <ahorden> *now
[09:45] <bob2> that doesn't help
[09:45] <bob2> push doesn't update the working tree on the remote end
[09:45] <bob2> (unless you're pushing to a file://) url
[09:46] <bob2> you could switch it to have trees + install the update-after-push plugin on all the clients
[09:46] <ahorden> so we would be better using it the way we have it now, and have a shell script do the checkout somewhere else away from the working resporatory?
[09:47] <ahorden> so to do a backup from bazaar all we need to do is run a checkout and stick this on our backup rotation?
[09:47] <bob2> you can just back up the repository
[09:50] <ahorden> bob2 this is where the confusion hit me, I was going to do that but then noticed no files other than directories with a .bzr in it so I was suspecting that would not work, but now I get how a --no-trees works
[09:51] <bob2> all the revision data is in the .bzr dirs
[09:51] <bob2> it's just nto checked out
[09:59] <ahorden> ah thanks bob2 I will keep playing, we use git in work so just trying to move over to bazaar on my own systems
[10:00] <bob2> in git you're discouraged from pushing to non-bare repositories for the same reason
[10:14] <tasslehoff> What GUI would you recommend for working with bzr in Windows? "none" is not a valid answer ;)
[10:15] <tasslehoff> I tried bzr explorer, but it is far from stable on my system when I work with a tree checked out from an svn server
[10:20] <ahorden> whats the best way to import from git?
[10:21] <thrashold> Hello. I want to include someone else's source code inside mine. Both of us are using bzr. What is the best thing I can do, since bzr doesn't support external references? Fork it?
[10:26] <GaryvdM> tasslehoff: what errors do you get?
[10:29] <GaryvdM> tasslehoff: bzr explorer is the best we have. Hopefully we can solve your problems.
[10:30] <tasslehoff> GaryvdM: I choose "log history", right click a commit and select "show tree". It crashes with bzrlib.errors.NoSuchRevision
[10:30]  * GaryvdM checks bug db
[10:30] <tasslehoff> GaryvdM: lunch now. back to debug more later
[10:33] <GaryvdM> tasslehoff: Seems like bug 383359. If you subscribe to that, you will get notified when it is fixed.
[11:02] <tasslehoff> GaryvdM: back. thanks. released doesn't mean released to the general public?
[11:04] <GaryvdM> Oh, sorry I made a mistake. That was fixed in 0.11.0 which is released. I thought that it was not fixed.
[11:04] <GaryvdM> tasslehoff^
[11:05] <GaryvdM> tasslehoff: I'll log a new bug
[11:07] <GaryvdM> tasslehoff: what happens if yeu run bzr qbrowse -r XXX ?
[11:07] <GaryvdM> *you
[11:10] <tasslehoff> GaryvdM: the same for a rather new version. for version 15 in the tree (now at ~1500) it works
[11:10] <GaryvdM> tasslehoff: so you got the some error?
[11:11] <GaryvdM> *same
[11:11] <tasslehoff> GaryvdM: yes
[11:11] <GaryvdM> jelmer: ^
[11:11] <jelmer> hey GaryvdM
[11:11] <jelmer> I think I missed some context
[11:11] <GaryvdM> Hi jelmer
[11:12] <GaryvdM> jelmer: If he does bzr qbrowse -r XXX he gets bzrlib.errors.NoSuchRevision
[11:12] <GaryvdM> jelmer: bzr-svn branch
[11:12] <jelmer> does the revision actually exist ? :-)
[11:12] <jelmer> does bzr log -rXXX work ?
[11:13] <GaryvdM> jelmer: How do you get the revision to be fetched
[11:13] <GaryvdM> jelmer: He can see it in qlog
[11:13] <jelmer> how do you mean?
[11:14] <jelmer> in that case, what about "bzr ls -rXXX" ?
[11:14] <tasslehoff> http://pastebin.ca/1819014
[11:15] <jelmer> that doesn't look like a bzr-svn branch
[11:15] <jelmer> (CHKInventoryRepository)
[11:16] <tasslehoff> jelmer: I followed "A simple example" on http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/svn_plugin.html to get started
[11:16] <GaryvdM> tasslehoff: Ok - I don't know what is causing that, but I can get browse to ignore it.
[11:17] <jelmer> is that revision a ghost perhaps?
[11:17] <GaryvdM> Perhapse
[11:18] <GaryvdM> jelmer: qbrowse tries to load all revisions for inventoryentry.revision
[11:19] <jelmer> GaryvdM: that'd explain it
[11:20] <tasslehoff> it actually works on every revision up to 1500, and fails from there
[11:20] <GaryvdM> jelmer: Is there a way to get bzr to fetch the ghosts?
[11:21] <jelmer> GaryvdM: bzr fetch-ghosts
[11:21] <GaryvdM> tasslehoff:logged as bug 530606
[11:21] <jelmer> GaryvdM: but they might not be fetchable
[11:21] <tasslehoff> GaryvdM: ok
[11:21] <jelmer> GaryvdM: in other words, not present anywhere
[11:22] <tasslehoff> how can I check if it's a ghost commit?
[11:22] <GaryvdM> jelmer: Ok. Thanks for the help.
[11:22] <GaryvdM> tasslehoff: try bzr fetch-ghosts
[11:23] <jelmer> GaryvdM, If it's a bzr-svn repo the revisions probably just won't be there
[11:25] <tasslehoff> GaryvdM: it did something, and said "Still missing" about four revisions
[11:29] <GaryvdM> tasslehoff: I'm not sure what would cause that. But I should be able to fix bug 530606 by the next qbzr release.
[11:37] <tasslehoff> GaryvdM: great
[12:53] <maxb> jelmer: dulwich got push --overwritten? Dropping "Fix memory leaks in error paths." ?
[12:56] <jelmer> maxb: oops, yeah
[12:57] <jelmer> maxb: I must've thought I forgot to dpush earlier
[12:57] <jelmer> maxb: Thanks for pointing that out, should be fixed now.
[12:57] <maxb> that was fast!
[16:46] <GaryvdM> Hi vila, Are you arround ?
[16:46] <vila> GaryvdM: no ?
[16:46] <vila> :)
[16:47] <GaryvdM> Hi
[16:47] <GaryvdM> vila: I'm looking test code that creates a tree with all the different types of conflicts.
[16:48] <GaryvdM> I'm batteling to grok test
[16:48] <GaryvdM> *test_conflicts
[16:48] <vila> GaryvdM: Yeah, tell me when you find it :)
[16:48] <vila> ha, yeah, it's a work in progress
[16:48] <GaryvdM> Oh
[16:48] <GaryvdM> So I need to write my own. Any tips?
[16:49] <vila> The best ones so far are in bt.test_conflicts
[16:50] <GaryvdM> Ok - thats what I was looking at
[16:50] <vila> I've started writing them as shell-like tests, but 1) that means blackbox tests 2) less precise
[16:50] <vila> I started converting them to whitebox tests instead and already found a bug
[16:50] <vila> So TestResolveContentConflicts is the last I wrote and the most recent
[16:51]  * GaryvdM looks
[16:51] <vila> GaryvdM: bug qblame would tell you that :)
[16:52] <vila> GaryvdM: What is your intent ?
[16:53] <GaryvdM> vila: Tests for bp.qbzr.lib.treewidget
[16:53] <GaryvdM> Before I start fixing some of its bugs
[16:53] <GaryvdM> One such bug is bug 528548
[16:54] <vila> hmm, then you can start with the scenarios already described in the tests
[16:54] <GaryvdM> Yes - that is what I'm hoping to do.
[16:55] <vila> the bug description is scarce...
[16:55] <vila> As far as you're concerned, you should have to worry about whether a file is involved in a conflict, it's either versioned or unknown (or ignored) no ?
[16:55] <vila> s/should/shouldn't/
[16:56] <GaryvdM> vila: I give options from qbrowse to open extmerge and resolve
[16:57] <vila> GaryvdM: haa. But only for text conflicts right ?
[16:58] <GaryvdM> The extmerge is only availible for text conflicts, But I show a status for  All conflicts, and the option to resolve
[16:58] <vila> interesting
[16:59] <vila> you know you can start displaying *several* options to resolve ?
[17:00] <GaryvdM> Yes. I have been ramping up on your improvement to resolve.
[17:00] <GaryvdM> vila: see http://bazaarvcs.wordpress.com/2009/11/08/new-working-tree-features-in-qbzr/ for screenshot.
[17:01] <vila> nice
[17:02] <vila> GaryvdM: Some info on the coming features here : http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution
[17:04] <vila> GaryvdM: Explicitly marking the file as resolved should be the exception, there are ways to mark them automatically (today for text conflicts, soon for more)
[17:04] <vila> GaryvdM: Keep that in mind for the ui
[17:04] <GaryvdM> ok
[17:05] <vila> but as far as bzr-2.1 is concerned, you're fine with this design
[17:06] <GaryvdM> It's the first time I've seen TestCaseWithTransportAndScript. That's cool
[17:07] <GaryvdM> Thanks vila.
[17:09] <vila> hehe
[17:09] <vila> Don't abuse them though, they are good for bug reports but a bit imprecise (since they are essentially blackbox tests)
[17:10] <GaryvdM> But fine for creating trees with conflicts?
[17:11] <vila> GaryvdM: if you explore the history around bug #529968 you'll see why
[17:11] <vila> GaryvdM: they are fine to create any configuration you may think of
[17:12] <vila> GaryvdM: but they are not the right tool for whitebox tests
[17:12] <GaryvdM> ok
[17:20] <GaryvdM> vila: Could you please point me to some example code again. I have a set of trees, and a set of widget tests. I want to run each test on each tree
[17:21] <vila> see bzrliv.tests.test_conflicts.load_tests
[17:21] <vila> your widget tests should be in classes that define attributes that are set by load_tests via a scenario
[17:22] <vila> a scenario is a tuple (name, dict)
[17:23] <GaryvdM> vila: there is no  bzrliv.tests.test_conflicts.load_tests, but I'm looking at another load_tests :-)
[17:23] <vila> name is displayed while running the tests as test_this(name) and dict contains the test class attribute names as keys and values as... values
[17:23] <vila> s/bzrliv/bzrlib/ and update you bzr.dev :)
[17:25] <GaryvdM> ah - the code never sleeps...
[17:26] <vila> hehe
[17:32] <GaryvdM> Hmm - I think I should do it the other way around. The widget configuration should be the senerio, the with a tests for different trees.
[19:36] <mtaylor> anybody around with pipeline zen?
[19:36] <mtaylor> I've got a pipeline that I want to push all of the pipes to launchpad so that I can do lp-submit
[20:11] <bjp> is nested branches the best way to handle multiple branches taht depend on the same branch?
[20:11] <bjp> like multiple programs using a shared library
[20:12] <jelmer> bjp: nested branches don't exist yet
[20:12] <bjp> it doesn't? i thought it did...
[20:13] <bjp> i could have sworn i tried it out a couple months ago :/
[20:13] <jelmer> perhaps you're using a different name?
[20:13] <jelmer> what did you do ?
[20:14] <bjp> branch within a branch
[20:14] <jelmer> oh, that works indeed - but cloning one branch won't clone the containing branches
[20:15] <bjp> with --bind (i think)? and their versions are tracked?
[20:16] <jelmer> bjp: bind is for bound branches
[20:16] <bjp> i was looking for a way to track a couple projects with shared dependencies, nested branches (trees?) was the only thing i found about it
[20:16] <jelmer> nested trees don't work yet; perhaps you tried one of the plugins?
[20:16] <bjp> i'm trying to find the web site i was reading
[20:17] <bjp> http://doc.bazaar.canonical.com/devnotes/nested-trees.html
[20:21] <bjp> is there a plugin that does something similar?
[20:22] <mgedmin> say, I bzr get lp:ubuntu/karmic/mc
[20:23] <mgedmin> is there a way of now doing bzr get lp:ubuntu/lucid/mc and share part of the history I already downloaded?
[20:23] <mgedmin> create a stacked branch e.g.?
[20:23] <lifeless> stacked branches don't do that
[20:23] <lifeless> repositories do
[20:24] <lifeless> so - bzr init-repo mc
[20:24] <lifeless> cd mc
[20:24] <lifeless> bzr branch lp:ubuntu/lucid/mc
[20:24] <lifeless> bzr branch lp:ubuntu/karmic/mc
[20:24] <lifeless> mgedmin: we strongly prefer 'branch' to 'get'.
[20:24] <mwhudson> mm
[20:24] <mwhudson> jelmer: http://launchpadlibrarian.net/39998980/albatross-trunk-log.txt <- new one on me!
[20:24] <mgedmin> 'get' is shorter to type, just be happy I wasn't doing 'bzr co' ;)
[20:25] <mwhudson> (bzr-hg failure)
[20:25] <mgedmin> back to the question: I already did bzr branch for the karmic
[20:26] <mgedmin> can I bzr branch mc new-repo/mc-karmic to get it to not download the whole history again?
[20:26] <mgedmin> can I have the repository not in ../ but rather next to the branches?  bzr init-repo .bzrrepo; bzr branch lp:... --using-repo=.bzrrepo ?
[20:27] <jelmer> moin mwhudson
[20:27] <jelmer> bjp, bzr-externals I think
[20:27] <jelmer> bjp: I have no experience with it though
[20:27] <jelmer> mwhudson, how's the kernel import?
[20:28] <mwhudson> jelmer: i think it got like 6k revs in or something
[20:28] <mwhudson> (staging is down for an update)
[20:28] <mwhudson> and then it failed, but in a way that didn't leave logs, so that probably means it being down for an update killed it or something
[20:28] <bjp> jelmer: interesting, is that the best way to handle the dependency problem until nested-trees is available?
[20:29] <bjp> i'm just looking for a good solution
[20:29] <mwhudson> jelmer: better than before, definitely
[20:29] <jelmer> bjp: I'm not sure, I'm probably not the best person to ask..
[20:29] <jelmer> mwhudson: but hopefully it'll continue after the update?
[20:29] <mwhudson> jelmer: yeah
[20:29] <bjp> k
[22:44] <poolie> hello all
[22:44] <james_w> morning poolie
[22:44] <poolie> hello james_w
[22:45] <poolie> james_w, any special requests at the moment?
[22:45] <james_w> nothing special
[22:45] <poolie> ok
[22:45] <poolie> we're pretty busy this week with community reviews
[22:46] <poolie> i expect we will get into rebase or conflicts after they're more in hand
[22:46] <poolie> i liked your mail  'what is bazaar about?'
[22:46] <poolie> i might try to answer it more fully in a separate thread
[22:47] <poolie> i think essentially i want something that's very easy and straightfoward for new contributors, but that has enough power and extensibility not to hold advanced developers back
[22:47] <poolie> perhaps that sounds too close to 'all things to all people'
[22:47] <james_w> yeah, I wondered if it should be a new thread, as it could be a long discussion :-)
[22:48] <james_w> do you know about Personas?
[22:48] <poolie> also this is a place where my two different hats as project leader and as canonical staffer are a bit different
[22:48] <poolie> not in disagreement but different emphases
[22:48] <poolie> yes, i know the idea
[22:48] <james_w> yeah, I can see how that could be tricky here
[22:48] <poolie> do you think they would be a good way to define this?
[22:49] <james_w> good, it could be a useful tool to help talking about this
[22:49] <poolie> so to define the few archetypal personas we care about?
[22:49] <poolie> that could be good
[22:50] <james_w> then you don't have to talk about "enough power and extensibility", you can say "Amy, an experienced Python coder can write plugins based on good documentation of how to start one and good API docs that allow her to customise Bazaar to her team's needs"
[22:50] <james_w> which gives you something to aim for
[22:51] <poolie> right
[22:51] <poolie> to me that's one step down from the real values of the project, but definitely easier to put into non-waffly words
[22:51] <james_w> yeah, I guess the values are embodied in the few personas you pick to play this role
[22:52] <poolie> and in the general culture/feeling of the list
[22:56] <james_w> yes
[23:12] <igc> morning
[23:29] <jasonlife> I can ssh into my bzr server without passwd, but I keep getting passwd prompt when I run bzr command, like "bzr up"
[23:29] <bob2> windows?
[23:29] <jasonlife> no
[23:29] <jasonlife> do I have to do something to prevent passwd with bzr commands?
[23:30] <bob2> not really anything to do with bzr
[23:30] <bob2> it just uses ssh
[23:30] <jasonlife> hmm
[23:30] <bob2> maybe ~/.bzr.log says something interesting?
[23:30] <jasonlife> that I expect.. but it doesn't work.. weird
[23:30] <jasonlife> I see
[23:32] <jasonlife> Nothing special I guess.   I have line about ssh... 0.295  ssh implementation is OpenSSH
[23:43] <james_w> morning igc
[23:48] <jasonlife> bob2: sorry for the noise.. After I checkout with bzr+ssh instead of sftp, no passwd anymore.. :)