[00:05] <lifeless> spiv: hi!
[00:05] <lifeless> spiv: you back?
[00:10] <spiv> lifeless: yeah, I hope so :)
[00:11] <spiv> With the help of cold & flu tablets.
[00:11] <lifeless> ok cool
[00:11] <lifeless> I was going to pickup the 'detect ghost inventories' patch
[00:12] <lifeless> if you're back, and it was next on your todo, perhaps you'd like to just follow through on it ?
[00:21] <jelmer> mwhudson: moin
[00:21] <jelmer> mwhudson: any more luck with bzr-git now?
[00:22] <mwhudson> jelmer: haven't tried with the latest versions yet
[00:24] <spiv> lifeless: sure
[00:27] <Peng_> So, um, what's the right branch of Dulwich to use?
[00:27] <mwhudson> jelmer: judging by the first two minutes, it seems much saner in terms of memory usage
[00:30] <igc> morning all
[00:30] <igc> lifeless: pong
[00:31] <lifeless> igc: hi
[00:32] <lifeless> igc: you mentioned that filter config has hit a wall; where should I read to read up on that
[00:32] <igc> lifeless: thanks for your email btw
[00:32] <lifeless> anytime
[00:33] <igc> lifeless: I'll email the list soon with an update
[00:33] <lifeless> literally apparently, it was what, 11? :P
[00:33] <igc> lifeless: see Alexander's latest email for the brief problem
[00:34] <igc> i.e. using an arbitrary file doesn't allow storage of that file in the tree
[00:34] <igc> because of various ordering issues w.r.t. tree building and filter application
[00:35] <lifeless> e: [MERGE] [BUG 363837] Catch _win32_delete_readonly failure to remove file or directory and try to recove ?
[00:37] <AmanicA> jelmer: sorry if the mail I just sent about your patch is confusing, but I'm tired and going to bed now
[00:52] <poolie> spiv: still sick today?
[00:53] <poolie> oh i see
[00:53] <spiv> poolie: no (well, not enough to stop me working)
[00:54] <igc> hi spiv. welcome back
[00:54] <spiv> I wouldn't recommend getting too close to me, though :)
[00:54] <spiv> Between this cold and the vaccinations last week my immune system should be very well exercised for Barcelona...
[01:20] <mwhudson> jelmer: is there any way of telling how a bzr-git pull is doing by looking at the .bzr directory?
[01:20] <lifeless> spiv: could you please eyeball my updated descriptions on https://bugs.edge.launchpad.net/launchpad-code/+bug/354036 and https://bugs.edge.launchpad.net/bzr/+bug/360791
[01:21] <lifeless> spiv: I've tried to make them very approachable for users
[01:21] <luke-jr> How can I get a list of all revids?
[01:22] <lifeless> cat /dev/urandom ?
[01:23] <lifeless> more seriously, a little context is needed - do you mean the revisions in a branch, or the contents of a repository, or some concordance of what people have used anywhere....
[01:23] <spiv> luke-jr: in a branch's mainline history?  in a branch's full ancestry?  in a repository?
[01:23] <lifeless> also do you want it in python, or shell scripting
[01:23] <luke-jr> spiv: a future revision
[01:24] <luke-jr> I did a bunch of bzr uncommit ;)
[01:24] <spiv> lifeless: the descriptions look very good, thanks!
[01:24] <spiv> luke-jr: you mean you want to know the revids of the uncommitted revs?
[01:24] <lifeless> bzr heads --dead
[01:25] <lifeless> will list all the heads
[01:25] <lifeless> uhm, log -r revid:ADEADHEAD  --show-ids will let you get at the ancestors of the dead head
[01:26]  * fullermd still wishes log -r..revid:FOO would give a log as if FOO were the head of a branch...
[01:26] <lifeless> fullermd: make it happen!
[01:26] <lifeless> fullermd: [is there a bug too]
[01:26] <spiv> And "bzr uncommit" in recent releases will display the revid of the revision you are uncommitting
[01:26] <luke-jr> lifeless: 'bzr heads' doesn't exist..?
[01:26] <fullermd> I tried, but my magic wand just sorta looks at me and says 'blert'...
[01:26] <luke-jr> spiv: it did, long off my scroll history
[01:27] <fullermd> Not sure.  I don't remember filing one.
[01:27] <lifeless> fullermd: you need to pay it more attention
[01:27] <luke-jr> bzr 1.14rc1 has no 'heads' cmd
[01:27] <fullermd> luke-jr: It's in bzrtools
[01:29] <lifeless> luke-jr: the revids may be in your bzr.log too
[01:30] <luke-jr> ty
[01:40] <lifeless> jml: when you do a web review, its annoying that you can't see what you are reviewing
[01:40] <lifeless> e.g. https://code.edge.launchpad.net/%7Embp/bzr/340352-rename-lock/+merge/4334/+review
[01:41] <lifeless> the bug style inline forms are _much_ more convenient
[01:41] <jml> lifeless: yeah, poolie filed a bug about this.
[01:41] <lifeless> ok cool
[01:43] <lifeless> I can't see it
[01:44] <mwhudson> mmm
[01:44]  * mwhudson still finds the distribution of concerns in progress reporting a little odd
[01:44] <mwhudson> mmm
[01:44] <mwhudson> maybe it's not bad actually
[01:44] <jml> https://bugs.edge.launchpad.net/launchpad-code/+bug/372059
[01:45] <jml> I haven't had the chance to triage it yet.
[01:46] <poolie> mwhudson: it's not fully baked yet i agree
[01:46] <lifeless> jml: thats when proposing a merge
[01:46] <lifeless> jml: I'm talking when doing a review
[01:46] <jml> lifeless: oh ok.
[01:46] <lifeless> jml: https://code.edge.launchpad.net/%7Embp/bzr/340352-rename-lock/+merge/4334/+review is an example url
[01:46] <mwhudson> poolie: concretely right now i wish TextProgressView._format_task was somewhere else :)
[01:47] <poolie> patches welcome :)
[01:48] <lifeless> jml: let me know, bug or feature:P
[01:48] <jml> lifeless: what do you think?
[01:48] <mwhudson> i guess i need to figure out what i want here
[01:49] <mwhudson> poolie: i'm just going to blabber requirements for a while, feel free to either ignore or read as you like
[01:49] <lifeless> jml: I think it would be better if it was like the bug discussion pages
[01:49] <mwhudson> this is for git code imports
[01:49] <mwhudson> we have a monitor process that considers a process stuck if it produces no output for an hour
[01:49] <jml> lifeless: me too.
[01:50] <mwhudson> so i'd like to have a progress reporter that prints some kind of progress indication
[01:50] <mwhudson> i think printing a line on every progress report would get a bit spammy
[01:51] <mwhudson> so i was thinking of printing a progress report on _progress_updated if nothing had been printed for, say 10 minutes
[01:52] <mwhudson> i guess i'll subclass clifactory
[01:53] <lifeless> mwhudson: don't you have this already
[01:53] <lifeless> mwhudson: I *sounds* like code you wrote in the past.
[01:54] <mwhudson> lifeless: it sounds a bit like something ddaa wrote
[01:54] <mwhudson> i think
[01:56] <lifeless> mwhudson: I'm pretty sure you already have a UI factory in your code base that does this
[01:56] <mwhudson> lifeless: i'm pretty sure we do not, any more
[01:56] <lifeless> oh, ok.
[01:56] <lifeless> 'bzr revert -r wheredidthatcodego'
[01:58] <lifeless> bug 373038
[01:59] <jml> thanks.
[02:00] <thumper> lifeless: yes, I know
[02:00] <lifeless> thumper: ?
[02:00] <thumper> lifeless: I've been planning to work on it with beuno but both of us have long lists :(
[02:00] <thumper> lifeless: bug 373038
[02:00] <lifeless> thumper: thats a new bug I just filed as the result of the discussion with jml
[02:00] <thumper> lifeless: yes, but we've known about it for ages :)
[02:00] <thumper> just bugless
[02:01] <lifeless> thumper: I'm honouring a promise I made to jml to be active about documenting my experiences with code
[02:01] <thumper> that's good
[02:01] <thumper> thanks
[02:01] <thumper> I do appreciate it
[02:01] <thumper> I just want you to know that we know about it and have been thinking about it
[02:01] <lifeless> ok, cool.
[02:07] <spm> lifeless: btw that pqm-config fix for the LANG (/home/pqm/bin/dchroot-run LANG=en_GB.utf8 make check) worked nicely for vila last night. Shall we roll to all the bzr config entries, or revert?
[02:07] <lifeless> spm: bzr.dev and new releases only
[02:08] <lifeless> spm: e.g. 'no'
[02:08] <spm> lifeless: new releases being 1.14+ ?
[02:08] <lifeless> the state of existing branches is unknown
[02:08] <lifeless> spm: 1.15
[02:08] <spm> oh yes of course. will do.
[02:08] <lifeless> thanks
[02:09] <lifeless> spiv: how goes it?
[02:10] <lifeless> spiv: I ask because AIUI you had a patch, but I don't recall seeing it up for review; I'm keen to put these bugs behind us and want to help :)
[02:10] <spiv> lifeless: just caught up on the worst of my mail and administrivia backlog
[02:12] <spiv> lifeless: the work-in-progress is lp:~spiv/bzr/all-referenced-texts-check
[02:12] <spiv> lifeless: I'm currently working on adding more test coverage
[02:12] <lifeless> ok
[02:12] <lifeless> the conceptual approach makes sense, and I browsed the patch yeseterday
[02:13] <spiv> lifeless: cool, that's good to know :)
[02:13] <jelmer> mwhudson: not really
[02:14] <spiv> The code feels overly complex, but I think that's hard to avoid.
[02:14] <mwhudson> jelmer: ok
[02:14] <spiv> We don't have particularly convenient APIs for working with the dependencies that are implicit in our graphs.
[02:15] <jelmer> mwhudson: it should give you a progress bar though
[02:15] <mwhudson> jelmer: yeah, if you install a ui factory at all :)
[03:03] <mwhudson> where does the ui_factory get set when you run bzr from the command line?
[03:04] <mwhudson> oh, main()
[03:05] <spiv> mwhudson: with the small exception of cmd_serve which unconditionally uses SilentUIFactory
[03:06] <mwhudson> spiv: ta
[03:08] <mwhudson> oh wow, i can actually pull bzr.dev over http now
[03:09] <mwhudson> i wonder if my isp has fixed their proxy at last...
[03:11] <thumper> jam/igc: any ETA on bbc stacking?
[03:14] <igc> thumper: no idea sorry - I'm not working on that
[03:15] <thumper> igc: hmm, lifeless just said it was with you and jam
[03:17] <lifeless> thumper: igc and jam are working on the bbc format and related things, spiv and I are working on networking - thats the split across the two major goals set for the bazaar team
[03:19] <thumper> ok
[03:20] <lifeless> thumper: it doesn't mean that everything we do is strictly in those buckets, nor that everything that needs to be done to move bbc from beta to release is actively being coded right now :)
[03:26] <poolie> mwhudson: so you're running bzr in a subprocess with a pipe on stderr/stdout?
[03:26] <poolie> and you just want it to mumble stuff, not draw a progress bar as such?
[03:26] <mwhudson> poolie: yes
[03:26] <mwhudson> right
[03:32] <mwhudson> hmm
[03:32] <mwhudson> can i use a plugin to override the default ui factory?
[03:33] <lifeless> mwhudson: yes
[03:33] <lifeless> mwhudson: it may be a little esoteric; I will put one together for you after I finish a little roadmap cleanup
[03:34] <mwhudson> lifeless: don't worry about it, i'll just hack for now
[03:34] <thumper> poolie: http://bazaar-vcs.org/Roadmap/BrisbaneCore seems to completely miss that bbc can't stack right now
[03:35] <lifeless> thumper: I'm editing it at the moment
[03:40] <lifeless> thumper: done
[03:41] <lifeless> mwhudson: ok
[03:42] <lifeless> mwhudson: hook into Command.hooks 'extend_command'
[03:42] <lifeless> mwhudson: bzr help hooks has the docs for this
[03:42] <lifeless> mwhudson: that will get called before any command is executed, and after the ui factory is set
[03:43] <mwhudson> lifeless: ta
[03:43] <lifeless> its a little hacky, and you may be invoked multiple times etc
[03:43] <lifeless> but it will work
[03:47] <mwhudson> lifeless: so will editing main() which is what i'm doing now >:)
[03:48] <lifeless> mwhudson: well you asked about a plugin to do it
[03:48] <mwhudson> yeah, sorry
[03:48] <lifeless> its about 4 lines in a plugin, including imports
[03:48] <SamB> and how many lines to install ?
[03:48] <lifeless> SamB: thats the lot
[03:49] <SamB> I meant, how many lines do you need to type in the shell ;-P
[03:49] <lifeless> SamB: oh heh
[03:55]  * spiv -> lunch
[03:58] <SamB> spiv: I maintain that you people are CRAZY!
[04:01]  * igc lunch
[04:01] <SamB> igc: yes, you too!
[04:01] <igc> SamB: :-)
[04:01]  * SamB <- dessert
[04:01]  * fullermd isn't edible.
[04:02] <SamB> (the dessert goes into me ;-)
[04:40] <poolie> igc, i'm trying to merge the doctools patch you mentioned yesterday
[04:40] <poolie> it has small failures on python2.4
[04:41] <igc> poolie: did jam suggest some workarounds in the review thread? It's a while ago now but I recall something like that
[04:41] <poolie> he had a small fix but i think not for that
[04:44] <lifeless> its the win32 installer it fixes I think
[04:54] <lifeless> spiv: http://bazaar-vcs.org/Roadmap/SmartServer I've tweaked; let me know if I used too big a cleaver
[04:57] <poolie> thanks for all the roadmap updates!
[04:58] <lifeless> poolie: as we were discussing, there is a balance here
[05:00] <mwhudson> poolie: this is the ui factory i've come up with so far, if you're curious: http://pastebin.ubuntu.com/165831/
[05:02] <lifeless> mwhudson: seems more complex than desirable
[05:02] <lifeless> mwhudson: but if it works great
[05:03] <mwhudson> lifeless: it's not _just_ for progress monitoring, it's also visible in the ui
[05:03] <mwhudson> so i put a bit of effort into making it useful too
[05:03] <lifeless> mwhudson: sure; by complex I mean its a shame you can't use existing code more
[05:03] <mwhudson> lifeless: ah right\
[05:03] <mwhudson> yes
[05:04] <lifeless> I mean, ideally you'd just override the render call and instead of doing [[05:04] <lifeless> or wahtever
[05:06] <lifeless> actually thats a good, serious question
[05:06] <lifeless> why didn't you do that?
[05:12] <mwhudson> hmm, i guess that would have been somewhat easier
[05:12] <mwhudson> would need to copy-paste-change some methods (and presumably submit changes to bazaar that would make that less relevant)
[05:16] <lifeless> naturally
[05:16] <lifeless> otoh it would be more obvious and likely easier to maintain
[05:23] <poolie> mwhudson: i like the time_source thing
[05:23] <mwhudson> poolie: deterministic tests ftw
[05:24] <poolie> i'd like to merge something like this into bzr
[05:24] <poolie> if you need to provide the stack stuff here that's a bug
[05:28] <mwhudson> poolie: i think as lifeless said, i'm somewhat operating at the wrong level
[05:28] <mwhudson> poolie: but operating at the right level nicely requires a bzr patch
[05:28] <mwhudson> poolie: i'll try to write that patch later
[05:29] <poolie> ok
[05:29] <poolie> i also want to keep improving this
[06:23] <eelik> Are there instructions anywhere for actually creating the repository layouts mentioned in http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#advanced-shared-repository-layouts
[06:29] <spiv> eelik: there's no special commands needed beyond the "bzr init-repo" to create the shared repository
[06:30] <eelik> but how about "container directories"? Are they versioned somehow?
[06:31] <spiv> eelik: no, just create an ordinary directory on your filesystem.
[06:31] <eelik> then I'm out of luck, because sourceforge doesn't make it possible
[06:32] <eelik> basically, it allows only using bzr command
[06:33] <lifeless> eelik: you can just use bzr commands
[06:33] <lifeless> eelik: bzr init-repo URL
[06:33] <eelik> yes, that's the easy one
[06:33] <eelik> it has to be done in a special ssh shell environment
[06:33] <lifeless> eelik: and then bzr push URL/foo to push a branch up
[06:34] <mwhudson> poolie: http://pastebin.ubuntu.com/165869/ <- version that uses more from bzrlib
[06:34] <mwhudson> poolie: it's a bit ugly, but a bzrlib patch will sort that out
[06:34] <eelik> that I can do also, but what if I want to create a branch in a nonversioned subdirectory or subsubdirectory
[06:35] <eelik> does bzr create them automatically
[06:35] <lifeless> eelik: bzr push URL/foo/bar --create-prefix
[06:35] <eelik> (well, I'm new to bzr as you can see)
[06:35] <eelik> ok, I have to try that
[06:36] <eelik> But I managed already to create a nonversioned directory into the sf server and it can't be removed
[06:37] <lifeless> eelik: bzr push --use-existing-dir URL if you want it to be a branch
[06:37] <eelik> their system may be unmature
[06:37] <lifeless> eelik: or if you wanted it to be a repository, bzr init-repo URL
[06:38] <eelik> ok, I have been reading the docs for couple of days but it's just too much :)
[06:38] <lifeless> eelik: could be :)
[06:38] <lifeless> sf have only recently added sf support, its true
[06:39] <eelik> and they don't offer any site specific documentation except for the very scarce intro
[06:40] <eelik> but thanks, I keep learning
[07:19] <the-erm> I have a security question.
[07:20] <the-erm> I notice that bzr has an ssh key
[07:21] <the-erm> if someone gets a hold of my ssh id_rsa.pub key from launchpad does that mean they can ssh into my computer?
[07:21] <lifeless> no
[07:21] <the-erm> Ok.
[07:21] <lifeless> ssh keys work in two parts
[07:21] <lifeless> the public part is like the lock
[07:21] <vila> hi all
[07:21] <lifeless> the private part, the bit you keep on your computer, is the actual key
[07:21] <the-erm> I realized the error of my question...after I asked it.
[07:22] <lifeless> the public key can be used to give you permission to login to machines, thats all
[07:22] <lifeless> hi vila
[07:25] <the-erm> I guess it didn't hurt to ask.  I'm pretty paranoid about letting people have access to my machine.
[07:28] <lifeless> thats healthy
[07:30] <lifeless> jelmer: ping
[07:49] <poolie> lifeless: +1 to your updates and thanks for writing it
[07:49] <poolie> updates to the advice
[07:57] <luke-jr> the-erm: I used to have an 'anonymous' account on mine, without a password
[07:57] <luke-jr> curiously, the botnets never noticed it
[07:58] <lifeless> poolie: I've finished for the day; feel free to let the announcement go free if you want :)
[07:58] <lifeless> poolie: otherwise I'll do it tomorrow
[07:58] <luke-jr> lifeless: announcement? ☺
[07:58] <lifeless> luke-jr: see the list, 'draft announcement..'
[08:05] <poolie> lifeless: let it go from teh moderation queue?
[08:05] <lifeless> poolie: I haven't mailed it anywhere
[08:05] <poolie> ok let it go by sending it?
[08:05] <poolie> sure
[08:14]  * jml really really wants an SQL-like frontend to Bazaar
[08:14] <jml> (except not enough to actually design and build one)
[08:18] <mwhudson> jml: select from revision where author like ... ?
[08:18] <jml> yeah
[08:18] <jml> or, a thing I wanted to refute a particular accusation
[08:19] <jml> select from revision where message.startswith('release-critical') and author in (...)
[08:19] <jml> except because of PQM you need the author of the second-to-left parent of the mainline revision.
[08:19] <jml> which is a pita
[08:20] <jml> also counts and averages and better time awareness
[08:21] <lifeless> jml: bzr log -m '\brelease\b' :P
[08:21] <lifeless> also bzr-search aims at this space, I'd be delighted to have a readline interface to it
[08:21] <jml> lifeless: that log command is obviously not good enough
[08:21] <jml> lifeless: because it doesn't restrict the set of authors.
[08:21] <lifeless> jml: yes, thats true
[08:22] <lifeless> igc and I and others want a query language we can make standard and reuse
[08:22] <lifeless> ETIME
[08:22] <jml> right
[08:26] <lifeless> jml: are there ppa package branches?
[08:26] <lifeless> [I have a piece of software; I'm going to upload it to a ppa; it would be nice if the branch I upload was clearly packaging]
[08:28] <jml> lifeless: there aren't ppa package branches, per se.
[08:28] <jml> lifeless: you can push to ~lifeless/ubuntu/karmic/software/branch though
[08:29] <lifeless> or jaunty presumably?
[08:29] <jml> or jaunty
[08:29] <jml> or lenny
[08:29] <lifeless> now, if the package hasn't been in ubuntu yet, will that fail?
[08:29] <jml> (or whatever they call it)
[08:29] <jml> lifeless: very good question. my guess is "yes"
[08:29] <jml> lifeless: but I haven't tried.
[08:30] <jml> let me know if I'm wrong :)
[08:34] <lifeless> software is 'package' ?
[08:37] <lifeless> jml: apparently subunit has been uploaded before, or the answer is 'no'
[09:03] <awilkins> Hmm, bzr just isn't good at whacking-great-enormous files.
[09:15] <awilkins> Is there any way that bzr support for large sized files could improve? I know it's not the core use case, but a lot of people check large files into e.g. SVN, which copes well with them, and this can make interoperating with those repositories with bzr something of a trial.
[09:16] <lifeless> awilkins: it will improve when jam lands a patch he has, but only by a factor of 3 or so; files that are large fractions of your memory require more radical changes
[09:16] <awilkins> What kind of fraction?
[09:17] <awilkins> My problem here is I think this repo has a single revision with about 600MB of data in it.
[09:17] <awilkins> It's sitting at around 2.1GB in top and swapping around every so often.. :-)
[09:18] <lifeless> to merge a file wit 600MB of content we need 1.8GB in memory, minimum.
[09:18] <lifeless> (three copies)
[09:19] <awilkins> Dammit, the server just dropped
[09:19]  * awilkins bites the edge of his shield
[09:19] <awilkins> I think it's split into several 150MB files
[09:20] <awilkins> I'll check it out the traditional way and see
[09:21] <awilkins> Would it be a valid approach to write a class that merges using disk as an intermediary, and "mutate" the memory based operation into a disk based operation if it was consuming a lot of memory?
[09:22] <bob2> or just give up and conflict out
[09:22] <lifeless> each 150MB file should be getting processed separately
[09:22] <bob2> 600MB files probably aren't text
[09:23] <lifeless> awilkins: yes, that is a valid approach [with costs, but yadayadayada].
[09:23] <awilkins> Ah, ok, even better(ish) it's more like 25-40MB files
[09:23] <awilkins> They are text files, they are just big ones
[09:23] <awilkins> They're CSV tables
[09:23] <lifeless> awilkins: ok, if *that* is giving headaches its not the 'big file' bug
[09:23] <lifeless> awilkins: what bzr version?
[09:23] <awilkins> This is bzr 1.14.1 plus whatever bzr-svn it ships with
[09:25] <lifeless> ok
[09:25] <lifeless> please file a bug
[09:25] <lifeless> with plenty of data about reproducing if possible
[09:25] <awilkins> It's probably bzr-svn
[09:25] <lifeless> it could be bzr-svn
[09:25] <lifeless> if you can simulate (e.g. fast-export fast-import, reproduce) it without bzr svn that would be good; if you can't it probably is bzr-svn :P
[09:25] <awilkins> I suspect that most of this data was committed in a single revision in the source SVN repo
[09:27] <poolie> night all
[09:34] <awilkins> Looks like 7 folder containing 150MB apiece of text files (60/60/25 MB) were committed in the same revision
[09:34] <awilkins> Which is the revision it was choking on
[09:37] <lifeless> awilkins: were you doing a pull from svn?
[09:45] <awilkins> lifeless: Yes
[09:45] <awilkins> lifeless: I just added a comment to the bzr-svn "Memory problems" bug
[09:46] <awilkins> I suspect it's trying to process an entire revision in memory in one step
[09:47]  * igc dinner
[09:47] <lifeless> awilkins: that makes sense to me
[09:49] <awilkins> I don't think svn even breaks a sweat - it doesn't even consume enough memory to hold one of the files as far as I can see
[09:49] <awilkins> But it doesn't have to do any "transcoding" or however you want to term it
[09:52] <lifeless> bzr itself won't either
[09:52] <lifeless> its likely a interface mismatch
[10:05] <Solarion> is there a way to change the parent and push information for a branch without actually pushing/pulling?
[10:05] <Solarion> I changed servers, and would like to point the projects at the right place in a one-off batch job
[10:05] <bob2> hack .bzr/branch/branch.conf
[10:06] <Solarion> that sounds like it's inviting breakage
[10:06] <bob2> how so?
[10:06] <bob2> it's just an ini file
[10:08] <Solarion> so no breakage?
[10:09] <lifeless> a little bit of sed should be fine
[10:09] <lifeless> or you could use the python API to set them
[10:11] <Solarion> sed sounds easier for a one-off project like this. :)
[10:11]  * Solarion is leery of poking around in .bzr
[10:14] <Solarion> thanks!
[13:35] <vadi2> Any work on when bzr-gtk will be updated in the ppa?
[13:35] <vadi2> *word
[14:03] <jelmer__> vadi2: what's broken about it?
[14:04] <vadi2> if I upgrade my bzr to ppa version, bzr-gtk stops working - I was told it needs an update in the ppa.
[14:04] <jelmer__> what bzr version does the ppa have?
[14:04] <vadi2> I think 14 something and bzr-gtk is 13
[14:05] <vadi2> 1.14.1 for bzr in the ppa
[14:05] <jelmer__> vadi2: that should be sufficient, bzr 1.14.1 didn't change the API since bzr 1.13
[14:05] <vadi2> "0.95.0+bzr629-1ubuntu1" for my bzr-gtk package... but it complains when I install the bzr ppa
[14:06] <vadi2> well, I tried it before, let me try again
[14:09] <vadi2> magic! works now :)
[14:09] <vadi2> here's what I had before for some reason:
[14:09] <vadi2> (08:36:26 AM) vadi2: Hi. I upgraded my bzr from the ubuntu ppa, and all of the g* commands broke - it says gtk+ wants an api version of 1, 13, 0 while only 1, 14, 0 is available. But there are no upgrades available.
[14:09] <jelmer__> vadi2: you had bzr 1.14.0 which incorrectly claimed it broke compatibility with bzr 1.13
[14:10] <vadi2> ohh
[14:36] <lifeless> jelmer: I'm a check committer now :P
[15:28] <Jemsquash> I'm getting a run() got an unexpected keyword argument 'location' when I type in bzr.exe xmllog --limit=200 build.xml. I'm using xmloutput 0.8.3 and Bazaar (bzr) 1.14. Does anyone know what the cause is & how to fix it?
[15:31] <beuno> verterok, ^
[15:32] <verterok> Jemsquash: do you have the traceback?
[15:32] <verterok> beuno: hi, thanks!
[15:32] <beuno> verterok, hi  :)
[15:33] <Jemsquash> 0.233  Traceback (most recent call last):
[15:33] <Jemsquash>   File "C:/tools/bazaar/plugins\xmloutput\xml_errors.py", line 61, in xml_error_handling
[15:33] <Jemsquash>   File "C:/tools/bazaar/plugins\xmloutput\__init__.py", line 356, in run
[15:33] <Jemsquash>   File "bzrlib\commands.pyo", line 937, in ignore_pipe
[15:33] <Jemsquash> TypeError: run() got an unexpected keyword argument 'location'
[15:35] <verterok> Jemsquash: it shouldl be fixed in trunk (vila's magic patches :)
[15:35] <verterok> *should
[15:35] <verterok> I'll do a new point release tonight
[15:36] <Jemsquash> Ok Thanks. Do I pick it up from http://verterok.com.ar/bzr-eclipse/update-site/ ?
[15:36] <verterok> Jemsquash: sorry, in bzr-xmloutput trunk :)
[15:37] <Jemsquash> ah ok.
[15:37] <Jemsquash> thanks
[15:37] <verterok> Jemsquash: also there is a new build of bzr-eclipse with the new and shiny send dialog (courtesy of Javier)
[15:38] <verterok> Jemsquash: btw, I'm working on bundling xmloutput in bzr-eclipse builds, so the only external dependecy is bzr itself ;)
[15:38] <verterok> hopefully I'll have it ready in a few days
[15:42] <Jemsquash> send looks good. First time I tried it was from the context of a file & it told me 'send is not enabled in this context'. I was a bit confused at first until I thought about what it was about. It worked from the project level.
[15:44] <verterok> great!
[15:45] <verterok> Jemsquash: yeah, that is a generic context handling error, it might be good that some commands override the default message
[15:46] <Jemsquash> yeah. Could it be disabled for that context?
[15:48] <Jemsquash> Am I misunderstanding something? I see that the project menu has a lot more enabled than the file context menu. Is there a reason the send menu item is here?
[15:49] <verterok> Jemsquash: sure, check the performance preference page, there is a checkbox: action availability
[15:49] <Jemsquash> ah ok.
[15:50] <verterok> Jemsquash: but you'r right, it shouldn't be in the file/folder menu, and that's just a config issue in the plugin xml
[15:50] <verterok> Jemsquash: could you file a bug about it?
[15:50] <Jemsquash> Can do if you want. What's the performance penalty?
[15:52] <Jemsquash> I'm assuming there is a performance penalty since the preference is in the performance preference panel.
[15:55] <verterok> Jemsquash: the filtering by file/folder/project is "free", the performance issue is related to bzr specific checks, like: only enable Switch in a checkou, or unbind in a boudn branch, etc
[15:58] <Jemsquash> Does that mean you want me to raise a bug that the default for that value should be on? Or change the message so that it mentions the preference or just the fact that menus should be disabled based on context?
[15:58] <verterok> Jemsquash: no, that Send should only be present in the Project context menu
[15:59] <verterok> e.g: like Branch
[15:59] <Jemsquash> OK. I'll raise the bug now.
[16:00] <verterok> Jemsquash: thanks!
[16:00] <Jemsquash> np
[16:10] <SamB> hmm ... that's annoying
[16:11] <SamB> I can't use M-x dvc-diff from the editor bzr commit opens for me to write the commit message in :-(
[16:13] <SamB> also ... shouldn't "bzr pull -d foo" give an error if it can't resolve "foo" to a branch to pull into?
[16:18] <Jemsquash> At work we use clearcase and when we do a merge and there are multiple conflict the merge tool is quite nice. You can do the 3 way merge and once complete you save and exit. The tool the automatically moves onto the next conflict. Is there any equivalent process when merging lots of conflicts in bzr?
[16:21] <verterok> Jemsquash: I use the extmerge plugin for the, bzr extmerge --all :)
[16:24] <Peng_> What's the best way to run the test suite nowadays? Install testtools and subunut and whatever and use the parallel version?
[16:25] <Peng_> Although then I have to remember how to spell "parallel".
[16:25]  * SamB wishes there was a tool designed simply to help VCS's call 3-way-merge tools
[16:26] <Jemsquash> Thanks verterok. Do you use kdiff3 are the any that play nicer than others with bzr? Especially with the .THIS .OTHER .BASE files. On Windows that is.
[16:26] <jam> SamB, Jemsquash: for conflict in `bzr conflicts --text`; do kdiff3 $conflict.BASE $conflict.OTHER $conflict; done
[16:27] <SamB> jam: well, I was actually thinking of how it would make using external merge tools with darcs easier ;-)
[16:27] <verterok> Jemsquash: don't know in windows, I use gvimdiff or meld
[16:38] <Mez> does anyone know what these damed ~1~ files are? ?
[16:38] <beuno> Mez, yes, when you revert, you get those
[16:38] <beuno> in case you didn't mean to  :)
[16:39] <Jemsquash> Thanks verterok & jam. You've been very helpful. I'm off to bed.
[16:40] <Mez> :'(
[16:41] <Mez> bzr clean-tree doesn't clean them up
[16:41] <Lo-lan-do> bzr ignored | xargs rm
[16:41] <Lo-lan-do> Be sure to run "bzr ignored" first :-)
[16:41] <jam> Mez: bzr clean-tree --ignored
[16:41] <jam> actually, bzr clean-tree --detritus is what you want
[16:41] <Mez> :P I just found that
[16:42] <Mez> Lo-lan-do: cd $(bzr root); bzr ignored | awk '{print $1}' | xargs rm
[16:42] <Mez> :P
[16:43] <Lo-lan-do> "bzr ls --ignored" will save you the awk process
[16:43] <Mez> :P
[16:43] <Lo-lan-do> Hmm.  bzr root.  I've been hoping for that for quite some time.
[16:44] <Mez> Lo-lan-do: it's been there for ages
[16:44] <Lo-lan-do> Maybe I've just been missing it for quite some time :-)
[16:44] <Lo-lan-do> Is there a similar command for getting to the root of the branch (in case of a lightweight checkout)?
[16:45] <Mez> it's the same, I'm pretty sure
[16:45] <Lo-lan-do> Apparently not.
[16:45] <Lo-lan-do> I could of course parse the output of bzr info, but yuk.
[16:59] <Lo-lan-do> Maybe I could hack that.
[17:11] <awilkins> Isn't there an --xml for that?
[17:12] <awilkins> Aha, `bzr xmlinfo`
[17:12] <awilkins> (in the xmloutput plugin)
[17:17]  * awilkins loves the Jaunty installer bit that resizes your windows partition and inserts an Ubuntu one
[17:17] <Peng_> Cool, my VPS can run "bzr selftest --parallel subprocess" in 8m8s. :)
[17:18] <Peng_> My PC has been going for...10.5 minutes and is only done with 13k tests.
[17:19] <igc> jelmer: I haven't got those benchmark results yet sorry - still converting emacs to --development7-rich-root so I have a large dataset to benchmark against
[17:19] <igc> night all
[17:20] <Peng_> igc: Good night. :)
[17:48] <awilkins> ]/join ubuntu
[17:57] <Lo-lan-do> Anyone interested in a --branch-root option for bzr root?
[17:58] <Lo-lan-do> It basically returns the directory where the branch.conf is to be looked for.
[17:59] <Lo-lan-do> An implementation is at http://pastebin.com/f37535a4f (inspired by cmd_info)
[18:01] <Lo-lan-do> Works for standalones, branches in repositories, and lightweight checkouts.  Not sure what more it should do.
[18:02] <rockstar> abentley, if I wanted to initialize a shared repo in brisane-core, how do I do that?
[18:03] <Peng_> rockstar: "bzr init-repo --development6-rich-root", I guess?
[18:04] <abentley> Peng_: or --development-rich-root, which is an alias of that.
[18:04] <Lo-lan-do> development6 != 1.14?
[18:04] <abentley> Lo-lan-do: I believe 1.14 was a working tree format change.
[18:05] <abentley> Lo-lan-do: brisbane-core is still a development format, not a fully-supported format.
[18:05] <Lo-lan-do> I see.
[18:11] <cornucopic> vila, ping. Hello.. 'authentication.conf' is looked into ONLY when the user/pass is not given in 'bazaar.conf'. right?
[18:11] <vila> cornucopic: right
[18:12] <cornucopic> vila, Cool. I am updating the bug report with clear description and how to reproduce. will ping you here once done.
[18:12] <Peng_> Right. Lo-lan-do: 1.14 is the same as 1.9, except with a new working tree format that supports content filters.
[18:13] <vila> cornucopic: it's even better if you write the *test* that reproduces the bug :)
[18:18] <james_w> do I have to add things to possible_transports myself?
[18:18] <james_w> i.e. if I do branch.Branch.open(location, possible_transports=possible_transports)
[18:19] <james_w> to I have to add a transport from the resulting branch to possible transports before opening the next branch, or is that done for me?
[18:21] <james_w> f not None, created
[18:21] <james_w>         transports will be added to the list.
[18:21] <james_w> great
[18:22] <cornucopic> vila, yes. I have had a look at the test file..need to understand it a bit more to code up the test.
[18:23] <vila> cornucopic: you may want to use 'bzr selftest -s bt.test_smtp_connection' to avoid running the whole test suite (but always run a bare 'bzr selftest' before submitting)
[18:23] <vila> cornucopic: 'bzr selftest -s bt.test_smtp_connection --list' may be useful too
[18:30] <jam> abentley: I added some comments to NestedTreesDesign
[18:34] <amit_> vila, I lost my 'cornucopic' nick for sometime..I have updated the description. Its clearer now.
[18:36] <Lo-lan-do> Bzr hackers: is there any way my "bzr root --branch-root" could be reviewed/merged, or should I turn it into a new command in a local plugin?
[18:36] <beuno> Lo-lan-do, submit it for review!
[18:37] <beuno> push up a branch, and file a merge proposal
[18:40] <cornucopic> vila, ah. got it back. :)
[18:45] <cornucopic> cornucopic, now I have to figure how to write the test case to produce the bug :)
[18:46] <Lo-lan-do> beuno: Doing that.
[18:49] <vila> cornucopic: again, look at bzrlib/tests/test_stmp_connection.py for example of smtp connection tests and also in bzrlib/tests/test_config.py for example of configuration files tests
[18:50] <cornucopic> vila, Ok. Please take a look the bug description and let me know if you find anything ambiguous
[18:54] <vila> cornucopic: that's fine, we never had so precise bug descriptions :-)
[19:02] <abentley> jam: Thanks!
[19:20] <Lo-lan-do> Um.  bzr branch lp:bzr is at 270 MB and still not done.  Should I worry?
[19:21] <Lo-lan-do> (Downloaded, that is)
[19:21] <Lo-lan-do> [/                   ] 283113kB @  766kB/s | Transferring:Walking content. 24646/24646
[19:22] <beuno> Lo-lan-do, not at 766Kb/s   :)
[19:22] <Lo-lan-do> That's just a peak
[19:23] <Lo-lan-do> Anyway, the progress bar being where it is after probably 15 minutes leaves me worried.
[19:23] <abentley> jam: You ask "Does ``bzr commit foobar`` commit just the subtree foobar?" but foobar is a tree, not a subtree.
[19:24] <jam> abentley: so I probably misunderstood that exact statement, but what *does* "bzr commit subtree" do, and how do you get the various permutations of what you might *want* it to mean
[19:25] <javierder> Hello. I'm having a persistent " Sorry, there was a problem connecting to the Launchpad server. "
[19:25] <javierder> All day long =(
[19:25] <beuno> javierder, production servers are having problems. You can use edge
[19:25] <abentley> jam: I would expect it means "commit all the changes in the subtree, commit changes to the tree-reference".
[19:25] <javierder> beuno, ok, thanks!
[19:26] <abentley> jam: I don't have any particular answers for the others, but I presume we can add options.
[19:26] <beuno> javierder, there, you should be automatically redirected to edge now
[19:27] <javierder> beuno, magic!(?)
[19:27] <javierder> beuno, thanks again!
[19:29] <Lo-lan-do> beuno: Patch sent, without an URL for a public branch.  I grew impatient after 410 MB downloaded.
[19:30] <Lo-lan-do> Now back to trying to understand bzr-upload-pack and get it to work.
[19:44] <amit_> vila, Can I discuss the 'test_smtp_password_from_auth_config' with you
[19:44] <amit_> ?
[19:51] <vila> cornucopic: shoot :)
[19:52] <cornucopic> vila, In 'self.get_connection' it is creating the authentication.conf contents right?
[19:53] <cornucopic> vila, or the bazaar.conf?
[19:55] <vila> cornucopic: bazaar.conf (you should have a look at bzrlib/config.oy if only to know the classes declared there and their associated files)
[19:57] <cornucopic> vila, Ok!
[20:32] <james_w> from the streaming pull bugs mail:
[20:32] <james_w> If you are using stacked branches, then using bzr versions before
[20:32] <james_w> 1.13.2, 1.14.2 or 1.14 and above may create repositories that cannot be
[20:32] <james_w> streamed from.
[20:32] <james_w> A fix for this issue will be included in bzr 1.15rc1, to be released
[20:32] <james_w> on or about the 15th of May.
[20:32] <james_w> "before ... 1.14.2 or 1.14" looks odd
[20:33] <james_w> and does the "fix" in the second 'graph refer to a fix that will mean the server can stream from affected branches without the fix script?
[20:33] <james_w> rather than being a fix for the problem of creating such branches in the first place
[20:35] <cornucopic> vila, please take a look at http://pastebin.com/d4b9e5bce.
[20:37] <vila> cornucopic: 1) don't modify an existing test, add a new one instead
[20:37] <cornucopic> vila, you mean a separate file?
[20:37] <vila> 2) Create the AuthenticationConfig from a text file, you can use triple quotes to create multi-lines strings without embedding the \n
[20:38] <vila> cornucopic: no, a separate method whose name begins with 'test_'
[20:38] <cornucopic> vila, the one you see is create by me!
[20:39] <vila> Ho sorry, good then
[20:39] <cornucopic> cool.
[20:39] <vila> my eyes didn't catch the /password/server/
[20:40] <vila> 3) you want to test that the correct user/password is selected, testing the _smtp_server is not relevant
[20:42] <vila> 4) that means you should the auth configurations before calling get_connection()
[20:42] <vila> s/should/should create/
[20:43] <vila> 5) you can then test _smtp_username, _smtp_password
[20:43] <vila> 6) you add an additional test to check that if the password is not specified the user is prompted (remember that it was *your* use case :)
[20:45] <vila> no wait, we already have the test prompting for the password, instead we want to cross tests server with and without port
[20:46] <vila> cornucopic: ^
[20:48] <amit_> vila, we can continue here,,,
[20:50] <vila> amit_: ouch what is the last message you got ?
[20:51] <amit_> vila, 4) that means you should the auth configurations before calling get_connection()
[20:51] <amit_> vila, (my Linux kernel confgs have been tossed up, so I keep getting disconnected by my PPPD)
[20:52] <LarstiQ> 21:42:41 < vila> s/should/should create/
[20:52] <LarstiQ> 21:43:09 < vila> 5) you can then test _smtp_username, _smtp_password
[20:52] <LarstiQ> 21:43:52 < vila> 6) you add an additional test to check that if the password is not specified the user is prompted (remember that it was *your* use case :)
[20:52] <LarstiQ> 21:45:50 < vila> no wait, we already have the test prompting for the password, instead we want to cross tests server with and without port
[20:52] <vila> amit_: stop messing around with kernels :) Use a stable distribution !
[20:53] <vila> LarstiQ: thanks :)
[20:53] <amit_> vila, I have sobered down quite a bit and have stopped living on the bleeding eldge :)
[20:54] <amit_> vila, just that 'apt-get' makes it so easy :)
[20:59] <amit_> vila, but it prompts the password, which is just the way it should behave. Why do we test it? (My usecase didn't know about authentication.conf' )
[20:59] <amit_> vila, If you see in the description of the bug, its the 'host:port' issue, the earlier modification that I proposed is not required at all
[21:02] <vila> amit_: did you update the test ? Can you pastebin it again ?
[21:02] <amit_> vila, I interchanged the last two lines, as you suggested.
[21:02] <amit_> vila, nothing else..
[21:03] <vila> the last two lines are:
[21:03] <vila> #
[21:03] <vila>          #conn._connect()
[21:03] <vila> #
[21:03] <vila>          self.assertEqual('mail.com:25', conn._smtp_server)
[21:03] <vila> #
[21:03] <amit_> vila, I have interchanged them and uncommented out conn._connect()
[21:06] <vila> amit_: but you use the same object to connect twice, since the test uses a fake smtp server, it's better to connect only once
[21:07] <vila> amit_: in fact you shoudn't use _connect() here, only get_connection()
[21:07] <amit_> vila, twice? the connection is done only in conn._connect() right ? I don't understand...:(
[21:08] <amit_> vila, get_connection actually connects? ah..why so?
[21:08] <vila> amit_: ghaa, no, sorry, let me concentrate on that
[21:08] <Lo-lan-do> Am I right in understanding there's currently no API to unset an arbitrary value from a configuration file?
[21:09] <amit_> vila, Okay !
[21:09] <amit_> vila, from what I see, it returns a connection object..
[21:11] <vila> amit_: I'm re-reading the other tests, so, you still need to test that, if smtp_server embeds the port we still can match auth.conf (ports should never be embedded there, they *can* be specified explicitly though)
[21:13] <helebek> Hi guys, I have a question.
[21:13] <Peng_> helebek: That's cool, since someone probably has an answer. :)
[21:14] <helebek> When I try to do "bzr init" in a folder (in dos prompt in windows), I get an error saying, "bzr: ERROR: [Errno 2] Can't create tunnel: The system cannot find the file specified."
[21:14] <helebek> It seems a little under described to me, or maybe I am not understanding it.
[21:15] <helebek> The folder is on a mapped network drive.
[21:15] <helebek> However, I can do the same operation on another folder in the same drive.
[21:15] <amit_> you mean to say, even him smtp_server embeds port, there can always be a explicit 'port'  declared?
[21:15] <amit_> vila, ^
[21:16] <amit_> vila, s/him/if
[21:16] <vila> in authentication.conf, you use 'host=example.com, port=12', not 'host=example.com:12'
[21:18] <amit_> vila, That case will probably work, but the bug is in the case in which the port is embedded in 'host'. So, shouldn't the test only test that ? (I could make one addition to see that 'port' is 'None' ). What do you say?
[21:19] <vila> amit_: embedding the port in 'host' *is* a different bug (you're welcome to file it too :-), let's concentrat on that one
[21:20] <helebek> Never mind, my question. The problem is solved when I deleted the ".svn" directory from the target folder. I think it had weird permissions.
[21:20] <vila> it's legal to use smtp_server=example.com:1234
[21:20] <helebek> Thanks any way.
[21:20] <vila> amit_: we need to fill the gap between smtp_server allowing the port and authentication.conf not allowing it
[21:21] <vila> amit_: if only the host is speficied in authentication.conf it should still match
[21:22] <vila> amit_: that's the actual bug so your test should fail because we can't get the password from auth.conf with only host specified
[21:22] <amit_> vila, I think I am confused about which bug to squash :(
[21:22] <vila> amit_: then you can fix the code so that get_user() is called with host and port splitted which will allow auth.conf to match
[21:23] <amit_> vila, could you please modify the bug desc. https://bugs.launchpad.net/bzr/+bug/372800 ? That will help me.
[21:23] <vila> amit_: the bug is to call get_user() with a host embedding a port instead of separate parameters for host and port
[21:24] <vila> https://bugs.edge.launchpad.net/bzr/+bug/372800/comments/3
[21:24] <vila> amit_: The simplest approach seems to be to extract the port in smtp_connection.py just before calling auth.get_user() (auth.get_password() can reuse that).
[21:26] <amit_> vila, what about the test case that I just produced to reproduce the bug?   Which bug is it reproducing anyway? (Isn't the bug filed yet? :)
[21:26] <amit_> vila, Is it reproducing this: >> amit_: embedding the port in 'host' *is* a different bug (you're welcome to file it too :-), let's concentrat on that one<<
[21:27] <vila> I meant let's concentrate on #372800
[21:27] <amit_> vila, Yes. So, my test case is reproducing the  bug with 'host:pair' ?
[21:27] <mwhudson> jelmer: hello
[21:28] <mwhudson> jelmer: bzr-git seems to be working fairly nicely now
[21:28] <mwhudson> jelmer: seems very cpu dominated, but i guess that's mainly down to not using a chk format yet?
[21:28] <vila> amit_: your test use mail.conf in bazaar.conf and mail.com:25 in the auth.conf, that's not what you described in #372800, that's the opposite
[21:29] <Peng_> mwhudson: Which branch do you get dulwich from?
[21:29] <mwhudson> Peng_: trunk, i think
[21:29] <amit_> vila, Its one of the 2 cases described there.
[21:29] <amit_> vila, the vice-versa is also true
[21:30] <mwhudson> Peng_: http://people.samba.org/bzr/jelmer/dulwich/trunk/ r296
[21:30] <vila> amit_: no the vice-versa is another bug, host:port is not *valid* in auth.conf
[21:30] <Peng_> mwhudson: Oh, thanks. I tried that yesterday but it didn't exist or something.
[21:30] <amit_> vila, I see. But it works? that's the bug ?
[21:30] <vila> What works ?
[21:31] <mwhudson> Peng_: well, it existed the day before that i think
[21:31] <vila> oh, using host=mail.com:25 is not recognized as an error in auth.conf, yes, that's the other bug
[21:32] <amit_> vila, fine. I will file it with the test case :)
[21:32] <Peng_> mwhudson: Yeah. it exists again right now.
[21:32] <vila> amit_: you'll need another test for that, in test_config.py
[21:33] <vila> amit_: but let's fix the first first :)
[21:33] <amit_> vila, to check whether host is host:port ?
[21:33] <amit_> vila, Yes :)
[21:34] <amit_> vila, so, test case for the first bug..
[22:13] <eferraiuolo> I'm having an issue setting up a bzr server which two people have ssh accounts on. We can't get the file permissions right. After going through a lot of work to get a root repos dir group-owned by a user group both of us belong to with sticky group permissions, and setting our umask to include group write permissions by default. Even with this when we run bzr+ssh:// commands group-writable isn't being applied
[22:14] <eferraiuolo> It appears that bzr+ssh:// isn't using our ssh .profile umask setting
[22:15] <eferraiuolo> There basically appears to be no straight forward way to have a server with bzr repos and branches be shared among two different user accounts that are being accessed via ssh.
[22:17] <AmanicA> eferraiuolo: I also gave up at some point, and made a cron job that fixes everything every hour
[22:17] <jelmer> mwhudson: hey
[22:17] <jelmer> mwhudson: cool
[22:17] <jelmer> mwhudson: yeah, that's indeed most likely related to not using a chk format
[22:18] <AmanicA> eferraiuolo: something that has worked out better for me is bzr+https
[22:18] <jelmer> mwhudson: and CPU is always going to be the problem for bzr-git
[22:18] <AmanicA> eferraiuolo: through apache I think its possible to setup proper user permissions
[22:18] <jelmer> mwhudson: as it has to convert between git and bzr serialization
[22:19] <eferraiuolo> AmanicA: bzr+https, is that webdav that would allow writes?
[22:19] <jelmer> mwhudson: network usage is bandwidth bound and memory usage should be O(delta)
[22:19] <AmanicA> eferraiuolo: no just fastcgi
[22:20] <AmanicA> it allows writes
[22:21] <AmanicA> eferraiuolo: though maybe you can use webdav, but I don't really know
[22:22] <AmanicA> what webdav is and what it does
[22:24] <AmanicA> eferraiuolo: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi
[22:30] <james_w> jelmer: subvertpy and bzr-svn in the daily PPA, but the jaunty ppa branch failed with ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'"), so that's missing currently
[22:49] <poolie> hello all
[22:49] <james_w> hi poolie
[22:50] <thumper> hi poolie
[22:51] <jelmer> james_w: somebody else was maintaining the jaunty ppa branch I think, and created it from scratch (no relation to bzr-svn itself)
[22:51] <jelmer> moin poolie
[22:51] <thumper> poolie: I'd like to talk to you about stacking and brisbane-core at some stage
[22:51] <james_w> jelmer: ah, ok. I'll take a look another time when I get fed up of the failures and probably work of the Debian branch or something
[22:57] <poolie> hi thumper
[22:58] <poolie> jam, are you still around? want to chat?
[22:58] <poolie> hi jelmer
[22:59] <james_w> development-rich-root doesn't support stacking?
[22:59] <poolie> emmajane: the thing about fonts is interesting but it's not really a bug...
[22:59] <thumper> james_w: nope, not at the moment
[22:59] <james_w> damn damn damn
[22:59] <emmajane> poolie, I did say feature request.
[23:00] <thumper> james_w: yes
[23:00] <thumper> james_w: want to fix it?
[23:00] <thumper> heh
[23:00] <james_w> thumper: I wasn't aware of that when we were in London
[23:00] <poolie> james_w, lifeless is working on that soon i think...
[23:00] <thumper> james_w: neither was I
[23:00] <james_w> that means I can either push up large branches that stack, or smaller ones that don't
[23:01] <james_w> smaller ones was better for other reasons as well, but I very much doubt they are small enough to not explode the disk space usage
[23:02] <james_w> I should probably work in the latest non-development rich root format I guess?
[23:02] <poolie> james_w incidentally you have bzr pqm access now, not sure if you knew
[23:02] <james_w> poolie: you mean jml?
[23:02] <james_w> I've had mine for a while :-)
[23:03] <james_w> I should be doing a few more reviews though
[23:05] <jam> hey poolie, yeah I'm around for a bit
[23:05] <jam> (Guess I had my volume muted)
[23:08] <poolie> no i meant you james_w, i was just updating the RT list as wasn't sure if you knew
[23:09] <james_w> ah, I do, thanks
[23:09] <lifeless> hi
[23:09] <lifeless> poolie: what am I working on soon ?
[23:10] <poolie> let me check if it's actually true :-) i was referring to b-c stacking, but i only remember you mentioning it
[23:11] <lifeless> It came up yesterday when I was talking with thumper about some of the implications of moving a trunk to bbc today
[23:11] <lifeless> Its not in my personal pipeline at all
[23:11] <lifeless> Its a disk format capabilities thing; I think its in the vila/jam/igc grouping
[23:12] <lifeless> igc seems to agree, but noone seems to have it targeted to do
[23:16] <james_w> are there in-efficiencies in bbc->older format transfer?
[23:16] <lifeless> james_w: stacking is done at the serialisation layer, so we can't [yet] stack cross serialisers
[23:17] <james_w> I remember being partially upgraded over one format change was terribly inefficient
[23:17] <lifeless> james_w: secondly, stacking is disabled in bbc itself and it needs to be enabled, fixed and tested
[23:17] <james_w> what's your estimate for that work?
[23:17] <lifeless> bbc-> older may be slow, it generates full xml on the way
[23:18] <james_w> ok
[23:18] <lifeless> james_w: I don't have an estimate for it at the moment
[23:18] <lifeless> spiv and I have a branch that is aiming at fixing bbc<->other formats to be more efficient over the wire
[23:18] <james_w> ok
[23:19] <james_w> we had decided to go with bbc for all package branches, but I don't think we can do that currently
[23:19] <jml> james_w: yeah, we were just talking about
[23:19] <james_w> I'd like to understand the various implications so that we can make a sensible decision of how to proceed
[23:19] <jml> james_w: no stacking is a deal-breaker.
[23:19] <james_w> hey jml
[23:20] <jml> (oh look, package branches auto highlights)
[23:20] <james_w> jml: I agree
[23:20] <james_w> heh :-)
[23:20] <jml> james_w: so, I'd suggest 1.9-rich-root
[23:20] <james_w> that's what I am thinking
[23:20] <jml> lifeless, poolie: any thoughts?
[23:20] <james_w> that means a couple of things:
[23:20] <james_w> 1. an upgrade step once bbc is stable
[23:21] <james_w> we will have needed development6 -> 2.0 upgrade, but that is less work I assume
[23:22] <james_w> and would have fewer issues about inefficiencies in a partial upgrade situation
[23:22] <lifeless> starting with rich roots is good
[23:22] <lifeless> it will mean you don't have a million little root changes
[23:22] <james_w> 2. I've forgotten 2
[23:22] <lifeless> [I mean fresh imports into rr]
[23:22] <james_w> it's not as good :-)
[23:23] <james_w> we don't get to help you dogfood on a massive scale
[23:24] <lifeless> jam: ping
[23:25] <lifeless> poolie: if you want skype let me know ;P
[23:27] <james_w> lifeless: do you agree on 1.9-rich-root then?
[23:28] <lifeless> james_w: in the absence of vila/igc/jam standing up and saying hallelujah I will have stacking working by tuesday.
[23:28] <james_w> ok, thanks
[23:37] <thumper> lifeless: will that be in time for 1.15?
[23:38] <thumper> is the 15th the date for 1.15rc1?
[23:39] <poolie> thumper, lifeless, i filed bug 373455 as a handle
[23:40] <lifeless> poolie: perhaps these items are key enough we should use bugs to track them all
[23:40] <lifeless> poolie: the 'before release items' I mean
[23:40] <poolie> yes, i think so
[23:41] <poolie> except i dislike bugs like "think about X"
[23:41] <poolie> how do you know when it's done
[23:43] <AmanicA> when your done thinking:)
[23:48] <lifeless> poolie: I do to
[23:48] <lifeless> poolie: so we shouldn't have ones for thinking about
[23:48] <poolie> lifeless: jam said he'll pass `log DIR` back to ian with some thoughts and look at stacking
[23:48] <lifeless> if the thinkng would result in an importance decision, make the bug critical
[23:48] <poolie> probably not tonight though
[23:49] <lifeless> and we can then think about it; if its not critical we drop the importance
[23:49] <lifeless> how does that sound?
[23:53] <poolie> sure, i didn't want to get too meta
[23:53] <poolie> i think as long as there is a predicate like "decide whether or not to do XX" then it's actionable
[23:54] <emmajane> poolie, you're far too practical. :)
[23:54] <awmcclain> I have a branch that I haven't wroked on in a while, but that has significant changes from trunk. I'm about to start work again on the branch, but I want to merge in the changes from trunk since I created the branch. The problem is, when I merge from trunk, all the new files that I've created in the branch get removed. What are my options?
[23:54] <poolie> awmcclain: really?
[23:54] <awmcclain> poolie: Yup.
[23:55] <poolie> that shouldn't happen, without them being conflicted or something
[23:55] <poolie> are these plain bzr branches
[23:55] <awmcclain> poolie: trunk is a bound branch (it's a checkout)
[23:56] <poolie> but no foreign branches?
[23:56] <awmcclain> poolie: From another VCS? No.
[23:59] <poolie> awmcclain: so, unless there's a bug in bzr, those files shouldn't be removed unless your changes have already been merged into trunk and then removed there..