[00:00] <Peng_> Cool, I've never had anything destroyed by customs before. :D
[00:01] <beuno> Peng_, I'll make sure to not send any live animals in it
[00:01] <mwhudson> canonical t-shirts have successfully got past nz biosecurity
[00:03] <mwhudson> which is probably about the strictest border control going
[00:03] <jelmer> mwhudson: which one was problematic ? I don't recall having pushed anything large recently
[00:04] <mwhudson> jelmer: not sure, perhaps i'm being over the top
[00:04] <mwhudson> jelmer: the openoffice ones certainly did, but they're disabled now
[00:05] <Peng_> What sizes are the t-shirts? Some strange, foreign measurement system that I've never heard of?
[00:06] <jelmer> mwhudson: I think the second largest one I've pushed so far would be samba, which is ~50k
[00:06] <Peng_> (Hey, I may not know anything about foreign countries, but at least I know they exist! :P )
[00:06] <mwhudson> jelmer: hm, i'd hope that would work
[00:06] <mwhudson> jelmer: ah, maybe not on prod actually
[00:07] <beuno> Peng_, they're measured en em's
[00:09] <Peng_> I wonder what my waist size is in ems?
[00:09] <Peng_> ...I wonder what it is in inches or centimeters?
[00:10] <beuno> Peng_, of course, I was kidding
[00:10] <beuno> s/m/l/xl?
[00:10] <servilio> hi! I have a working dir that I started from scratch and now I'd like make its history look like if it would have been started off from another branch
[00:10] <beuno> Peng_, http://shop.canonical.com/product_info.php?products_id=399&osCsid=deb8dc669413edbef04a27d04685add7
[00:10] <beuno> see size charts
[00:10] <servilio> I've tried bzr-rebase, but only to have the other pulled and completely overwriting the new one
[00:10] <servilio> any suggestions?
[00:12]  * servilio notes that it is his first time using rebase, so it might easily be that he's used it wrongly
[00:12] <Peng_> Cue Firefox freezing. Argh.
[00:19] <Peng_> beuno: XL, I guess. Can you steal my address from my Canonical Store account?
[00:19] <Peng_> (Actually, if you could, that'd probably be a huge privacy violation... :P )
[00:20] <lifeless> Peng_: beuno can't. A sysadmin could; you should file a question asking them to give him the address :)
[00:20] <lifeless> Peng_: or... you could just tell beuno
[00:20] <Peng_> :D
[00:20] <Peng_> Hmm, which of those is less typing? If the question was really terse...
[00:20] <lifeless> yo, give bueno moi address
[00:22] <Peng_> beuno: Normal lp:~beuno email address?
[00:23] <Peng_> You can't see the sizing chart without logging in. :\
[00:33] <beuno> Peng_, got it, thanks
[00:34] <Peng_> beuno: ok :)
[00:52] <igc> hi all
[00:52]  * igc off to the dentist - bbl
[00:52] <lifeless> jam: let me know when you pass the token
[01:23] <lifeless> jam: ping
[01:49] <jelmer> mwhudson: btw, is it right that the API doesn't support removing branches yet?
[01:49] <jelmer> mwhudson: (I'm interested in cleaning up all those broken mirrored branches at some point)
[01:53] <thumper> jelmer: yes, the api doesn't yet support removing branches
[01:53] <thumper> jelmer: file a bug please :)
[01:53] <thumper> jelmer: tag with "api", kthxbye
[02:23] <thumper> poolie: I can hack if you need me to try something
[02:26] <lifeless> jelmer: what are the urls for samba, both git an dbzr ?
[02:45] <igc> back
[02:50] <lifeless> jelmer: jeeeeelmer
[03:06] <BasicOSX> This branch may be out of date, as Launchpad was not able to access it 21 minutes ago. (Not a branch: "http://bazaar-vcs.org/bzr/bzr.1.15/".) Launchpad will try again shortly.
[03:06] <lifeless> BasicOSX: I don't think it has been created
[03:07] <lifeless> BasicOSX: poolie asked in a company channel a couple of weeks back, I think noone actioned.
[03:07] <BasicOSX> ok, I'll wait, just anxious to work on it
[03:07] <lifeless> poolie: btw, when asking for a branch; if you don't get an ACK from a LOSA, the process is - file an RT
[03:07] <poolie> i know
[03:07] <poolie> i thought i did
[03:07] <lifeless> BasicOSX: we'll look at getting 1.15 on lp natively; that will need losa support, and I've started the discussion now.
[03:07] <poolie> it may be just a typo, hold on
[03:07] <poolie> hello BasicOSX
[03:08] <BasicOSX> hello poolie
[03:08] <poolie> lifeless: could this just be the quirk that it doesn't push til the first commit?
[03:08] <poolie> spm^^ does the pqm 1.15 branch exist?
[03:08] <lifeless> poolie: the instructions for making a branch for pqm include a manual push
[03:09] <lifeless> poolie: it has been made actually
[03:09] <lifeless> poolie: but it will be very out of date
[03:09] <poolie> i don't see it in http://bazaar-vcs.org/bzr/
[03:09] <lifeless> yah
[03:10] <lifeless> do you want it made this far ahead of the rc?
[03:10] <poolie> 2 days? sure
[03:10] <poolie> especially considering for spm there's only 1.5 working days until the rc
[03:10] <poolie> even less depending on travel
[03:10] <lifeless> spm: might like to update the docs, insofar as its make, setup config, and push once ;)
[03:10] <spm> updating docs is good. doing.
[03:11] <lifeless> spm: its a manual push as there isn't a default push location
[03:11] <lifeless> e.g.
[03:11] <lifeless> bzr info ../1.14
[03:11] <lifeless> copy, paste, change 1.14->1.15, bzr push
[03:11] <lifeless> (which I've just done)
[03:11] <spm> ta
[03:12] <lifeless> BasicOSX: its all there
[03:12] <lifeless> we'll do native lp for 1.16/2.0
[03:13] <BasicOSX> Should be able to get via lp or http?
[03:13] <lifeless> lp will need to try again
[03:13] <lifeless> http://bazaar-vcs.org/bzr/bzr.1.15 for now
[03:13] <spm> lifeless: that push was to escu I assume. verifying.
[03:13] <lifeless> spm: look in pqm's bash history
[03:13] <lifeless> spm: it was litteraly
[03:13] <lifeless> bzr info ../1.14
[03:14] <lifeless> bzr push (copied and adjusted url)
[03:14] <spm> awesome. perfect, ta.
[03:14] <poolie> thanks spm
[03:20] <thumper> lifeless: so is my bug a dupe? and being fixed?
[03:21] <lifeless> thumper: have you donethe test ?
[03:21] <thumper> lifeless: yes, and added comments to the bug
[03:21] <thumper> lifeless: bug mail is delayed...
[03:21] <thumper> lifeless: I thought it would have gone out by now
[03:21] <thumper> :-|
[03:21] <poolie1> thumper: which?
[03:23] <thumper> poolie1: which what? which bug? bug 376287
[03:25] <lifeless> bug 376255
[03:25] <lifeless> is what I think it may be a dup of
[03:25] <lifeless> or at least very close
[03:27] <thumper> lifeless: but the smart server isn't being used between two local directories is it?
[03:27] <lifeless> thumper: same code path can be
[03:28] <thumper> ok
[03:57] <lifeless> jam: ping
[03:58] <jam> hey lifeless, I just saw your earlier request.
[03:58] <jam> I'm sorry to say I didn't get to presentations.
[03:58] <jam> We had the power go out last night
[03:58] <lifeless> ok
[03:58] <jam> and I didn't have internet for half the day
[03:58] <lifeless> I'll carry on then
[03:58] <lifeless> jam: was just blocked until I got the token back
[03:58] <jam> Please push them up somewhere and I'll be happy to focus on them tomorrow
[03:58] <jam> And if you sent me an email... I didn't get it
[03:58] <lifeless> jam: I did; its in mail to you from yesterday
[03:58] <jam> problem with hosting your own...
[03:59] <lifeless> I'll send another one when I finish up with them today
[03:59] <jam> lifeless: yeah, no mail from 12am => 6am
[03:59] <jam> and then down again 9:30 => 12
[03:59] <lifeless> jam: it'll be queued somewhere. I sent to jam@c.c
[03:59] <jam> lifeless: right, my queue hasn't all flushed yet
[03:59] <lifeless> jam: anyhow, look for a mail from me tomorrow; as I'm grabbing the lock now :)
[04:00] <jam> Yeah, the power going out was pretty flukish, but it really messed up the day
[04:01] <jam> of course, it didn't help that when the internet went out it took them 1.5 hours to realize it was an site-wide effect
[04:12]  * igc lunch
[05:21] <bob2> does bzr use "pyftpdlib"?
[05:21] <lifeless> we use the stdlib ftp client
[05:21] <lifeless> and medusa as a test servere
[05:23] <bob2> bugs.debian.org/528602
[05:29] <lifeless> :!grep -n pyftp bzrlib/transport/ftp/* /dev/null 2>&1| tee /tmp/v308109/0
[05:29] <lifeless>  
[05:29] <lifeless> I'd query it
[05:56] <jfroy> bah
[05:56] <jfroy> bzr takes way
[05:56] <jfroy> too much memory when adding large files
[05:56] <jfroy> or rather when committing large files for the first time
[05:56] <jfroy> Keeps biting me since I tend to work with large media files on a regular basis (1 GB + HD files)
[05:56] <jfroy> :(
[05:56] <lifeless> jfroy: :(
[05:57] <jfroy> it's at 2 GB real ATM
[05:57] <jfroy> >.>
[05:59] <jfroy> is there any hope of addressing that in the future?
[06:00] <lifeless> yes
[06:00] <jfroy> or it is a design necessity and someone need to slap me for versioning large binary files?
[06:00] <lifeless> but for a trivial answer, split and join your files yourself ;)
[06:01] <jfroy> yeah well if I split those files they won't work anymore :p
[06:01] <lifeless> 'and join' :)
[06:02] <AfC> jfroy: you didn't ask if there was any hope of $whatever being addressed in the _near_ future...
[06:02] <jfroy> thought: could use a fancy content filter to auto-split and auto-unsplit stuff
[06:03] <lifeless> content filter api is probably not powerful enough
[06:03] <lifeless> but yes, broadly; and patches to make such a thing would be good
[06:03] <jfroy> :(
[06:03] <jfroy> I wouldn't even know where to start looking :|
[07:06] <lifeless> thumper: try lp:~lifeless/bzr/repo-source
[07:15] <thumper> lifeless: do I need to build extensions?
[07:15] <lifeless> no
[07:15] <thumper> lifeless: just branch and try?
[07:15] <lifeless> but you should
[07:15] <thumper> how?
[07:15] <lifeless> yah
[07:15] <lifeless> make
[07:15] <lifeless> you need python-dev and zlib1g-dev packages installed
[07:16] <thumper> pyrex?
[07:16] <lifeless> python-pyrex
[07:18] <lifeless> bbs, caving in and having a pastry
[07:21] <vila> hi all
[07:22] <thumper> lifeless: branch that with 1.15dev I got AbsentContentFactory :(
[07:22] <lifeless> branching from it ?
[07:23] <thumper> lifeless: object has no attribute get_bytes_as
[07:23] <thumper> yes
[07:23] <thumper> well, cbranch, but yes
[07:23] <lifeless> so pushing worked but the result is broken ?
[07:24] <thumper> lifeless: I got the error getting your bzr branch from launchpad :(
[07:24] <lifeless> thumper: very interesting
[07:24] <lifeless> thumper: you have a broken bzr in production, is what that means
[07:25] <thumper> lifeless: it is 1.14.1 + patches that you got mwhudson to do
[07:25] <lifeless> yes
[07:25] <thumper> so...
[07:25] <thumper> now what?
[07:25] <lifeless> clearly thats not quite enough
[07:25] <thumper> clearly
[07:26] <lifeless> it would be nice if my bundle was not deleted when I send to merge@...
[07:26] <thumper> lifeless: it isn't
[07:26] <lifeless> its not in the mail that gets sent out
[07:26] <thumper> lifeless: it is in the librarian
[07:26] <lifeless> well
[07:26] <lifeless> branch bzr.dev
[07:26] <thumper> all incoming email is stored
[07:26] <lifeless> and pull from the bundle
[07:26] <lifeless> and you'll have a working bzr to test with
[07:27] <thumper> the email is stored, but not really accessible
[07:27] <lifeless> so
[07:27] <thumper> I'm updating my trunk
[07:27] <lifeless> I mean 'people should get the bundle I send'
[07:27] <lifeless> to be precise
[07:27] <thumper> and I'll try again to see if it matters
[07:27] <thumper> lifeless: interesting idea
[07:28] <lifeless> with BB I would mail the list
[07:28] <lifeless> and people get my original signed email
[07:28] <lifeless> BB then send out additional data
[07:28] <lifeless> I quite liked that
[07:31] <lifeless> really fooding now
[08:09] <lifeless> https://code.edge.launchpad.net/~lifeless/+junk/bbctest
[08:14] <bob2> bbc = brisbane something core?
[08:15] <bob2> hah, poor lp doesn't like that branch
[08:18] <lifeless> yes
[08:18] <lifeless> https://bugs.edge.launchpad.net/launchpad-code/+bug/376255
[08:21] <lifeless> mwhudson: ^
[08:37] <lifeless> poolie: can you review my patch for bug 376255
[08:37] <lifeless> poolie: I'll send it in tonight if you do, if looks sane to you
[08:38] <poolie> lifeless: i'll try
[08:38] <poolie> lifeless: are you talking in barcelona?
[08:38] <poolie> more than usual i mean :)
[08:38] <lifeless> poolie: 3 times
[08:38] <poolie> of course you are, you told me you're preparing them
[08:41] <lifeless> poolie: I did:)
[09:01] <lifeless> poolie: /wave, done for day modulo adhoc chats and submitting that branch if you ok it
[09:01] <poolie> i'll looknow
[09:01] <poolie> was talking to vila
[09:17] <vila> bob2: BBC == BrisBane Core
[09:17] <vila> bob2: BC was already taken
[09:29] <poolie> i kind of wish you'd just spell it out
[09:29] <poolie> having one name was meant to avoid confusion, not invite new names
[09:32] <lifeless> poolie: when creating a test branch, abbreviations will be used, by nearly everyone
[09:32] <lifeless> I do use brisbane-core for tags and other things ;)
[09:33] <poolie> yeah, the branch name that provoked bob's question was not a good example
[09:35] <lifeless> :)
[09:44] <poolie> lifeless: review done, effectively a 'tweak'
[09:44] <poolie> and i already filed last week the bug asking for a 'tweak' status
[09:53]  * igc dinner
[09:55] <poolie> hi igc
[09:55] <poolie> night
[10:03] <igc> hi poolie. first cut at smarter upgrades just pushed to lp btw
[10:03] <igc> hope to clean-up & submit for review tonight or tomorrow
[10:04] <igc> poolie: also, branch making commit FILE 4x faster on dev6-rr pushed for review last night
[10:04] <poolie> nice one
[10:04] <poolie> ones :)
[10:04]  * igc ready heads for dinner now
[10:04] <igc> really
[10:04] <flo_hns> hello everyone. For one of my project, instead of having one branch for the whole thing, I split it into a branch per component, figuring that would be smarter.
[10:05] <lifeless> igc: one thing that would be really useful would be a pack() after an upgrade to rr6
[10:05] <flo_hns> I have by now concluded that it's not so smart after all, and would like to unify all those branches into one ? Are there tools/ways to do that, without losing the history ?
[10:09] <flo_hns> So, to summarize, what I'm looking for is a way or tool, to go from many branches with no common ancestor to one branch, without losing the history. So kinda of a "repo merge" operation.
[10:10] <flo_hns> anyone knows of such a thing ? :)
[10:11] <bob2> branch, not repo
[10:16] <flo_hns> bob2: well, I didn't want someone to tell to go for "bzr merge" :) so i figured branch might be confusing.
[10:28] <lifeless> flo_hns: merge-into
[10:29] <flo_hns> lifeless: ah awesome, looks like what I need. thanks!
[13:36] <jelmer> lifeless: man, that pack is taking long
[13:51] <vds> I have a problem trying to pqm-submit a branch on launchpad, after asking for the gpg passphrase bzr just hangs
[14:10] <lifeless> jelmer: you're doing it local right ?
[14:13] <lifeless> jelmer: do you have the C extensions build ?
[14:24] <jelmer> lifeless: yes; no
[14:24] <jelmer> lifeless: no python-dev on target machine
[14:26] <jelmer> lifeless: done
[15:06] <lifeless> jelmer: It would be nice to get it repacked with the C extensions
[15:06] <lifeless> jelmer: I'm pulling a copy myself to test
[15:07] <lifeless> jam: fetch from a non-optimal-packed bbc branch over VFS is _painful_. Something we might want to address before 2.0
[15:07] <lifeless> jam: one readv per revision painful
[15:07] <jam> lifeless: well, given that it is what, 2-40x larger?
[15:07] <jam> lifeless: so I've written code to "batch up" groups
[15:07] <jam> it is just the eternal question between
[15:07] <jam> how much do you batch
[15:07] <jam> and when do you issue the request
[15:07] <lifeless> sure
[15:07] <jam> by *not* batching, we avoid holding the whole repo in memory
[15:07] <jelmer> lifeless: this branch is also on launchpad, but disabled I think because of size issues
[15:07] <lifeless> we have reasonable asnwers though
[15:07] <lifeless> e.g. 64KB
[15:07] <jam> lifeless: actually, the batching was a large win for stuff like 'bzr ls' because it had to hit a lot of tiny groups
[15:07] <lifeless> jelmer: yes, it was 1.5GB :P
[15:07] <lifeless> jam: I must sleep, was just finishing off a little personal hacking when you happened by ;)
[15:07] <lifeless> 23:40 here
[15:07] <jam> sure
[15:07] <jam> sleep well
[15:07] <jelmer> g'night lifeless
[15:07] <jam> lifeless: argh.... 'bzr push lp:...' AttributeError: 'AbsentContentFactory' object has no attribute 'get_bytes_as'
[15:07] <lifeless> I sent you a couple of mails too, largely content free :P
[15:07] <jelmer> when should I be using str.decode("utf-8") and when osutils.decode_utf8() ?
[15:07] <jam> pushing up a non-stacked branch, as the project doesn't have any development focus yet
[15:07] <lifeless> jam: it has ghosts
[15:07] <lifeless> jam: updated your bzr
[15:07]  * lifeless is gone
[15:07] <jam> well, this is 4359
[15:08] <jelmer> jam: ^
[15:08] <lifeless> way to old you need 4362 or so
[15:08] <jam> jelmer: my copy of osutils doesn't have decode_utf8
[15:08] <jelmer> jam: sorry, I mean cache_utf8.decode
[15:08] <jam> jelmer: I would generally use .decode('utf-8'). cache_utf8.decode will shove the unicode and str objects into dicts
[15:08] <jam> so as to 'de-dupe' them later
[15:08] <lifeless> jam: https://code.edge.launchpad.net/~lifeless/bzr/repo-source.
[15:08]  * lifeless is gone
[15:24] <LarstiQ> hah, the maintenance of http://bazaar-vcs.org/ is returning html when bzr looks for the bzrdir format on http://bazaar-vcs.org/bzr/bzr.dev
[16:14] <jam> LarstiQ: yep, just ran into that myself
[16:15] <jam> It seems bzr is about 3 revs old in Launchpad
[16:15] <jam> Fortunately, I get to cheat
[16:15] <jam> and I can connect directly to the host via bzr+ssh :)
[16:15] <LarstiQ> tsk :)
[16:17] <jam> that said, even with Robert's fix, 'bzr push' fails for this branch unless I do 'nosmart+'
[16:24] <LarstiQ> is the most recent bzr.dev available via a smart protocol?
[16:24] <LarstiQ> for the general public
[16:27] <bialix> jam: hi
[16:28] <jam> hey bialix
[16:28] <jam> LarstiQ: no, I just have SSH access to that machine
[16:28] <bialix> does merging through pqm still the same as year ago?
[16:28] <jam> bialix: yep
[16:30] <jam> I can submit if you prefer
[16:30] <jam> I know there is also some maintenance going on, though I don't think it effects pqm right now
[16:30] <bialix> jam: please do
[16:30] <bialix> jam: I think your latest note should be tweak
[16:30] <bialix> if you'll send merge request, can you tweak, please?
[16:30] <jam> sure
[16:30] <bialix> jone more question
[16:30] <bialix> s/jone/one/
[16:30] <Tak> bialix meant: one more question
[16:30] <jam> well, it depended on whether we actually wanted to do the change or not, I left it open for you to decide
[16:30] <bialix> jam: it was premature optimisation
[16:30] <LarstiQ> Tak: are you a bot?
[16:31] <LarstiQ> s/you/running/
[16:31] <Tak> LarstiQ meant: Tak: are running a bot?
[16:31] <bialix> nice
[16:31] <bialix> Tak: teach me English please
[16:31] <LarstiQ> s/s/&/
[16:32] <LarstiQ> hmm, I hope that didn't cause an infinite loop
[16:32] <bialix> jam: my patch for unicode cmdline: it will be in next bzr 1.16?
[16:33] <jam> bialix: well, 1.15, yes
[16:33] <bialix> ah, even so
[16:33] <bialix> that's nice to have in rc1. more people will test it
[16:35] <bialix> today we have a question in ru-bzr about diff headers and non-ascii filenames
[16:35] <bialix> the problem is: diff headers encode filenames as utf-8
[16:36] <bialix> this is very bad for windows console
[16:36] <bialix> I remember we discussed it in the past
[16:36] <bialix> there is no right choice here
[16:37] <bialix> I'm thinking about adding special command-line option, e.g. --header-encoding, to force diff header show filenames in other encoding (oher than utf-8)
[16:37] <bialix> jam: ^
[16:37] <jam> bialix: so the code to fix that sort of thing is rather involved
[16:37] <jam> It required changing 3-4 layers to pass around a 'path_encoding' parameter
[16:37] <bialix> wdym?
[16:37] <bialix> oops
[16:37] <bialix> does it will affect merge directives?
[16:37] <jam> The place where we would know the output encoding
[16:38] <bialix> is it will be major API break?
[16:38] <Tak> argh
[16:38] <jam> then has to pass that down through about 4 layers to actually get that value set to the code that writes to the screen
[16:38] <jam> Tak: ??
[16:38] <Tak> sorry, I didn't mean for the regex script to be running in this channel
[16:38] <jam> LarstiQ: what is s/s/&?
[16:39] <jam> or is it just that you were regexing a regex?
[16:41] <bialix> :-D
[16:41] <jam> bialix: It isn't a "major" break, but a minor one, and tracking down all the cases was ugly enough I didn't continue to persue it a while ago
[16:41] <LarstiQ> jam: s/prefix/& append/
[16:41] <LarstiQ> jam: and indeed, the s was an attempt to regex the regex :)
[16:41] <bialix> jam: and this change also affects log -p IIUC
[16:42] <bialix> I'm not sure about merge directoves
[16:42] <bialix> directives
[16:42] <jam> bialix: if we had support to pass a value for path encoding
[16:42] <jam> we can just make sure that merge directives pass utf-8 there
[16:42] <bialix> one thing that bothers me is behavior of GNU diff (from gnuwin32.sf.net). It emits filenames in user_encoding
[16:43] <jam> bialix: I'm pretty sure GNU diff emits everything in OEM encoding
[16:45] <jam> so Unicode names aren't guaranteed to work
[16:45] <bialix> jam: no
[16:45] <jam> what do you get for: "diff Тест جوجو" ?
[16:45] <jam> My very strong guess is that 'GNU diff' thinks of filenames as pure 8-bit octets
[16:45] <jam> and if OEM encoding can't handle a given Unicode filename
[16:45] <jam> it just fails
[16:45] <jam> since it can't *read* the file
[16:45] <jam> (on my platform, both of those would show up as ???? ????, and I don't have a filename named ????)
[16:45] <jam> I could certainly be wrong
[16:46] <bialix> jam: I've got nothing
[16:46] <bialix> I'll try to create Arabic filename first
[16:48] <jam> bialix: Explorer should handle it fine
[16:50] <bialix> C:\Temp\2>diff -u Тест جوجو.txt
[16:50] <bialix> diff: ????.txt: Invalid argument
[16:50] <jam> bialix: yep
[16:50] <bialix> GNU diff does not handle pure unicode
[16:50] <jam> bialix: right, so if you don't deal with unicode ,then you just write the 8-bit string that you read, back onto the wire
[16:50] <jam> which is generally OEM encoding
[16:50] <jam> IIRC
[16:50] <jam> it doesn't specifically matter what it is
[16:50] <bialix> but
[16:50] <bialix> C:\Temp\2>diff -u Тест Тест2
[16:50] <bialix> --- Тест        2009-05-14 18:44:25.953125000 +0300
[16:50] <bialix> +++ Тест2       2009-05-14 18:44:38.734375000 +0300
[16:50] <bialix> @@ -1 +1 @@
[16:50] <bialix> -foo
[16:50] <bialix> +bar
[16:50] <bialix> filenames in cp1251
[16:50] <jam> bialix: Is this on Russian windows?
[16:50] <bialix> no
[16:50] <bialix> it's on English netbook
[16:50] <Tak> LarstiQ: it disallows that :-P
[16:51] <bialix> but with Russian settings
[16:52] <jam> bialix: http://www.eggheadcafe.com/conversation.aspx?messageid=33050149&threadid=33050144
[16:55] <jam>  If an application is compiled for ANSI API, then the filenames will be recoded to/from current codepage.
[16:55] <jam> Which means, try doing "chcp 437"
[16:55] <jam> and see if 'diff' continues to work
[16:55] <bialix> yes, it works
[16:55] <bialix> C:\Temp\2>diff -u Тест Тест2
[16:55] <bialix> --- ╥σ±≥        2009-05-14 18:44:25.953125000 +0300
[16:55] <bialix> +++ ╥σ±≥2       2009-05-14 18:44:38.734375000 +0300
[16:55] <bialix> @@ -1 +1 @@
[16:55] <bialix> -foo
[16:55] <bialix> +bar
[16:55] <bialix> but filenames still in cp1251 as you could see
[16:55] <jam> bialix: well, I see them as horribly horribly broken
[16:55] <jam> at least in your paste
[16:55] <bialix> them? GNU diff?
[16:55] <jam> bialix: in the paste you just generated, I get very bad characters shown
[16:56] <jam> --- [] [sigma] [+/-] [>=]
[16:56] <bialix> C:\Temp\2>chcp 866
[16:56] <jam> bialix: and when I do "diff Тест.txt Тест.txt"
[16:56] <bialix> Active code page: 866
[16:56] <jam> I get:
[16:56] <bialix> C:\Temp\2>diff -u Тест Тест2
[16:56] <bialix> --- ╥хёЄ        2009-05-14 18:44:25.953125000 +0300
[16:56] <bialix> +++ ╥хёЄ2       2009-05-14 18:44:38.734375000 +0300
[16:56] <bialix> @@ -1 +1 @@
[16:56] <bialix> -foo
[16:56] <jam> diff: ????.txt: No such file or directory
[16:56] <jam> diff: ????.txt: No such file or directory
[16:56] <bialix> +bar
[16:57] <bialix> I've created my files first
[16:57] <bialix> C:\Temp\2>diff --version
[16:57] <bialix> diff (GNU diffutils) 2.8.7
[16:57] <bialix> Written by Paul Eggert, Mike Haertel, David Hayes,
[16:57] <bialix> Richard Stallman, and Len Tower.
[16:57] <bialix> Copyright (C) 2004 Free Software Foundation, Inc.
[16:57] <bialix> This is free software; see the source for copying conditions.  There is NO
[16:57] <bialix> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
[16:58] <jam> bialix: i created them as well
[16:58] <bialix> jam: as I could see diff emits simply characters in cp1251 encoding
[16:58] <jam> bialix: not according to your paste
[16:58] <bialix> regardless of real console encoding
[16:58] <jam> it emits them as 8-bit filenames
[16:58] <jam> which then get interpreted by the consoles' code page
[16:59] <jam> now, I'm not sure how these are stored *on disk* exactl
[16:59] <jam> but the fact that Arabic didn't work hints that more might be going on
[17:00] <jam> bialix: anyway, what *I* would do in bzr, is to take the Unicode name, and try to encode it into the sys.stdout.encoding (with replace=True). And if sys.stdout is a file, then do something like always utf-8
[17:00] <bialix> bear in mind recent patch for unicode cmdline it seems GNU diff using filenames "as is" without encoding them to unicode
[17:00] <jam> I think technically it is supposed to be locale.getpreferredencoding at that point
[17:01] <bialix> bbiab
[17:08] <jam> jelmer: I'm not sure what you are doing, but I see: Thu May 14 16:38:46 2009 UTC: Jelmer Vernooij <jelmer@samba.org>, Request for non-PQM managed branch.
[17:08] <jam> on http://pqm.bazaar-vcs.org/
[17:09] <jam> I'm guessing you have your submit branch set up incorrectly
[17:09] <jelmer> jam: oh
[17:09] <jelmer> jam: pqm-submit was spitting out HTML so I send in a merge request manually
[17:10] <jelmer> jam: still is, btw - is anything up with it?
[17:10] <jam> jelmer: bazaar-vcs.org is undergoing maintenance
[17:10] <jam> and yielding HTML when you try to read .bzr/branch/format
[17:11] <jam> (It yields the main page, IIRC)
[17:11] <jam> Though I thought 'pqm-submit' only checked that your public branch was valid
[17:11] <jam> so I don't have any idea why it would be checking bazaar-vcs.org
[17:17] <jelmer> jam: it asks the submit branch for its public location apparently
[17:18] <jam> jelmer: right, so that you can have a local mirror, and not have to hit the remote location
[17:18] <jam> to determine what revisions to send
[17:19] <jam> well, that is why we have it for 'bzr send', and the 'merge target' gets reused for pqm-submit
[17:24] <Kissaki> using bzr on windows. On "bzr ignore <file>" a versioned file, it will warn me that it's versioned. On "bzr status" it will still list it as modified (as before) and worse, the ignored .bzrignore file is displayed as well. "bzr revert .bzrignore" will even tell me "removed" but the file itself is still on the hdd.
[17:24] <Kissaki> maybe I should submit a bug ticket
[17:24] <Kissaki> ...
[17:29] <jam> Kissaki: after 'bzr revert .bzrignore' Isn't the file renamed to .bzrignore.~1~ ?
[17:29] <jam> The property of being "versioned" supersedes the property of being ignored
[17:29] <Kissaki> no
[17:29] <jam> so if you want to remove and ignore you need to do that
[17:30] <Kissaki> so there's no way to ignore a versioned file?
[17:30] <Kissaki> but still, it's broken
[17:30] <jam> Kissaki: "bzr ignore X; bzr rm X
[17:30] <jam> Kissaki: I just checked, we never delete newly added files via revert
[17:30] <Kissaki> it won't fetch it then again?
[17:30] <jam> so if you do:
[17:30] <jam> bzr add somefile
[17:30] <jam> bzr revert
[17:30] <Kissaki> ah ok
[17:30] <jam> It will leave 'somefile' alone
[17:30] <jam> you may want "bzr rm --keep X"
[17:31] <jam> depending on whether you want the file actually deleted from disk, or not
[17:34] <Kissaki> thx
[17:53] <Kissaki> wtf, now after adding another, unversioned file it's displayed as added again, the .bzrignore
[17:57] <KX> Does anyone use bzr with redmine?
[18:02] <jam> Kissaki: we generally version .bzrignore, so that your ignore list gets transmitted
[18:02] <jam> I belivee 'bzr ignore X' automatically creates it and versions it.
[18:05] <Kissaki> but it did seem to work before... Maybe I did delete it from repo, but it was kept on hdd...
[18:05] <Kissaki> so I thought it would work without commiting it
[18:06] <Kissaki> but if I specifically ignore .bzrignore, shouldn't it be ignored then?
[18:06] <Kissaki> after all, if I want it versioned, I won't ignore it
[18:33] <Youssef> Hello guys!
[18:34] <Youssef> i just have a question
[18:35] <Youssef> I would like to know what's the difference between "Create a checkout" and "Make a local copy of the branch" please
[18:35] <Youssef> in the tortoisebzr gui
[19:01] <KX> well
[19:02] <KX> since the site is down and I can't access the docs, would someone mind helping me set up my ssh key on windows?
[19:03] <KX> I used puttygen.exe on my pc, saved id_rsa and id_rsa.pub in Docs & Settings/Me/.ssh and then on the server in ~/.ssh I made authorized_keys with my public key all on one line and the "run bzr in cmd shell" still asks me for an SSH password when I do e.g. bzr update
[19:05] <jam> Kissaki: you could try doing echo "./.bzrignore" > .bzrignore
[19:05] <jam> but doing "bzr ignore .bzrignore" wouldn't do what you want, as it would then add the file
[19:05] <jam> KX: I would usually use pageant, if you have putty
[19:05] <jam> Start/Programs/Putty/Pageant
[19:05] <KX> I have it, just not sure hwat to do
[19:06] <jam> adds an icon to your systray
[19:06] <jam> then right click on the icon, Add Key
[19:06] <KX> I've efound out that apparently putty uses a different format to openssh
[19:06] <jam> KX: just for the key file format
[19:06] <KX> so I'm going to try doing export as openssh key real quick
[19:06] <jam> but the Public/Private key stuff is the same
[19:06] <jam> If you use Pageant, then you *want* putty's format
[19:06] <KX> mmm, well is it not possible without pageant?
[19:06] <jam> It *is* possible, but I still think pageant is *easier*
[19:06] <KX> I guess I'll do it that way if it works
[19:07] <KX> Ok I've opened it
[19:07] <jam> So there should be an icon of a computer with a hat in your systray
[19:07] <KX> so I save the private key as id_rsa.ppk in .ssh and then click on the icon anadd key and locate that file
[19:07] <jam> yep
[19:07] <KX> ok
[19:08] <jam> If pageant is running, and your key has been added, then we can access it without promptingyou
[19:08] <jam> though you still need to get the public key line from puttygen so that you can upload your key to the remote machine
[19:08] <KX> oh, so that's it? I'll try it now then
[19:08] <KX> I've already done that
[19:09] <KX> authentication publickey failed
[19:09] <KX> it should be called id_rsa.pub in .ssh right?
[19:10] <jam> KX: so the key format from puttygen doesn't match 'id_rsa.pub' format.
[19:10] <jam> however, if you added the key to pageant, we don't care what files are around
[19:11] <jam> we talk to pageant *first* (and then look for files)
[19:11] <KX> well the format looks like
[19:11] <jam> so if you are getting failed
[19:11] <jam> that means there is a problem elsewhere
[19:11] <KX> ---- BEGIN SSH2 PUBLIC KEY ----
[19:11] <jam> can you paste the connection output?
[19:11] <KX> and an END block, with data in between
[19:11] <KX> Well all it says after I run bzr update is
[19:11] <jam> It is possible you are running openssh which doesn't know how to connect to pageant, versus using paramiko internally
[19:11] <jam> try:
[19:11] <jam> set BZR_SSH=paramiko
[19:11] <jam> bzr update
[19:11] <KX> Connection (version 2.0, OpenSSH_4.3)
[19:12] <KX> Authentication (publickey) failed.
[19:12] <KX> SSH password:
[19:12] <jam> well, if it is printing out "Connection (version...)" then it is using paramiko
[19:12] <KX> but it says openssh there :s
[19:12] <jam> so I'm guessing you don't have the public key uploaded to the other side correctly.
[19:12] <jam> KX: That is the *remote*
[19:12] <vxnick> can anyone tell me how I can ignore all subdirectories except a certain one? I've tried expanding on the one provided by 'bzr help ignore', but I get "event not found" when trying "RE:(?!modules/babble/).*"
[19:12] <jam> openssh locally doesn't print a Connection line :)
[19:13] <jam> vxnick: "bzr ignore *; bzr add subdir"
[19:13] <jam> the add will supersede the ignore
[19:13] <KX> on the remote, it is in ~/.ssh/authorized_keys and it looks like ssh-rsa SPACE lots of junk ending with == SPACE rsa-key-.....
[19:13] <jam> or you could do
[19:13] <jam> bzr ignore ./*
[19:13] <vxnick> jam: thanks :)
[19:13] <jam> to just ignore top-level dirs automatically
[19:13] <KX> anything wrong with that?
[19:13] <jam> KX: well, that *sounds* correct. Of course, you have to check things like
[19:13] <jam> perms on ~/.ssh
[19:13] <jam> and ~/.ssh/authorized_keys
[19:13] <KX> what should they be?
[19:14] <jam> IIRC if they arent 700 and 600 then openssh refuses to connect
[19:14] <jam> let me check here
[19:14] <KX> thanks
[19:14] <jam> KX: chmod 0700 .ssh; chmod 0644 .ssh/authorized_keys
[19:14] <jam> is what I have
[19:15] <jam> If you have 'root' access on the remote machine, I think it gives warnings about this in /var/log/secure
[19:15] <KX> I can access /var/log but not secure
[19:15] <KX> I'll try now I changed the file modes
[19:16] <jam> you might check /var/log/messages, but yeah, usually only root can read the logs
[19:16] <jam> just in case
[19:16] <KX> thank you very much
[19:16] <vxnick> jam: ignore * then bzr add sub/dir didn't exactly work, as it re-added the parent 'modules' directory in order to add modules/babble
[19:16] <KX> jam it works lovely now, thanks I've been trying to do this for 2 days ... who'd have thought it was file permissions ...
[19:19] <jam> vxnick: that is required
[19:19] <jam> if you did "bzr init ."
[19:19] <jam> you can't just add "foo/bar" without adding "foo/"
[19:19] <jam> if you prefer, you could
[19:19] <jam> cd foo
[19:19] <jam> bzr init
[19:19] <jam> or cd foo/bar; bzr init
[19:19] <vxnick> well this is a checkout you see
[19:19] <KX> vxnick, what are you trying to do with our dirs? :P
[19:20] <vxnick> it's not a problem, just wanted to let you know
[19:39] <davidstrauss> What's up with the bzr site?
[19:53] <LarstiQ> davidstrauss: hrmph, this is silly now
[19:53] <davidstrauss> LarstiQ: ?
[19:53] <LarstiQ> jam: can you/should I raise the topic of bazaar-vcs.org
[19:54] <LarstiQ> davidstrauss: this is no longer 'shortly'
[19:54] <davidstrauss> LarstiQ: please explain
[19:55]  * LarstiQ counters with a question
[19:55] <LarstiQ> davidstrauss: when you said "what's up with the bzr site", what did you have in mind?
[19:55] <LarstiQ> maybe we're talking about different things
[19:55] <davidstrauss> LarstiQ: When will the wiki be back online
[19:56] <LarstiQ> davidstrauss: right. I don't know. I'm surprised it isn't back already.
[19:57]  * beuno asks
[19:58] <LarstiQ> beuno: if it really still needs to be down, could they at least make `bzr pull http://bazaar-vcs.org/bzr/bzr.dev` not bork on bzrdir format query getting html back?
[19:59] <beuno> LarstiQ, asking  :)
[19:59] <LarstiQ> beuno: kiitos :)
[20:07] <jam> LarstiQ: I already asked in canonical #is, it seems that moin upgrade was having real problems
[20:07] <jam> beuno: argy was the one working on it
[20:08] <jam> well, that was ~3 hours ago
[20:08] <LarstiQ> oops
[20:08] <LarstiQ> is this my fault? :)
[20:08] <jam> LarstiQ: no
[20:08]  * LarstiQ asked for a moin upgrade
[20:09] <jam> LarstiQ: AFAIK they upgraded the machine to Hardy, which "comes with" an upgrade to moin
[20:09] <jam> Apparently moin upgrades aren't very perfect ...
[20:09] <LarstiQ> jam: ah ok
[20:09] <jam> beuno: sorry, 'agy' not 'argy'
[20:09] <beuno> jam, yeah, guessed it  :)
[20:10] <beuno> nobody's answering though
[20:10] <jam> well, given London time, it is ~ 8pm there
[20:11] <jam> it is possible he stopped, though it would be nice to have *something* before he leaves
[20:11] <jam> I guess we have the Maintenance warning, rather than utter failure
[20:11] <jam> (in the morning it was ConnectionError)
[20:12] <LarstiQ> ah
[20:14] <luke-jr__> jelmer: btw, the svn+http syntax is basically required for password-locked repositories it seems
[20:16] <jelmer> luke-jr__: That's caused by bzr sending a POST request to see if there's a bzr smart server running
[20:16] <jelmer> luke-jr__: that triggers a "auth required" error on a lot of servers
[20:17] <luke-jr__> no doubt
[20:17] <luke-jr__> the "svn+ is obsolete" message just gets annoying while it's still required
[20:18] <jelmer> luke-jr__: that's no longer printed in newer bzr-svn's
[20:18] <luke-jr__> i c
[20:21] <fbond> bzr missing shows I have an extra revision and so does my parent, but `bzr rebase` does nothing.  Any good reason for this?
[20:22] <fbond> bzr rebase says "Rebasing on file:///...", but then nothing happens.
[20:22] <LarstiQ> fbond: rebasing on a different branch than missing checked?
[20:22] <LarstiQ> are you sure you want to rebase btw?
[20:23] <fbond> LarstiQ: Yes, I'm sure, and yes, both are going to the parent implicitly.
[20:23] <fbond> Or at least, both are claiming to go to the same branch (the parent).
[20:23] <LarstiQ> fbond: if they print out the same branch url, then yes.
[20:24] <LarstiQ> fbond: oh, wait.
[20:24] <LarstiQ> fbond: if you have one extra, and no missing, there is nothing to do for rebase.
[20:24] <LarstiQ> fbond: by definition the rebase result is the same as prior to the rebase.
[20:25] <fbond> LarstiQ: I have one extra, and the parent has one extra, too.
[20:25] <fbond> bzr missing lists a total of two revisions, one on my side, one on the parent's side.
[20:25] <LarstiQ> fbond: ok.
[20:25] <LarstiQ> in that case, no idea.
[20:25] <LarstiQ> fbond: anything in ~/.bzr.log?
[20:26] <fbond> Only what I would expect; no trace backs or anything.
[20:26] <jelmer> fbond: rebase rebases on the push location by default, not on the parent location
[20:26] <LarstiQ> jelmer: fbond mentioned the branch urls are both the parent
[20:27] <fbond> jelmer: bzr help rebase says it uses the parent...
[20:28] <jam> fbond: I'm pretty sure you want 'replay' but I'm not positive
[20:28] <jelmer> fbond: Sorry, never mind me. It is the parent actually.
[20:29] <fbond> jelmer: No problem.
[20:29] <fbond> Anyway, rebase has certainly worked for me in the past.
[20:29] <LarstiQ> fbond: I would indeed expect something to happen.
[20:29] <LarstiQ> fbond: does -r help?
[20:29] <jam> LarstiQ: bazaar-vcs.org seems to be working...
[20:29] <fbond> Yeah, I think it's a bug...
[20:29] <fbond> LarstiQ: I'll try using -r.
[20:29] <LarstiQ> jam: yay!
[20:30] <LarstiQ> jam: thanks to whomever fixed it.
[20:30] <LarstiQ> davidstrauss: ^^
[20:30] <fbond> LarstiQ: Ouch, weird.
[20:30] <davidstrauss> LarstiQ: cool
[20:30] <beuno> LarstiQ, server should be up again
[20:30] <LarstiQ> beuno: pull worked, thanks
[20:30] <fbond> LarstiQ: bzr rebase -r XXX caused *my* XXX to be replaced by *parent's* XXX.
[20:31] <jelmer> fbond: any merge revisions involved?
[20:31] <fbond> (and my XXX has disappeared)
[20:31] <fbond> No big deal, this was a merge from another branch, anyway.
[20:31] <fbond> But that was not expected.
[20:31] <jelmer> fbond: rebase ignores merges, there's an open bug about that
[20:31] <fbond> jelmer: Ignores merges?
[20:32] <fbond> There was content from this merge, FWIW.
[20:32] <fbond> jelmer: Do you have a bug #?
[20:33] <jelmer> fbond: it's the highest listed one in the bzr-rebase bugs page iirc
[20:35] <fbond> jelmer: Looks about right.
[20:35] <jam> fbond: cd trunk; bzr merge ../my branch; bzr revert --forget-merges
[20:35] <jam> should be ~equivalent to 'bzr rebase'
[20:36] <jam> Note that you'll lose the merge parent of 'my branch'
[20:36] <jam> you could get it back if you want to be extra creative
[20:37] <fbond> jam: Thanks; it's easy enough to recreate the merge revision.
[20:37] <fbond> I was just surprised to see rebase fail.
[20:57] <jam> LarstiQ: well, it looks like the new Moin engine changed {{{ verbatim }}} display a bit
[20:57] <jam> If you have a multi-line verbatim
[20:57] <jam> you have to start it with an empty line
[20:57] <jam> or it doesn't think it is verbatim
[20:57] <jam> see the change to http://bazaar-vcs.org/Roadmap/BrisbaneCore/Details
[20:58] <jam> just in case we run into that elsewhere, I want someone else to know about it :)
[20:58]  * LarstiQ looks at Download
[20:59] <LarstiQ> jam: ah, I see
[21:00] <LarstiQ> it seems the wiki comments do work now
[21:01] <jam> comments?
[21:02] <jam>  ### lines ?
[21:03] <LarstiQ> {{{#! wiki comment
[21:03] <LarstiQ> or /* */
[21:04] <jam> ah, k
[21:05] <jelmer> jam: I'm now getting 1.35s to extract all bzr.dev revs using the XML serializer
[21:05] <jelmer> jam: and 0.91 with the RIO one
[21:06] <LarstiQ> jam: which I had attempted for the list of older releases on /Download
[21:06] <jam> LarstiQ: so {{{#! => <!- ?
[21:06] <jam> or whatever the HTML comments were
[21:07] <LarstiQ> jam: no, a <div> which is not visible by default, but you can toggle comments to be visible
[21:07] <jam> ah, interesting
[21:07] <jam> I guess that makes it logical for the download stuff
[21:07] <jam> since a screen-scraper will always see the div
[21:07] <jam> and probably won't apply the CSS
[21:10] <LarstiQ> jam: exactly, I gleaned the idea from the TurboGears (pypi listed) download location, which easy_install knew how to handle
[22:02] <dirkD> is it possible to let bzr not ignore *.so files?
[22:03] <dirkD> (without using bzr add .......................so al the time)
[22:03] <jelmer> dirkD: remove the *.so pattern from the .bzrignore file
[22:05] <dirkD> jelmer: it's not there
[22:05] <dirkD> it seems like bzr ignores *.so by default
[22:07] <jelmer> dirkD: perhaps ~/.bazaar/ignore ?
[22:07] <dirkD> yes, there it is
[22:08] <dirkD> is it possible to make an exception for that (in the tree)?
[22:08] <dirkD> otherwise every developer has to change his ~/.baazaar/ignore file
[22:09] <jelmer> I think I've seen something like that, I'm not sure how exceptions work though
[22:09] <beuno> lifeless, VFS calls have gone away on a few operations when interacting with Launchpad. Did LP get upgraeded os is the client getting smarter?
[22:24] <vxnick> hi guys - is there a way that I can bzr ignore ONLY the root index.php file, and not the same in sub-dirs?
[22:25] <dirkD> vxnick: bzr ignore ./index.php i think
[22:25] <dirkD> (i'm not sure)
[22:25] <vxnick> thanks dirkD I'll give it a go
[22:28] <vxnick> that looks like it worked, thanks :)
[22:31] <dirkD> np vxnick
[22:37] <lifeless> beuno: neither
[22:38] <lifeless> beuno: you're not using enough bits in your mask for determining'same operation'
[22:38] <beuno> lifeless, uhm...  what?
[22:39] <lifeless> beuno: push with the same format is vfs free except on new branches
[22:39] <lifeless> same for pull
[22:40] <lifeless> differing formats will trigger vfs
[22:40] <lifeless> new branches will trigger vfs
[22:41] <lifeless> moin
[22:41] <lifeless> btw
[22:41] <beuno> mornin  :)
[22:41] <jelmer> ah, moin is working again \o/
[22:42] <jam> dirkD: If you 'bzr add foo.so' it will always be versioned
[22:43] <jam> There isn't a way to specify you want to 'undo' an ignore otherwise
[22:43] <dirkD> yes, but then i have to ass 130 .so files manually
[22:43] <jam> so people creating new .so files won't see them
[22:43] <dirkD> s/ass/add
[22:43] <jam> dirkD: find . -name *.so -print0 | xargs bzr add
[22:43] <jam> dirkD: find . -name *.so -print0 | xargs -0 bzr add
[22:43] <jam> takes... 2s ?
[22:44] <lifeless> bzr ls --ignored | xargs bzr add
[22:44] <dirkD> that's an option, but it has to be used by some people who will forget this
[22:45] <beuno> lifeless, btw, bling: https://code.edge.launchpad.net/bzr
[22:45] <beuno> (I know you like bling)
[22:45] <dirkD> jam: giving them a new ~/.bazaa/ignore is more easy then
[22:45] <lifeless> beuno: the graph?
[22:46] <lifeless> beuno: is the word 'ago' meant to be below the ..... line ?
[22:46] <beuno> lifeless, it's suppose to be on the same line
[22:47] <lifeless> beuno: its on the same row as lp:bzr/1.15
[22:47] <beuno> lifeless, ah. shouldn't be. Got a screenshot handy?
[22:48] <lifeless> beuno: unmaximaise your browser
[22:48] <lifeless> :)
[22:48] <lifeless> mines about 800px wide
[22:48] <beuno> lifeless, borwser size doesn't break it
[22:48] <beuno> font size does, though
[22:48] <beuno> but I have to increase it 4 times
[22:48] <jam> hey lifeless
[22:48] <lifeless> also, perhaps it would read better as "124 commits in 90 days. Last 3 hours ago."
[22:49] <lifeless> cause I don't know what 'max' means
[22:49] <beuno> right
[22:49] <beuno> that's the problem
[22:49] <lifeless> beuno: I'm using epiphany
[22:49] <beuno> 124 is the max number of commits per day
[22:49] <jam> lifeless: do you have a min-font size set?
[22:49] <beuno> in 90 days
[22:49] <beuno> not super-clear
[22:50] <lifeless> jam: no
[22:50] <lifeless> I have my DPI set accurately
[22:50] <lifeless> and 10 point document font in font-appearances
[22:50] <lifeless> beuno: peak daily
[22:50]  * beuno tries epiphany
[22:50] <lifeless> beuno: 90 day activity, 124/day peak, last 3 hours ago
[22:51] <lifeless> 90 day view, peaked at 124/day, idle for 3 hours
[22:51] <lifeless> hi jam
[22:52] <beuno> lifeless, thanks for the feedback, will look into it
[22:53] <beuno> lifeless, right, in epiphany it does wrap
[22:53] <beuno> I'll look into that as well
[22:54] <lifeless> beuno: its cute; its likely also broken :)
[22:54] <lifeless> beuno: I bet that 124 is 'a big merge'
[22:54] <beuno> lifeless, yes, i
[22:54] <beuno> it's not mainline commits
[22:54] <beuno> I decided that explicitely
[22:55] <lifeless> I think it will be confusing if that graph doesn't line up with bzr log
[22:55] <beuno> why wouldn't it?
[22:55] <beuno> because of it not showing merges now?
[22:55] <lifeless> bzr log by default now only shows mainline commits
[22:55] <lifeless> I'm not advocating either position btw
[22:56] <lifeless> I'm just advocating keeping the theme the same across the platform
[22:56] <lifeless> lp's branch view only shows mainline commits
[22:57] <beuno> yeah, it's a tough choice
[22:57] <beuno> because merges, in many ways, show more work
[22:57] <lifeless> I don't think its that tough ;) confuse users? [Yes] [no]
[22:57] <lifeless> oh yes; FWIW I argued for keeping log showing all commits not just mainline
[22:58] <lifeless> which would be consistent with the bling
[22:58] <beuno> if only performance hadn't been so bad, I would of agreed  :)
[22:59] <lifeless> beuno: we have to revisit revnos; either to get better code to assign or to change it to one we can write fast code for
[22:59] <jam> lifeless: for the groupcompress talk, should I start with the graphs (to give "wow" factor) or should it come after discussion of the design?
[23:00] <jam> It feels like I'm starting "wow" and then just sort of talking without ending with a bang
[23:00] <jam> lifeless: we also need to consider the merge-sorted indenting
[23:00] <jam> *just* revnos isn't enough
[23:01] <jam> you can approximately do what we have with set-difference operations, and a smart difference that doesn't walk the whole ancestry
[23:01] <lifeless> jam: yes; well revnos were enough in the first round of dotted revnos, I think. anyway, its moot- until someone has it as top of pile
[23:02] <lifeless> but I do feel we should decide sooner rather than later the plan so users don't get flummoxed again, later.
[23:02] <lifeless> jam: the gc talk, IIRC was a big gc and a bit chk
[23:03] <lifeless> so we could do two separate sets of graphs
[23:03] <jam> lifeless: so far the GC talk has no chk
[23:03] <lifeless> or we could use some summary numbers, and then graphs at the end
[23:03] <jam> new compression backend 'group-compress'. John and I present the internals of this exciting compressor, its genesis, design and performance details.
[23:03] <lifeless> oh right
[23:03] <lifeless> no chk for us
[23:04] <lifeless> we can obviously cheat
[23:04] <lifeless> anyhow
[23:04] <jam> well, I can move the "text extraction" performance slides to the end
[23:04] <lifeless> I think waking the audienc eup is good
[23:04] <jam> and leave the "compressed size" to the front
[23:05] <lifeless> we could even spread them around
[23:05] <lifeless> bzr vs git at the front
[23:05] <lifeless> wow we sucked

[23:05] <lifeless> bzr v git now
[23:06] <lifeless> [I know that more than gc is in there, but we could compare just compressors]
[23:06] <lifeless> or perhaps hg would be more entertaining
[23:06] <lifeless> btw we're still slightly larger than git for samba
[23:06] <lifeless> not sure why
[23:06] <jam> lifeless: we are larger than git for launchpad, too
[23:06] <jam> 95 => 105 or so
[23:07] <jam> w/ lzma we are ~=
[23:07] <lifeless> that overall or .pacj
[23:07] <jam> lifeless: du -ksh .bzr .git
[23:07] <jam> so including indices
[23:07] <lifeless> I haven't got an overall for samba yet
[23:08] <lifeless> hmm, still need to make finding revisions faster
[23:08] <lifeless> we need 'empty' to come back from the smart server
[23:08] <jam> lifeless: so for 'time get_record_stream(all_texts)' I get a peak of about 330MiB/s if I do 1 pass, and 570MiB/s if I put it under timeit
[23:08] <jam> thoughts?
[23:08] <luke-jr__> git has about 3 minor things better than bzr
[23:09] <lifeless> jam: you mean for record in stream:record.get_bytes_as() ?
[23:09] <luke-jr__> IMO
[23:09] <jam> ah, gc.disable => 461MB/s
[23:09] <jam> lifeless: right
[23:09] <jelmer> luke-jr__: well, what are they ? :-)
[23:09] <luke-jr__> jelmer: it tracks copies, to some small degree
[23:09] <jam> I'm just trying to present things 'faithfully' though I know that 'peak' is almost 2x more than 'standard'
[23:09] <lifeless> jelmer: I recompressed samba, a 169MB pack
[23:10] <jam> lifeless: down from 1.5GiB?
[23:10] <lifeless> jam: yes
[23:10] <lifeless> jam: actually, 1.7 or so
[23:10] <luke-jr__> jelmer: I kinda like the "git add everything to commit" thing
[23:10] <luke-jr__> and cherry picking
[23:10] <jelmer> luke-jr__: Git doesn't track copies any more than bzr does, but the UI can infer where a copy was done
[23:10] <luke-jr__> jelmer: the UI is part of git
[23:10] <jam> lifeless: could be the de-duping
[23:10] <jam> (for lp in git)
[23:10] <jelmer> luke-jr__: yeah, but tracking implies it's stored somewhere
[23:11] <lifeless> jam: of same sha files?
[23:11] <jam> IIRC, we have about 50% dupe texts, 70% of which are the empty text
[23:11] <jam> lifeless: right
[23:11] <luke-jr__> jelmer: what git does is slightly better than bzr
[23:11] <lifeless> jam: would be good to make the file graph really separate
[23:11] <jam> lifeless: yep
[23:11] <jelmer> luke-jr__: I'm not disagreeing there :-)
[23:11] <luke-jr__> jelmer: I still think bzr needs to add copy support ;)
[23:11] <jelmer> luke-jr__: What do you mean with "git add everything to commit" exactly ?
[23:11] <lifeless> jelmer: the index
[23:11] <luke-jr__> jelmer: git doesn't commit changes unless you add them explicitly
[23:11] <jelmer> luke-jr__: It's planned, but not one of the highest priority features
[23:11] <jelmer> luke-jr__: ah, ok
[23:11] <luke-jr__> just because fileA changes doesn't mean you want to commit t
[23:12] <luke-jr__> it*
[23:12] <jelmer> luke-jr__: What's better about git's cherrypicking?
[23:12] <luke-jr__> jelmer: it works?
[23:12] <lifeless> jelmer: it has a one-shot command
[23:12] <luke-jr__> bzr's cherrypicking is just a diff patch
[23:12] <jelmer> luke-jr__: gits is a diff patch too
[23:12] <lifeless> luke-jr__: so is gits
[23:12] <luke-jr__> really? :/
[23:12] <lifeless> really
[23:12] <luke-jr__> it doesn't update the tree?;
[23:13] <lifeless> they record the revid it came from
[23:13] <lifeless> thats all
[23:13] <jelmer> luke-jr__: it adds to the commit message a note saying what was cherrypicked
[23:13] <luke-jr__> and copy that revid and its dependencies into the repo?
[23:13] <lifeless> no
[23:13] <luke-jr__> :/
[23:13] <luke-jr__> ok, 2 things then :p
[23:13] <luke-jr__> oh
[23:13] <luke-jr__> git does appear to be OK with cross-merges
[23:13] <luke-jr__> merge A into B, then B into A, etc
[23:14] <jam> lifeless: token is yours, push just finished
[23:14] <lifeless> thanks
[23:14] <jelmer> luke-jr__: bzr handles that too, although you have to specify --lca to merge to get it to deal with them properly
[23:15] <lifeless> where are we up to
[23:15] <jelmer> lifeless: it'll actually tell you if it sees a cross merge
[23:15] <jelmer> s/lifeless/luke-jr__/
[23:16] <luke-jr__> jelmer: does --lca actually work reliably?
[23:16] <luke-jr__> --weave sure doesn't
[23:16] <bob2> is --lca going to become the default sometime?
[23:16] <jelmer> luke-jr__: I've never had trouble with --lca
[23:16] <jelmer> I think we scared Aaron by talking about merge algorithms
[23:18] <luke-jr__> jelmer: inferred renames would be a nice thing too
[23:18] <jelmer> luke-jr__: see "bzr rename --auto"
[23:18] <jelmer> or at least I think that was what the name was
[23:18] <luke-jr__> ah
[23:18] <luke-jr__> ok, so really just 2 :)
[23:19] <luke-jr__> 1. explicit adding to commits (very minor, especially since I can uncommit after making a mistake)
[23:19] <luke-jr__> 2. copying
[23:19] <luke-jr__> IMO, there needs to be 3 new kind of copying
[23:20] <luke-jr__> 1. template (changes in original need to be merged into the copy; not sure how this would apply correctly outside of merges)
[23:21] <luke-jr__> 2. history-only (new file, but retaining history of original file at time of copy)
[23:21] <luke-jr__> 3. unknown copy (always causes conflicts in ambiguous cases)
[23:22] <jelmer> luke-jr__: what about files that are being split?
[23:22] <luke-jr__> jelmer: that's more of a block-copy, unrelated but nice to add
[23:22] <jelmer> luke-jr__: I think copy tracking and how it should be implemented is perhaps better left until the moment people start working on it, it's a complex beast
[23:23] <luke-jr__> eg, splitting a file is on par with moving a funciton from a.c to (pre-existing) b.c