[00:04] <spiv> Mez: if you install a pre_change_branch_tip hook, and only allow write access via a smart server, then you can enforce it.
[00:08] <poolie> jam, hi
[00:09] <igc> morning
[00:09] <poolie> hello igc
[00:10] <poolie> does anyone have ideas for Ubuntu Open Week?
[00:10] <poolie> apparently emmajane is going to talk
[00:10] <igc> hi poolie, jam, jelmer, lifeless, spiv
[00:11] <poolie> https://lists.ubuntu.com/archives/ubuntu-devel/2009-April/028061.html
[00:15] <SamB> is there some secretly better version of bzr-bisect that I'm somehow missing out on?
[00:22] <jelmer> SamB: what's wrong with bzr-bisect?
[00:23] <SamB> it seems to have a tendancy to introduce changes into the working directory that conflict with eachother ...
[00:25] <SamB> ... and bzr proper seems unaware what revision bzr-bisect is looking at ?
[01:03] <jelmer> SamB: please file a bug
[01:03] <SamB> jelmer: where/how?
[01:04] <jelmer> SamB: launchpad.net/bzr-bisect I guess
[01:05] <SamB> jelmer: er, uh, can't!
[01:06] <SamB> see https://answers.launchpad.net/bzr-bisect/+question/66893
[01:17] <jelmer> SamB: ah, I guess Jeff doesn't use launchpad
[01:18] <SamB> well, I don't think that HTTP URL is going to accept any bug reports, somehow ...
[01:19] <jelmer> SamB: you should still be able to report bugs in Launchpad though even though the project isn't officially using it
[01:19] <SamB> jelmer: perhaps!
[01:20] <SamB> but I can't see a way past all these yellow boxes
[02:12] <SKArfaceGC> are all of the permissions with bzr handled via fs perms?  are there any plugins that can handle blocking/accepting various types of access?
[02:14] <spiv> SKArfaceGC: There's contrib/bzr_access in the source releases, I'm not sure how good it is.
[02:15] <SKArfaceGC> hrm.  I'm ultimately looking for something that does for bzr what sheila does for CVS.
[02:15] <SKArfaceGC> I'll check that out.
[02:18] <SKArfaceGC> It's also possible I'm just thinking about the problem incorrectly.  only been messing with bzr for a week or so.
[02:27] <Odd_Bloke> SKArfaceGC: What does sheila do for CVS?
[03:34] <SKArfaceGC> Odd_Bloke: it allows certian users to grant karma to other users so that they may commit.  it also facilitates locking the repository so no one can commit.  i.e. while running builds etc.
[03:38]  * igc lunch & medical stuff - back in a few hours
[04:29] <Toksyuryel> Doesn't sound like what sheila does would apply to bzr, since the whole point of distributed vcs is to remove the situation that makes something like sheila necissary
[04:30] <Toksyuryel> Then again it's possible to use bzr exactly like cvs (if you're insane) so maybe it exists?
[04:31] <lifeless> SKArfaceGC: bzr has atomic commits, so we can lock ourselves
[04:32] <lifeless> SKArfaceGC: and untrusted users just commit to their own repository, so you don't need to have portions of a repository writable by different people - you just create a new repository
[04:33] <lifeless> jml: this should be a no-brainer to review : https://code.edge.launchpad.net/~lifeless/subunit/done/+merge/5346
[04:34] <jml> Done.
[04:35] <lifeless> thanks
[05:38] <poolie> lifeless: i would like, possibly in vain, to drive to 0 New bugs
[05:38] <poolie> it would help if when you file bugs by mail you also mark them confirmed
[05:38] <lifeless> poolie: ride, surely.
[05:38] <poolie> and set a priority
[05:38] <lifeless> I often do
[05:39] <lifeless> I also often don't.
[05:42] <poolie> yes :)
[06:12] <lifeless> poolie: You've mentioned this before. I guess I don't make it a must-do simply because we're usually wrong anyway
[06:12] <poolie> about the priority?
[06:12] <poolie> i agree
[06:13] <poolie> i think basically i just want one bit which says "this has been considered by a developer"
[06:13] <poolie> possibly i should write a script which looks for untriaged bugs filed by one of us and marks them confirmed:whenever
[06:16] <Peng_> What if the bug really isn't confirmed?
[06:16] <fullermd> If it isn't confirmed, maybe it's infirm?
[06:20] <lifeless> Peng_: if $coredev files a bug its fair to assume its confirmed
[06:20] <lifeless> poolie: actually I have a suggestion
[06:20] <lifeless> poolie: a search for bugs with no activity by a core dev
[06:20] <lifeless> [open bugs]
[06:22] <Peng_> lifeless: $coredev can make a mistake.
[06:22] <lifeless> Peng_: yes, but I don't think martin is interested in confirmation
[06:22] <Peng_> Although that will be rare, so it'll take less effort to fix mistakes than to confirm every bug filed by #coredev.
[06:22] <Peng_> s/#/$/
[06:23] <lifeless> Peng_: I think he is interested in identifying bugs that a core dev has not looked at and considered.
[06:31] <poolie> that's correct
[06:33] <poolie> sometimes one developer will want to disagree with another one's bugs, but that's a different problem
[06:34] <poolie> or, not really "problem", "case"
[07:04] <vila> hi all
[07:08] <lifeless> hi vila
[07:09] <vila> lifeless: great, you're still there, your patch raised questions I wanted to clarify instead of blindly landing
[07:10] <vila> lifeless: you did get my mail right ?
[07:10] <lifeless> yes
[07:10] <lifeless> I replied
[07:11] <vila> ok, so I didn't have the right subunit
[07:12] <vila> but you're saying startTests is optional, is that true for done too then ?
[07:13] <lifeless> they are not well defined yet
[07:13] <vila> 'startTests' doesn't convey that, it surely shouldn't be used for suite.setUp for example as I was tented to do, nor done() for suite.tearDown()
[07:13] <vila> s/tented/tempted/
[07:13] <lifeless> its on result, you can't use it for those no matter how tempted you are
[07:14] <vila> I realized that
[07:14] <lifeless> also if you want to do a suite.setUp, you're thinking about the problem wrong
[07:15] <vila> I don;t want a suite.setUp(), but we use atexit anyway and that's wrong too
[07:16] <vila> and I don't like re-installing a hojj in the test suite either :-)
[07:16] <vila> s/hojj/hook/
[07:16] <lifeless> where do we use atexit?
[07:17] <lifeless> oh, make_test_root
[07:17] <vila> test/__init__.py to delete TEST_ROOT
[07:17] <lifeless> it should be deleted after every test
[07:17] <lifeless> its buggy
[07:17] <lifeless> or use testresources
[07:18] <vila> wazzat ?
[07:18] <lifeless> lp:testresources
[07:18] <jamesh> speaking of testresources, there are some proposed changes that need reviewing ...
[07:19] <lifeless> jamesh: yes
[07:19] <lifeless> I'm hoping to get to it in easter
[07:19] <lifeless> its not exactly work..
[07:19] <jamesh> cool.
[07:19] <jamesh> maybe if bzr used testresources it could count as work? :)
[07:21] <lifeless> vila: I want to leave these fuzzy for now
[07:21] <lifeless> vila: good definitions are being hammered out on the tip list; when we have them bzr can just inherit them
[07:22] <vila> lifeless: haa, just what I wanted to confirm, why don't you tell that first :-)
[07:22] <vila> lifeless: and I missed that hint about subunit yesterday obviously :-/
[07:23] <vila> I see it now... it looks like most of the messages I miss on IRC occur just after I send one, my parser should be buggy
[07:27] <vila> lifeless: so, now that *I* have sync, I've remove the getattr for done,
[07:27] <lifeless> ok
[07:28] <vila> so if we you don't want more strict testing of the supported TestResult (but which ones), I can land
[07:28] <lifeless> conformance testing of test results isn't something I feel we need for this change to be landable
[07:29] <ronny> lifeless: are there any plans to support some kind of automated setup + aggregation in subunit, im in search of automated ways to run the testsuite for anyvc against different versions of hg/bzr
[07:31] <lifeless> ronny: subunit can aggregate already; setup is something orthogonal - subunit won't get in the way but it isn't really in a position to help either
[07:31] <ronny> so i'll have to find a way to encode the currently tested versions in the context
[07:35] <ronny> lifeless: did the integration into other testing tools get any better?
[07:36] <ronny> at least its still not easy_install-able
[07:36] <lifeless> ronny: I would accept patches for easy-install; downloading random code off the internet isn't something I buy into though
[07:36] <lifeless> I'm in the [rather large] easy_install OMG
[07:36] <lifeless> group
[07:37] <ronny> lifeless: its pretty convient
[07:38] <lifeless> ronny: what sort of integration do you mean though?
[07:38] <ronny> lifeless: stuff like nose
[07:38] <lifeless> well, you were working on that
[07:38] <ronny> i wrote a initial plugin some time ago, but it didnt seem to get any further attention
[07:38] <lifeless> weren't you?
[07:39] <lifeless> bzr uses subunit now, for parallel testing
[07:41] <ronny> lifeless: i think all it needs to be easy-installable is a src tarball on pypi (at least for the python parts)
[07:41] <lifeless> ok, well I'm happy to put it on pypi
[07:42] <ronny> lifeless: oh, and is there finally any way to report additional metadata about a test
[07:43] <lifeless> tag: foo
[07:43] <ronny> stuff like stdout/err + profiling + coverage comes to mind
[07:43] <lifeless> well
[07:43] <lifeless> this is what you were asking about before
[07:43] <ronny> hmm
[07:44] <lifeless> I'm happy to discuss ways to embed this in the stream
[07:44] <lifeless> unittest has no standard for it today, so its a little awkward to talk about it
[07:47] <Mez> spiv: I dont want to enforce it, I want to have it run the test suite after a commit. So that 1) commits dont take forever and 2) we can still commit and just fix after
[07:48] <spiv> Mez: running a buildbot is the usual way to do that.  You can have it trigger on commit emails and the like.
[07:49] <spiv> (or by a post_change_branch_tip hook that pokes it directly...)
[07:53] <ronny> lifeless: until it is standardized one could do something xdata: stdin [ ... ]
[07:55] <vila> lifeless: one more thing: leaking threads report (data collection really) is broken for both fork and subprocess (by design), just something to keep in mind
[07:57] <lifeless> ronny: well it should be in  the result comment area
[07:57] <lifeless> ronny: IMO
[07:57] <lifeless> ronny: the problem isn't defining stream handling for data, its defining how to present it to the TestResult in python
[07:58] <lifeless> TestCase->TestResult is a [deliberately] narrow interface
[08:01] <ronny> lifeless: well, then one would have to mangle it somehow and not mess up other parsers
[08:01] <lifeless> ronny: I don't see why
[08:01] <lifeless> subunit expects arbitrary data there
[08:06] <ronny> hmm, so something like a trace is not actually expected?
[08:08] <lifeless> it does the best it can
[08:08] <lifeless> but you don't get traces from tap, or the C unit tester 'check' or cppunit or a bunch of other places
[08:09] <ronny> it would be nice to have more metadata about what is in there
[08:10] <lifeless> I agree; there is a tension between simple and structured
[08:11] <ronny> ideally there would also be a way to hook into it via rpc and introspect the objects/data
[08:11] <BasicOSX> poolie:  You should also merge (not pull) the release branch into lp:~bzr/bzr/current, so that branch contains the current released code at any time.
[08:11] <BasicOSX> That is the releasing documentation (bug 358199) the wording is confusing to me. I'll make changes and RFC it.
[08:11] <BasicOSX> oops sorry Bug 357521
[08:11] <lifeless> its meant to be sufficiently transparent that 'import pdb;pdb.set_trace()' will just work
[08:11] <lifeless> ronny: ^
[08:12] <ronny> lifeless: but how will that work with parallel tests and or wireing it into a ide
[08:12] <BasicOSX> I also thought lp:~bzr/bzr/current meant bzr.dev
[08:12] <ronny> specifying new hooks?
[08:14] <lifeless> as a streaming protocol, you don't really want it to keep things around - in fact you can't be sure it will do that at all
[08:14] <lifeless> IMO running in debug mode is a setup issue - subunit can pass the output from debugging mode over the wire, including any IDE or other control data
[08:14] <ronny> ok, so subunit is purely reporting
[08:15] <lifeless> (by 'it' I mean the remote test code; it could be C, or just a saved file)
[08:15] <lifeless> subunit is a wire version of the TestCase->TestResult API
[08:15] <lifeless> where users of subunit want things that belong in that API, but the API doesn't support them yet, I've tried to add them in tasteful ways that don't distort the base design
[08:17] <lifeless> vila: so are you landing that branch now?
[08:17] <lifeless> vila: oh I see, its now playing :)
[08:17] <vila> :-)
[08:23] <ronny> lifeless: i'll try to build something around it while im away, the next few days i might be disconnected
[08:26] <Peng_> jelmer: Why make bzr-svn's default stacked format 1.9-rich-root instead of 1.6.1-rich-root? The latter would be better for compatibility.
[08:26] <lifeless> ronny: ok cheers
[08:26] <lifeless> ronny: I'd start just by getting your tests to run in a subprocess.
[08:26] <lifeless> e.g. use IsolatedTestSuite
[08:27] <lifeless> or if you want more control
[08:27] <lifeless> (such as execing a new thing) ExecTestCase
[08:27] <lifeless> or more control still
[08:27] <lifeless> use the ProtocolTestClient and TestProtocolServer
[08:27] <ronny> lifeless: i'll try - i need to figure a simple way to set up virtualenvs for the tests and install the currently required versions
[08:28] <lifeless> http://lists.idyll.org/pipermail/testing-in-python/2009-April/001458.html
[08:29] <lifeless> that describes using the result and proxy testcase directly
[08:29] <lifeless> or you could look at bzr.dev's selftest --parallel=subprocess
[08:32] <lifeless> later all
[08:33] <Peng_> jelmer: Also: You left some pdb bits in test_repository.py in 0.5 and 0.6.
[08:41] <yogsototh> Hi all
[08:42] <yogsototh> I make a bzr pull ftp://name@orange.fr:pass@perso-ftp.orange.fr/root
[08:42] <yogsototh> and it works on OS X
[08:42] <yogsototh> but not on Windows XP with Cygwin
[08:43] <Peng_> yogsototh: What version of bzr on OS X and XP? Pastebin the traceback you got.
[08:44] <Peng_> (Not that I'll be able to help, but other people will probably need that information.)
[08:45] <yogsototh> on Cygwin I installed a bzr version 1.3.1 (details http://www.mibbit.com/pb/TEixVg )
[08:46] <yogsototh> The traceback is http://www.mibbit.com/pb/swVLXd , which means It cannot retrieve my username (certainly because of the @ in the user name wich can confuse with the @ just before the servername.)
[08:47] <Peng_> yogsototh: What version of bzr on OS X?
[08:48] <yogsototh> sorry my bzr version is 1.13.1 on Cygwin and I believe it is older on OS X but I don't remember exactly wich, may be 1.11, but I'm not certain.
[08:48] <Peng_> yogsototh: There have been recent fixes related to usernames with @ in them. Maybe the version you're running on XP is too old but the version you're running on OS X is new enough.
[08:48] <Peng_> Oh. Haha, never mind, I guess. :D
[08:49] <yogsototh> 1.13 is the last stable version
[08:49] <BasicOSX> 1.13.1
[08:49] <yogsototh> Then I'll try with the 1.14rc1
[08:50] <Peng_> yogsototh: Unless you're running 1.14rc1 on OS X, I'm probably wrong.
[08:50] <Peng_> Wait a minute, from the error you pasted, it sounds like the error is coming from the server, not the client.
[08:50] <yogsototh> I clearly not running the 1.14rc1 on OS X
[08:50] <yogsototh> Yes
[08:50] <yogsototh> The error come from the server
[08:51] <yogsototh> But the weird thing about that is that it works on OS X
[08:53] <yogsototh> OK, you're certainly right.
[08:54] <yogsototh> I don't understand why, but I cannot connect my ftp server from windows, even with filezilla.
[08:54] <yogsototh> Sorry then, it is then not a bazaar issue.
[09:02] <stewart>  bzr branch lp:~eday/drizzle/eday-dev
[09:02] <stewart> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('NoSuchRevision',)
[09:02] <stewart> from latest bzr
[09:03] <Peng_> stewart: As a workaround, you could branch over http or sftp.
[09:26] <lifeless> spiv: is the fix done?
[09:28] <bob2> hm, something on my system is weird and made bzr's progress bar print one line per update
[09:29] <lifeless> lol
[09:29] <lifeless> some terminals do a line feed when you hit the bottom right square
[09:29] <lifeless> other terminals can emulate this on demand
[09:30] <lifeless> we write a lot of ' ' to blank out a line
[09:53] <natureshadow> hi there!
[09:54] <natureshadow> I just want to checkout a branch from a project's bzr repository on launchpad and generated an ssh key which I also uploaded to Launchpad
[09:54] <natureshadow> But I renamed it to ~/.ssh/launchpad because I don't want so many files called id_dsa around ;)
[09:54] <natureshadow> How do I make bzr use this key file?
[09:55] <poolie> BasicOSX: ok
[09:55] <poolie> bob2: try running the command 'reset'
[09:56] <Kinnison> natureshadow: You can add "IdentityFile ~/.ssh/launchpad" to an appropriate Host section of your .ssh/config
[09:56] <Kinnison> natureshadow: I've never tried before, but from reading 'man ssh_config' that seems the appropriate thing to do
[09:57] <natureshadow> Kinnison: oh, of course .... stupid me, didn't think of ssh config ;)
[09:57] <natureshadow> What is the hostname, then?
[09:57] <Kinnison> Now that, I couldn't say
[09:57] <natureshadow> bazaar.launchpad.net ?
[09:57] <Kinnison> but *.launchpad.net wouldn't be a bad guess
[09:57]  * Kinnison hugs wildcarded hosts
[09:57] <natureshadow> Kinnison: ok :)
[09:58] <Kinnison> good luck anyway
[09:58] <Kinnison> this is all untested guesswork advice
[09:59] <poolie> natureshadow: i think it tries id_* or something
[10:01] <natureshadow> I actually wonder what I need this for anyway, I thought I only need it for committing changes
[10:04] <lifeless> or just do 'ssh-add ~/ssh/launchpad
[10:05] <Kinnison> poolie: according to the manpage, it only does id_rsa and id_dsa
[10:06] <Kinnison> lifeless: that also works, but only for one session
[10:07] <natureshadow> Now bazaar advices me to file a bug report because of an itnernal error
[10:07] <natureshadow> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 32: ordinal not in range(128)
[10:23] <lifeless> garh
[10:23] <lifeless> loggerhead search support broken
[10:25] <Peng_> It is? How?
[10:25] <Peng_> (Not that I'll fix it, but I'm curious.)
[10:27] <lifeless> search.py is imported before load_plugins() is called
[10:27] <lifeless> Aarons change to plugin path defaults means that that breaks loading search when search isn't globally installd
[10:27] <Peng_> Aughhhh! Loggerhead filled up my /tmp directory!
[10:27] <Peng_> Stupid ext3 32k link limit. But aughhh! Loggerhead, WTF?!
[10:28] <Peng_> Oh god, shell autocomplete is slooow.
[10:29] <Peng_> And I spammed the heck out of auth.log by trying to "sudo mv" them all at once. :D
[10:30] <Kinnison> Peng_: tmpreaper might be your friend
[10:32] <Peng_> Kinnison: Also Loggerhead not creating thousands of directories.
[10:32] <Peng_> Looks like I noticed after only 2 hours. Great. :)
[10:37] <Peng_> Glad my Loggerhead site is so unpopular. :D
[10:44] <lifeless> Peng_: I have put a fix up for bug 334250
[10:45] <lifeless> Peng_: if you wanted to poke at it that would be good
[10:46] <Peng_> lifeless: Currently busy on "Loggerhead filled my /tmp", but I'd be happy to look at it, though there's an extremely small chance of me knowing how to help.
[10:47] <lifeless> Peng_: 'works for me'
[10:48] <lifeless> Peng_: would be a good start :)
[10:53] <Peng_> lifeless: OK. Yeah, WFM.
[10:54] <lifeless> that tmp thing looks fugly
[10:54] <Peng_> What looks fugly?
[10:54] <Peng_> The bug, or using /tmp at all or what?
[10:55] <lifeless> 30K tmp dirs :)
[10:55] <lifeless> at the very least it could create a subdir off of tmp to put it's dirty linen in.
[10:57] <Peng_> lifeless: Well, it's only *supposed* to create one per load.
[10:57] <Peng_> Although it doesn't clean it up on shutdown.
[10:57] <Peng_> Err, by "load" I mean "starting Loggerhead", not "page load".
[11:36] <poolie> night all
[11:39] <Peng_> poolie: Good night.
[11:47] <Mez> I keep having issues that I cant check in, it just sorta hangs at Transfer: Stage 0/4
[11:48] <lifeless> that means you are using a checkout from a network branch, sos it has to push
[11:48] <lifeless> what bzr version
[11:48] <lifeless> and what branch did you checkout
[11:50] <Mez> 1.13
[11:50] <awilkins> How's Ashton-under-Lyne today?
[11:50] <Mez> yeah, we have a checkout of a network branch, and we're checking out over bzr+ssh.
[11:50] <Mez> (It's our own repository)
[11:51] <Mez> but it's just hanging, doing nothing. (sometimes comes back with "too many concurrent connections)
[11:51] <Mez> but this seems to be something that's happening a lot of late.
[11:51] <lifeless> Mez: in which case, the time it takes to commit will be roughly the same as 'bzr push' after doing a commit in a local branch rather than a checkout
[11:51] <lifeless> hmm
[11:51] <lifeless> run with -Dhpss
[11:51] <lifeless> see what it is hanging on
[11:51] <lifeless> also check the server .bzr.log for errors
[11:52] <Mez> well, I'm running a reconcile on the server at the moment.
[11:54] <Mez> 1.760  opening SVN RA connection to 'chroot-3076886316:/home/bzr/fusion'
[11:54] <Mez> wtf?
[11:56] <Mez> http://rafb.net/p/sYsx3J74.html
[11:56] <Peng_> Mez: bzr is trying to figure out what type of branch it is, so it asks bzr-svn, along with checking the built-in formats.
[11:56] <awilkins> Would anyone be against `bzr revert` accepting globs?
[11:58] <Peng_> awilkins: Well, since I'm not a Windows user with a crappy shell, I would be.
[11:59] <Peng_> awilkins: It would mean I'd have to double-escape paths so they wouldn't be interpreted as globs, right?
[11:59] <awilkins> Peng_: That's just mocking the afflicted though :-) - if it's good enough for SVN.......
[12:00] <awilkins> I hadn't considered that ; but I don't see it either - what would you have to escape to stop it looking like a glob (my internal definition of "glob" may also be wrong here)?
[12:01] <Mez> lifeless: this is the .bzr.log so far up until it's hanging
[12:01] <Mez> http://rafb.net/p/Fxi2Dc91.html
[12:02] <Peng_> awilkins: Well, if  want to version a file called "foo*.txt" for some strange reason, I'd have to escape the filename for my shell, and then I'd have to escape it again for bzr.
[12:02] <awilkins> My example would be ; when I export a load of VBA form modules so I can version them, VBA inserts time-specific data into form resources, making them change every time, despite having no substantive changes in them. This I want to revert en-masse ;   svn allows   `svn revert *.frx` , bzr doesn't. As you pointed out, Windows isn't as accomplished in the shell dept and doesn't have xargs, for example
[12:03] <awilkins> Peng_: Are you even allowed to name files like that on Linux VFS?
[12:03] <lifeless> awilkins: we process *.foo ourselves on windows
[12:03] <lifeless> awilkins: its completely fine to file a bug saying 'revert does not do this correctly on windows'
[12:03] <lifeless> awilkins: because we special case windows ;)
[12:04] <awilkins> Does it work using bash?
[12:04] <Peng_> awilkins: Bash does glob expansion itself.
[12:04] <awilkins> That was my next question :-)
[12:04] <awilkins> I'm using Powershell, which is good
[12:05] <lifeless> awilkins: 'bzr add' for instance definitely does shell expansion itself; its probably a small matter of code to fix revert
[12:05] <lifeless> [on windows]
[12:05] <awilkins> The neatest construct I've found that works well so far is `ls *.frx | foreach { bzr revert $_ }
[12:05] <lifeless> Mez: thats odd
[12:05] <lifeless> Mez: is the process on the server busy?
[12:05] <awilkins> But that invokes a separate process for each file so less than ideal
[12:06] <awilkins> bzr revert (ls *.frx) #  that works much better
[12:07] <Mez> lifeless: not particularly
[12:07] <Mez> http://rafb.net/p/G5WRq285.html
[12:08] <lifeless> Mez: thats a lot of active processes
[12:08] <lifeless> are they all from the same user?
[12:09] <Mez> yes
[12:09] <Mez> they're all root
[12:09] <lifeless> *blink*
[12:09] <Mez> though I think some of them are previous failed attempts?
[12:10] <lifeless> are you connecting as root?
[12:10] <lifeless> or perhaps you're running an anonymous server at the same time ?
[12:10] <Mez> (we're logging in through SSH as root, as it seems to be the only way to get round the damned issues with permissions)
[12:10] <lifeless> oh
[12:10] <lifeless> could you strace them all
[12:10] <lifeless> get a few seconds activity
[12:11] <Mez> Process 14831 attached - interrupt to quit
[12:11] <Mez> read(0,
[12:11] <Mez> is the latest one, and it's hung there
[12:12] <Mez> they're all the same
[12:12] <lifeless> ok, they are waiting for a request from the bzr client
[12:12] <lifeless> do you have ssh connection sharing on ?
[12:12] <lifeless> (Master* stuff in your ~/.ssh/config)
[12:12] <Mez> not that I know of
[12:13] <lifeless> well
[12:13] <lifeless> kill them all
[12:13] <lifeless> then, your branch is probably locked
[12:13] <lifeless> so 'bzr break-lock' the url of your branch
[12:13] <lifeless> on the server
[12:13] <Mez> afk
[12:19] <awilkins> Gragh, BB needs to support searching
[12:19] <Mez> bak
[13:00] <Mez> lifeless: ok, all killed... what next (sorry, lunchtime)
[13:02] <lifeless> Mez: break-lock as above
[13:02] <Peng_> Well, only if it's necessary.
[13:02] <Peng_> Or do we already know that it is?
[13:02] <lifeless> Peng_: one known cause of toomanyconcurrent
[13:03] <lifeless> Peng_: fixed I think, but - worth checking
[13:03] <Peng_> Oh, really? Interesting.
[13:03] <SamB> hmm, why does bzr have to keep deciding that directory adds cause conflicts :-(
[13:03] <SamB> just because I personally have a directory in a given place already ?
[13:04] <lifeless> SamB: two possible reasons; if you ahve an unversioned local dir, bzr can't make the dir that a commit you're pulling added
[13:04] <SamB> why can't it just use the same one ?
[13:04] <lifeless> SamB: and secondly bzr versions directories so if A and B both add a dir called 'foo', seperately, bzr doesn't know that it should be the same dir
[13:04] <lifeless> well say you had a dir called tests
[13:04] <lifeless> with some thousands of test logs
[13:05] <lifeless> and someone adds a dir called tests to the project, with real files
[13:05] <lifeless> when you pull, would you want those intermingled?
[13:05] <SamB> what makes it particularly lame is that I think bzr tried to delete the directory in the first place ... but decided not to since there were files in (which I did not care about)
[13:06] <lifeless> SamB: right, this is a particular bug, its in discussion on the list, and its really annoying when it happens
[13:06] <lifeless> SamB: we will be fixing it!
[13:06] <SamB> oh good
[13:07] <lifeless> the issue is those files that weren't versioned
[13:08] <lifeless> bzr doesn't know 'ignored, passwords' from 'ignored, editor backups'
[13:08] <lifeless> so we err on the side of preserving user data.
[13:08] <SamB> I'm not saying it should have deleted the directory
[13:08] <SamB> ;-)
[13:08] <lifeless> well
[13:08] <lifeless> there are a number of ways to fix bzr here
[13:08] <SamB> but it would be nice if it remembered that it had tried
[13:09] <lifeless> I'm just explaining the background
[13:13] <Mez> damned netsplits :D
[13:15] <Mez> did everyone survive ok ?
[13:16] <SamB> lifeless: I don't suppose you can turn on bug-tracking for bzr-bisect?
[13:17] <lifeless> SamB: if the author is maintaining it outside launchpad, he won't see bugs put into it...
[13:18] <lifeless> SamB: also its late, and I don't trust my judgement at this hour :)
[13:18] <lifeless> Mez: yes; have you break-lock'd the branch?
[13:18] <Mez> yup
[13:18] <james_w> SamB: I thought it was on
[13:19] <lifeless> Mez: ok, try your commit now
[13:21] <Mez> seems to have frozen again
[13:23] <lifeless> check strace on the server
[13:23] <lifeless> if its in read(0, ) again
[13:23] <lifeless> then a) file a bug
[13:24] <lifeless> b) hit ctrl-\ on the client, then 'bt' to get a backtrace.
[13:31] <lifeless> and put that in the bug report too
[13:32] <lifeless> do a bzr check on the server on the branch
[13:32] <lifeless> gnight all
[13:33] <Peng_> lifeless: Good night. :)
[13:43] <OllieR> hey I have renamed the directory which contains a bzr branch. It seems to think that it is still at its old location. See http://stikked.com/view/94640778
[13:45] <Peng_> OllieR: ls -l .bzr
[13:45] <jelmer> vila: hi
[13:45] <jelmer> vila: how do you think the fallback credentials stores should work?
[13:46] <OllieR> Peng_: yeah there is a .bzr dir in there
[13:46] <vila> by being queried when they are registered iff no user and/or password is found
[13:47] <OllieR> Peng_: see output here http://stikked.com/view/95451041
[13:47] <jelmer> vila: but where should the fallbacks hide?
[13:47] <jelmer> vila: AuthenticationConfig.get_credentials()?
[13:47] <vila> jelmer: but before the user is prompted
[13:48] <jelmer> vila: right
[13:48] <vila> yes, get_credentials sounds right and should respect the constraints above naturally
[13:49] <Peng_> OllieR: You're either using a checkout or a shared repository. If the former, fix the path in .bzr/branch/branch.conf. If the latter, make sure the branch can still find the shared repo.
[13:50] <vila> jelmer: did I lose track of your get_username submission or should you still send one ?
[13:50] <Peng_> OllieR: Probably; I dunno. :P
[13:51] <OllieR> so ls .bzr/branch/ output format  location
[13:51] <OllieR> location shows the old dir
[13:52] <OllieR> i will try changing this
[13:52] <jelmer> vila: I still need to send it
[13:53] <jelmer> vila: I need to fix the tests still
[13:53] <vila> ok
[13:58] <bialix> igc: around?
[13:59] <Peng_> bialix: ffwiw, he said "back in a few hours" 10 hours ago.
[13:59] <Peng_> fwiw*
[13:59] <bialix> anybody using fast-import plugin? I saw in ML several days ago fast-import trunk is broken for pack-0.92 format
[13:59] <Peng_> Sorry, not me.
[14:00] <bialix> hmm
[14:03]  * bialix won't try to pull latest trunk then, and use known stable rev.
[14:19] <Peng_> beuno: Pingy ping? :D
[14:46] <Mez> ok, power fail :(
[15:55] <SamB> how come the Bzr wiki doesn't have a place where you can click on the node title to see backlinks?
[15:59] <Kinnison> What is the recommended way for a new project wanting a robot-controlled mainline and web-based review to set up using bzr these days?
[16:00] <Kinnison> At one point it was bundlebuggy+pqm
[16:00] <Kinnison> then there was talk of launchpad doing it
[16:00] <Kinnison> and I've been out-of-the-loop for too long
[16:03] <Peng_> Kinnison: You can replace Bundle Buggy with Launchpad if you want to, but you're stuck with PQM.
[16:03] <Kinnison> I read about someone writing something which used launchpad's branch review stuff to trigger merges
[16:03] <Kinnison> I think it's 'tarmac'
[16:05] <Peng_> Ah. Good point.
[16:07] <Kinnison> I used to run a PQM
[16:08] <Kinnison> So I might stick with that and sort out a bundlebuggy
[16:08] <Kinnison> But I do quite like launchpad's review stuff
[16:08] <Kinnison> urgh
[16:08]  * Kinnison shall have to think about this, thanks peng
[16:09] <emmajane> hey all -- I'm adding myself to the OpenWeek schedule for an intro-to-bzr session.
[16:19] <SamB> hmm ... how do I switch a working tree to a specific revision?
[16:19] <Peng_> SamB: You can't really. Best you can do is "bzr revert -r 123".
[16:19] <jam> vila: good morning
[16:24] <vila> jam: hi !
[16:27] <jam> vila having a good day?
[16:28] <vila> jam: not one of the best :-/
[16:47] <SamB> hmm ... ran into bug 348456 ...
[16:48] <SamB> and there's something wrong with the URL formatting in http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html
[17:36] <kfogel> abentley: in Nested Trees, does "push" nest automatically?  If you run push in the containing tree, and you supply a dest argument, I guess the containing tree pushes to that location, but where would subtrees push to -- same place (hmrmrm) or to a remembered location?  Or not push?
[17:36] <kfogel> (abentley: realized it makes more sense to ask you bzr questions here!)
[17:45] <abentley> kfogel: I believe push doesn't currently nest, but it should.  It would push branches for subtrees to the same relative path the subtree is at.  Branch already does nest.
[17:48] <kfogel> abentley: thanks.  So just curious: if you go inside a subtree and do 'bzr push some-other-location --remember', will that memory be pushed up too?
[17:48] <kfogel> E.g, later you do 'bzr push' from the containing tree, with or without dest and with or without --remember, subtree still goes to old remembered location?
[17:48] <abentley> kfogel: --remember will only have a local effect.
[17:49] <kfogel> *nod*
[17:50] <abentley> kfogel: So perhaps when you push to a location, that branch should be consulted to determine where to push subtree branches to.
[17:50] <abentley> So, with branch "a" and branch "a/b", pushing to "c".
[17:50] <kfogel> abentley: that's one possibility, yeah.  I can see how figuring out the expected behavior might get complicated here :-).
[17:50] <abentley> Push a to c.
[17:51] <kfogel> abentley: support for single-file subtrees?  That is, do subtrees have to be directories?
[17:51] <abentley> look up d's location for b.
[17:51] <abentley> sorry, look up c's location for b
[17:51] <abentley> Which is 'd'.
[17:51] <abentley> Push to 'd'.
[17:51] <kfogel> (I like that solution best, I think.)
[17:52] <abentley> kfogel: Subtrees have to be directories.
[17:52] <kfogel> The whole push question has nothing to do with the Subversion comparison, of course -- Subversion doesn't support that stuff anyway.
[17:52] <abentley> Maybe not, but I appreciate the questions.  These answers have a bearing on what I'm working on right now.
[17:54] <kfogel> no plans to change the "subtrees must be directories" thing, right?
[17:54] <kfogel> And, any plans to change the "must be specific revision-id" rule?
[17:54] <abentley> kfogel: It doesn't really make sense to me.
[17:55] <abentley> kfogel: If it were a file, what would the reference point to?  You can't have a working tree without at least a root directory.
[17:55] <kfogel> abentley: in terms of user-visible behavior, we could describe what it means.  How it would be implemented, I have no idea.
[17:56] <abentley> kfogel: the must be specific revision-id thing isn't a firm stance-- I'm curious why using head might be a good idea.
[17:56] <kfogel> abentley: you could horn the metadata into the containing tree's metadata, i.e., "we've also got this file here from out of town...".  Not saying this is clean or desirable, just describing how svn does it.
[17:56] <abentley> kfogel: Ah, so svn externals may be files?
[17:56] <kfogel> abentley: some projects under development want (even need) to track the dev versions of dependencies.
[17:57] <kfogel> abentley: yes.  svn's single-file support is currently weak, but that's only because of technical reasons; there are plans to make it stronger.
[17:57] <abentley> kfogel: Sure.
[17:58] <abentley> But I think you would address that by updating to the latest dev version, and committing.
[17:58] <abentley> You can still pull new dev versions at any time.
[17:59] <kfogel> abentley: it's interesting -- it sort of approaches the same result, over time, yeah.
[17:59] <abentley> kfogel: I think it makes a lot of sense that when you check out a tree that has subtrees, you get a reproducible result.
[18:00] <kfogel> abentley: I agree that can be a useful property.
[18:00] <abentley> I thought maybe svn didn't do that because users were managing that metadata.
[18:00] <kfogel> I think that's a good analysis.
[18:01] <abentley> And updating it all the time would be a pain.
[18:01] <kfogel> the way bzr does it is more appropriate for bzr.
[18:02] <abentley> kfogel: Yeah, reading the SVN docs, I realize that nested trees are not going to be a superset of externals, at least not initially.
[18:03] <kfogel> abentley: so you can read this at the newly-updated http://bazaar-vcs.org/NestedTreesDesign page, but: svn has a "--ignore-externals" flag that can apply to any operation that would normally pay attention to externals.
[18:03] <abentley> kfogel: If we decide we want to allow the head to be specified, we can use one of our reserved revision-ids.
[18:03] <kfogel> abentley: interesting!  Yeah.  But I kind of think you're right: there's no need to support it, and in fact it would be rather un-bzr-like.
[18:04] <kfogel> Subversion just does it that way because updating the specific revision-id would not be easy, given that it doesn't come for free with the other UI around updating.
[18:04] <abentley> Similarly, once we support partial checkouts, we might be able to support references to single files.
[18:05] <kfogel> ah, cool
[18:05] <abentley> kfogel: At the same time as supporting references to parts of the tree.
[18:06] <abentley> kfogel: For now, we can suggest using symlinks like launchpad does.
[18:06] <kfogel> partial trees will be nice, I think.
[18:07] <abentley> kfogel: You're not the one who'll have to update merge :-(
[18:07] <kfogel> abentley: that's right :-)
[18:07] <kfogel> abentley: why, I'm so enjoying the freedom to have opinions without worrying about how I'd implement them.  "Waiter, I'll take one more of these, please!  No, actually, make that two."
[18:08] <abentley> kfogel: lol
[18:11] <abentley> kfogel: Thanks for looking at that.
[18:12] <abentley> kfogel: Is there anything I should clarify in the design doc?
[18:13] <kfogel> abentley: who is the intended audience for the design doc?
[18:13] <kfogel> devs or users?
[18:14] <abentley> kfogel: devs
[18:15] <kfogel> cool (that was my guess).  I think just clarify the plans around push, since the answer there is not obvious.
[18:18] <abentley> Cool, will do.
[18:25] <SKArfaceGC> kfogel: thanks for your comment on my learning bzr stuff I posted last week.
[18:26] <kfogel> SKArfaceGC: hey, glad you're writing it
[18:26] <SKArfaceGC> kfogel: I think I'm going post about messing around with repositories and push/pull next.  I'll work on auth/permissions in the next one.
[18:27] <kfogel> ok, I'll wait :-)
[18:28] <SKArfaceGC> how did you find it?
[18:28] <kfogel> google alert
[18:28] <kfogel> bzr
[18:28] <SKArfaceGC> aaah
[18:30] <SKArfaceGC> after using cvs for 10+ years bzr is like a breath of fresh air.  Still working through stuff, but I think it may ultimately solve several problems for us.
[18:38] <mrooney> Anyone know where svn stores its cached auth data in windows, I need to clear it.
[18:40] <mrooney> I bet jelmer would know :)
[18:40] <Peng_> I bet #svn would know! :P
[18:40] <Peng_> (Kidding kidding.)
[18:40] <mrooney> Peng_: I asked there too but there are plenty of smart svn people here :)
[18:56] <jelmer_> kfogel: I noticed you added some comments about svn:externals to the NestedTrees wiki page
[18:56] <jelmer_> kfogel: I've been trying to decide how to deal with unversioned svn:externals in bzr-svn as there doesn't seem to be a good bzr substitute for those
[19:09] <abentley> jelmer: Did you see my comments under "Comments on differences"?
[19:13]  * jelmer_ looks
[19:14] <jelmer_> abentley: most of the svn:externals uses I have seen so far don't use an explicit revision
[19:15] <jelmer_> abentley: I'm not sure if this is because it's hard to update the revision (you have to edit a revision property to do so) or because people prefer pointing at HEAD
[19:15] <jelmer_> s/revision property/file property/
[19:15] <abentley> jelmer_: I think it's probably the first.
[19:16] <abentley> jelmer_: it may be that we add head support anyway, just to make bzr-svn work.
[19:19]  * LarstiQ certainly uses revision pinning in svn:externals
[19:19] <LarstiQ> hello, btw
[19:23] <abentley> LarstiQ: hey.
[19:48] <jelmer_> hi LarstiQ
[20:00] <jelmer_> vila: Is it correct that webdav support may end up in bzr core?
[20:01] <LarstiQ> hi abentle, jelmer_
[20:17] <jelmer_> LarstiQ: have you looked at bug 336749 recently?
[20:23] <LarstiQ> jelmer_: no. I realize you'd like to tackle it before 1.0
[20:24] <LarstiQ> jelmer_: please tell me I'm not the only hope of progress?