| === ubott2 is now known as ubottu | ||
| Odd_Bloke | So, anyone in here going to FOSDEM? | 00:19 |
|---|---|---|
| bartzitz | hello, i'm affected by this bug https://bugs.launchpad.net/bzr/+bug/319790 (can't unshelve my changes) | 00:22 |
| ubottu | Launchpad bug 319790 in bzr "bzr unshelve crashes losing all changes" [Medium,Confirmed] | 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:22 |
| bartzitz | help, anyone? | 00:23 |
| jfroy|work | spiv: branches to address URL escaping in bzr and loggerhead have been submitted. Thanks again for your input last week. | 00:24 |
| 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:26 |
| 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:27 |
| bartzitz | it shows a progress bar (something is going on). but in the end the same message: bzr: ERROR: No such file: None | 00:28 |
| lifeless | bartzitz: I'm just looking at the bug now | 00:31 |
| bartzitz | lifeless: ok thanks, i'll wait | 00:31 |
| lifeless | bartzitz: reproduced, so I can investigate | 00:34 |
| lifeless | spiv: ping | 00:37 |
| lifeless | pdb bailing worse :( | 00:38 |
| 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 |
| ubottu | Launchpad bug 319790 in bzr "bzr unshelve crashes losing all changes" [High,Confirmed] | 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:39 |
| 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:40 |
| bartzitz | lifeless: bzr.dev, development version you mean? | 00:42 |
| lifeless | bartzitz: yes, it has the bug still | 00:43 |
| lifeless | bartzitz: first thing in confirming, make sure its not fixed already :) | 00:43 |
| 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:44 |
| spiv | lifeless: gar, it seems to be a bug in my workaround :( | 00:45 |
| 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:47 |
| spiv | (in bzrlib/commands.py, of course) | 00:48 |
| lifeless | thanks spiv | 00:50 |
| lifeless | spiv: now, the other issue :) | 00:50 |
| lifeless | spiv: shall we sprint? | 00:50 |
| lifeless | bartzitz: its just deletes; working on a fix | 00:56 |
| bartzitz | lifeless: thanks a lot, i have some critical stuff in there | 00:57 |
| poolie | (out to lunch) | 01:00 |
| spiv | lifeless: the weather is making me disinclined to move, let alone go out and about ;) | 01:01 |
| lifeless | spiv: ok | 01:02 |
| spiv | It would be good to get together again soon though. How about Monday? | 01:02 |
| 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:03 |
| 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:04 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:21 |
| bartzitz | lifeless: great | 01:22 |
| lifeless | jam: around? | 01:23 |
| lifeless | vila: or you ? | 01:24 |
| === asac_ is now known as asac | ||
| === kgoetz is now known as Kamping_Kaiser | ||
| jelmer | looks like ohloh will be having bzr support soon \o/ | 01:47 |
| jelmer | lifeless, could pqm be stuck atm? | 01:48 |
| beuno | jelmer, where have you read this? | 01:50 |
| === mark1 is now known as markh | ||
| jelmer | beuno, talking with one of the ohloh folks | 01:56 |
| beuno | jelmer, awesome | 01:57 |
| lifeless | jelmer: its quiesced; as per the mail on bazaar@ | 01:58 |
| jelmer | lifeless: ah, sorry - must've missed that | 01:58 |
| mwhudson | jelmer: cool beans | 02:03 |
| lifeless | whats cool? | 02:05 |
| mwhudson | ohloh | 02:06 |
| lifeless | oh right | 02:06 |
| fullermd | No, ohloh. | 02:06 |
| 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:07 |
| 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:08 |
| lifeless | iIRC yes | 02:09 |
| igc | hi all | 02:09 |
| lifeless | I think its also come up in errata | 02:09 |
| 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:10 |
| mwhudson | true i guess | 02:11 |
| lifeless | gimme a sec to page this in | 02:11 |
| 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:12 |
| mwhudson | ah no | 02:13 |
| * mwhudson reads | 02:13 | |
| lifeless | 2183 says '2184 for non-ascii params | 02:13 |
| 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:18 |
| 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:19 |
| mwhudson | ow | 02:20 |
| mwhudson | loggerhead can't even _render_ a link to a file containing non-ascii | 02:20 |
| * mwhudson stabs python | 02:20 | |
| === mark1 is now known as markh | ||
| fullermd | Wuff. Hour 38 to 'check' bzr.dev. | 02:30 |
| * fullermd remembers why he doesn't do it very often. | 02:31 | |
| lifeless | fullermd: wtf | 02:31 |
| lifeless | oh yeah | 02:31 |
| lifeless | see my mailabout faster check ? :P | 02:32 |
| === kiko-afk is now known as kiko-zzz | ||
| lifeless | bartzitz: ok, its PreviewTree missing some api's | 02:41 |
| lifeless | bartzitz: I think>. Anyhow, am progressing | 02:41 |
| === mark1 is now known as markh | ||
| 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 | 02:59 |
| 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:00 |
| 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:02 |
| 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:03 |
| lifeless | completely agree | 03:04 |
| 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:05 |
| 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:06 |
| 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:08 |
| mwhudson | hm | 03:09 |
| mwhudson | it seems list_files is | 03:09 |
| mwhudson | but walkdirs() isn't | 03:10 |
| 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:11 |
| 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:18 |
| lifeless | bartzitz: though I'm going to persevere a bit more | 03:19 |
| jfroy | quick question: is there a command to switch an existing repo to having no trees by default | 03:28 |
| 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:29 |
| lifeless | bartzitz: fixed | 03:47 |
| lifeless | bartzitz: just apply the patch from the bug report to your local copy of bzr | 03:47 |
| * igc lunch & medical stuff - bbl | 04:15 | |
| 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:16 |
| 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:17 |
| KhaZ | Ah. Heh, I do want to avoid that. ;) | 04:18 |
| KhaZ | I do dig that launchpad website. No chance that the software driving that is open source, eh? :) | 04:19 |
| 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:20 |
| KhaZ | Allowing we're around at that point, given all the bloody layoffs. :( | 04:21 |
| === mark1 is now known as markh | ||
| 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:22 |
| 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:23 |
| KhaZ | Hmm. Still complains about not having a module named 'foreign' in 1.11. Guess I need to go install it. | 04:27 |
| 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:28 |
| KhaZ | Ah, awesome. | 04:29 |
| lifeless | mwhudson: repository.get_inventory_xml | 04:29 |
| lifeless | KhaZ: ones with C extensions will need more | 04:29 |
| 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:30 |
| 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:31 | |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| KhaZ | http://pastebin.com/m45e9b8a1 | 04:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| lifeless | jfroy: mwhudson: anyhow those were the two points; standardings on 'unicode' type strings is very slow in python, we learnt this late | 04:58 |
| 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. | 04:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| * 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:05 |
| 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:06 |
| ubottu | Ubuntu bug 325974 in loggerhead "Use bzrlib.urlutils to provide prettier URLs" [Undecided,New] | 05:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| mwhudson | so i should encode as utf-8 first? | 05:10 |
| 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:11 |
| 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:12 |
| jfroy | and yeah, that will force _url_base to be a str object | 05:13 |
| 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:14 |
| lifeless | spiv: so, did my recap email help? | 05:15 |
| 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:16 |
| jfroy | AFAIK puling pulls changesets from the source branch, and thus, no. | 05:17 |
| jfroy | *pulling | 05:17 |
| KhaZ | Ah, nuts. :/ | 05:17 |
| 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:18 |
| 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:19 | |
| 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:20 |
| 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:21 |
| 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:22 |
| jfroy | lifeless: I suppose, but I don't like it. | 05:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| jfroy | I think that's called failure to communicate. | 05:49 |
| jfroy | :p | 05:49 |
| 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:50 |
| lifeless | poolie: did you find the mail? | 05:51 |
| KhaZ | Yeah. I think if I ever push DVCS it'll be engineers only. | 05:51 |
| 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:52 |
| 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:53 |
| * 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:54 |
| 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:55 |
| 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:56 |
| === sdboyer is now known as magic_pixie | ||
| === magic_pixie is now known as sdboyer | ||
| jfroy | mwhudson: looks good | 05:57 |
| mwhudson | jfroy: good enough for me, thanks :) | 05:57 |
| jfroy | mwhudson: bah, right | 05:58 |
| jfroy | I'll open a bug and huh... mail them a merge bundle? | 05:58 |
| 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 | 05:59 |
| 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:00 | |
| mwhudson | jfroy: anyway, thanks for being a sounding board, i'll look at your merge proposal properly on monday :) | 06:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| bob2 | KhaZ: bzr cdiff in bzrtools does that | 06:14 |
| KhaZ | Ah, neat. I still like not having to train my lazy brain to remember to use 'cdiff'. ;) | 06:15 |
| KhaZ | Huh. TortoiseBzr doesn't allow me to checkout to my usb drive. Weird. | 06:25 |
| poolie | KhaZ: what happens? | 06:33 |
| 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:34 |
| poolie | lifeless: i answered | 06:41 |
| === _Nicke_ is now known as Nicke | ||
| vila | hi all | 07:14 |
| 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:15 |
| vila | s/ti/to/ | 07:16 |
| poolie | oh | 07:16 |
| poolie | what was the toy? | 07:16 |
| vila | icore7-965/12GB/60GBSSD/1TBHDD :-) | 07:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:22 |
| 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:23 |
| jeddy3 | morning | 07:38 |
| 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:41 |
| 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 | 07:42 |
| jeddy3 | in other words a --depth for bzr | 08:04 |
| jeddy3 | ...which at a closer look doesn't seem to exist...nevermind | 08:06 |
| 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:08 |
| jeddy3 | poolie: ah, sounds nice! | 08:10 |
| jeddy3 | and actually filtered views is a really good analogy for it | 08:11 |
| ollie | need a quick bit of advise about a bzr repo | 08:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| speakman | http://ppa.launchpad.net/bzr/ppa/ubuntu still breaks bzr upgrade due to uncompatible bzrtools: http://pastebin.com/me990cae | 08:18 |
| * 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) | 08:20 | |
| === mark1 is now known as markh | ||
| === kiko-zzz is now known as kiko | ||
| * Lo-lan-do → FOSDEM | 09:57 | |
| jeddy3 | hmmm | 10:47 |
| jeddy3 | bzr pull on a subversion tree takes extremly long time... :| | 10:48 |
| jeddy3 | it should be up to date or maybe almost up to date | 10:51 |
| 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:52 |
| 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:53 |
| jeddy3 | spiv: that would not return any tags, what is the effect of that? :) | 10:54 |
| === kiko is now known as kiko-afk | ||
| jeddy3 | spiv: i mean does that have any consequences? | 10:55 |
| jeddy3 | spiv: if not, why does even find_tags exist? ;) | 10:56 |
| spiv | jeddy3: right, that's the downside. | 11:00 |
| spiv | jeddy3: but if you don't care much about tags, then it might be an okay tradeoff :) | 11:01 |
| jeddy3 | :D | 11:09 |
| jeddy3 | spiv: thank you | 11:09 |
| 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:46 |
| BjornW | Nobody got any hints or tips to perform a partial export? | 11:58 |
| beuno | BjornW, BjornW what version of bzr are you using | 11:59 |
| beuno | you can do: bzr export file.tar.gz my_dir | 11:59 |
| 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:00 |
| beuno | BjornW, yes, more than 1.3.1 :) | 12:01 |
| 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:02 |
| beuno | BjornW, you're welcome | 12:03 |
| BjornW | beuno: just tried it and you just saved me a lot of annoying work. Thanks! | 12:22 |
| beuno | BjornW, happy to help. You should see quite a few improvements with newer versions of bzr | 12:25 |
| beuno | performance especially in the next few months, if you keep updated through the PPA | 12:26 |
| 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:44 |
| === kiko-afk is now known as kiko | ||
| 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:47 |
| BjornW | bialix: thanks, I'll have a look tonight at it. | 12:54 |
| bialix | BjornW: also there is bzrlib/tests/blackbox/test_export.py | 12:56 |
| awilkins | jelmer: ? | 12:57 |
| edgimar | How do I change my working directory so that all the files are from an earlier revision? | 13:38 |
| awilkins | bzr revert -r <my earlier revision> | 13:40 |
| 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:41 |
| 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:43 |
| 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:44 |
| 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:45 |
| awilkins | There's no PPA for it on launchpad | 13:46 |
| edgimar | bzr: ERROR: Not a branch: "http://bzr.licquia.org/bzr-bisect/.bzr/branch/" | 13:47 |
| 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:48 |
| 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:50 |
| 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:51 |
| 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:57 |
| mtaylor | edgimar: nope | 13:58 |
| awilkins | edgimar: Start at the tip, and bisect will handle the searching | 13:58 |
| 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... | 13:59 |
| 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:00 |
| mtaylor | manual search bad | 14:01 |
| mtaylor | :) | 14:01 |
| 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:04 |
| jeddy3 | awilkins: version 0.49 | 14:05 |
| jeddy3 | sorry 0.4.9 | 14:05 |
| 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:07 |
| 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:09 |
| jeddy3 | heh :) | 14:10 |
| 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:11 |
| jeddy3 | hehe, 34000 revisions here, but still | 14:12 |
| jeddy3 | (repository-wise) | 14:12 |
| 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:13 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| edgimar | Ok, that clarifies things... | 14:37 |
| edgimar | Ok, now things are looking more like I'd expect.. :) | 14:38 |
| 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:40 |
| 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 | 14:42 |
| microft | need some quick help: how do I merge new changes from a launchpad project to my launchpad branch? | 15:28 |
| jam | hi bialix | 15:29 |
| 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:30 |
| microft | jam: thanks | 15:33 |
| bialix | hi all | 15:42 |
| bialix | dear bzr hackers, I need a little help about writing test for my plugin, I need to emulate interaction with remote server | 15:43 |
| 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:46 |
| 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:47 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| Tak | nevermind, it's working the way I'd think it would, I just typoed the first attempt | 15:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 :-) | 15:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| microft | ~~~~~~ | 16:16 |
| jdong | alright looks like I have to go with a different approach then :) | 16:17 |
| 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:18 |
| 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:19 |
| jdong | or... for this stupid little hackish program... just shell out to bzr's binary | 16:20 |
| jdong | btw, I would just like to say bzr's Windows compatibility rocks; the best of the DVCSes I've tried. | 16:21 |
| 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:25 |
| Tak | jdong: have you looked at https://launchpad.net/monodevelop-bzr ‽ | 16:30 |
| jdong | awilkins: yeah git is great on a POSIX platform; though I beg to differ with its UI | 16:41 |
| jdong | Tak: very cool, I'll look at it. | 16:42 |
| jam | jdong: you need a 3-way merger on Windows? | 16:44 |
| 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:45 |
| bialix | I suspect this!@ | 16:46 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| rockstar | jam, so I'll have to bzr init --1.9 the branch as well. Okay. | 16:52 |
| derekS | jam: generally? | 16:52 |
| jam | derekS: I *think* I know what you are trying to do, and it should just work. | 16:53 |
| derekS | ok :) | 16:56 |
| derekS | thanks | 16:56 |
| 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:11 |
| abentley | Peng_: I think you mean 1.6. 1.9 has other advantages. | 17:24 |
| 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:28 |
| 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:29 |
| 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:44 |
| KhaZ | CaMason: bzr push [central repo url] | 17:46 |
| 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:47 |
| CaMason | bzr log is showing the most recent entry as 172, yet doing 'bzr check' shows 178 revisions | 17:51 |
| CaMason | so I try bzr revert -r 178, and it says the revision does not exist | 17:52 |
| CaMason | Anyone have any ideas? I've been working on this all-day and really need to get that 178 revision back | 17:53 |
| EnCuKou | CaMason: Maybe `bzr heads` will show you the revision-id? | 17:57 |
| 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 | 17:59 |
| 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:00 |
| 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:01 |
| bialix | so sftp server is most common solution? | 18:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:14 |
| 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:15 |
| CaMason | right, it's bound. Now, should I do a bzr update? | 18:16 |
| bialix | to reproduce the bug? yes, of course | 18:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| bialix | bzr update put your history in sync with the server, and not vice versa | 18:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| bialix | I'm lost in your hardware | 18:25 |
| bialix | .moved files are because you've added them in different branches with the same name | 18:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| ubottu | Ubuntu bug 326278 in bzr-svn "'bzr log' KeyError" [Undecided,New] | 18:29 |
| 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:30 |
| 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:31 |
| 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:34 |
| CardinalFang | CaMason, using what command? | 18:36 |
| 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:49 |
| amanica_ | and then you cant tell what changed outside of the pending commits | 18:50 |
| 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:51 |
| amanica_ | this happen when you do an update with local commits and changes in the working tree at the same time. | 18:52 |
| amanica_ | (sorry I forgot to mention the update part before0 | 18:53 |
| amanica_ | (there is some bugs related to what I described eg. Bug #113809 , I think I should log what I described here seperately) | 18:59 |
| ubottu | Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809 | 18:59 |
| 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:07 |
| 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:08 |
| nDuff | CaMason, run the following: echo $DISPLAY | 19:09 |
| CaMason | blank output | 19:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:17 |
| CaMason | nDuff: I'll make a test repo and tr it | 19:31 |
| CaMason | http://pastebin.com/d30394fa1 | 19:33 |
| CaMason | nDuff:?^^ | 19:34 |
| nDuff | ...is that actually the gtk plugin, or the dbus plugin? | 19:34 |
| CaMason | no idea... I literally inited a repo, added a testfile, commit.. and get that output :) | 19:35 |
| 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:36 |
| CaMason | nDuff: certainly, 2 mins | 19:37 |
| CaMason | so I should leave bzr-gtk installed? | 19:37 |
| nDuff | yup | 19:38 |
| CaMason | removing bzr-dbus also removed bzr-avahi | 19:38 |
| CaMason | had to run an update first. The commit succeeded without crashing | 19:39 |
| nDuff | CaMason, OK. Is there any output from the command "set | grep DBUS"? | 19:40 |
| CaMason | nDuff: nothing | 19:41 |
| nDuff | CaMason, if you reinstall bzr-dbus, and run the commit command as "dbus-launch bzr commit", does it still fail? | 19:42 |
| 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:43 |
| CaMason | `bzr commit` = crash | 19:44 |
| 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:45 |
| CardinalFang | KhaZ, "merge" copies from other trees. | 19:46 |
| CardinalFang | ...or something like them. | 19:46 |
| 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:49 |
| CaMason | nDuff: that variable is present on the laptop, but not present when in via SSH | 19:50 |
| nDuff | CaMason, yup -- and that's exactly why you're having the problem when you're only connecting over SSH. | 19:51 |
| 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:52 |
| CaMason | https://bugs.launchpad.net/bzr-dbus/+bug/326320 | 19:59 |
| ubottu | Ubuntu bug 326320 in bzr-dbus "`bzr commit` throws an exception when bzr-dbus is installed, and commit is via SSH" [Undecided,New] | 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. | 19:59 |
| CaMason | excellent. Glad I was able to help somewhat | 20:00 |
| ronny | LarstiQ: http://www.geeksugar.com/2471026 | 20:12 |
| === kiko__ is now known as kiko | ||
| 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:29 |
| bialix | bzr tags | 20:30 |
| bialix | bzr tags -d remote-branch | 20:30 |
| bialix | compare results and decide which tags are right | 20:31 |
| nekohayo | but.. the results are identical | 20:31 |
| bialix | nope | 20:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| bialix | ok, back to tags | 20:35 |
| bialix | if your local tags is the right one, you need to push --overwrite | 20:35 |
| === bac is now known as bac_afk | ||
| nekohayo | it worked, thanks! /me notes this somewhere | 20:39 |
| bialix | may be adding this to faq? | 20:40 |
| bialix | or blog about this ;-) | 20:41 |
| amanica__ | conflicting tags scares some people, maybe this should be explained in a topic, and referenced in that message | 20:45 |
| 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:46 |
| bialix | it's a bug? | 20:47 |
| bialix | Bug #213184 | 20:49 |
| ubottu | Launchpad bug 213184 in bzr "'conflicting tags' could be more helpful" [Wishlist,Confirmed] https://launchpad.net/bugs/213184 | 20:49 |
| bialix | it's marked as wishlist though | 20:50 |
| nekohayo | bialix: I actually saw that bug report before coming to this channel, because nobody had given an answer on that bug report | 20:52 |
| bialix | perhaps because that bug was reported by one of the core dev | 20:54 |
| bialix | I think it should be easy to fix. someone with good english skill just need to write some explanation | 20:55 |
| bialix | or maybe tags v2 should be implemented first | 20:56 |
| jbalint | any idea what this means? bzr: ERROR: A nested progress bar was not 'finished' correctly. | 20:57 |
| 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:58 |
| 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 | 20:59 |
| 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:00 |
| * bialix looks | 21:01 | |
| bialix | there are only 3 questions | 21:03 |
| * bialix has answered one question, others 2 out of his competence | 21:06 | |
| jbalint | nice | 21:08 |
| bialix | thx | 21:09 |
| 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:10 |
| 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:11 |
| amanica__ | CardinalFang: that bothered me once too, but I was told that trafic is quite minimal | 21:12 |
| 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:13 |
| amanica__ | (with exact I mean there should not me non-upstream commits present) | 21:14 |
| bialix | it's easy to reconstruct, actually | 21:14 |
| bialix | nekohayo: I guess there are plans to make some screencasts | 21:15 |
| 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:16 |
| 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:17 |
| bialix | Cardinal: you really should create somewhere on disk base branch | 21:19 |
| bialix | and use it as SUBMIT_BRANCH argument | 21:19 |
| 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:20 |
| bialix | it's *your* post-commit hook. Is not you're master on your hooks? | 21:21 |
| bialix | slightly change the hook? not? | 21:21 |
| 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:22 |
| CardinalFang | Yeah. I can get the base other ways. I'll get to that, once I see it works. | 21:23 |
| 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:24 |
| bialix | bzr+ssh, http? | 21:25 |
| bialix | look at .bzr.log first | 21:25 |
| bialix | or into .bzr.log | 21:25 |
| 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:26 |
| bialix | CardinalFang: abentley thinks different | 21:27 |
| 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:29 |
| 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:30 |
| 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:31 | |
| fullermd | Why is there air? | 21:32 |
| bialix | oh, my hero is here! | 21:33 |
| * fullermd dons his cape and strikes a pose. | 21:33 | |
| bialix | what about air actually? | 21:33 |
| fullermd | I dunno. You just asked for a question, and it came to mind. | 21:34 |
| bialix | ah | 21:34 |
| bialix | stupid me | 21:34 |
| bialix | I wanna get my call to a friend! | 21:35 |
| fullermd | That doesn't mean you can get away with not answering it! :p | 21:35 |
| bialix | there -- is where? | 21:35 |
| bialix | if I'm answer it in russian -- does it will counts? :-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:36 |
| 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:38 |
| fullermd | Wait, I'm supposed to not cheat now, too? If you'd just lay out all these rules ahead of time... | 21:39 |
| bialix | I think it should be good litycs | 21:40 |
| bialix | lyrics | 21:40 |
| bialix | what is other 4 words | 21:40 |
| 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:41 |
| bialix | my answer is valid? | 21:42 |
| fullermd | I guess. I think it's cheating though :p | 21:42 |
| bialix | I'm learn from the best | 21:43 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| bialix | o! | 21:54 |
| ignas | bialix: think so | 21:54 |
| bialix | ignas: I guess very close | 21:54 |
| ste_ | well, trying this merge | 21:54 |
| ste_ | 10x for the help | 21:55 |
| ignas | bialix: yeah | 21:55 |
| bialix | fullermd: ? | 21:56 |
| bialix | jam: thanks! lol | 21:57 |
| fullermd | Hmm? | 21:57 |
| bialix | I did my call to a friend | 21:58 |
| bialix | see above ;-P | 21:58 |
| 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 | 21:59 |
| 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:00 |
| bialix | :-D | 22:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| jam | However, I think you might be able to create MergeDirective2() directly | 22:06 |
| jam | with the right values | 22:06 |
| jam | and use the appropriate value to "MergeDirective2._generate_bundle()" | 22:07 |
| * CardinalFang looks. | 22:09 | |
| bialix | what exactly means: "I dunno"? | 22:10 |
| 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:13 |
| 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! Thank you. | 22:14 |
| bialix | jam: got it | 22:14 |
| jam | bialix: Actually, in common pronunciation, there are almost no consonants | 22:14 |
| jam | I -uh -oh | 22:15 |
| fullermd | Man, you yankees... | 22:15 |
| bialix | I'm dizzy | 22:15 |
| fullermd | A perfectly natural reaction to English ;p | 22:16 |
| bialix | I can teach you russian a bit | 22:16 |
| ste_ | cool, it worked | 22:17 |
| ste_ | thank you guys | 22:17 |
| bialix | what? 42? | 22:17 |
| fullermd | I don't know. Third base. | 22:17 |
| CardinalFang | Heh. | 22:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:26 |
| bialix | no | 22:27 |
| KhaZ | Hrmm. | 22:28 |
| bialix | what these binary numbers means? | 22:29 |
| ste_ | they mean base 2 | 22:30 |
| bialix | hmmm | 22:31 |
| garyvdm | Hello | 22:31 |
| bialix | I'm definitely don't understand baseball enough | 22:31 |
| bialix | hi Gary | 22:31 |
| bialix | fursuits? | 22:33 |
| bialix | oh, never mind | 22:34 |
| 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:35 |
| * ste_ bye | 22:36 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
