[00:38] <igc> morning all
[00:42] <jelmer> hi Ian
[00:42] <jelmer> lifeless: it looks ok, but it seems like the check patch is significantly changeed, not just polished?
[00:43] <igc> hi jelmer. Thanks that your reviews over the weekend. Much appreciated
[00:43] <igc> morning lifeless
[00:44] <jelmer> igc: svn-keywords is already partially working :-)
[00:44] <igc> jelmer: I'm actually keen to get bzr-keywords into the core as well, so you can assume that code is there and build on it
[00:45] <igc> jelmer: now that the fallback bit is in place, you'll only need to register how to expand the keywords I think
[00:45] <igc> jelmer: and you get the sweet publishing features in bzr-keywords for free as well
[00:46] <igc> next weekend maybe :-)
[00:47] <stbuehler> jelmer: saw my feedback for svn / dpush ?
[00:47] <jelmer> stbuehler: hi
[00:47] <jelmer> stbuehler: where?
[00:47] <jelmer> (I haven't seen anything yet)
[00:48] <stbuehler>  jelmer: just wanted to give some feedback: bzr dpush does *not* give you the svn-revisions back, even if you had new commits pushed to upstream svn
[00:49] <stbuehler> perhaps that works if you never used the normal push, didn't try that
[00:49] <stbuehler> seems like i cannot force bzr to rebase to the svn branch
[00:50] <jelmer> stbuehler: no, it doesn't as that would require changing existing revisions; we can keep a map though and display that sort of information
[00:51] <lifeless> jelmer: yes, 0.9.5 to 0.9.6 added a special linker script
[00:51] <stbuehler> i wouldn't mind changing them, if it where an option :)
[00:52] <jelmer> stbuehler: can you please file a bug report about this? I'll try to get it fixed for the next version
[00:53] <stbuehler> jelmer: so dpush should change existing revisions? k, let me try :)
[00:54] <jelmer> stbuehler: yeah, dpush basically pushes all revisions into the remote repository
[00:55] <jelmer> stbuehler: and then fetches the revisions that were created remotely and overwrites the local revisions with them
[00:58] <jelmer> stbuehler: push (by definition) only changes the remote revision
[00:58] <jelmer> s/revision/branch/
[00:59] <stbuehler> yes, that is perfectly valid :)
[01:02] <lifeless> jelmer: the 0.9.6 patch is polish from the subunit point of view, its just updating against the check project
[01:18] <jelmer> stbuehler: oh, maybe I misunderstood
[01:18] <jelmer> stbuehler: dpush won't change any previously "bzr push"'ed revisions of course
[01:19] <jelmer> it only affects revisions not yet in svn in any form
[01:23] <stbuehler> i mentioned i "dpush"ed new commits, which were not in svn
[01:23] <stbuehler> but maybe it only works if you never used "push"
[01:24] <jelmer> stbuehler: sorry
[01:25] <jelmer> stbuehler: it should work fine if older revisions were pushed
[01:25] <jelmer> stbuehler: is this repo public?
[01:25] <stbuehler> svn://svn.lighttpd.net/spawn-fcgi/trunk
[01:26] <jelmer> thanks
[01:28] <jelmer> stbuehler: ok, I figured out what's happening, this shouldn't be too hard to fix
[01:47] <jelmer> lifeless: btw, I hope to split out libtorture from samba at some point
[01:48] <jelmer> so we can use that in bitlbee, ctrlproxy, etc in favor of libcheck
[01:48] <lifeless> jelmer: thats your C testing infrastructure?
[01:48] <jelmer> lifeless: yep
[01:48] <jelmer> it already does subunit
[01:48] <lifeless> jelmer: I'd be inclined to put patches into libcheck, the fork isolation really is nice
[01:49] <jelmer> lifeless: is there any chance of your subunit patch actually making it into libcheck?
[01:49] <lifeless> jelmer: yes
[01:50] <lifeless> I've resubmitted it, chris pickett has ack'd that they were being overly nitpicky
[01:51] <jelmer> hmm
[01:54] <lifeless> entry point to the recent dicussion http://sourceforge.net/mailarchive/message.php?msg_name=1235597368.24285.63.camel%40lifeless-64
[01:54] <lifeless> its a terrible list archive ui
[01:59] <jelmer> ah, cool
[02:24] <jelmer> bleh, sf svn is still slow :-(
[02:24] <jelmer> lifeless: you are using bzr-svn for check development, right ? >-)
[02:24] <lifeless> jelmer: yes, do you want me to push trunk in bzr format somewhere?
[02:25] <jelmer> lifeless: yes, if it's not too much trouble
[02:25] <lifeless> sure thing
[02:26] <jelmer> I can do a pull myself, but it looks like it's going to take at least 30 min at this rate..
[02:27] <lifeless> there is a  https://code.edge.launchpad.net/~vcs-imports/check/trunk :)
[02:28] <jelmer> lifeless: except that imports from CVS, and hasn't been updated since 2005 :-)
[02:29] <lifeless> heh. we should redirect it then :) . bzr+ssh://bazaar.launchpad.net/%7Elifeless/check/svn
[02:29] <lifeless> pushing my subunit branch now
[02:30] <jelmer> lifeless: thanks
[02:32] <lifeless> jelmer: bzr+ssh://bazaar.launchpad.net/~lifeless/check/subunit
[02:34] <jelmer> got it
[02:34] <jelmer> did launchpad just upgrade to 1.13 or something?
[02:34] <lifeless> not for 2 more days
[02:35] <jelmer> it's too freakishly fast all of a sudden
[02:38] <spiv> Last week bzr.dev got a fix for a performance bug when pushing to pre-1.13 servers, maybe it's that?
[02:38] <lifeless> I think jelmer was pulling :)
[02:39] <jelmer> well, pushing was the main thing that got faster
[02:39] <jelmer> I pushed a 130Mb repo to lp in < 1m
[02:42] <lifeless> that would be spiv's fix
[02:45] <spiv> :)
[03:25] <lifeless> lunch, back soon
[03:42] <jml> lifeless: the only subunit branch up for review I see is https://code.edge.launchpad.net/~radix/subunit/report-errors-better/+merge/4292
[03:42] <lifeless> jml: jelmer reviewed the polish branch
[03:42] <jml> oh cool.
[04:02] <lifeless> jml: if you didn't get notice about the subunit branch, are you subscribed appropriately to trunk ?
[04:25] <thumper> lifeless: what would cause a knit to become corrupt and raise SHA1KnitCorrupt when calling show_log?
[04:26] <lifeless> an actual knit?
[04:26] <lifeless> or something in a pack?
[04:30] <lifeless> thumper: ^
[04:34] <ovnicraft> hi folks. is it posible configure bzr with emacs to commit comments?
[04:43] <bob2> ovnicraft: recent emacs has vc-bzr built in
[04:47]  * igc lunch
[04:52] <ovnicraft> bob2, yep i got it thx
[04:57] <beuno> igc, hi
[04:58] <beuno> I was looking at your mergeline cache RFC supersede your plugin?
[05:01] <lifeless> tracked down the commit failure
[05:02] <lifeless> [bah]
[05:25] <igc> hi beuno
[05:31] <beuno> hey igc
[05:32] <beuno> how are you?
[05:33] <igc> beuno: flat out - trying hard to make our next-gen the best it can be
[05:34] <igc> beuno: no, it doesn't supercede it - it helps it though
[05:34] <beuno> igc, I've seen. It's impressive work
[05:35] <beuno> ok, good, because I was about to spend the weekend working on loggerhead + your plugin to get them working well together
[05:35] <igc> beuno: there's still a need for caching the full history to make log *really* fast - that the revnocache
[05:35] <beuno> I obviously got sidetracked by RL, but was very clse  :)
[05:35] <beuno> *cloase
[05:35] <igc> the mergeline case helps *one* special but importasnt case - lookup of a single non-mainline revno
[05:35] <beuno> hotcha
[05:36] <beuno> (typing sucking)
[05:36] <beuno> I see
[05:36] <beuno> brisbane-core is going to rock...
[05:37] <fullermd> Hmm.  Is there some reason it can't help in other cases?
[05:37] <lifeless> igc: a 22K file is quite a lot of data to be updating on push/pull over the wire... I'm inclined to react cautiously and suggest taking the revnocache approach
[05:38] <fullermd> I can see that it wouldn't save you any total time on log (since you pull all the info anyway), but wouldn't it let you number and start displaying more quickly?
[05:39] <igc> lifeless: it doesn't get updated on push or pull
[05:39] <igc> lifeless: only the first time log is used on that remote branch
[05:57] <Stanlin> hi
[06:00] <lifeless> igc: I don't get the connection between my ocmment and your reply :)
[06:03] <Stanlin> May i use BZR with any kind of files?
[06:04] <igc> lifeless: log, status and diff are read operations
[06:05] <igc> you suggested not updating files during them
[06:05] <fullermd> bzr currently maintains an embargo against Cuban and North Korean files...
[06:05] <igc> I'm saying "that's the whole basis of the design"
[06:05] <igc> I'm now updating the mergeline-store file *outside* the read transaction
[06:06] <igc> so I think it's safe
[06:06] <igc> given I check the data is still current before saving it
[06:06] <igc> and lack of data there is handled without a drama
[06:06] <igc> lifeless: make more sense now?
[06:07] <igc> lifeless: and sorry if the reply wasc rushed - I'm tired today :-(
[06:07] <igc> s/wasc/was/
[06:10] <lifeless> igc: well, its clearly vulnerable to race conditions
[06:11]  * fullermd is somewhat uncomfortable on principle with the idea of 'log' writing stuff...
[06:11] <lifeless> igc: I assume I'm not understanding the cache, and I'm really concerned that this is being rushed into - we have only this week to freeze the bbc format, if I remember the dates
[06:13] <igc> lifeless: right. fwiw, I'm not doing anything that couldn't work on bzr.dev now - it's not tied to brisbane-core though I'm ok with doing that
[06:13] <lifeless> igc: this isn't clearly correct, and has serious potentially serious issues as all caches do.
[06:14] <lifeless> not to mention that writing during a read operation is simply impossible on e.g. http:// urls, so its entirely useless there
[06:14] <fullermd> Are serious potentially trivial issues more or less hazardous than trivial potentially serious issues?
[06:14] <igc> lifeless: true. But the important case if local so we could easily restrict it to that
[06:14] <igc> s/if/is/
[06:14] <igc> and remove any network concerns
[06:15] <lifeless> igc: I'm finding the discussion hard, it feels like you're presenting this as all-or-nothing, and already-analysed-this-is-right, rather than engaging
[06:15] <igc> lifeless: sorry - I'm not meaning to come across like that
[06:16] <igc> lifeless: and I'm very interested in how you think it's subject to race conditions and/or ought to proceed
[06:16] <lifeless> igc: so as a design principle we are trying to remove all our caches
[06:17] <lifeless> for instance, one possible cache that was proposed as an alternative to brisbane-core was to cache inventory deltass in commit objects
[06:17] <lifeless> we successfully avoided that while still getting good performance
[06:17] <lifeless> which means we get good performance on arbitrary tree deltas rather than only on adjacent ones
[06:18] <igc> lifeless: really? That's sounds crazy. Caches are necessarily bad. Even bash has them :-)
[06:18] <igc> s/are/aren't/
[06:19] <bob2> Stanlin: yes
[06:19] <lifeless> for this case, I'm interested in: what the root problem is. (is it revnos? is it index performance? something else?) I'm interested in why the operations are faster *overall* with this - what work is it actually saving, and why
[06:20] <lifeless> igc: caches increase data storage, add the opportunity for bugs relateed to coherency, increase writes needed and can often reduce performance overall
[06:20] <Stanlin> bob2: including graphics and big files??
[06:21] <fullermd> Stanlin: It will _work_ for them (mod performance or memory issues with large files, anyway).  Whether it's particularly _useful_ depends on your situation.
[06:22] <Stanlin> fullermd: awesome, ok so i can go ahead and use bzr for all my desktop
[06:23] <fullermd> If any files are a significant fraction of your available physical memory (ISO's and the like are common offenders), you're likely to hit some unpleasantness.
[06:23] <fullermd> And of course a number of operations (like merging) are a lot less useful with binary files.
[06:23] <Stanlin> fullermd: well for starters i just want to do it with small documents
[06:24] <Stanlin> fullermd: what is the best scenario to , use bzr, as server,   and lets all users push and pull, without editors or any control?
[06:25] <lifeless> igc: so we really want caches where they really appear to be the best answer, not the first answer.
[06:26] <fullermd> Stanlin: That's way too broad a question to answer in general   :)
[06:26] <lifeless> igc: and this one, given the data I have so far, appears to be the first answer with none of the deep questions answered
[06:26] <fullermd> Stanlin: Very dependant on exactly what your situation is.
[06:27] <Stanlin> is bzr superior to Git?
[06:27] <lifeless> igc: I may well be wrong and have missed the guts of the analysis
[06:27] <lifeless> Stanlin: we think so :)
[06:27] <fullermd> Yes and No and See Me Next Tuesday.
[06:27] <Stanlin> gnight all :D
[06:29] <lifeless> woo, faster commit landing
[06:30]  * Stanlin performs aptitude remove git
[06:35] <igc> lifeless: it's very early days w.r.t the mergeline cache. It works but that doesn't make it the answer. Please don't reject it on principle though. From *my* analysis, it's the smallest amount of data needed to make some selected use cases perform well. I done lots in work in recent months on stuff like revnocache and this is the only part of that plugin that I've ever thought should go in the core
[06:35] <igc> And if it's not core-worthy, it will go into revnocache instead
[06:36] <lifeless> igc: I won't reject it on principle; but to put it in core I would want those deeper questions considered
[06:36] <igc> lifeless: sure, and I have considered cache currency in the design already, for example
[06:37] <lifeless> I need to head off; day is done and all
[06:37] <lifeless> http://pqm.bazaar-vcs.org/
[06:37] <lifeless> record-iter-changes commit - landing now
[06:38] <igc> lifeless: well done and thanks no the commit stuff
[06:38] <igc> s/no/on/
[06:39] <igc> and for playing devil's advocate :-)
[06:40] <fullermd> FWIW, I agree in principle too...
[06:40] <fullermd> I'd rather see fixable performance issues fixed (even if rather later) than papered over.
[06:40] <fullermd> Once papered over, fixes tend to get pushed back a long ways, and even when made, the papering often remains messing things up worse   :|
[06:41] <fullermd> (this of course expresses no opinion whatsoever on where the current questions falls on that spectrum, since that's all the opinion I'm qualified to express...)
[06:43] <igc> fullermd: we currently cache the last revno and last-rev-id for the mainline
[06:43] <lifeless> igc: revno is a cache, last-rev-id isn't
[06:43] <lifeless> :)
[06:43]  * lifeless goes
[06:44] <igc> fullermd: all I'm doing is extending the idea to each "mergeline" so finding a rev-id for x.y.z doesn't require a full graph build
[06:45] <fullermd> igc: Convincing me of the fitness or lack thereof of some internal mechanism is kinda wasted effort   ;)
[06:47] <fullermd> I have pro and con feelings on the issue, but considering how drastically uninformed they are compared to anybody else you talk to about it...
[06:51] <igc> fullermd: thanks for the tip. I was being polite and offering an explanation in case you cared :-)
[06:54] <fullermd> Oh, I do appreciate that.  It's why I'm here and occasionally even pay attention   8-}
[06:55] <fullermd> Just that pretty much any insight or judgement that might occur to me, lifeless already thought of 20 minutes before I read any descriptions, and either already brought up or mentally discarded as absurd.
[07:41] <vila> hi all
[07:42] <Peng_> Good morning.
[07:43] <igc> hi vila
[08:09] <thumper> can someone tell me the difference between 1.13 and 1.13.1?
[08:09] <thumper> will it matter server side?
[08:09] <thumper> should LP use 1.13 or 1.13.1?
[08:17] <Peng_> thumper: Look at the announcement: 1.13.1 fixes a version number mismatch in bzr vs. bzrlib, fixes an error in NEWS (I think), fixes 'merge --force', and bzr-1.13.tar.gz didn't include the Pyrex-generated C files. Does any of that matter for LP?
[08:18] <Peng_> thumper: If LP doesn't use "bzr", doesn't use "bzr --force" and has Pyrex installed on the build machine or doesn't use the tarball in the first place, I guess it doesn't really matter.
[08:26] <thumper> Peng_: thanks, I think LP will stick with 1.13
[08:26] <thumper> :)
[08:27] <Peng_> Err, "bzr merge --force", I meant..
[09:03] <spiv> thumper: I agree with Peng_'s assessment.  Also, we write the NEWS file for a reason ;)
[09:03] <thumper> spiv: don't expect people to actually read NEWS, geez
[09:03] <thumper> spiv: what makes you think I have a copy of trunk?
[09:05] <spiv> thumper: Well, I'm reasonably sure you have a tool to browse files in branches online
[09:06] <spiv> thumper: but also the relevant parts of NEWS are sent in each release announcement
[09:06] <thumper> spiv: geez, why all this reading when someone can just ask :P
[09:07] <spiv> thumper: of course, http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/head:/NEWS would be even better if LP didn't time out trying to render it ;)
[09:07] <spiv> thumper: when you ask, all I do is go and read that file
[09:07] <spiv> thumper: so you might as well cut out the middle man :)
[09:07] <thumper> spiv: and save me the trouble :)
[12:09] <VSpike> Greetings.  A general question.  I have a project where parts of it are customized files for the end customer - e.g. web pages, set up files, theme files etc...
[12:09] <VSpike> I want to maintain these branches in parallel for the long term.  Is there a way to make this easier, i.e. to ensure that some changes in a branch never get pushed to the parent?
[12:10] <VSpike> The other approach would be to treat all the customer specific files as a separate project under source control.
[12:10] <VSpike> But bzr doesn't seem to handle related sub-projects yet - unless that has change since I last checked?
[12:26] <yogsototh> VSpike: got the same problem with 3 différent environments.
[12:26] <yogsototh> I use 3 differents branches
[12:26] <yogsototh> And I never use pull nor push
[12:26] <yogsototh> but only merge
[12:27] <yogsototh> That should work just great
[12:38] <VSpike> yogsototh: do you mean that you never make code changes in the child branches that need go back to parent?
[13:20] <joie> Apologies if I'm asking the obvious - but I can't find it in the docs. Is there any way of finding out the common ancestor a merge command is using?
[13:21] <joie> (I'm kinda new to bzr - but been using baz for a long while, trying to make the switch!)
[13:21] <lifeless> joie: bzr find-merge-base
[13:22] <lifeless> joie: found in 'bzr help hidden-commands'
[13:22] <joie> Ahhah - sounds like a useful thing to know - thanks!
[13:23] <joie> I'm essentially trying to do the equivalent of a baz apply-delta to put all the work from one branch onto my working branch, and want to be sure that merge is doing the "right" thing!
[13:43] <james_w> jelmer: hey, thanks, I was just about to take another look at bzr 1.13.1 and I saw the ACCEPTED mail.
[13:56] <jelmer> james_w: it turned out there was a bug in the python2.6 package in experimental that I had instlaled
[13:56] <jelmer> james_w: uninstalling it made the problem go away
[14:05] <Tak> jelmer: hello
[14:13] <igc> night all
[14:18] <emmajane> igc, just got your email. The reason I emailed you back with the link was because I don't have time to do this right now.
[14:32] <liw> what's this mean: Unable to contact DBus session: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed.
[14:36] <jelmer> liw: bzr-dbus was unable to contact your local DBus
[14:37] <jelmer> liw: while attempting to signal that a new commit was made / branch was updated
[14:39] <liw> ok. why is dbus being contacted? I'm not running under X for that command (ssh into the machine; there is an open X session in the console, though)
[15:14] <jelmer> liw: you have bzr-dbus installed probably
[15:14] <jelmer> liw: newer versions of bzr-dbus will not show any error / output if it fails
[15:22] <liw> jelmer, ok, then I'll just ignore it, thanks
[15:34] <jam> vila: just a quick question, if you managed to fix the duplicate "CHKInventory" stuff.
[15:35] <vila> ajmitch: yu[
[15:35] <vila> ajmitch: sorry wrong target
[15:35] <vila> jam: yes ?
[15:36] <jam> vila: ?? or 'yes' :)
[15:36] <vila> jam: I pushed --overwrite on vilajam
[15:36] <vila> jam: 'just quick question, if' I was waiting for the question :)
[15:41] <vila> jam: the fix may not be the cleanest one (you can still find the duplicate in a couple of revisions if you dig enough), but I think it's "good enough"
[15:49] <meuserj> Is there an existing plugin or other method for creating a default template for commit text?
[15:50] <jelmer> meuserj: there's no plugin yet, but there is a hook you can use if you're going to write such a plugin
[15:55] <vila> jam: in gc, _compress last returned value is length, documented as 'number of bytes accumulated in the group output so far' but the code seems to calculate the delta length instead
[15:56] <vila> vila: it seems to be used only in _insert_record_stream and even there that seems like a left over
[16:03] <jam> vila: so the return is currently (sha1, start_of_record, end_of_record, kind, length_of_record)
[16:03] <jam> the last part is obviously redundant with end_of_record - start_of_record
[16:04] <vila> jam: not so obviously :-) but thanks for confirming, it's not always the case for the python impl. but if the semantic is correct, I'll just delete it
[16:05] <vila> jam: can I get also get rid of the last_fulltext_len in _insert_record_stream ?
[16:07] <jam> vila: sure, I think there was something about returning the size of the fulltext that was being compressed, etc
[16:07] <jam> I would probably just get rid of 'length'
[16:07] <jam> (evolving interfaces :)
[16:08] <vila> jam: ok, doing it right now
[16:08] <jam> so stuff like last_fulltext_len was meant as a possible way to play with varying the compression decisions
[16:09] <vila> I can 1) get rid of it as well as length, 2) keep it and update it with end - start
[16:10] <jam> vila: We can always bring it back if we decide we want to use it
[16:10] <jam> for now, cleaner code is probably better for landing in bzr.dev
[16:10] <vila> ok
[16:22] <jelmer> jam: hi
[16:22] <jelmer> jam: How do I create a branch5 format programmatically?
[16:31] <jam> jelmer: in a test suite or just from bzrlib?
[16:32] <jelmer> jam: in a testsuite
[16:33] <jelmer> for other branch formats I can use ._matchingbzrdir
[16:33] <jam> jelmer: self.make_branch('dirstate'
[16:33] <jam> would probably be fine
[16:33] <jam> at least that was the last one to use Branch5
[16:33] <jam> if you need more control than that, then I can go through it
[16:34] <jam> (that will be a knit format repo, with a branch5 branch)
[16:34] <jelmer> jam: is there any way to obtain that from a BranchFormat instance?
[16:34] <jam> jelmer: are you saying you need the name of the format?
[16:35] <jelmer> jam: I have a BranchFormat instance (BzrBranchFormat5) and need to create a branch that uses it
[16:35] <jam> bzrlib.branch.BranchFormat5.initialize()
[16:35] <jelmer> preferably as generic as possible, without special casing BzrBranchFormat5
[16:35] <jelmer> This is for the InterBranch tests
[16:35] <jam> jelmer: my_format.initialiaze(a_bzrdir) ?
[16:35] <jam> my_format.initialize(a_bzrdir) ?
[16:35] <jelmer> jam: but in that case what format can a_bzrdir have?
[16:36] <jam> jelmer: there is only 1 'metadir' bzrdir format
[16:36] <jelmer> can I use a BranchFormat5 with a recent repo format?
[16:36] <jam> jelmer: yes
[16:36] <jam> it will "work" we just don't give you a way to specify that with a short name from 'init'
[16:36] <jelmer> ah, neat, I wasn't aware of that
[17:14] <jam> vila: so where are you at? I haven't seen your commit showing up yet :)
[17:15] <vila> I tracked down the unicode symlinks error back to bzr.dev@4216 :-/
[17:15] <vila> Can you run ./bzr selftest -s bt.branch_implementations.test_sprout.TestSprout.test_sprout_with_unicode_symlink in your bzr trunk ?
[17:18] <vila> jam: ^ ?
[17:19] <jam> vila: currently on win32, I'm sure it will pass just fine :)
[17:19] <vila> jam: lol, yeah, but I don't understand how pqm let it pass
[17:21] <jam> vila: on my server, that test fails about 5 times
[17:21] <jam> 'ascii' codec can't decode byte 0xce
[17:21] <vila> yup, that one
[17:21] <jelmer> with or without the dirstate pyrex extensions?
[17:21] <jam> jelmer: both
[17:21] <vila> jelmer: both
[17:22] <jam> vila: maybe a python2.4 issue?
[17:22] <vila> revno 4215 succeeds, 4216 fails
[17:22] <vila> just reproduced it with 2.4 too 8-/
[17:26] <jam> vila: so I could see where 'iter_changes' is accidentally using 8-bit symlink_target rather than unicode, but yeah, I don't see how pqm didn't fail just like us
[17:28] <vila> UnicodeFilenameFeature not available on pqm ?
[17:28] <jam> vila: certainly possible, I don't know
[17:28] <jam> actually, probably likely
[17:28] <jam> try setting LANG=fr
[17:28] <jam> or something
[17:28] <jam> rather than fr.UTF-8
[17:29] <vila> EMYOSDOESNTSPEAKFRANCAIS :)
[17:29] <vila> LANG=en_US.UTF-8
[17:29] <vila> always
[17:30] <jam> :)
[17:30] <jam> so LANG=en_US  then :)
[17:30] <jam> vila: yeah, it passed with a skip here
[17:30] <vila> yup, tests are skipped in that case
[17:32] <vila> crap
[17:33] <vila> jam: by the way, I pushed my last changes at vilajam
[17:34] <vila> jam: you may want to pull --overwrite from there though
[17:34] <vila> jam: I mean, I you keep a mirror of that one
[17:34] <vila> jam: I mean, IFF you keep a mirror of that one
[17:36] <jam> vila: well, I'm a bit saddened that you keep '--overwrite'ing all of my branches. You pushed up your history for brisbane-core, and vilajam...
[17:37] <vila> jam: ?? I try to respect the mainline most of the time, but here you had committed *on top* of the error, so I tried to get rid of the problem as best as I can :-/
[17:39] <vila> jam: I tried alternate ways to fix it, but most of them ended up with the wrong annotation for both CHKInventory and CHKInventoryDirectory (all the lines were attributed to *me*), at least now the attributions are correct and  your revisions still present
[17:40] <jam> not a big deal, really
[17:40] <jam> I was just surprised to see both mainlines changing to "merged bbc@" especially since it was the bbc trunk
[17:40] <vila> I thought correct annotations were more important than revision history :-/
[17:41] <jam> vila: personally I use "bzr log" about 20x more than "bzr annotate", but as I said, in another week I won't even notice
[17:41] <vila> jam: and yes, the way I rebuilt my loom wasn't the clearest either :-/
[17:42] <vila> jam: on the other hand, may be you should push to jamvila :)
[17:43] <jam> :)
[17:51] <vadi2> does bzr use sha1 behind the scenes?
[17:52] <james_w> yes
[18:24] <luks> heh, python is going to use mercurual
[18:28] <cody-somerville> luks, its official?
[18:28] <cody-somerville> luks, link?
[18:28] <luks> http://mail.python.org/pipermail/python-dev/2009-March/087931.html
[18:44] <jszakmeister> yep, it's official.
[18:47] <cody-somerville> That sucks :(
[18:47] <cody-somerville> bzr rocks
[18:48]  * jszakmeister agrees
[18:48] <cody-somerville> Is there an announcement or anything?
[18:48] <jszakmeister> It probably boiled down to performance... the email is a little vague, but I agree... a decision needed to be made
[18:49] <jszakmeister> luks put the url in IRC
[18:58] <cody-somerville> but bzr is fast now :(
[19:06] <BFrank> that is the joy of open source, you are free to choose amongst many good choices
[19:08] <cody-somerville> I can't wait until Launchpad supports git and mercurial imports
[19:09] <santagada> is the code for launchpad avaliable somewhere already?
[19:09] <cody-somerville> santagada, You might want to ask in #launchpad - this is #bzr
[19:09] <Toksyuryel> and each choice typically tries its best to make switching between choices as painless as possible
[19:09] <mwhudson_> cody-somerville: soon!
[19:09] <mwhudson_> for git
[19:09] <santagada> cody-somerville: no one here knows? I would supose it is pretty important
[19:10] <cody-somerville> santagada, Why?
[19:10] <cody-somerville> mwhudson_, :)
[19:12] <antoranz> when I pack, can I delete everything in .bzr/repository/obsolete_packs/?
[19:12] <beuno_> antoranz, in general, yes
[19:12] <antoranz> ok
[19:19] <bialix> hi guys, in which time igc (Ian) will be here?
[19:20] <beuno> bialix, I'd say in about 3 hours or so
[19:20] <bialix> thanks. perhaps too late for me
[19:21] <BFrank> why doesn't it cleanup obsolete packs?
[19:22] <bialix> igc: I'd like to talk about eol labels and strategies with you tomorrow morning (~ 6-8 am UTC). OK?
[19:22] <beuno> BFrank, I don't know all the details, but it mostly has to do to ensure that we don't run into data loss
[19:22] <BFrank> hmm
[19:22] <bialix> igc: I'll be there tomorrow.
[19:22] <beuno> BFrank, there are some crazy scenarios where that happens
[19:22] <BFrank> when exactly does it cleanup the obsolote packs?
[19:22] <BFrank> shouldn't there be a point when it is safe for bazaar to clean them up?
[19:23] <james_w> it cleans them up before writing any more
[19:23] <james_w> so next time it does a "pack" operation it first removes the obsolete ones
[19:24] <BFrank> shouldn't it cleanup for other types of operations, where it won't create new ones?
[19:24] <BFrank> or do all operations create them?
[19:24] <james_w> no, just the ones you would expect
[19:24] <james_w> commit, pull, pack, merge, push into, etc.
[19:25] <BFrank> hmm
[19:25] <antoranz> what tool can I use to import a git repository into bzr?
[19:26] <mwhudson> antoranz: bzr-git or bzr-fastimport
[19:26] <antoranz> ok
[19:31] <mwhudson> antoranz: the latter is probably more robust at this point, but bzr-git is moving fast
[19:31] <antoranz> ok
[19:32] <jelmer> mwhudson: moin
[19:32] <mwhudson> jelmer: hi
[19:32] <jelmer> mwhudson: my git import now works on lp btw
[19:32] <mwhudson> jelmer: yes, i saw that
[19:32] <mwhudson> jelmer: did you find out what was going on when it was just showing 1000 revs?
[19:33] <jelmer> mwhudson: yes, I had only pushed 1000 revisions (bzr push -r1000) :-)
[19:33] <mwhudson> jelmer: hahahaha
[19:49] <mwhudson> jelmer: so if i wanted to make a bzr-svn import of pypy, what would i have to do?
[19:49] <mwhudson> jelmer: i remember you saying that i could probably hack something to ignore certain errors
[19:57] <jelmer> mwhudson: ah, yeah
[19:57] <jelmer> mwhudson: when it calls get_dir()
[19:57] <jelmer> you have to ignore 157002 errors
[20:15] <mwhudson> jelmer: alternatively
[20:15] <mwhudson> if i dump the repo, filter out the offending fileprops, recreate it locally
[20:15] <mwhudson> do the import from my local repo, will it be possible to update the import from codespeak?
[20:16] <jelmer> mwhudson: yes
[20:21] <mwhudson> jelmer: awesome
[20:21] <mwhudson> jelmer: do you happen to know how to filter a dumpfile?
[20:25] <jelmer> mwhudson: vi ? :-)
[20:25] <mwhudson> jelmer: heh
[20:28] <phinze> so i've got a meeting this afternoon about revising my group's code review practice, which currently consists of all devs (4-6 of them) sitting around a table and scrolling through one big diff that's getting deployed
[20:28] <phinze> wondering if anyone else using bazaar in a dev group can talk about what they do for code review?
[20:29] <phinze> we're hoping to move toward peer-review where one other dev signs off on each commit to trunk
[20:33] <james_w> phinze: that's what bzr does, as you probably know
[20:33] <phinze> yes bzr does PQM where what like at least one other dev must approve?
[20:34] <james_w> you work with much smaller, more targetted diffs, which is a big win
[20:34] <james_w> but there will some cross-change intricacies that can be missed
[20:34] <james_w> yeah, two core devs total, so you get two reviews of code from those that haven't been let in to that group yet
[20:35] <phinze> we're thinking of using PQM here too
[20:35] <james_w> I think that's a stricter requirement than a lot of open source projects, where once you are a core committer you can generally do what you like
[20:36] <phinze> yeah seems pretty strict but also seems like it works :)
[20:36] <phinze> so it's either BB:approve or BB:reject...?
[20:36] <james_w> e.g. in Ubuntu. What happens there is sometimes you request your changes are reviewed before uploading (committing to mainline). Some people watch the -changes list (equivalent to -commits) and review things that catch their eye
[20:36] <james_w> so it's much less comprehensive
[20:37] <james_w> but the volume of changes there is too large, and the expertise too thinly spread, to have bzr's system of review.
[20:37] <phinze> ahh yeah
[20:38] <james_w> there is BB:approve, BB:reject, BB:rebsubmit, BB:tweak, BB:comment and BB:abstain I think
[20:38] <phinze> lol abstain
[20:38] <james_w> where approve, resubmit and tweak are the most commonly used
[20:38] <phinze> how to resubmit/tweak work in that case
[20:38] <phinze> are they just different semantic keywords on top of reject?
[20:40] <phinze> s/to/do
[20:40] <james_w> reject is pretty final, "I don't want any change like this in bzr", for something like "remove bzr commit, make everyone commit by editing .bzr/repository"
[20:40] <phinze> :)
[20:41] <james_w> resubmit means, "I'm fine with where you are going, but there are some problems with your implementation, make some changes and ask for review again"
[20:41] <james_w> tweak means "basically fine, there's a typo here, fix that up and submit it, you don't need to get it re-reviewed"
[20:42] <phinze> from BB/PQM's perspective, though, it's just a "go/no go"?
[20:42] <james_w> BB tracks the votes, I'm not sure what algorithm it uses to decide, if any
[20:42] <james_w> PQM is not automatic, a developer has to submit each change
[20:43] <james_w> there's no link between them currently
[20:43] <phinze> ahh BB and PQM are two separate systems... i thought they were two head of one beast
[20:43] <james_w> PQM just saves you from having to wait for the testsuite before committing, you submit, and some time later get a mail telling you if it passed or not
[20:44] <james_w> nah, they could work more closely together, but it works fine to have them separate, so no-one put the effort in
[20:57] <mwhudson> jelmer: ok, i have a dump file, can you give me some clues what i'm looking for?
[21:00] <jelmer> mwhudson: look for the particular revision that was causing problems (I think I mentioned it in the bug report)
[21:00] <jelmer> You'll see entries in the dump file for each property change and each file change
[21:00] <jelmer> just remote the K ... / V ... bits for the problematic property (with a / in the name IIRC)
[21:02]  * mwhudson wonders about an appropriate tool for editing a 3.7 gig file
[21:03] <stbuehler> "rm" :)
[21:04] <NfNitLoop> heh.
[21:04] <thumper> mwhudson: sed
[21:04] <mwhudson> thumper: you might be rite
[21:04] <thumper> mwhudson: or emacs :)
[21:04] <mwhudson> right
[21:04] <mwhudson> does emacs not load the entire file into ram?
[21:04] <mwhudson> i was ~sure it did
[21:04] <NfNitLoop> a friend of mine had to remove middle chunks of very large (gig+) files and ended up using head & tail.
[21:05] <thumper> mwhudson: I'm not sure
[21:05] <jelmer> mwhudson: there are some tools for editing svn dumps
[21:05] <jelmer> but I'm not familiar with them
[21:05] <jelmer> they do exist though :-)
[21:08] <mwhudson> ok
[21:08] <phinze> james_w: thanks for explaining all that; very helpful!
[21:10] <james_w> np
[21:10]  * mwhudson finds a perl thingy
[21:14] <mwhudson> hang on
[21:15] <mwhudson> jelmer: can svn-import import from a dump file?
[21:16] <mwhudson> or
[21:16] <jelmer> mwhudson: it can import from a dump file but it will simply load the dump file into a repo and then import it
[21:16] <jelmer> mwhudson: actually, you should be able to import from that dumpfile directly
[21:16] <jelmer> mwhudson: as that problem only occurred over http
[21:17] <mwhudson> right
[21:17] <mwhudson> that was what i was thinking
[21:24]  * mwhudson plays the install dependencies game
[21:36] <shtylman_> I am looking to setup my own bzr server for a group I am working with. I wanted to do it using https transport to basically get pretty urls (ie. https://domain/repo/project) ... I know bzr can work over ssh, but then I don't get the pretty name...without putting the repo under root...which I would like to avoid...any suggestions/ideas?
[21:50] <NfNitLoop> shtylman_: You can use read-only "dumb servers" over HTTP trivially:
[21:50] <NfNitLoop> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
[21:50] <NfNitLoop> but ssh will probably be best (read: easiest) if you want to give people write access.
[21:56] <shtylman_> NfNitLoop: I am aware of the "dumb" servers...and yea...I was thinking the same thing....but just wondering if I overlooked something simple
[21:57] <NfNitLoop> Not that I know of.
[21:57] <NfNitLoop> you could use `bzr serve`, but that's apparently only for a single repo.
[21:59] <LarstiQ> afaik bzr serve is for directory hierarchies, not repositories.
[21:59] <NfNitLoop> Oh.  ok, misread that while skimming.
[21:59] <LarstiQ> so serving / would work
[21:59] <NfNitLoop> there you go then, bzr serve.
[21:59] <NfNitLoop> (though, you probably don't want to serve /)  ;)
[22:00] <LarstiQ> shtylman_: you could use a chrooting ssh server to prettify your urls, just like launchpad does
[22:00] <mwhudson> jelmer: import to a brisbane-core format blew up in a really exciting way
[22:01] <shtylman_> LarstiQ: will that interfere with the current ssh server on the machine? sounds like it will...
[22:01] <LarstiQ> shtylman_: it could
[22:02] <mwhudson> jelmer: http://pastebin.ubuntu.com/140987/
[22:02]  * LarstiQ goes to bed
[22:06] <mwhudson> jelmer: and then when trying to import into --1.9 http://pastebin.ubuntu.com/140995/
[22:25] <jelmer> mwhudson: not sure any of those are bzr-svn issues
[22:25] <mwhudson> jelmer: what might they be?
[22:26] <mwhudson> the thread-starting one is pretty odd
[22:27] <jelmer> mwhudson: Does it start a very large number of threads or something like that?
[22:27] <mwhudson> jelmer: bit hard to tell, this is on a remote machine
[22:28] <mwhudson> which is an openaz slice, or something, so it's possibly a slightly strange environment
[22:28] <lifeless> shtylman_: you could put a symlink in the root
[22:29] <shtylman_> lifeless: yep...decided on that few min ago :)
[22:33] <jam> jelmer: for the first pastebin, something is passing a 'key' that has a unicode string, which I don't think is allowed. Since both "file_id" and "revision_id" are declared to be utf-8 strings internally.
[22:34] <jam> Given that it is clearly an 'id' followed by a 'path' I'm a bit confused by it, though
[22:34] <jam> Though it also seems be failing in the middle of 'svn/errors.py ... convert'
[22:35] <jam> which sounds like an exception in the middle of reporting an exception.
[22:35] <mwhudson> jelmer: i'm tar tjf-ing the repo, will see if it ends up small enough to download to my laptop reasonably
[22:36] <mwhudson> cfj, obv
[22:37] <jam> anyway, I'm off for tonight, catch y'all later :)
[22:38] <lifeless> gnight jam
[22:54] <igc> morning al
[22:54] <igc> all
[22:56] <lifeless> hi igc
[22:57] <igc> hi lifeless
[22:57] <igc> lifeless, jam: I'm up at the hospital most of the day
[22:57] <lifeless> igc: good luck
[22:57] <igc> what code do you want me reviewing while I'm there?
[22:57] <igc> I'm thinking chk_map
[22:58] <igc> (groupcompress in out of my depth and we have 3 people who ought to know it reasonably well)
[22:58] <igc> s/in/is/
[22:58] <lifeless> that would make sense; re the cache you are proposing, yes your mail comes across very strongly ;). I would like to note that AIUI the revnos do _not_ require the full graph to be traversed
[22:59] <lifeless> so if we strip the hyperbole we can be examining that part of the problem
[23:00]  * SamB_irssi begins to wonder why svn-import is only available for svn ...
[23:10] <plexq> I'm trying to merge lots of subprojects into one big central project.  Is there a way to do that?
[23:11] <plexq> should I just make one big honking bzr
[23:11] <lifeless> there is a merge-into plugin
[23:11] <plexq> or do subprojects like you can in svn
[23:11] <plexq> merge-into - yeah - I saw that - does it still work? i t hasn't been touched in 9 months?
[23:12] <lifeless> as far as I know it does work yes
[23:13] <lifeless> we have sub projects being worked on but its not really ready yet
[23:14] <plexq> kk
[23:15] <plexq> I'd heard a rumour that bazaar was going away because Gnome picked git, is there any truth to this?
[23:15] <SamB_irssi> I heard that Emacs is going to be switching to bzr soon ...
[23:15] <james_w> first I've heard of it
[23:19] <lifeless> plexq: no truth to it at all
[23:19] <lifeless> and yes, emacs are talking timeframes now
[23:20] <plexq> I know for us - it will depend on IDE plugins.  We are using bazaar right now, but I've heard there is a pure Python version of git, and IntelliJ 8.1 now has a git plugin, but no good bazaar support :(
[23:22] <lifeless> plexq: the pure version of git is 'dulwich' a project started for 'bzr-git', our git interoperation plugin
[23:23] <plexq> heh
[23:23] <lifeless> eclipse has bzr support FWIW
[23:23] <plexq> yeah - but eclipse is a POS
[23:23] <plexq> it's horrible
[23:23] <plexq> took one look at IntelliJ and never looked back
[23:54]  * igc breakfast