[00:19] <Odd_Bloke> So, anyone in here going to FOSDEM?
[00:22] <bartzitz> hello, i'm affected by this bug https://bugs.launchpad.net/bzr/+bug/319790 (can't unshelve my changes)
[00:22] <bartzitz> i have a shelf file and my changes are visible there
[00:22] <bartzitz> but i can't decrypt the syntax
[00:23] <bartzitz> help, anyone?
[00:24] <jfroy|work> spiv: branches to address URL escaping in bzr and loggerhead have been submitted. Thanks again for your input last week.
[00:26] <spiv> jfroy|work: you're welcome!
[00:26] <lifeless> bartzitz: its a binary file these days, it can be extracted using bzrlib
[00:26] <lifeless> bartzitz: does 'unshelve --dry-run' work ?
[00:27] <bartzitz> as far as i can see it's not completely binary, i mean i can see snippets with my shelved changes
[00:27] <bartzitz> i reaaly need to quickly recover it
[00:27] <bartzitz> wii try --dry-run now
[00:28] <bartzitz> it shows a progress bar (something is going on). but in the end the same message: bzr: ERROR: No such file: None
[00:31] <lifeless> bartzitz: I'm just looking at the bug now
[00:31] <bartzitz> lifeless: ok thanks, i'll wait
[00:34] <lifeless> bartzitz: reproduced, so I can investigate
[00:37] <lifeless> spiv: ping
[00:38] <lifeless> pdb bailing worse :(
[00:39] <lifeless> abentley: ping
[00:39] <lifeless> abentley: need some insight into transform
[00:39] <spiv> lifeless: ouch
[00:39] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/319790
[00:39] <lifeless> follow my recipe at the end
[00:39] <spiv> lifeless: ok
[00:39] <lifeless> with BZR_PDB=1 and bzr.dev
[00:39] <lifeless> then do
[00:39] <lifeless> bt
[00:39] <lifeless> list
[00:40] <lifeless> for me, that gave be a backtrace from pdb :P
[00:40] <lifeless> spiv: also, do you want to get together today?
[00:40] <lifeless> I don't know if you saw, but I'd kind of like to
[00:42] <bartzitz> lifeless: bzr.dev, development version you mean?
[00:43] <lifeless> bartzitz: yes, it has the bug still
[00:43] <lifeless> bartzitz: first thing in confirming, make sure its not fixed already :)
[00:44] <bartzitz> lifeless: i see. i'll have to compile it then
[00:44] <lifeless> bartzitz: hang on
[00:44] <lifeless> bartzitz: you don't need to do anything till I have a fix for you
[00:44] <bartzitz> lifeless: ok
[00:45] <spiv> lifeless: gar, it seems to be a bug in my workaround :(
[00:47] <spiv> lifeless: ok, trivial fix for the pdb issue:
[00:47] <spiv> lifeless:
[00:47] <spiv> -                p.curframe = p.stack[p.curindex]
[00:47] <spiv> +                p.curframe = p.stack[p.curindex][0]
[00:48] <spiv> (in bzrlib/commands.py, of course)
[00:50] <lifeless> thanks spiv
[00:50] <lifeless> spiv: now, the other issue :)
[00:50] <lifeless> spiv: shall we sprint?
[00:56] <lifeless> bartzitz: its just deletes; working on a fix
[00:57] <bartzitz> lifeless: thanks a lot, i have some critical stuff in there
[01:00] <poolie> (out to lunch)
[01:01] <spiv> lifeless: the weather is making me disinclined to move, let alone go out and about ;)
[01:02] <lifeless> spiv: ok
[01:02] <spiv> It would be good to get together again soon though.  How about Monday?
[01:03] <lifeless> spiv: I could pop up if you like
[01:03] <spiv> (IIRC the weather is supposed to be kinder by then...)
[01:03] <lifeless> re Monday I'll need to check with Lynne
[01:03] <spiv> I'll need to check with Mary too, but IIRC she'll be at uni that day.
[01:03] <spiv> So here would be fine.
[01:03] <mxpxpod> what is the difference between the shelve/unshelve in bzrtools and the one that's included with bzr?
[01:04] <lifeless> mxpxpod: the bzrtools one predates and isn't as capable
[01:04] <mxpxpod> lifeless: ok, thanks
[01:04] <lifeless> mxpxpod: its deprecated now in fact
[01:04] <mxpxpod> lifeless: so I should be using shelve and unshelve rather than shelve1
[01:04] <lifeless> mxpxpod: yes
[01:04] <mxpxpod> ok, thanks
[01:06] <mxpxpod> how do you show the changes in something that's shelved?
[01:06] <lifeless> mxpxpod: unshelve --dry-run
[01:06] <lifeless> spiv: I
[01:07] <lifeless> 'm a tad confused, are you saying your place is fine Monday, or today :)
[01:07] <lifeless> crossed-threads I think
[01:07] <lifeless> OTOH if its really hot, perhaps I should just stay here in my airconditioned room :)
[01:08] <spiv> lifeless: Monday
[01:08] <mxpxpod> lifeless: is there a way to see the diff output of --dry-run?
[01:08] <lifeless> mxpxpod: I'm not sure
[01:08] <mxpxpod> lifeless: ok
[01:08] <spiv> lifeless: I don't have air con, so you probably do want to avoid here today ;)
[01:08] <lifeless> mxpxpod: if you can't figure one out, file a bug ?
[01:08] <mxpxpod> alright, thanks
[01:21] <lifeless> bartzitz: I've figured out the api for shelve enough to do a low level unit test now, which means the next thing is the actual fix
[01:22] <bartzitz> lifeless: great
[01:23] <lifeless> jam: around?
[01:24] <lifeless> vila: or you ?
[01:47] <jelmer> looks like ohloh will be having bzr support soon \o/
[01:48] <jelmer> lifeless, could pqm be stuck atm?
[01:50] <beuno> jelmer, where have you read this?
[01:56] <jelmer> beuno, talking with one of the ohloh folks
[01:57] <beuno> jelmer, awesome
[01:58] <lifeless> jelmer: its quiesced; as per the mail on bazaar@
[01:58] <jelmer> lifeless: ah, sorry - must've missed that
[02:03] <mwhudson> jelmer: cool beans
[02:05] <lifeless> whats cool?
[02:06] <mwhudson> ohloh
[02:06] <lifeless> oh right
[02:06] <fullermd> No, ohloh.
[02:07] <lifeless> someone should setup ohlol
[02:07]  * lifeless looks at fullermd
[02:07] <fullermd> I'm working on ohhai first.
[02:07] <mwhudson> ohrly etc
[02:07] <lifeless> with its sister site ohbai?
[02:07] <mwhudson> because i'm lazy
[02:08] <fullermd> ohbai is replacing 401 in HTTP/2.0.
[02:08] <mwhudson> how should i encode a filename in a content-disposition header?
[02:08] <mwhudson> as i would for a url?
[02:09] <lifeless> iIRC yes
[02:09] <igc> hi all
[02:09] <lifeless> I think its also come up in errata
[02:10] <lifeless> http://www.ietf.org/rfc/rfc2183.txt
[02:10] <mwhudson> yeah just found that one
[02:10] <mwhudson>    Current [RFC 2045] grammar restricts parameter values (and hence
[02:10] <mwhudson>    Content-Disposition filenames) to US-ASCII.
[02:10] <lifeless> well
[02:10] <lifeless> URL's are US_ASCII too
[02:11] <mwhudson> true i guess
[02:11] <lifeless> gimme a sec to page this in
[02:12] <mwhudson> well, don't want to distract
[02:12]  * mwhudson watches ff save a file called "a%20b"
[02:12] <lifeless> did you find http://www.ietf.org/rfc/rfc2184.txt
[02:13] <mwhudson> ah no
[02:13]  * mwhudson reads
[02:13] <lifeless> 2183 says '2184 for non-ascii params
[02:18] <mwhudson> huh
[02:18] <bartzitz> lifeless: don't want to bother you, but how the unshelf fix is going? i'll have to find other solution if it's going to take long
[02:18] <mwhudson> so for the case i'm interested it most immediately (a filename containing spaces), all i have to do is put the filename in quotes
[02:18] <mwhudson> oops
[02:19] <lifeless> bartzitz: in progress
[02:19] <bartzitz> lifeless: thanks
[02:19] <lifeless> bartzitz: its a bit of the code base I'm not very familiar with, and noone that is on is either
[02:20] <mwhudson> ow
[02:20] <mwhudson> loggerhead can't even _render_ a link to a file containing non-ascii
[02:20]  * mwhudson stabs python
[02:30] <fullermd> Wuff.  Hour 38 to 'check' bzr.dev.
[02:31]  * fullermd remembers why he doesn't do it very often.
[02:31] <lifeless> fullermd: wtf
[02:31] <lifeless> oh yeah
[02:32] <lifeless> see my mailabout faster check ?  :P
[02:41] <lifeless> bartzitz: ok, its PreviewTree missing some api's
[02:41] <lifeless> bartzitz: I think>. Anyhow, am progressing
[02:59] <mwhudson> >>> inv['TREE_ROOT'].children.keys()
[02:59] <mwhudson> ['a b', 'serve-branches.log', u'\xe9']
[02:59] <mwhudson> this isn't what i was hoping to see, btw
[03:00] <mwhudson> is there some way i can get this information in a type-consistent way?
[03:00] <lifeless> mwhudson: what information
[03:00] <mwhudson> lifeless: the list of files in a directory
[03:02] <mwhudson> hm, maybe i'd be better off using revtrees rather than inventories directly?
[03:02] <lifeless> that looks type consistent to me, modulo python suckage
[03:02] <lifeless> you can use inventories if you want, but trees are the recommended interface
[03:03] <mwhudson> the way to avoid python suckage is to be consistent about using unicode or bytestrings
[03:03] <lifeless> oh yes
[03:03] <lifeless> and we are :)
[03:03] <lifeless> I will wager your test code isn't consistent or something like that
[03:03] <mwhudson> only using unicode when there are high-bit set characters is not consistent in my book
[03:04] <lifeless> completely agree
[03:05] <lifeless> we decode('utf8') all the paths coming out of dirstate
[03:05] <lifeless> and we take what we get from the xml parser in pythons standard library
[03:05] <lifeless> don't assume what you are seeing is bzrlibs fault
[03:05] <mwhudson> http://pastebin.ubuntu.com/114346/
[03:05] <mwhudson> well, maybe not
[03:06] <mwhudson> anyway, trees seem saner, so i'll go that way i guess
[03:06] <lifeless> I will bet you that the xml decode is what is giving the ascii strings there
[03:08] <lifeless> I guess I'm saying
[03:08] <lifeless> don't go rewriting a bunch of code to avoid this
[03:08] <lifeless> as RevisionTree answers directly from inventory anyway
[03:08] <lifeless> it won't be saner in this respect
[03:09] <mwhudson> hm
[03:09] <mwhudson> it seems list_files is
[03:10] <mwhudson> but walkdirs() isn't
[03:11] <lifeless> why does it matter to you - if its a path in bzrlib, treat it like its unicode. Unless you explicitly use a utf8 API that is
[03:18] <lifeless> bartzitz: I have bad news for you
[03:18] <lifeless> bartzitz: I'm going to need to consult with the author off this code to get a proper fix; I don't understand some of the intent
[03:19] <lifeless> bartzitz: though I'm going to persevere a bit more
[03:28] <jfroy> quick question: is there a command to switch an existing repo to having no trees by default
[03:29] <jfroy> or do I need to touch .bzr/repository/no-working-trees ?
[03:29] <lifeless> for now, touch it
[03:29] <lifeless> there is a patch in progress
[03:29] <jfroy> ok
[03:29] <jfroy> I just don't like (too much) to rely on implementation details :p
[03:29] <jfroy> and thank you :)
[03:47] <lifeless> bartzitz: fixed
[03:47] <lifeless> bartzitz: just apply the patch from the bug report to your local copy of bzr
[04:15]  * igc lunch & medical stuff - bbl
[04:16] <lifeless> jelmer: you really should push your improvements to bzr-hg and bzr-git trunks :P
[04:16] <KhaZ> Hi!  Quick question about bzr-hg, if anyone's familiar with it.  Are you supposed to use bzr pull [url-to-your-hg-path] to populate it?  or bzr branch, or which?
[04:17] <bob2> zing!
[04:17] <lifeless> KhaZ: bzr init; bzr pull
[04:17] <lifeless> KhaZ: if you do 'bzr branch' it will create a hg branch in the output ;)
[04:18] <KhaZ> Ah.  Heh, I do want to avoid that. ;)
[04:19] <KhaZ> I do dig that launchpad website.  No chance that the software driving that is open source, eh? :)
[04:20] <spiv> KhaZ: It will be in July: https://dev.launchpad.net/OpenSourcing
[04:20] <KhaZ> Oooh, neato.  I wonder if my work would be interested in that.
[04:21] <KhaZ> Allowing we're around at that point, given all the bloody layoffs. :(
[04:22] <lifeless> KhaZ: are you @ IBM/MS/Sun ?
[04:22] <KhaZ> Hrmm.  I'm trying to use hg-bzr from jelmer's branch, and it's complaining about 'No module named foreign'.
[04:22] <KhaZ> lifeless: No, Disney, technically.
[04:22] <lifeless> oh cool
[04:22] <KhaZ> Is 'foreign' something from Python, or something from a version of bzr that I don't have?
[04:22] <lifeless> its a addin bzr has
[04:22] <mwhudson> KhaZ: you probably need a newer bzr
[04:23] <lifeless> jelmer wrote it as common infrastructure to bzr-hg/bzr-git/bzr-svn
[04:23] <KhaZ> Hrmm. 1.9 isn't cool enough? :)
[04:23] <lifeless> its been merged to bzr itself recently
[04:23] <KhaZ> Ah, neat.
[04:23] <lifeless> we're getting ready to release 1.12
[04:23] <KhaZ> How recent?  1.10?  1.11?
[04:23] <lifeless> so 3 months
[04:23] <lifeless> 1.11 should be fine
[04:23] <mwhudson> i think 1.11 is new enough
[04:23] <KhaZ> OK.  Unmasking I will go.
[04:23] <lifeless> igc: hi
[04:27] <KhaZ> Hmm.  Still complains about not having a module named 'foreign' in 1.11.  Guess I need to go install it.
[04:28] <mwhudson> can i dump the xml of an inventory somehow?
[04:28] <lifeless> you may bzr.dev
[04:28] <lifeless> *need*
[04:28] <KhaZ> Is there an automated way to install bzr plugins?  Or do I have to do the download/extract/setup.py build/setup.py install?
[04:28] <lifeless> mwhudson: yes but why
[04:28] <KhaZ> Like the trunk?
[04:28] <lifeless> mwhudson: I smell the need for a preimp chat
[04:28] <mwhudson> lifeless: still infuriated by this unicode thing
[04:28] <bob2> KhaZ: cd ~/.bazaar/plugins ; bzr co lp:bzr-something ; bzr whateveritdoes
[04:28] <mwhudson> just want to confirm what's going on, not actually coding anything
[04:28] <lifeless> KhaZ: most plugins just work by 'bzr branch lp:bzr-PLUGIN ~/.bazaar/plugins/PLUGIN
[04:29] <KhaZ> Ah, awesome.
[04:29] <lifeless> mwhudson: repository.get_inventory_xml
[04:29] <lifeless> KhaZ: ones with C extensions will need more
[04:30] <KhaZ> Nift.  Can I make 'aliases' in bzr, much like in hg with it's alias module?
[04:30] <lifeless> mwhudson: or r.inventories.get_record_stream([('foo',), 'topological', True).next().get_bytes_as('fulltext')
[04:30] <lifeless> KhaZ: yes
[04:30] <KhaZ> Like, could I alias that bzr branch line to something like 'bzr install_plugin PLUGIN'?
[04:30] <KhaZ> Hot diggity.
[04:31] <KhaZ> Hrmm.  I take it there's more than sudo bzr branch lp:bzr-foreign /usr/lib/python2.5/site-packages/bzrlib/plugins/foreign tho?
[04:31] <KhaZ> I do that, and it still complains about not having 'foreign' as a module.
[04:31] <mwhudson> lifeless: get_inventory_xml worked thanks
[04:31]  * mwhudson stabs the effbot
[04:32] <mwhudson> >>> [e.get('name') for e in et.parse(StringIO(b.repository.get_inventory_xml(b.last_revision()))).findall('file')]
[04:32] <mwhudson> ['a b', 'serve-branches.log', u'\xe9']
[04:33] <lifeless> mwhudson: see above, not bzrlib
[04:33] <KhaZ> lifeless: I take it you meant to send that to me
[04:33] <lifeless> mwhudson: but you haven't answered my question
[04:33] <lifeless> KhaZ: send what to you ?
[04:33] <KhaZ>  < lifeless> mwhudson: see above, not bzrlib
[04:34] <KhaZ>  < lifeless> mwhudson: see above, not bzrlib
[04:34] <KhaZ> Oops.
[04:34] <lifeless> KhaZ: no, I meant to send that to mwhudson
[04:34] <KhaZ> Oh.  Apologies. ;)
[04:34] <mwhudson> lifeless: so loggerhead blows up reasonably thoroughly when there are non-ascii names in the inventory
[04:34] <jfroy> ouch
[04:34] <mwhudson> lifeless: just related and slow paced digging related to that
[04:35] <lifeless> mwhudson: are you treating the paths as unicode
[04:35] <lifeless> mwhudson: or are you treating them as bytes
[04:35] <mwhudson> lifeless: well so far mostly limping along ignoring the issue
[04:35] <lifeless> I *know* you are getting bytes from the inventory, but what are you treating them as
[04:35] <jfroy> mwhudson: I actually glanced over loggerhead's source today, and I did get somewhat worried that it didn't seem to really pay attention to using unicode internally and encoding only at the end
[04:35] <jfroy> :|
[04:36] <mwhudson> lifeless: deciding which is obviously somewhat related to fixing the problem :)
[04:36] <lifeless> if you treat everything as unicode it should just work
[04:36] <mwhudson> jfroy: hello, by the way :)
[04:36] <jfroy> mwhudson: yo :)
[04:36] <lifeless> KhaZ: run bzr with -Derror
[04:36] <lifeless> KhaZ: and pastebin the result plase
[04:36] <lifeless> *please*
[04:36] <jfroy> lifeless: lol
[04:37] <mwhudson> jfroy: loggerhead is going to become the focus of my work time for the next couple of weeks btw
[04:37] <jfroy> interesting
[04:37] <mwhudson> jfroy: so i should be able to fix all this rubbish up
[04:37] <mwhudson> certainly, the intent of rendering is to produce a unicode string
[04:37] <KhaZ> bzr -Derror just seems to send --help?
[04:38] <jfroy> I've pushed a minor branch today to prettify URLs coming out of its templates (basically making it use bzrlib.urlutils instead of urllib, and I fixed up urlutils)
[04:38] <jfroy> mwhudson: huh no :p
[04:38] <lifeless> KhaZ: bzr -Derror $WHATEVER_YOU_WERE_DOING
[04:38] <KhaZ> Oy. ;)  No need to yell!  (J/k!)
[04:38] <jfroy> you want to work with unicode strings internally, then output utf-8 in the templates, or, if you're using a filename as a URL, encode the URL properly (the functions in urlutils will do that)
[04:38] <mwhudson> jfroy: which is then encoded as it is sent to the client
[04:39] <mwhudson> in utf-8, indeed
[04:39] <jfroy> right
[04:39] <jfroy> for what it's worth, BTW, buildbot equally blows up when there are non-ascii strings making it to its template engine :p
[04:39] <lifeless> jfroy: mwhudson: Two things
[04:39] <jfroy> I borked more than one of those with my properly spelled named :sigh:
[04:40] <mwhudson> two facts (1) i am not a *complete* cretin when it comes to unicode handling (2) i am not entirely responsible for all of the code in loggerhead :-p
[04:40] <mwhudson> it's also hot and the end of my work day, so i'm probably being a bit vague
[04:40] <lifeless> the first things i that the encoding of content of user files is not well defined in bzrlib
[04:40] <lifeless> so whatever you plan, understand bzrlib will only give bytestrings for that content.
[04:40] <jfroy> lifeless: ah, that's a different problem, isn't it -- the file viewer, that is.
[04:41] <mwhudson> lifeless: i think loggerhead copes vaguely well with this (well, non-explody) actually
[04:41] <jfroy> the cheap way is probably to try to decode utf-8 internally, if that doesn't fail send it as utf-8 to the client, and if it fails encode as ascii with losses or something.
[04:41] <lifeless> secondly, while we define all paths as unicode in the API, we find that this sucks performance wise; we are slowly [carefully, very carefully] migrating much of bzrlib to use utf8 everywhere
[04:42] <jfroy> lifeless: interesting
[04:42] <mwhudson> lifeless: right, i was vaguely aware of this
[04:42] <mwhudson> lifeless: it seems that this has mostly affected working tree stuff so far?
[04:42] <lifeless> jfroy: I won't get into a discussion about heuristics right now :P
[04:42] <lifeless> anyway
[04:43] <lifeless> python unicode -> 4 bytes per character, very slow
[04:43] <jfroy> oh whoa, really
[04:43] <lifeless> python utf8 -> 1 byte per char for most chars, much leaner and faster
[04:43] <jfroy> UTF32 eh, that's pretty heavyweight
[04:43] <lifeless> UCS4 I thihnk, specifically
[04:43] <mwhudson> not really UTF :)
[04:43] <jfroy> right
[04:43] <jfroy> yeah
[04:44] <jfroy> my mistake :|
[04:44] <jfroy> In any case, I wonder why they decided to go with such a heavy representation.
[04:44] <mwhudson> simplicity of implementation and speed of indexing
[04:44] <mwhudson> i think
[04:44] <jfroy> And yeah, cutting your memory usage for all paths, filenames and URLs by an average of 4 is going to be a win
[04:45] <lifeless> its build time I think
[04:45] <lifeless> anwyay
[04:45] <lifeless> if you've ever done
[04:45] <mwhudson> also the bytestring code is probably more optimized
[04:46] <lifeless> python -c 'import cStringIO; print repr(cStringIO.StringIO(u"a").getvalue())'
[04:46] <KhaZ> lifeless: http://pastebin.com/m4497eb3b
[04:46] <KhaZ> Sorry about the wait; puppy needed to poop.
[04:46] <KhaZ> OH.  foreign should be in the hg directory
[04:46] <mwhudson> lifeless: shut it :)
[04:47] <jfroy> lifeless: 'a' :p
[04:47] <lifeless> jfroy: what platform are you on, and what python version
[04:47] <jfroy> darwin 2.5
[04:47] <lifeless> very interesting
[04:48] <lifeless> KhaZ: excellent
[04:48] <lifeless> KhaZ: yes, it should be
[04:48] <KhaZ> Unfortunately now it barfs about not finding os.
[04:48] <KhaZ> :(
[04:49] <KhaZ> http://pastebin.com/m45e9b8a1
[04:50] <lifeless> KhaZ: looks like a bug in jelmers branch of bzr-hg
[04:50] <lifeless> file a bug :)
[04:50] <jfroy> lifeless: what output were you expecting?
[04:50] <KhaZ> Heh.  doing an 'import os' at the top of the file works fine.
[04:50] <lifeless> $ python -c 'import cStringIO; print repr(cStringIO.StringIO(u"a").getvalue())'
[04:50] <KhaZ> Well, it makes it take a damned long time. ;)
[04:50] <lifeless> 'a\x00\x00\x00'
[04:51] <KhaZ> Am I technically allowed to check into jelmers branch?  Or would jelmer kill me? (Or, less dramatically, would I be denied permissions?)
[04:51] <lifeless> you would be denied
[04:51] <KhaZ> Le sigh.
[04:51] <lifeless> but
[04:51] <lifeless> its a DVCS
[04:51] <lifeless> you can create your own branch
[04:51] <lifeless> in fact you ahve locally
[04:51] <lifeless> so commit your fix
[04:51] <KhaZ> Yeah.  I've got it local at least.
[04:52] <lifeless> then do
[04:52] <KhaZ> Yessir.
[04:52] <lifeless> bzr push lp:~KhaZ/bzr-hg/fix-whatever
[04:52] <lifeless> assuming you've setup an account on launchpad
[04:52] <KhaZ> Ah crap. :(
[04:52] <KhaZ> bzr: ERROR: exceptions.AttributeError: 'InventoryFile' object has no attribute 'find_previous_heads'
[04:52] <lifeless> and given lp your ssh public key
[04:53] <lifeless> jfroy: your build of python has either a fixed cStringIO, or uses utf8 internally
[04:53] <lifeless> jfroy: this will depend on what python is using for its unicode string ops; I think its some system library it ends up depending on that determines this
[04:53] <KhaZ> lifeless: How/when do these branches get merged?  Is there one maintainer for all this?
[04:53] <jfroy> I never read the implementation of that module, but I'm surprised it'd be any different than that of other unix platforms
[04:54] <jfroy> that's quite possible
[04:54] <lifeless> jfroy: darwin is quite different
[04:54] <lifeless> jfroy: cStringIO won't be different
[04:54] <jfroy> Is it? Mac OS was very different, indeed. I know there's some massaging to build Python as a framework.
[04:54] <lifeless> jfroy: but apple carry patches to python; they might have fixed it so that cStringIO.StringIO(unicodething) transcodes rather than reading the representation array
[04:55] <jfroy> that's quite possible
[04:55] <lifeless> jfroy: so yeah, either a cStringIO fix, or the representation arry is utf8
[04:55] <lifeless> KhaZ: when you think the branch is ready you can create a merge proposal
[04:55] <lifeless> just go to lp to your branch and click on 'propose for merging'
[04:55] <jfroy> in any case, it doesn't really change the validity of the argument -- utf-8 is going to be more compact on average.
[04:56] <lifeless> oh yes
[04:56] <KhaZ> Interesting.
[04:56] <jfroy> There's probably going to have to be a round-trip to unicode for NFC normalization on darwin
[04:56] <lifeless> jfroy: which is why we are moving to it
[04:56] <lifeless> jfroy: utf8 is unicode :P
[04:57] <jfroy> I meant to the unicode type.
[04:57] <jfroy> IIRC the unicodedata module works with unicode objects
[04:57] <lifeless> jfroy: but yeah, when normalisation is needed, and we have utf8_bytestrings we need to either decode, which is a nonsense no-op on utf8 internal pythons, or have direct C access to something to normalise for us
[04:58] <lifeless> jfroy: mwhudson: anyhow those were the two points; standardings on 'unicode' type strings is very slow in python, we learnt this late
[04:59] <lifeless> don't start down the wrong path
[04:59] <jfroy> I'm half surprised by that. I fully expected them to be slower, but not enough to not be willing to pay the cost.
[04:59] <mwhudson> ah hah
[04:59] <mwhudson> maybe i can blame paste for this
[04:59] <jfroy> But 4 bytes per character, if indeed some implementations are using that, is overkill.
[05:00] <lifeless> jfroy: you can see my test
[05:00] <lifeless> jfroy: python on ubuntu/debian does
[05:00] <lifeless> and I suspect redhat etc too
[05:00] <KhaZ> Now, pardon my ignorance, but there's no other way to import an hg repository other than bzr-hg, yeah?
[05:00] <lifeless> KhaZ: you can use fast-export
[05:00] <mwhudson> KhaZ: there's fast-import based approachs
[05:00] <jfroy> lifeless: I assume you are building a sub-class of str for this?
[05:01] <mwhudson> the rage, it boils
[05:01] <lifeless> jfroy: no, we are just careful to use hungarian names for variables, and we use str
[05:01] <jfroy> lifeless: I'm not sure I like that too much, but I suppose if you're *very* careful.
[05:02] <lifeless> jfroy: subclassing str would be terribly slow
[05:02] <KhaZ> Huh.  What's fast-export/import?
[05:02] <jfroy> I had in mind something like NSString / CFString which will vary their internal encoding based on what operations you perform on them and how they were initialized -- most of the time they never upgrade their internal representation to unicode.
[05:02] <jfroy> lifeless: Ah I see.
[05:02] <lifeless> jfroy: here's a data point to think about
[05:03] <lifeless> jfroy: the history of bzr itself, has 3.3GB of raw text in the inventory metadata
[05:03] <jfroy> *internal representation to USC2
[05:03] <lifeless> jfroy: we do a huge amount of text processing
[05:03] <jfroy> you don't need to convince me :p
[05:04] <KhaZ> Oh, NEAT.  So if I understand correctly. bzr-fast-import basically sucks in a repository but doesn't worry about syncing back and forth?
[05:04] <lifeless> KhaZ: right, its a great migration tool
[05:04] <lifeless> its not as seamless but its been used very successfully by folk
[05:04] <KhaZ> lifeless: Oh, perfect!  That's all I need.
[05:05]  * mwhudson thinks about monkey patching urllib.quote with bzrlib.urlutils.encode
[05:05] <lifeless> mwhudson: no
[05:05] <mwhudson> thanks
[05:05] <lifeless> mwhudson: send in a branch
[05:05] <lifeless> urllib does need love
[05:05] <mwhudson> lifeless: to cpython?
[05:05] <mwhudson> won't help my 2.4 deployment
[05:06] <jfroy> mwhudson: I did that :p
[05:06] <jfroy> more or less
[05:06] <mwhudson> jfroy: do you know what the status of this issue is? http://mail.python.org/pipermail/python-dev/2006-July/067248.html
[05:06] <jfroy> https://bugs.launchpad.net/loggerhead/+bug/325974
[05:07] <mwhudson> jfroy: i don't think that one will help the issue at hand though
[05:07] <jfroy> probably not, if paste is using urllib internally
[05:07] <mwhudson> right
[05:07] <mwhudson> construct_url(environ, path_info=u'
[05:07] <jfroy> I actually tried to patch in urllib in serve-branches during imports
[05:07] <jfroy> before importing anything else
[05:07] <mwhudson> \xe9') --> boom
[05:08] <jfroy> the trick is urlutils.encode uses urblib.quote
[05:08] <jfroy> hence, sadness ensued
[05:08] <mwhudson> i guess we need to supply our own version of construct_url
[05:08] <jfroy> if bzrlib's urlutils are fixed up to operate independently, then the monkeywrenching could be done
[05:08] <mwhudson> (nice thing about paste: at least we can do this)
[05:09] <jfroy> you're not supposed to ever give quote unicode strings :|
[05:09] <jfroy> well, unicode objects
[05:09] <jfroy> to not confuse things
[05:10] <mwhudson> so i should encode as utf-8 first?
[05:11] <mwhudson> ah that works
[05:11] <jfroy> Ah, actually
[05:11] <jfroy> http://bazaar.launchpad.net/%7Ejeanfrancois.roy/loggerhead/pretty-url/revision/265
[05:11] <jfroy> I did 2 things
[05:11] <mwhudson> of course, processing the resulting url fails horribly :)
[05:11] <jfroy> put urlutils.escape(urlutils.unescape(...)) after request.construct_url
[05:11] <jfroy> but also, in def app
[05:12] <jfroy> urlutils.escape(urlutils.unescape(...)) self._url_base and self._static_url_base
[05:12] <jfroy> def url() basically works with url_base to build URLs
[05:13] <jfroy> and yeah, that will force _url_base to be a str object
[05:14] <jfroy> since urlutils.encode encodes a unicode object to utf-8 before it hands it to urllib.quote
[05:14] <jfroy> and then forces the output through str()
[05:15] <lifeless> spiv: so, did my recap email help?
[05:16] <KhaZ> Just reading up on the comparisons between hg and bzr.  I've read you can't checkout a single directory underneath a repository, but you can checkin based solely on a subdirectory.  Which is true for pulling?  Can you pull based only on a subdirectory?
[05:17] <jfroy> AFAIK puling pulls changesets from the source branch, and thus, no.
[05:17] <jfroy> *pulling
[05:17] <KhaZ> Ah, nuts. :/
[05:18] <KhaZ> That really irritated me about hg too.  Was hoping bzr was better about it. ;)
[05:18] <jfroy> bzr is atomic
[05:18] <jfroy> you can't have some subdirectory at revid xyz and the rest at abcd
[05:19] <jfroy> that's an inconsistent snapshot of the branch history -- it's bad :p
[05:19] <lifeless> KhaZ: its something I would like to make more flexible, and so would igc
[05:19] <lifeless> atomic shouldn't mean inflexible
[05:19] <KhaZ> *shrugs* I dunno.  I work with multiple hobby projects all in one repository.  Creating multiple repositories for my tiny applications would be bad too.
[05:19]  * KhaZ nods at lifeless
[05:20] <lifeless> KhaZ: well you can just use lots of seperate branches one per hooby project
[05:20] <lifeless> KhaZ: branch and repo are disconnected in bzr
[05:20] <KhaZ> I suppose that's true.  And seeing as how svn+ssh makes it all hidden anyways.  Never thought about that.
[05:20] <mwhudson> jfroy: what's your interest in loggerhead/bzr if you don't mind me asking?
[05:20] <jfroy> lifeless: how would you ever make that work? If directory B has new source that depends on new source in directory A to compile, then pulling only directory B will get you a broken branch / working copy (assuming that the changes in A and B were commited together)
[05:20] <KhaZ> Would make the bzr st better too.
[05:21] <lifeless> jfroy: of course
[05:21] <KhaZ> jfroy: I agree, but in my opinion a user who asks for that is asking for user error.  But that's just the way my brain works with vcs's.
[05:21] <mwhudson> jfroy: you clearly know a bit more about the practicalities of url generation/processing than i do, i hope you can stick around :)
[05:21] <jfroy> mwhudson: sharing / browsing branches at work. an internal, mini-launchpad-while-waiting-for-launchpad-to-be-open-sourced
[05:21] <lifeless> jfroy: but you're conflating what can go wrong with how the tool should behave
[05:21] <mwhudson> jfroy: ah cool
[05:22] <KhaZ> Oh neat.  So with bzr I have a separation between a 'repository' and a 'working directory'?
[05:22] <KhaZ> hg kinda blurred the lines, or so I thought?
[05:22] <jfroy> lifeless: I would personally not be willing to sacrifice changeset atomicity
[05:22] <lifeless> jfroy: specifically, you'd track the revid per dir, and warn about old subdirs on status etc, and have the default to be to update everything
[05:22] <jfroy> KhaZ: yes1
[05:22] <jfroy> *!
[05:22] <lifeless> jfroy: you'd still be atomic
[05:22] <KhaZ> Hawt.  I like that.
[05:23] <jfroy> lifeless: I suppose, but I don't like it.
[05:24] <jfroy> atomicity means your working copy is at a specific revid of a specific branch, not kool-aid.
[05:24] <jfroy> *no kool-aid.
[05:24] <lifeless> jfroy: right, so you wouldn't need to use it :)
[05:24] <jfroy> The next step would be being able to mix 2 or more branches in the same working copy.
[05:24] <lifeless> jfroy: thats an asked for feature too; other more mature things like perforce and clearcase support that
[05:24] <KhaZ> Heh.  Atomicity to me always meant that when you check in, it doesn't barf half way and end up with a half submit. ;)  Ahh, visual source safe, how archaic you now are.
[05:25] <jfroy> directory A is using branch alpha at revid 123 and directory B branch beta at revid 2345, go go nightmare
[05:25] <lifeless> jfroy: I think it would be a nightmare if it could ever happen accidentally, or without warning
[05:25] <jfroy> I believe that giving people the ability to do it is just as bad.
[05:25] <lifeless> jfroy: but there are plenty of valid use cases which people simulate with 'revert -r 123 directory_a' at the moment
[05:26] <jfroy> That's why I don't like git -- it lets you do completely arcane things that will rear their ugly heads later on and beat you up
[05:26] <mwhudson> well, woo, i can annotate a file called 'é' in loggerhead
[05:26] <jfroy> mwhudson: :)
[05:26] <KhaZ> The ability to have different directories at different 'revisions' is supported by a lot of software, and in some cases, a lot of use cases too.  At work for instance we have a lot of artists who have their data at a higher revision than the code, because they just want to see their updates.
[05:26] <lifeless> jfroy: they already have it, but bzr doesn't know that they are doing it well enough to help them or warn them
[05:27] <jfroy> I suppose
[05:27] <lifeless> jfroy: I really do appreciate the issues; and I certainly am not suggesting that we definitely do something to directly support this
[05:27] <lifeless> but! it comes up a lot
[05:27] <lifeless> and saying 'turn dir X into a nested branch' really isn't a good answer
[05:27] <lifeless> its too big a hammer
[05:28] <lifeless> and its the wrong sort of hammer for many cases
[05:28] <jfroy> KhaZ: that doesn't make sense to me, in the sense that if an artist commits a new asset, the asset commit will increment the artist's revno by one.
[05:28] <lifeless> KhaZ: in svn ?
[05:28] <jfroy> The source code won't be "behind", it just won't be changed by that changeset.
[05:28] <jfroy> lifeless: agreed
[05:29] <KhaZ> lifeless: We use Perforce at work, sadly.
[05:29] <lifeless> jfroy: I think the use case is 'source code behind trunk, changes to assets done to trunk'
[05:29] <lifeless> jfroy: so there isn't a single revno for the whole tree on the artists disk
[05:29] <KhaZ> jfroy: Sure.  Well our artists iterate a lot on their assets, and often don't want to upgrade to the latest development snapshot that we've checked in, as stuff just 'works' right then and there.
[05:29] <poolie> lifeless: hi; can you tell me again the mail subject you especially wanted me to answer?
[05:29] <lifeless> poolie: you did, last night :)
[05:29] <lifeless> poolie: it was the on-track on
[05:29] <lifeless> e
[05:30] <KhaZ> Quick question, I've got my repo built now, but if I do 'bzr update', I get: bzr: ERROR: No WorkingTree exists for "file:///var/hg/repositories/eddie-bzr/.bzr/checkout/".
[05:30] <KhaZ> How'd I dun' brokenated it so soon?
[05:30] <lifeless> KhaZ: 'bzr checkout .' in that directory
[05:30] <KhaZ> Oh.
[05:30] <jfroy> KhaZ: I've been working with DVCSes for too long I guess. I my mind that just means an artist isn't pulling from the blessed master branch and commits to his or her local branch his or her new assets
[05:30] <poolie> i thought you mentioned another this morning?
[05:30] <poolie> hey but if that's all, i'm happy
[05:30] <lifeless> the output from the converter is a little odd
[05:30] <KhaZ> bzr checkout . = bzr: ERROR: Not a branch: "/var/hg/repositories/eddie-bzr/.bzr/branch/".
[05:30] <lifeless> poolie: oh
[05:30] <KhaZ> I think bazaar hates me.
[05:30] <jfroy> and the artists could potentially have their own blessed central branch which they could update from time to time with the coder's blessed branch.
[05:30] <jfroy> etc
[05:30] <lifeless> KhaZ: look in the subdirs
[05:31] <KhaZ> jfroy: Yeah, and I've never worked with DVCS (to my chagrin).  That's why I find this conversation so intriguing and so mind blowing. ;)
[05:31] <lifeless> poolie: uhm, I mailed yesterday about fetch and old history
[05:31] <jfroy> KhaZ: checkout == branch + bind
[05:31] <lifeless> poolie: or wednesday maybe
[05:31] <KhaZ> And to be honest, I wonder about DVCS and artist workflows.  Inability to merge makes me think artists should never use DVCS.
[05:31] <jfroy> so the argument is a branch, and optionally a destination directory
[05:31] <lifeless> KhaZ: bzr supports a central model too, which is roughly svn like
[05:32] <lifeless> jfroy: there is a special case in checkout
[05:32] <KhaZ> "Look in the subdirs"?  I've got .bzr, hg-export.status (not a dir) and 'master', whatever that is.
[05:32] <jfroy> lifeless: when cwd is a branch?
[05:32] <lifeless> jfroy: if you do 'checkout .' in a branch, you just build a tree
[05:32] <jfroy> makes sense
[05:32] <lifeless> jfroy: which is what a number of vcs do
[05:32] <KhaZ> lifeless: Hrmm, interesting.  Can you 'mix' modes?  i.e, have a section of a tree that's 'central' and a section that's normal DVCS?
[05:32] <lifeless> KhaZ: cd master
[05:32] <jfroy> KhaZ: the idea is more to "bless" remote branches.
[05:33] <lifeless> KhaZ: yes you can mix, but not like that :P
[05:33] <lifeless> KhaZ: its a configuration for a given branch/working tree
[05:33] <jfroy> People saying "OK, http://internal.example.com/bzr/master" is the master branch from which we'll ship.
[05:33] <KhaZ> Right.  Interesting stuff.
[05:33] <lifeless> KhaZ: just 'bzr checkout URL' rather than 'bzr branch URL', and when you commit it will go straight to URL rather than just locally.
[05:33] <KhaZ> So is 'master' bzr lingo for 'trunk'?
[05:33] <lifeless> KhaZ: its hg lingo
[05:33] <jfroy> nope
[05:33] <jfroy> well
[05:33] <lifeless> KhaZ: you just converted from hg
[05:33] <KhaZ> Ah.
[05:33] <jfroy> it's entirely up to you :)
[05:33] <jfroy> master, trunk, mainline, dev
[05:33] <KhaZ> So I can rename that 'master' to 'trunk' or 'fred' or what have you?
[05:34] <jfroy> pick what you prefer :)
[05:34] <lifeless> yes
[05:34] <lifeless> anyhow that master is probably your branch from hg
[05:34] <jfroy> it's just the name of the branch / branch directory
[05:34] <lifeless> cd to it and look at whats in it
[05:34]  * mwhudson avoids thinking about content-disposition headers for now
[05:34] <KhaZ> Nothing, but bzr update has it doing a lot of stuff. ;)
[05:34] <KhaZ> So if I understand correctly, the directory above 'master' is the repo, and 'master' is just the working copy?
[05:35] <jfroy> mwhudson: wait wait, isn't that a MIME header? Why would you care about that :p
[05:35] <jfroy> KhaZ: master is the branch
[05:35] <jfroy> a branch may or may not have a working tree. Generally, remote branches don't, to save disk space
[05:35] <KhaZ> Man.  I've got to read up on this branch/repo differentiation again.  I've been playing with too many VCS lately.
[05:36] <jfroy> a repository is, essentially, a "bucket of related changesets"
[05:36] <jfroy> it's an optimization to avoid duplicating history data for branches with a common ancestor
[05:36] <mwhudson> jfroy: it's an "often implemented" http header according to the http/1.1 rfc
[05:36] <KhaZ> Ah, neat.
[05:36] <mwhudson> we set it for download links
[05:36] <KhaZ> So it's like the master branch, or something?
[05:37] <KhaZ> Neat, so if I understand correctly, a repository will have zero or more branches, but a branch will always have a repo.
[05:37] <jfroy> You'd store the "master" branch in a repository on the remote branch server, along other branches
[05:37] <jfroy> KhaZ: no, branches can be standalone.
[05:37] <jfroy> They can exist outside or inside a repository
[05:37] <mwhudson> jfroy: does this look sort-of vaguely sane to you? http://pastebin.ubuntu.com/114424/
[05:38] <jfroy> when they are created inside a repository, they delegate history storage to the repository. Otherwise, they store history data within themselves.
[05:38] <KhaZ> jfroy: Right, but they have to reference a repository somehow, no?
[05:38] <KhaZ> Oh.
[05:38] <KhaZ> So they can be literally stand-alone.
[05:38] <jfroy> KhaZ: right, if you move a branch outside of its repository (using mv say), you'll break it
[05:38] <jfroy> yup
[05:38] <KhaZ> At the point at which they store history data within themselves, are they essentially a repository at that point?
[05:38] <KhaZ> Or is there still a difference between a 'stand alone' branch and a repository?
[05:38] <lifeless> KhaZ: they get a .bzr/repository subdir
[05:39] <jfroy> a repository is not a branch
[05:39] <jfroy> you cannot branch or checkout a repository
[05:39] <jfroy> a repository is merely a bucket of history data :p
[05:40] <KhaZ> History as in deltas?  Or meta data about the deltas?
[05:40] <KhaZ> Or both?
[05:40] <jfroy> A branch can be either stand-alone, or stored in a repository, correct.
[05:40] <jfroy> both
[05:40] <jfroy> the deltas themselves -- the changesets.
[05:40] <KhaZ> Right.  And all the informationa bout them.
[05:40] <jfroy> indeed
[05:40] <KhaZ> So you can PULL from a repository to create a branch, yeah?
[05:41] <jfroy> no, you always, always pull from a branch
[05:41] <lifeless> KhaZ: at a code level, we can do that, but there isn't any ui
[05:41] <jfroy> you can push a branch into a repository, creating a new branch stored inside the repository
[05:41] <jfroy> lifeless: what would the semantics of that be?
[05:41] <KhaZ> Huh, interesting.
[05:41] <jfroy> mwhudson: yeah
[05:42] <mwhudson> goody
[05:42] <KhaZ> Quick question, that centralized model (I'm reading up on it now); I'm guessing there's no way to truly 'lock' files?
[05:42] <KhaZ> i.e., artist 1 starts editing a maya scene, and artist 2 wants to edit it as well.  THe system can't notify artist 2 that it's already open for edit somehow?
[05:43] <lifeless> jfroy: init a target branch; source = bzrlib.repository.Repository.open(source); target = bzrlib.repository.Repository.open(target); target.fetch(source, tip); branch = bzrlib.branch.Branch.open(target); branch.set_revision_info(tip, tip_revno)
[05:43] <lifeless> jfroy: roughly
[05:43] <lifeless> KhaZ: no, there is no advisory locking of files today
[05:43] <lifeless> KhaZ: doable as a plugin though
[05:43] <fullermd> Not with distributed branches, no.  You don't even have any way of knowing that artist 1 HAS a branch, much less what they're doing with it.
[05:43] <fullermd> If they were working on a common branch, there's no theoretical obstacle to doing so, but nobody's done it.
[05:44] <KhaZ> I suppose it doesn't make as much sense in a VCS that doesn't do Perforce's read-only-if-not-checked-out schtick anyhow.
[05:45] <KhaZ> Is there a global option or something to make bzr commands only apply to a specified subdir and below?
[05:45] <jfroy> yeah, Bazaar isn't based on a lock model at all.
[05:46] <jfroy> Branches are merged and conflicts generated by merge algorithms.
[05:46] <KhaZ> Oh, never mind, it does already!
[05:46] <KhaZ> Or at least bzr st seems to.
[05:46] <KhaZ> jfroy: Yeah.  Doesn't work so well with binary files tho. :/
[05:46] <jfroy> nope :p
[05:46] <fullermd> WT commands generally do by passing them the dir, yah.
[05:46] <KhaZ> Stupid artists.  Learn to code your drawings. ;)
[05:46] <lifeless> KhaZ: no there isn't, but paths are shown relative to ., I believe
[05:47] <KhaZ> lifeless: Awesome.  Already a win over hg.
[05:47] <bob2> KhaZ: bzr'll at least recognise that and let you pick which file to go with
[05:48] <KhaZ> bob2: Ah, that's kinda neat.  I'm just trying to avoid the typical problem artists had with non-locking models of "F#@!, what do you mean you've been working on that for two weeks?  SO have I!  I'm not throwing out my changes!"
[05:49] <jfroy> I think that's called failure to communicate.
[05:49] <jfroy> :p
[05:50] <KhaZ> Yup.  But it happens more than you'd care to imagine...
[05:50] <jfroy> I sympathize with you though; it would be a big problem for a non-locking VCS.
[05:50] <lifeless> ok, time to call it a weke
[05:51] <lifeless> poolie: did you find the mail?
[05:51] <KhaZ> Yeah.  I think if I ever push DVCS it'll be engineers only.
[05:52] <jfroy> well, as was mentioned, a plug-in could be developed for that.
[05:52] <lifeless> KhaZ: we have reports of folk using bzr with artists and the like very successfully
[05:52] <KhaZ> jfroy: Hrmm, good point.  Well, it's a long way off until anyone at work cares what I think anyhow, so I can wait until said plugin comes to fruition. ;)
[05:52] <jfroy> Plug-ins can be extremely powerful things -- so many possibilities :)
[05:53] <KhaZ> jfroy: Aye.  I think I prefer bzr's plugin model over hg's too.
[05:53] <KhaZ> The simple fact I couldn't rewire hg diff drove me up the wall.
[05:53]  * mwhudson trials and errors with ff
[05:53] <KhaZ> lifeless: I'd be interested to hear how it works for them.
[05:54]  * jfroy wants more success stories too :)
[05:54] <KhaZ> Seriously now.  I'm glad I don't pay for Tortoise* software, because I have a veritable tortoise farm growing in my 'Add/Remove Programs'
[05:54] <KhaZ> TortoiseSVN/TortoiseHG/TortoiseBZR... Sheesh.
[05:54] <lifeless> KhaZ: 'well'
[05:54] <mwhudson> jfroy: another fun diff! http://pastebin.ubuntu.com/114432/
[05:54] <lifeless> KhaZ: :P
[05:55] <lifeless> KhaZ: seriously, thats all the detail I have
[05:55] <KhaZ> lifeless: That's the detail on my tortoise farm, or on the artists enjoying bzr? :)
[05:55] <lifeless> artists enjoying bzr?
[05:55] <lifeless> ok, see you all Monday
[05:56] <KhaZ> lifeless:  <  lifeless> KhaZ: we have reports of folk using bzr with artists and the like very successfully
[05:56] <KhaZ> lifeless: Later, thanks for your help. ;)
[05:56] <mwhudson> jfroy: btw, re: https://code.edge.launchpad.net/~jeanfrancois.roy/bzr/url-safe-escape/+merge/3417, bazaar doesn't use launchpad for tracking merge proposals
[05:57] <jfroy> mwhudson: looks good
[05:57] <mwhudson> jfroy: good enough for me, thanks :)
[05:58] <jfroy> mwhudson: bah, right
[05:58] <jfroy> I'll open a bug and huh... mail them a merge bundle?
[05:59] <mwhudson> yep
[05:59] <mwhudson> bzr send
[05:59] <mwhudson> + some twaddle in locations.conf
[05:59] <jfroy> yeah
[05:59] <jfroy> :sad:
[05:59] <jfroy> that needs to be improved
[06:00] <jfroy> child_submit_to (or whatever) isn't bad, but it can't go in locations.conf, it has to be in branch.conf
[06:00] <jfroy> which means you can't blanket a repository of (say shared remote) branches with it
[06:00]  * jfroy grumbles
[06:02] <mwhudson> jfroy: anyway, thanks for being a sounding board, i'll look at your merge proposal properly on monday :)
[06:03] <jfroy> No rush
[06:03] <jfroy> but cool :)
[06:03] <jfroy> My biggest concern right now is building some kind of bi-directional bridge between svn and bzr
[06:04] <jfroy> svn needs to stay the "master", because the svn server is backed up offsite, blah blah blah, and some people want to continue using it.
[06:04] <jfroy> While I and others want to use bazaar
[06:05] <jfroy> I'm aiming for a setup where there's a blessed bzr branch somewhere that stays in sync with svn (probably only svn trunk, svn branches be damned) through bzr-svn
[06:05] <jfroy> people using bazaar can branch off that svn mirror branch and do stuff, and eventually push back to that mirror branch, which will then sync up those changes with svn.
[06:06] <jfroy> I'm wondering how to handle conflicts in all this, ideally by not having to worry about them at all, e.g. preventing pushes to the svn mirror branch if that would cause a conflict.
[06:07] <jfroy> Maybe that mirror needs to be a bound branch....
[06:07] <jfroy> mmmmm
[06:07] <bob2> that'll just lead to a more annoying display of the conflicts
[06:07] <KhaZ> Hrmm, stupid question.. How do I set a custom diff tool in bzr?  Can't find anything in the configuration stuff to do it...
[06:08] <jfroy> KhaZ: you need the difftools plugin
[06:08] <jfroy> I believe
[06:08] <jfroy> bob2: am I aiming for the proverbial pipe dream?
[06:09] <bob2> KhaZ: extdiff, iirc
[06:09] <KhaZ> Ah... Will this replace the 'diff' command, or will I have to remember to always type 'bzr cdiff' or some such other?
[06:10] <jfroy> you can replace the diff command with an alias
[06:10] <bob2> no idea, cdiff is far too convenient for me to replace it
[06:10] <jfroy> or a plugin can override it, yeah
[06:10] <jfroy> but that would probably be rude
[06:10] <KhaZ> Haha
[06:11] <KhaZ> Does anything in bzr rely on diff exporting diff's of that variety?
[06:11] <bob2> jfroy: not sure, sorry
[06:11] <bob2> you can alias bzr diff to whatever you want
[06:11] <KhaZ> Oh that's awesome.  hg didn't allow that.
[06:11] <KhaZ> Yeah, just got it working with diff = diff --using colordiff
[06:12] <jfroy> bob2: I think to get a really robust solution, the bzr-svn syncing will have to happen as a subversion pre-commit hook
[06:12] <jfroy> and refuse commits that would cause a conflict, on either side
[06:12] <jfroy> well, commits from subversion, and basically bazaar you won't be able to push to a branch that has diverged and that takes care of that
[06:14] <bob2> KhaZ: bzr cdiff in bzrtools does that
[06:15] <KhaZ> Ah, neat.  I still like not having to train my lazy brain to remember to use 'cdiff'. ;)
[06:25] <KhaZ> Huh.  TortoiseBzr doesn't allow me to checkout to my usb drive.  Weird.
[06:33] <poolie> KhaZ: what happens?
[06:34] <KhaZ> poolie: Just doesn't show up as an option.
[06:34] <KhaZ> poolie: But if I do a checkout from the C:\ and rename C:\ to L:\ (my USB drive directory) it works fine.
[06:41] <poolie> lifeless: i answered
[07:14] <vila> hi all
[07:15] <poolie> hello vila
[07:15] <poolie> how's stuff?
[07:15] <vila> finer on the hardware side :) I had ti go back to store yesterday with my new toy just to discover that the failure was transient :-/
[07:16] <vila> s/ti/to/
[07:16] <poolie> oh
[07:16] <poolie> what was the toy?
[07:16] <vila> icore7-965/12GB/60GBSSD/1TBHDD :-)
[07:17] <poolie> a desktop machine?
[07:17] <vila> That's the Dr Jekyll of the MacBook Air Mr Hide :)
[07:17] <vila> yup
[07:17] <poolie> ah
[07:17] <poolie> i had some hardware trouble the other day
[07:17] <poolie> one of my hdds stopped working
[07:17] <poolie> it might have been too hot
[07:18] <poolie> in fact _i_ am too hot because my apartment is poorly designed and the airconditioner is broken atm
[07:18] <vila> I'm still searching for the best way to show hardware sensors with intrepid...
[07:18]  * fullermd is still flabbergasted at how Intel totally failed to interest him in an i7...
[07:18] <poolie> it's very inconsistent between different hardware i think
[07:19] <vila> I stop yesterday evening under the impression that my chipset was a bit too new for lm-sensors
[07:19] <poolie> mbmon works ok for me on a much older 965 board
[07:20] <vila> I'll look into that, I think I got the chipset (IHC10 ?) recognized with a more recent version of sensors-detect, but I'm not sure I don't need some other pieces...
[07:22] <fullermd> 's too bad, 'cuz it sure looks like a secksay chip.  But I guess I'm still an AMD guy 'till their next refresh at least   :|
[07:22] <vila> fullermd: very sexy indeed, but pricey...
[07:23] <fullermd> Yeah.  Doubly so with the DDR-3 memory, too.  That's off-putting.
[07:23] <vila> the fun thing is launching status monitor and try to understand what is going on with *8* curves instead of 2 :-)
[07:38] <jeddy3> morning
[07:41] <jeddy3> at the office we use subversion in the way that we build a complete tree of our repository but only check out the parts we actually need and leave big parts of the directory tree empty, is this possible with bzr?
[07:42] <jeddy3> (we have a huge repository with different products, 10 branches and 30k-something revisions) and with this scenario you don't have to fetch the whole repository, but you can still update/commit multiple branches at the same time
[08:04] <jeddy3> in other words a --depth for bzr
[08:06] <jeddy3> ...which at a closer look doesn't seem to exist...nevermind
[08:08] <poolie> jeddy3: ian's working a bit on it; our name for it is 'filtered views'
[08:08] <poolie> i don't know if it's ready for testing yet though
[08:10] <jeddy3> poolie: ah, sounds nice!
[08:11] <jeddy3> and actually filtered views is a really good analogy for it
[08:12] <ollie> need a quick bit of advise about a bzr repo
[08:13] <ollie> I have my main developers and they work in /home/bazaar/repository/web/project/trunk/sub-project. I then have an outside developer who I want to provide a branch for. I created a branch within my repo but it ended up creating the files in the repo which I wasn't expecting
[08:13] <ollie> I want the developer to be able to do a checkout from this branch. What is the best way to achieve this?
[08:14] <poolie> ollie: so it sounds like you have a branch that contains a working tree
[08:14] <poolie> you can still make a checkout of it somewhere else
[08:14] <ollie> yes that is exactly what I have
[08:15] <ollie> ok, and then will it be easy to merge the two?
[08:15] <poolie> the wt in the central repository will get out of date (unless/until you run 'update')
[08:15] <poolie> if you don't want the tree there, just run 'bzr remove-tree'
[08:15] <poolie> hth
[08:15] <poolie> good night all
[08:15] <ollie> ah didn't know you could do that
[08:18] <speakman> http://ppa.launchpad.net/bzr/ppa/ubuntu still breaks bzr upgrade due to uncompatible bzrtools: http://pastebin.com/me990cae
[08:20]  * AmanicA wonders how long bundlebuggy will be on holiday  (it doesn't pick up merge requests for some reason. I do hope I didn't break it again. sorry)
[09:57]  * Lo-lan-do → FOSDEM
[10:47] <jeddy3> hmmm
[10:48] <jeddy3> bzr pull on a subversion tree takes extremly long time... :|
[10:51] <jeddy3> it should be up to date or maybe almost up to date
[10:52] <spiv> jeddy3: file a bug
[10:52] <spiv> jeddy3: I think it may be because it's wasting a lot of time in find_tags
[10:53] <spiv> jeddy3: as a hack, if you put a "return {}" at the top of find_tags() in bzr-svn's repository.py it might workaround it...
[10:54] <jeddy3> spiv: that would not return any tags, what is the effect of that? :)
[10:55] <jeddy3> spiv: i mean does that have any consequences?
[10:56] <jeddy3> spiv: if not, why does even find_tags exist? ;)
[11:00] <spiv> jeddy3: right, that's the downside.
[11:01] <spiv> jeddy3: but if you don't care much about tags, then it might be an okay tradeoff :)
[11:09] <jeddy3> :D
[11:09] <jeddy3> spiv: thank you
[11:46] <BjornW> I want to perform a partial export. As in exporting only 1 directory or file. This doesn't seem possible with bzr or am I missing something?
[11:58] <BjornW> Nobody got any hints or tips to perform a partial export?
[11:59] <beuno> BjornW, BjornW what version of bzr are you using
[11:59] <beuno> you can do:  bzr export file.tar.gz my_dir
[12:00] <BjornW> beuno: 1.3.1 (I use Ubuntu 8.04 LTS)
[12:00] <beuno> BjornW, it probably wasn't available then
[12:00] <beuno> you could use the bzr PPA
[12:00] <beuno> to get the latest version
[12:00] <beuno> https://launchpad.net/~bzr/+archive
[12:00] <BjornW> beuno: ok, is it production stable?
[12:01] <beuno> BjornW, yes, more than 1.3.1  :)
[12:02] <BjornW> beuno: haha ok, so I can do this: bzr export some_dir_in_my_repos /releases/some_new_release
[12:02] <beuno> BjornW, the other way around, but yes
[12:02] <beuno> 'bzr help export' will tell you the gory details
[12:02] <BjornW> beuno: cool, that's what I need. I'm gonna upgrade bzr now. Thanks for the info!
[12:03] <beuno> BjornW, you're welcome
[12:22] <BjornW> beuno: just tried it and you just saved me a lot of annoying work. Thanks!
[12:25] <beuno> BjornW, happy to help. You should see quite a few improvements with newer versions of bzr
[12:26] <beuno> performance especially in the next few months, if you keep updated through the PPA
[12:44] <BjornW> beuno: Cool, actually I'm thinking of working some on bzr as well. I'd to add a --force for exports to override previous exports. I've been missing this from svn. Any hints on the best way to start doing this?
[12:47] <bialix> BjornW: may be it's better to start reading builtins.pt cmd_export
[12:47] <bialix> builtins.py
[12:47] <bialix> actual export code lives at bzrlib/export/ dir
[12:54] <BjornW> bialix: thanks, I'll have a look tonight at it.
[12:56] <bialix> BjornW: also there is bzrlib/tests/blackbox/test_export.py
[12:57] <awilkins> jelmer: ?
[13:38] <edgimar> How do I change my working directory so that all the files are from an earlier revision?
[13:40] <awilkins> bzr revert -r <my earlier revision>
[13:41] <edgimar> awilkins: ok, so if I don't specify a filename, it just does the entire working directory?
[13:41] <awilkins> edgimar: Yes
[13:41] <edgimar> ok great.  Thanks.
[13:41] <awilkins> Bug hunting?
[13:43] <edgimar> indeed...  Is there a 'bisect' like extension for bzr which automates things partly?
[13:43] <awilkins> edgimar: Yup, that's what I was segueing into
[13:44] <edgimar> Is it in fact 'bisect'?  Maybe I need to install it separately?
[13:44] <awilkins> Yes, it's a plugin
[13:44] <edgimar> And where do I get it / how do I install it?
[13:45] <awilkins> bzr co http://bzr.licquia.org/bzr-bisect/ ~/.bazaar/plugins/bisect   # that ought to cover it
[13:45] <awilkins> (on *nix, anyway)
[13:45] <edgimar> I guess there isn't an Ubuntu/Debian package for it?
[13:46] <awilkins> There's no PPA for it on launchpad
[13:47] <edgimar> bzr: ERROR: Not a branch: "http://bzr.licquia.org/bzr-bisect/.bzr/branch/"
[13:48] <awilkins> Dang
[13:48] <awilkins> Aha
[13:48] <awilkins> bzr co http://bzr.licquia.org/bzr-bisect/trunk ~/.bazaar/plugins/bisect   # that ought to cover it
[13:48] <edgimar> ok thanks.
[13:48] <mtaylor> lifeless: awake?
[13:50] <awilkins> edgimar: You should also be able to branch it from it's launchpad mirror at   lp:bzr-bisect
[13:50] <awilkins> That seems to be where my install is from
[13:50] <edgimar> ok -- the previous co cmd worked though.
[13:51] <awilkins> Yes, they're both identical mirrors (just checked). It hasn't changed in a long while, it must use very stable parts of the API
[13:57] <edgimar> awilkins: so I take it that the way bisect works is that I first need to revert to a very old revision, and then do 'bisect start' and other bisect commands.?
[13:58] <mtaylor> edgimar: nope
[13:58] <awilkins> edgimar: Start at the tip, and bisect will handle the searching
[13:59] <mtaylor> yup
[13:59] <awilkins> You are looking for the revision where a particular property of your tree emerges
[13:59] <awilkins> In this case, a bug
[13:59] <mtaylor> and it's tha bomb, if I'm allowed to use that word
[13:59] <awilkins> bzr bisect start
[13:59] <awilkins> Then for each tree it presents you with, you test for the property. If it's there, bzr bisect yes
[13:59] <awilkins> if not bzr bisect no
[13:59] <edgimar> it strikes me as funny that you must 'revert' to the tip revision...
[14:00] <awilkins> You may also give it hints if you wish to speed it up (ie - you know a particular revision was "good")
[14:00] <mtaylor> edgimar: why would you need to revert?
[14:00] <awilkins> mtaylor: He reverted to an older revision when searching manually
[14:00] <mtaylor> ah, gotcha
[14:01] <mtaylor> manual search bad
[14:01] <mtaylor> :)
[14:04] <jeddy3> hmm, is bzr pull on a bzr-svn repo supposed to take 1h20m even when there are NO NEW REVISIONS? :P
[14:04] <awilkins> jeddy3: You upgraded to bzr-svn 0.5 recently?
[14:05] <jeddy3> awilkins: version 0.49
[14:05] <jeddy3> sorry 0.4.9
[14:07] <nevans> oi vey, bzr-svn 0.5 is *slow* for me (only when talking to svn).  I pushed to svn 26 minutes ago.  svn recorded the commit 25 minutes ago.  "bzr push" finally returned just now.
[14:09] <nevans> of course, the last several releases of bzr-svn 0.4 didn't work for me at *all*, and bzr (not talking to svn) has sped up dramatically since then, so I suppose I shouldn't complain.  :)
[14:10] <jeddy3> heh :)
[14:11] <nevans> also, I'm working with a ~53000 revision svn-repo, and this branch has 16746 revisions, so my bzr-svn performance may not be typical.
[14:12] <jeddy3> hehe, 34000 revisions here, but still
[14:12] <jeddy3> (repository-wise)
[14:13] <nevans> I'm thinking that I need to finally hunker down and (re-)learn python, so I can take a look and profile it myself, and stop just being a complainer :)
[14:33] <edgimar> awilkins: With bisect, I start with the tip revision, and type 'bzr bisect start' -- then it doesn't present me with a new tree, but I must first do bzr bisect yes/no.  Is that right?
[14:34] <awilkins> edgimar: Yes
[14:34] <awilkins> Start with "yes" if your tree has the property,
[14:34] <awilkins> THen "no" when it doesn't
[14:34] <edgimar> Also, does 'bisect yes' mean 'yes, there is a bug observed', or 'yes, this works correctly'?
[14:34] <awilkins> You could automate it, if you have a test for the bug that isn't in the tree itself
[14:35] <awilkins> "yes" means "this tree contains the property I'm looking for"
[14:35] <awilkins> Which is the bug in this case
[14:35] <edgimar> But it doesn't matter if I decide yes=bug, or yes=no bug?
[14:36] <edgimar> (as long as I'm consistent)
[14:36] <awilkins> I think it assumes that it's looking for something that once didn't exist, but now does. So yes should mean "bug"
[14:37] <edgimar> Ok, that clarifies things...
[14:38] <edgimar> Ok, now things are looking more like I'd expect.. :)
[14:40] <edgimar> It occurs to me, however, that bisect can't really handle 'local optima', where the bug may have been introduced, and then is removed, and later introduced again.  ??
[14:40] <awilkins> No, I don't think it could handle that
[14:40] <jam> nevans: if you do "bzr XXXX --lsprof-file foo.txt" it will run a profile for you
[14:42] <awilkins> edgimar: You could work around that as long as you knew at least one "good" revision in the period between "bug" and "bug : the return"
[14:42] <bialix> рш офь
[14:42] <bialix> hi jam
[15:28] <microft> need some quick help: how do I merge new changes from a launchpad project to my launchpad branch?
[15:29] <jam> hi bialix
[15:30] <jam> microft: "bzr co lp:~myuser/project/branch; cd branch; bzr merge lp:~other/project/branch" ?
[15:30] <jam> bzr commit -m "new changes from $other"
[15:33] <microft> jam: thanks
[15:42] <bialix> hi all
[15:43] <bialix> dear bzr hackers, I need a little help about writing test for my plugin, I need to emulate interaction with remote server
[15:46] <Necoro> does there exist a possibility (e.g. bzr command) to check whether a directory is a bzr branch? - and which returns false in case it is an svn repo ;)
[15:46] <Necoro> I used "bzr revno" up till now ... but if bzr-svn is installed, this will also succeee
[15:46] <Necoro> but take way to long
[15:47] <jdong> hey guys; what's the current status of bzr/bzrlib in IronPython? I have a project on the CLR I'd like to interface with bzr
[15:47] <jdong> and am currently debating between an IronPython bridge or just some CLI hackery.
[15:51] <Tak> jdong: ironpython bridge was a no-go when I tried a few months ago
[15:51] <vila> bialix: what kind of remote server ?
[15:51] <bialix> jdong: try to look at ironclad
[15:51] <bialix> vila: hi
[15:51] <vila> yo :-)
[15:51] <bialix> any kind of server is good
[15:51] <bialix> yo!
[15:52] <bialix> I think about sftp
[15:52] <Tak> hmm, can I unmerge a merge I did a few commits ago?
[15:52] <bialix> because paramiko is strong dependency
[15:52] <bialix> but http is also good
[15:52] <vila> then look at bzrlib.test.test_sftp I think there is a class (or 3) about that
[15:53] <vila> for http look at bzrlib.test.test_http, plenty of servers there :-) Even bzrlib.test.http_server
[15:53] <bialix> I don't see test_sft.py
[15:53] <vila> bialix: sorry, that's bzrlib.test.test_sftp_transport
[15:54] <bialix> there is test_sftp_transport.py
[15:54] <bialix> aha
[15:54] <vila> bialix: sorry, that was from memory, I checked after typing instead of the opposite :-)
[15:55] <Tak> nevermind, it's working the way I'd think it would, I just typoed the first attempt
[15:56] <bialix> vila: basically I need to have writable transport to test init/push for scmproj
[15:56] <bialix> and get/pull too
[15:56] <vila> so that will be sftp
[15:57] <bialix> TestCaseWithSFTPServer -- it's what I need?
[15:57] <vila> you may have a look at bzrlib.tests.commands too, where the need for a writable transport guided the design
[15:58] <bialix> tests/commands/test_init.py does not shed many lights here :-)
[15:58] <vila> bialix: yes, and bzrlib.tests.commands really use bzrlib.test.transport_util to define the right transport and server
[15:58] <vila> bialix: looks like you're too fast for me today, wait *some* seconds after each of my response may help :)
[15:59] <bialix> vila: I think my question is: how can I inspect the files supposed to be on the server, or used by server?
[15:59] <vila> ha
[15:59] <bialix> ok, I'm waiting
[15:59] <vila> Here is the dirty secret: we cheat :-)
[16:00] <bialix> what?
[16:00] <bialix> how can you dare?!?!
[16:00] <bialix> :-)
[16:00] <vila> We access the files locally knowing there are the same ones that the test server is using
[16:01] <vila> for 99% of the cases that makes no difference, the remaining 1% is when *I* try to test with real ftp servers :-)
[16:01] <bialix> vila: but how I can say to the server: you should serve files from *this* directory?
[16:01] <vila> If you use the bzr test framework it's mostly transparent
[16:01] <bialix> I'm working on plugin for bzr
[16:02] <bialix> so yes, I'm trying to use existing test framework
[16:02] <vila> because the tests run in a TMP directory and that's the current directory as far as the test writer (you) is concerned
[16:02] <bialix> may I explain you more specific example?
[16:02] <vila> sure
[16:02] <bialix> it's about scmproj plugin
[16:03] <bialix> I want to test init of new scmproj control dir
[16:03] <bialix> it's almost equal to regular bzr branch
[16:03] <bialix> so I'll doing local init, first commit, then push to testing server
[16:03] <bialix> then I want to check what's on the server
[16:04] <bialix> this is my test case
[16:04] <bialix> is it correct?
[16:04] <bialix> 2 questions: what should be URL to the testing server?
[16:05] <vila> so let's say you push at self.get_url('branch'), you can then test f = open('branch/my_file')
[16:05] <bialix> and second: the files I'm push will be in current testing dir? it's fine
[16:05] <vila> yup
[16:05] <bialix> self.get_url?
[16:05] <vila> You must remember to use different paths to avoid
[16:05] <vila> argh
[16:06] <vila> get_url should be defined for any TestCaseWithTransport, let me check :)
[16:06] <bialix> get_url seems to be defined in the TestCaseWithMemoryTransport
[16:07] <bialix> which is father of all other tests
[16:07] <vila> yup, that's right, and inherited from there
[16:07] <bialix> that's right?
[16:07] <vila> hehe, faster than you there ! :)
[16:07] <bialix> rats
[16:07] <bialix> you win
[16:08] <bialix> why for get_server() methods are used/supposed?
[16:08] <vila> you can also use self.get_transport(relpath) to get a transport pointing at the remote server
[16:09] <bialix> yes, maybe I'll need this
[16:09] <bialix> so, if I'm using TestCaseWithSftpServer -- I can suppose the server is auto-started?
[16:09] <vila> you need get_server() mostly when you want to test the server itself
[16:09] <vila> yes, the server is handled for you
[16:10] <bialix> no, I need test only the result of interaction with the server
[16:10] <bialix> not the server itself
[16:10] <bialix> so, I can create branch in current test dir and then work with it via server. it's fine
[16:11] <bialix> and easy
[16:11] <bialix> vila: thank you thank you thank you
[16:11] <vila> bialix: be my guest and happy to help(TM) :)
[16:11] <bialix> this is the quote?
[16:12] <vila> happy to help is jam's quote :)
[16:12] <bialix> merci beaucau (sorry if I mispelled)
[16:12] <vila> very close: merci beaucoup
[16:12] <bialix> :-[
[16:13] <awilkins> jdong: Tried IronPython a week or 2 ago
[16:13] <bialix> my english now is better than my francais
[16:13] <jam> vila: I think it is actually "always happy to help"  :)
[16:13] <vila> jam: :)
[16:13] <awilkins> jdong: It would need significant work
[16:13] <bialix> jam: you rocks
[16:13] <bialix> and vila rocks
[16:13] <bialix> thank you guys
[16:16] <microft> ~~~~~~
[16:17] <jdong> alright looks like I have to go with a different approach then :)
[16:18] <jdong> OT then, anyone know of alternative 3-way mergers for directories that don't rely on a VCS? :)
[16:18] <jdong> I don't need a revision history or anything, just a decent 3-way sync
[16:18] <awilkins> jdong: The way that bzr-svn makes a little XMLRPC server process would be a reasonable integration method
[16:19] <jdong> yeah I suppose I can use a Python script to expose some sort of IPC protocol for the Mono side to talk to
[16:20] <jdong> or... for this stupid little hackish program... just shell out to bzr's binary
[16:21] <jdong> btw, I would just like to say bzr's Windows compatibility rocks; the best of the DVCSes I've tried.
[16:25] <awilkins> I agree with you ; every time I try Hg or git to see if they got any better I run into something that either stops it working or makes me go "gaaaaaaaah!"
[16:25] <awilkins> I'm sure that git in particular is awesomely powerful - on it's home turf
[16:30] <Tak> jdong: have you looked at https://launchpad.net/monodevelop-bzr ‽
[16:41] <jdong> awilkins: yeah git is great on a POSIX platform; though I beg to differ with its UI
[16:42] <jdong> Tak: very cool, I'll look at it.
[16:44] <jam> jdong: you need a 3-way merger on Windows?
[16:45] <jam> there is stuff like "meld" but I believe that is linux-only (though there is a lot that is portable)
[16:45] <bialix> jelmer is like superman. he's everywhere
[16:45] <jam> I suppose it also depends on what your "base" is, and how you are tracking it
[16:45] <vila> bialix: naah, the truth is that there are twins ( 3 of them in fact :)
[16:46] <bialix> I suspect this!@
[16:48] <fullermd> The magic of cloning...
[16:48] <jdong> jam: basically I have, on an arbitrary number of machines, a repo of text files. They operate partially disconnected and I'd like to be able to propagate the latest changes from any repo to any other.
[16:48] <jdong> currently I am thinking of representing them as bzr branches and merge operations
[16:48] <rockstar> If I create a shared repo with --1.9, will all the branches in that repo also be in format 1.9?
[16:48] <jam> rockstar: not without individually upgrading them
[16:49] <jam> though the upgrade in that dir should be trivially fast
[16:49] <rockstar> jam, what if it's from scratch?
[16:49] <rockstar> So I just create a new repo and a new branch in that repo?  Will that branch be format 1.9 ?
[16:50] <jam> rockstar: "bzr init-repo --1.9 repo; cd repo bzr init my-branch" the branch will use the 1.9 storage, but will technically be a 'pack-0.92' branch
[16:51] <jam> with the only difference being a flag that indicates it supports stacking
[16:51] <derekS> hey guys, can i push to a local repository, then push that up to another repo?
[16:51] <jam> though if you do "cd my-branch; bzr push lp:xxx" it will use the fact that the repo can stack, and auto-upgrade the branch format, IIRC
[16:51] <jam> derekS: generally, yes
[16:51] <jam> rockstar: in other words, "bzr init" does not use a containing repository to define the branch format.
[16:52] <rockstar> jam, so I'll have to bzr init --1.9 the branch as well.  Okay.
[16:52] <derekS> jam: generally?
[16:53] <jam> derekS: I *think* I know what you are trying to do, and it should just work.
[16:56] <derekS> ok :)
[16:56] <derekS> thanks
[17:11] <Peng_> If you don't care about stacking, you don't need to use 1.9 format branches.
[17:11] <Peng_> As long as you don't mind "bzr info" saying "format: unnamed".
[17:24] <abentley> Peng_: I think you mean 1.6.  1.9 has other advantages.
[17:28] <jam> abentley: the 'branch' format for 1.6 and 1.9 are identical.
[17:28] <KhaZ> Weird.  TortoiseBazaar can be forced to do a checkout to a USB drive, but it won't give me any options to manipulate said items on the usb drive. :/
[17:29] <jam> so doing "cd repo; bzr upgrade --1.9; cd branch; bzr upgrade --1.6" will have "bzr info" tell you 1.9
[17:29] <abentley> jam: Yes, I see that in this specific case, it's true.
[17:29] <jam> yay for summary items
[17:29] <jam> that don't quite tell the truth
[17:44] <CaMason> hi guys. I've been committing locally, and now want to send those changes to the central repo. What's the correct process?
[17:46] <KhaZ> CaMason: bzr push [central repo url]
[17:47] <CaMason> I ran bzr update, but I seem to have buggered up my local copy (the one I've been using commit --local with)
[17:51] <CaMason> bzr log is showing the most recent entry as 172, yet doing 'bzr check' shows 178 revisions
[17:52] <CaMason> so I try bzr revert -r 178, and it says the revision does not exist
[17:53] <CaMason> Anyone have any ideas? I've been working on this all-day and really need to get that 178 revision back
[17:57] <EnCuKou> CaMason: Maybe `bzr heads` will show you the revision-id?
[17:59] <bialix> monsieur vila, may I ask one more time about testing server?
[17:59] <vila> sure, sir Alexander
[17:59] <CaMason> EnCuKou: 'bzr heads --all' shows one of my last commit messages
[17:59] <CaMason> then it says (dead) after it
[18:00] <bialix> is there any benefit to use sftp server for testing over bzr:// writable one?
[18:00] <awilkins> CaMason: So you have 178 revisions - they just aren't all part of your current branch
[18:00] <bialix> CaMason: because it's dead actually
[18:00] <CaMason> http://srtsolutions.com/blogs/chrismarinos/archive/2008/10/24/don-t-loose-your-head-with-bazaar.aspx
[18:00] <CaMason> that's exactly what's just happened to me
[18:01] <bialix> vila: I remember in the past I have many failures in bzr selftest on win32 related to sftp server
[18:01] <vila> bialix: I'm not sure there is a test bzr server... at least I have no experience with it, spiv would know better, but I think only some tests use a smart test server
[18:01] <bialix> vila: ahh
[18:02] <bialix> so sftp server is most common solution?
[18:03] <vila> for a writable server, yes, at least last time I needed one, I used sftp and fall back to ftp if paramiko wasn't available
[18:04] <bialix> yes, but ftp one in turn require Medusa, IIRC
[18:04] <bialix> ok
[18:04] <CaMason> this is a pretty serious problem if a 'bzr update' is killing off my local commits
[18:05] <bialix> bzr update?
[18:05] <CaMason> yeah, I just did 'bzr update' and it killed all of my local commits from today
[18:05] <CaMason> took me back to revision 172 (from 178) and I just had to use bzr heads --all
[18:06] <bialix> I think they should be converted to pending merges
[18:06] <vila> yes, medusa is required, until I find another solution (which is needed for 2.6, but there is no urgency there so don't hold your breath...)
[18:06] <CaMason> pending merges?
[18:06] <bialix> CaMason: may be you accidentally run bzr revert
[18:06] <CaMason> bialix: I can promise you I didn't
[18:06] <CaMason> I still have the original shell window up
[18:07] <vila> bialix: but if you have too much troubles with paramiko and medusa, I have some pointers if you want to replace medusa :-0
[18:07] <CaMason> I do know that bazaar crashed during the process, something to do with x-server not being available (as I'm in via SSH)
[18:07] <bialix> vila: no, paramiko is always available for me at win32 :-)
[18:07] <bialix> vila: it's hard dependency here
[18:07] <bialix> CaMason: ah, um
[18:08] <bialix> CaMason: but your data is still in the repo
[18:08] <CaMason> bialix: sure, but I have no idea how to get my previous commits back
[18:08] <bialix> bzr pull . --overwrite -r revid:dead-revid
[18:09] <bialix> that's all
[18:09] <CaMason> atm, I've used "b revert -r revid:..." but that only restored files
[18:09] <bialix> you need pull
[18:09] <CaMason> what is pull going to do?
[18:09] <bialix> the article you've linked is incomplete
[18:09] <bialix> it's hard question
[18:09] <CaMason> all of these changes are --local commits on a laptop
[18:10] <bialix> that's fine
[18:10] <bialix> so you're locally
[18:10] <CaMason> so I had an updated checkout at revision 172... I've been committing using --local today up to revision 178. I used "bzr revert -r revid:..." and my fils are back
[18:11] <CaMason> yet my log still shows 172, and all of these files I just reverted are showing as modified/new etc. Doing a commit will seemingly skip over my previous commits
[18:11] <CaMason> "bzr pull . --overwrite" looks scarily like it's going to overwrite my local commits from the central repo
[18:12] <bialix> CaMason: please, try the pull command I gave you, but instead of dead-revid put your real revid of dead head
[18:12] <bialix> you can branch if you like
[18:12] <bialix> bzr branch broken-branch new-branch -rrevid:dead-revid
[18:12] <CaMason> ok thanks I'll do that first
[18:12] <bialix> it's also restore your hstory
[18:14] <CaMason> ok I did that branch and my log now shows up to 176 which is about correct
[18:14] <CaMason> I have no working copy though
[18:14] <bialix> perhaps you're inside treeless repo
[18:14] <bialix> bzr co .
[18:15] <CaMason> ok, this is working, thanks. So, now I should bind this to my central repo?
[18:15] <bialix> if you like
[18:15]  * CaMason feels less panicky now
[18:15] <bialix> relax, take it easy
[18:15] <bialix> :-)
[18:16] <CaMason> right, it's bound. Now, should I do a bzr update?
[18:16] <bialix> to reproduce the bug? yes, of course
[18:17] <CaMason> I mean, to get these files pushed back to the central repo
[18:17] <bialix> if you want push them you need push command
[18:18] <bialix> I'm late in discussion of your problem, can you describe your setup?
[18:18] <CaMason> sure, 2 seconds
[18:18] <CaMason> I have a central repo on my machine in the office. I usually have a checkout on my laptop to work whilst I'm away
[18:19] <CaMason> I got home today, and did a bzr commit to try and place my changes on the central repo. It said I needed to update first. I did that, and it deleted all of my changes and put me back to revision 172 (the revision before I left the office, and the revision on the central repo)
[18:20] <bialix> at this point you should have your local commits as pending merges
[18:20] <CaMason> so what should be the normal process for performing this local -> central merge?
[18:20] <bialix> well, it's depend
[18:21] <bialix> bzr update put your history in sync with the server, and not vice versa
[18:22] <bialix> kfogel: are you here?
[18:22] <CaMason> my laptop did crash earlier, so I'm hoping that was the reason for this mess-up
[18:22] <bialix> I don't see the liason
[18:23] <CaMason> from what I recall.. I would normally do 'bzr update' which would pull in the newest changes from the central repo, and tell me if there are any conflicts
[18:23] <bialix> can you execute `bzr update` now
[18:23] <bialix> ?
[18:23] <CaMason> bialix: yes and it's all working fine
[18:23] <CaMason> I'll try it on the bugged machine too
[18:23] <bialix> run `bzr st`
[18:24] <CaMason> it says a few files are 'unkown' and they all end with .moved
[18:24] <bialix> it's in the branch when the history changed from 176 to 172?
[18:24] <CaMason> yes. I'd since ran bzr update and that's updated the log to show 172 to 176
[18:24] <CaMason> and the files are now the correct version
[18:25] <bialix> I'm lost in your hardware
[18:26] <bialix> .moved files are because you've added them in different branches with the same name
[18:27] <CaMason> PC: contains repository. LAPTOP: Contains checkout... normally I do `bzr commit --local` on the laptop whilst I'm not online. When I return, I do `bzr update`, sort out any conflicts, then `bzr commit`. However, this time, `bzr update` on the laptop deleted all of my changes, so that my working copy looked like -r 172
[18:27] <bialix> ah
[18:27] <bialix> it smells like the bug
[18:28] <CaMason> and I had no reference to -r 173,174,175,176, except when I ran `bzr heads --all` and 176 showed up as (dead)
[18:28] <bialix> this is right
[18:28] <CaMason> is this a known issue?
[18:28] <bialix> the history is linear
[18:28] <CaMason> ls
[18:28] <CaMason> (oops)
[18:29] <bialix> about update? not converting your local commits to pending merges? I don't know. never seen this before.
[18:29] <bialix> may be
[18:29] <luke-jr> https://bugs.launchpad.net/bzr/+bug/326278
[18:30] <luke-jr> err, entirely unrelated to Ubuntu..
[18:30] <CaMason> bialix: like I say, my laptop crashed earlier and fsck showed up numerous errorrs
[18:31] <CaMason> no idea if it's related, but I'll see if it ever crops up again
[18:31] <CaMason> Thanks for helping me get my commits back though :D
[18:34] <CaMason> on another note.. if I SSH into a machine that has bazaar with bzr-gtk installed, commits will crash, complaining of something to do with X server being unavailable
[18:36] <CardinalFang> CaMason, using what command?
[18:49] <amanica_> CaMason: btw if you are using checkouts with local commits, allways make sure you don't have local changes and local commits
[18:49] <awilkins> CaMason: Are you passing the -m argument or not?
[18:49] <amanica_> because it will make your commits pending
[18:50] <amanica_> and then you cant tell what changed outside of the pending commits
[18:51] <amanica_> i.e your pending commit changes and your workingtree changes will all be committed with the next commit
[18:51] <amanica_> maybe this isn't an issue for you
[18:52] <amanica_> this happen when you do an update with local commits and changes in the working tree at the same time.
[18:53] <amanica_> (sorry I forgot to mention the update part before0
[18:59] <amanica_> (there is some bugs related to what I described eg. Bug #113809 , I think I should log what I described here seperately)
[19:07] <CaMason> amanica_: it's possible that I had changes as well as local commits when this issue happened
[19:07] <CaMason> infact, probably likely
[19:08] <nDuff> CaMason, is the DISPLAY variable set at all when bzr-gtk is interfering with your commits on a remote host? Does unsetting it help?
[19:08] <amanica_> CaMason: I don't think that would cause all your pending commits to dissappear, unless you did a revert
[19:08] <CaMason> nDuff: sorry for being a newbie... where do I check that?
[19:09] <nDuff> CaMason, run the following: echo $DISPLAY
[19:09] <CaMason> blank output
[19:10] <nDuff> CaMason, hmm -- I'd hope that bzr-gtk would be smart enough to not try at all to use X with an empty DISPLAY; that said, I don't have a copy checked out to look at the source to myself.
[19:11] <CaMason> nDuff: that would be the expected behaviour, I'm sure
[19:11] <CaMason> whenever I do a commit locally on the laptop, there's a notification (on ubuntu). I do this when connected to the laptop via SSH, and it shouldn't try to bother with X at all. But seemingly, it does
[19:12] <EnCuKou> If you're checking $VISUAL, also check $EDITOR and $BZR_EDITOR
[19:12] <awilkins> That was why I was asking whether he was passing -m
[19:12] <CaMason> as in 'commit -m "my commit message" ?
[19:12] <EnCuKou> Sorry, wrong window
[19:13] <awilkins> CaMason: Yes ; I reckon you might have gvim or the like in $EDITOR
[19:13] <CaMason> nothing in $EDITOR or $BZR_EDITOR
[19:13] <CaMason> it actually loads up pico
[19:13] <awilkins> Ah well, that's that theory out of thw indow
[19:13] <CaMason> brb washing up!
[19:17] <nDuff> CaMason, I just took a quick look at the source to bzr-gtk, and it looks like it's trying to check for that case (and should exit with an error "No DISPLAY. Unable to run GTK+ application" if trying to run a GTK-involved subcommand in that case). What version do you have? Could you pastebin the exception?
[19:31] <CaMason> nDuff: I'll make a test repo and tr it
[19:33] <CaMason> http://pastebin.com/d30394fa1
[19:34] <CaMason> nDuff:?^^
[19:34] <nDuff> ...is that actually the gtk plugin, or the dbus plugin?
[19:35] <CaMason> no idea... I literally inited a repo, added a testfile, commit.. and get that output :)
[19:36] <CaMason> This is on a relatively fresh Ubuntu 8.10 install, with bazaar installed via synaptic
[19:36] <nDuff> CaMason, could you check whether uninstalling or disabling only the dbus plugin makes the issue go away? If so, that provides some targeting for fixes/bug reports/such.
[19:37] <CaMason> nDuff: certainly, 2 mins
[19:37] <CaMason> so I should leave bzr-gtk installed?
[19:38] <nDuff> yup
[19:38] <CaMason> removing bzr-dbus also removed bzr-avahi
[19:39] <CaMason> had to run an update first. The commit succeeded without crashing
[19:40] <nDuff> CaMason, OK. Is there any output from the command "set | grep DBUS"?
[19:41] <CaMason> nDuff: nothing
[19:42] <nDuff> CaMason, if you reinstall bzr-dbus, and run the commit command as "dbus-launch bzr commit", does it still fail?
[19:43] <CaMason> interestingly, reinstalling bzr-dbus didn't prompt to install bzr-avahi
[19:43] <nDuff> CaMason, makes sense -- that indicates a one-way dependency from bzr-avahi on bzr-dbus.
[19:43] <CaMason> `dbus-launch bzr commit` no crash
[19:44] <CaMason> `bzr commit` = crash
[19:45] <KhaZ> bzr st yields a list of things that are renamed and conflicts, but if I do a 'bzr merge [path-to-item-that-is-renamed-and-or-conflicted]' it says 'nothing to do'.  How do I go about running a merge tool on these two items?
[19:46] <CardinalFang> KhaZ, "merge" copies from other trees.
[19:46] <CardinalFang> ...or something like them.
[19:49] <nDuff> CaMason, OK -- the bzr-dbus plugin should probably just short-circuit if the DBUS_SESSION_BUS_ADDRESS variable is unset; that should be a pretty easy patch to write or bug report to file.
[19:50] <CaMason> nDuff: that variable is present on the laptop, but not present when in via SSH
[19:51] <nDuff> CaMason, yup -- and that's exactly why you're having the problem when you're only connecting over SSH.
[19:52] <CaMason> excellent :D (ish)
[19:52] <CaMason> now, I'd file a bug report if I knew how
[19:52] <nDuff> CaMason, see the "report a bug" link at https://launchpad.net/bzr-dbus
[19:59] <CaMason> https://bugs.launchpad.net/bzr-dbus/+bug/326320
[19:59] <nDuff> CaMason, thanks; there's actually some relevant discussion going on over in #dbus right now, so I'll go paste that in.
[20:00] <CaMason> excellent. Glad I was able to help somewhat
[20:12] <ronny> LarstiQ: http://www.geeksugar.com/2471026
[20:29] <nekohayo> just committed and pushed my branch, and bazaar tells me I have conflicting tags
[20:29] <nekohayo> now what? I have no indication of what to do with that
[20:30] <bialix> bzr tags
[20:30] <bialix> bzr tags -d remote-branch
[20:31] <bialix> compare results and decide which tags are right
[20:31] <nekohayo> but.. the results are identical
[20:31] <bialix> nope
[20:32] <nekohayo> bialix: http://ecchi.ca:8000/1.png
[20:32] <nekohayo> unless I should swap "remote-branch" by "lp:specto"
[20:32] <bialix> try with --show-ids flag
[20:32] <nekohayo> aah, using lp:specto does show that it's the same tag on rev 107
[20:33] <bialix> yep
[20:33] <bialix> I guess you just find the bug
[20:33] <nekohayo> now the question is what's the next step once I decided that my local branch (tag on 108) is the right one?
[20:34] <bialix> remote-branch is not valid path in your tree>
[20:34] <bialix> ?
[20:34] <bialix> wait, the bug first please
[20:34] <nekohayo> I had to use lp:specto instead of remote-branch.
[20:34] <bialix> bzr should tell you that you provide wrong path
[20:35] <bialix> ok, back to tags
[20:35] <bialix> if your local tags is the right one, you need to push --overwrite
[20:39] <nekohayo> it worked, thanks! /me notes this somewhere
[20:40] <bialix> may be adding this to faq?
[20:41] <bialix> or blog about this ;-)
[20:45] <amanica__> conflicting tags scares some people, maybe this should be explained in a topic, and referenced in that message
[20:46] <bialix> I think the error message should be more clear itself
[20:46] <bialix> there is help topics on conflicts, but it say nothing about conflicting tags
[20:47] <bialix> it's a bug?
[20:49] <bialix> Bug #213184
[20:50] <bialix> it's marked as wishlist though
[20:52] <nekohayo> bialix: I actually saw that bug report before coming to this channel, because nobody had given an answer on that bug report
[20:54] <bialix> perhaps because that bug was reported by one of the core dev
[20:55] <bialix> I think it should be easy to fix. someone with good english skill just need to write some explanation
[20:56] <bialix> or maybe tags v2 should be implemented first
[20:57] <jbalint> any idea what this means? bzr: ERROR: A nested progress bar was not 'finished' correctly.
[20:58] <bialix> you're running bzr.dev?
[20:58] <jbalint> my own dev :)
[20:58] <bialix> I mean: are you running bzr from sources?
[20:58] <jbalint> i'm editing the sources
[20:59] <bialix> check your .bzr.log then
[20:59] <bialix> or try to merge latest changes from bzr.dev
[20:59] <jbalint> oh joy, not paying attention here. thanks :)
[20:59] <bialix> next question please
[21:00] <jbalint> i have nothing else atm
[21:00] <bialix> it's not to you personally
[21:00] <bialix> i've tried to joking
[21:00] <jbalint> you can check the questions on launchpad!
[21:01]  * bialix looks
[21:03] <bialix> there are only 3 questions
[21:06]  * bialix has answered one question, others 2 out of his competence
[21:08] <jbalint> nice
[21:09] <bialix> thx
[21:10] <CardinalFang> Hi all.  With bzrlib, I want to use "send" or "merge_directive" to create a mergable bundle, bug I don't want to have top be connected to the net.  Assuming that only the last commit is outstanding, how can I construct a bundle without touching the upstream target_branch?
[21:10] <amanica__> bialix: stop joking around in IRC, and get cracing on that layout changes!
[21:10] <amanica__> :)
[21:10] <bialix> I'm not enough sterkte tonight!
[21:10] <bialix> :-P
[21:11] <amanica__> LOL
[21:11] <amanica__> I see your on a roll here, enjoy.
[21:11] <nekohayo> hmm. I've seen a bunch of slides of talks about bazaar... but are there any videos of such talks, or videos of bazaar tutorials/demos, especially advanced features like cherry-picking ?
[21:11] <bialix> thank you, dude!
[21:12] <amanica__> CardinalFang: that bothered me once too, but I was told that trafic is quite minimal
[21:13] <bialix> CardinalFang: if you sure what revisions should go in the bundle you can use local branch as the base
[21:13] <amanica__> an exact local mirror is preferable
[21:13] <bialix> yes
[21:13] <amanica__> even if it is a little outdated
[21:14] <amanica__> (with exact I mean there should not me non-upstream commits present)
[21:14] <bialix> it's easy to reconstruct, actually
[21:15] <bialix> nekohayo: I guess there are plans to make some screencasts
[21:16] <bialix> actually there are 2 of them listed at http://bazaar-vcs.org/Documentation
[21:16] <bialix> see Screencast section
[21:16] <CardinalFang> bialix, I think I tried.  I'm writing a post-commit plugin, so I get the revid before and after.  I use os.curdir to say "right here".  My bundle header looks right (I think), but the bundle contents are empty -- aside from the preamble.  I .decode("base64") and then unbz2'sd it, and its not much -- nothing describing the change.
[21:17] <CardinalFang> I suspect it's a fencepost problem.  N-1 exclusive to N inclusive = 0
[21:17] <bialix> no, you need to create bundle against another branch, not against itself
[21:17] <bialix> fencepost?
[21:17] <CardinalFang> Off by one.
[21:17] <bialix> LOL
[21:17] <CardinalFang> Counting fenceposts instead of fence-spans.
[21:19] <bialix> Cardinal: you really should create somewhere on disk base branch
[21:19] <bialix> and use it as SUBMIT_BRANCH argument
[21:20] <bialix> hmm, you even can try t create base branch as --stacked to your dev branch
[21:20] <bialix> it should be very cheap then
[21:20] <CardinalFang> bialix, It's not me.  Assume my user branches from off the 'Net, and then gets on an airplane.  Hack hack hack.  Commit.  My post-commit hook runs.
[21:21] <bialix> it's *your* post-commit hook. Is not you're master on your hooks?
[21:21] <bialix> slightly change the hook? not?
[21:22] <CardinalFang> Yes, I'm writing it now.  I can design it.
[21:22] <bialix> so... os.curdir perhaps is bad idea to using for specifying base branch
[21:23] <CardinalFang> Yeah.  I can get the base other ways.  I'll get to that, once I see it works.
[21:24] <ignas> how do I see the connection debug info? my merge is timing out, but I don't know why...
[21:24]  * bialix shrugs his shoulders
[21:24] <bialix> what kind of connection?
[21:25] <bialix> bzr+ssh, http?
[21:25] <bialix> look at .bzr.log first
[21:25] <bialix> or into .bzr.log
[21:26] <ignas> bzr+ssh
[21:26] <CardinalFang> So -- to construct a bundle, I assumed I really don't need another branch somewhere, if I know what is outstanding and can include everything that would go into a bundle.
[21:26] <CardinalFang> ignas,  -Dhpss as parameter.
[21:26] <bialix> for gather debug stat use `bzr -Dhpss <YOUR COMMAND HERE>`
[21:27] <bialix> CardinalFang: abentley thinks different
[21:29] <bialix> in the good ol days when the grasp was green and te heaven was blue... bundles have worked that way
[21:29] <ignas> is there a way to use bzr repositories in launchpad through http?
[21:29] <bialix> yes
[21:29] <ignas> how do i do that?
[21:29] <bialix> go to branch page
[21:30] <bialix> look at url under source code button
[21:30] <bialix> remove files at the end
[21:30] <bialix> you'll have valid url
[21:30] <bialix> someone told even simpler way
[21:31] <bialix> but I don't remember
[21:31] <ignas> bialix: thanks
[21:31] <bialix> next question please
[21:31]  * bialix wants to win jackpot
[21:32] <fullermd> Why is there air?
[21:33] <bialix> oh, my hero is here!
[21:33]  * fullermd dons his cape and strikes a pose.
[21:33] <bialix> what about air actually?
[21:34] <fullermd> I dunno.   :-P
[21:36] <fullermd> "is there" ~~ "does exist"
[21:36] <fullermd> Well, only if I understand it.  I think my Russian vocabulary runs to 6 words or so...
[21:36]  * ignas can translate
[21:36] <bialix> I can try to answer using only your words
[21:38] <fullermd> I know da and nyet, so I guess that means you can answer in binary?  :p
[21:38] <bialix> fullermd: you cheating! http://en.wikipedia.org/wiki/Why_Is_There_Air%3F
[21:38] <bialix> da and nyet == yes and no. what is other
[21:39] <fullermd> Wait, I'm supposed to not cheat now, too?  If you'd just lay out all these rules ahead of time...
[21:40] <bialix> I think it should be good litycs
[21:40] <bialix> lyrics
[21:40] <bialix> what is other 4 words
[21:41] <fullermd> Oh, that was just a number I pulled off the top of my head.  I know the bits and pieces you can't help but pick up of languages.
[21:41] <fullermd> Which isn't enough to explain much of anything   :p
[21:41] <bialix> :-P
[21:42] <bialix> my answer is valid?
[21:42] <fullermd> I guess.  I think it's cheating though   :p
[21:43] <bialix> I'm learn from the best
[21:45] <ste_> hi all
[21:45] <bialix> fullermd: but I feel you're win
[21:45] <ste_> does anybody know how can I merge two different and unrelated branches into a single new branch ?
[21:46] <bialix> bzr merge -r0..-1
[21:46] <bialix> is not this answer should be in the faq?
[21:46] <CardinalFang> ste_, With different roots?  Er, that sounds tricky.
[21:46] <ste_> like, they were divided, but now I want to put them all under a brand new branch
[21:46] <ste_> but replaying the changes
[21:46] <CardinalFang> There were [once the same but are now] divided, .. ?
[21:46] <ste_> in svn I did with a svndump
[21:47] <ste_> well, sorry, I see it's tricky
[21:47] <ste_> i'll explain better
[21:47] <ste_> I started developing two programs, and I gave them a bzr init each
[21:47] <ste_> each branch so created went in its own direction, with many commits
[21:47] <ste_> now I realized that I want these two programs to be part of a single branch
[21:48] <ste_> quick and dirty solution: i bzr init a new empty dir
[21:48] <bialix> so?
[21:48] <ste_> copy the contents of the two old ones
[21:48] <bialix> bzr merge -r0..-1
[21:48] <ste_> and bzr add everything
[21:48]  * bialix can repeat this 3rd time
[21:48] <ste_> that's good, I want to be sure ;)
[21:49] <bialix> to be sure - what?
[21:49] <ste_> that you understood the problem I have, since I reread myself and even I didn't understand what i wanted ;)
[21:49] <bialix> it's much easier than questiona bout air
[21:50] <bialix> do you knwo the answer on question about air?
[21:50] <jam> bialix: because otherwise we'd all be dead
[21:50] <jam> or at least, life as we know it would not exist
[21:50] <bialix> it's too easy for fullermd
[21:50] <ste_> i know the answer to life, universe and everything, does that count ?
[21:50] <jam> though that answer may be a bit self serving
[21:51] <ste_> air is part of everthing
[21:51] <ste_> therefore
[21:51] <bialix> may be otherwise we don't breath at all?
[21:51] <jam> (if there was no air, we wouldn't know about it, because we would not exist, thus for us to be as we are, and aware of air existing, it must exist)
[21:51] <ste_> the answer to air is part of the answer to everything
[21:51] <bialix> wonderful!
[21:52] <jam> Either that or "just because"
[21:52] <ste_> mostly depends on what you mean by air...
[21:52] <bialix> ignas: just because == потому что,
[21:52] <bialix> ?
[21:52] <ste_> you can survive breathing a different atmosphere
[21:53] <ste_> but I would not define it "air" in the conventional sense
[21:53] <ste_> moreover, fishes don't need air in the conventional sense
[21:53] <ste_> so if we were intelligent fishes
[21:53] <ste_> you know what I mean
[21:54] <bialix> o!
[21:54] <ignas> bialix: think so
[21:54] <bialix> ignas: I guess very close
[21:54] <ste_> well, trying this merge
[21:55] <ste_> 10x for the help
[21:55] <ignas> bialix: yeah
[21:56] <bialix> fullermd: ?
[21:57] <bialix> jam: thanks! lol
[21:57] <fullermd> Hmm?
[21:58] <bialix> I did my call to a friend
[21:58] <bialix> see above ;-P
[21:59] <jam> ste_: if we were intelligent fishes, we still wouldn't be us as we are today
[21:59] <ste_> yep, and we wouldn't know
[21:59] <ste_> although, developing metallurgy in water environment would be tricky
[22:00] <fullermd> But think of the money we'd save on towels.
[22:00] <ste_> maybe near some vulcano
[22:00] <jam> ste_: perhaps. you just need a different heat source, since water could carry a lot more heat than air anyway
[22:00] <bialix> it's remind me the book of Harry Harrison about dynosaurus
[22:00] <fullermd> We'd certainly all be using water-cooled computers   :p
[22:00] <fullermd> (except a few extreme fanatics who'd try for uber-overclocks with air cooling)
[22:00] <ste_> :D
[22:01] <bialix> :-D
[22:02] <CardinalFang> jam, Do you know much about the bundle construction code?  I'm trying to create one containing only the last revision, without touching a target branch.  I hear it's impossible, but this sounds weird.
[22:02] <bialix> "winter in the eden", I hope I re-translate the title right
[22:02] <jam> CardinalFang: "without touching a target branch" ?
[22:02] <jam> Are you trying to do it in bzrlib? or with a bzr command ?
[22:03] <bialix> jam knows everything
[22:03] <jam> for some value of everything :)
[22:03] <bialix> and this too :-)
[22:03] <CardinalFang> bzrlib.  If I branch from somewhere on the net, and then climb on an airplane with no net access, can I commit and then construct a bundle containing that?
[22:03] <jam> well, the easiest way is:
[22:04] <jam> bzr branch -r -2 . ../old
[22:04] <CardinalFang> ....without branching up ...  ha.
[22:04] <jam> bzr send -o out ../old
[22:04] <jam> it is possible
[22:04] <jam> Just saying what is easiest
[22:04] <CardinalFang> Yep.  I'm writing a post-commit function.  So, I don't want to do that.  :)
[22:05] <bialix> "west of eden" series actually
[22:05] <jam> so you want to look at "bzrlib.merge_directive.MergeDirective2.from_objects()"
[22:05] <jam> It, unfortunately, takes a "target_branch" and not a "target_revision"
[22:06] <jam> However, I think you might be able to create  MergeDirective2() directly
[22:06] <jam> with the right values
[22:07] <jam> and use the appropriate value to "MergeDirective2._generate_bundle()"
[22:09]  * CardinalFang looks.
[22:10] <bialix> what exactly means: "I dunno"?
[22:13] <jam> CardinalFang: http://paste.ubuntu.com/114984/
[22:13] <jam> At least, that is my wholely untested but probably close-to-right attempt
[22:13] <jam> bialix: "I don't know"
[22:13] <bialix> how it pronounced?
[22:14] <jam> Espec. in America, the last part of the "don't" merges with the beginning of "know" and you get
[22:14] <jam> I dun-no
[22:14] <CardinalFang> jam, wow, you're great!    Third base.
[22:17] <CardinalFang> Heh.
[22:18] <ste_> third base like in xkcd?
[22:18] <CardinalFang> Yes.  Exactly like that.
[22:18] <ste_> passing the virginity maginot like ?
[22:18] <ste_> line
[22:18] <fullermd> Well, I was thinking more Abbott & Costello, myself, but that would probably be more fun   :p
[22:19] <CardinalFang> fullermd, Who?
[22:19] <CardinalFang> (First base.)
[22:19] <fullermd> What?
[22:19] <CardinalFang> No, first.
[22:19] <jam> fullermd: http://xkcd.com/540/
[22:19] <fullermd> Yes.
[22:20] <jam> see you all around next week, I'm off
[22:20]  * CardinalFang commiserates with fullermd, and shakes his fist at the kids on his lawn.
[22:20] <CardinalFang> G'night, jam.
[22:26] <KhaZ> I can't seem tog et bzr st to only show paths from the directory I'm in or below.  i.e, if I have a file versioned as /a/b/c/file.txt, and I'm in 'c', I'd hope bzr st would print 'file.txt'.  Instead it prints '/a/b/c/file.txt'.  Is there a setting I'm missing somewhere?
[22:27] <bialix> no
[22:28] <KhaZ> Hrmm.
[22:29] <bialix> what these binary numbers means?
[22:30] <ste_> they mean base 2
[22:31] <bialix> hmmm
[22:31] <garyvdm> Hello
[22:31] <bialix> I'm definitely don't understand baseball enough
[22:31] <bialix> hi Gary
[22:33] <bialix> fursuits?
[22:34] <bialix> oh, never mind
[22:35] <ste_> good, back to code
[22:35] <ste_> thanks for the help!
[22:35] <bialix> Janeane?
[22:35] <ste_> and for bzr, I like it
[22:36]  * ste_ bye