| lifeless | hi poolie | 00:00 |
|---|---|---|
| lifeless | I slept in this morning :) | 00:00 |
| poolie | spiv, igc, do you want to talk? | 00:02 |
| poolie | lifeless: i was just saying to john i woke up about 6:30 on my holiday but now i find it hard to get going | 00:03 |
| lifeless | :) | 00:03 |
| spiv | Sure. | 00:03 |
| igc | morning | 00:48 |
| thumper | morning igc | 00:49 |
| jelmer | lifeless: what is the difference between InventoryFile.text_id and InventoryFile.file_id exactly? | 01:10 |
| lifeless | text_id? wtf | 01:11 |
| jelmer | lifeless: in particular, they don't ever seem to differ - can they? | 01:11 |
| lifeless | text_id was bzr 0.0.6 and before only | 01:11 |
| jelmer | ah, ok | 01:11 |
| lifeless | its in the api for compatibility, you don't want to set it or consult it | 01:12 |
| jelmer | I came across it trying to find a solution to two problems in bzr-git: | 01:12 |
| jelmer | - ideally I'd like to use one-tuples rather than two-tuples for file texts | 01:13 |
| jelmer | - I need a place to stash the file modes that are stored for all git files | 01:13 |
| lifeless | what would be in the one-tuples? | 01:14 |
| rockstar | igc, thumper was asking about an ETA for historycache. Can you give me something specific? | 01:14 |
| lifeless | spiv: let me know when you've done that review please | 01:16 |
| jelmer | lifeless: blob sha | 01:17 |
| jelmer | lifeless: that would of course bring up the problem of file graphs | 01:17 |
| lifeless | right, bzr core doesn't do this | 01:17 |
| lifeless | note that a blob sha != sha of the bytes | 01:18 |
| lifeless | its sha of the bytes + git header | 01:18 |
| jelmer | lifeless: yes, I know | 01:18 |
| jelmer | lifeless: the blob sha is what I get from git though, for the content sha I have to fetch and unpack the blob | 01:18 |
| jelmer | anyway, the second issue is more pressing | 01:19 |
| jelmer | I've thought of two ugly solutions so far | 01:20 |
| igc | rockstar: I'll try to get something out this week, but I think next week is more likely | 01:20 |
| jelmer | storing the changed modes in a revision property | 01:20 |
| lifeless | by file modes you mean extended permissions? | 01:20 |
| jelmer | storing the modes in the texts for the directories | 01:20 |
| jelmer | lifeless: unix file modes | 01:20 |
| rockstar | igc, that's straight gangsta | 01:20 |
| jelmer | lifeless: not sure if that's what you mean by extended permissions? | 01:21 |
| lifeless | jelmer: broadly | 01:21 |
| lifeless | jelmer: more than 'x' ;) | 01:21 |
| jelmer | lifeless: ah, extended in that sense, yes :-) | 01:21 |
| lifeless | note that we don't do more than x because extended permissions get in the way of VCS | 01:22 |
| jelmer | lifeless: yes, I'm not arguing bzr should do more | 01:22 |
| lifeless | I thought git didn't store full unix bits anyway, only a subset | 01:22 |
| jelmer | lifeless: it does, but recent versions of git restrict a little bit what you can set | 01:22 |
| jelmer | lifeless: (it does store full unix bits I mean) | 01:23 |
| lifeless | ok | 01:23 |
| lifeless | well | 01:23 |
| jelmer | lifeless: In order to be able to reproduce the exact git commits from a bzr revision I need to store these modes somewhere | 01:23 |
| lifeless | how does etckeeper store modes | 01:23 |
| jelmer | lifeless: plaintext file in the root | 01:24 |
| jelmer | lifeless: I'd prefer to keep this data away from the user though | 01:25 |
| lifeless | jelmer: so you could either: special case it for git; write a general solution for bzr core and then use that; do something compatible with one of the other 'backup via vcs' tools out there and use that for bzr-git | 01:25 |
| jelmer | lifeless: hmm | 01:25 |
| lifeless | I'm ok with more bits being storable in bzr and our UI leaving them unset (though it implies a trinary field not a binary - unknown, off, on) | 01:26 |
| lifeless | or a mask + bits | 01:27 |
| lifeless | or something like that | 01:27 |
| lifeless | [we don't want to suddenly start having the problems associated with setting overly strict modes on files we create etc] | 01:27 |
| lifeless | this would take discussion | 01:28 |
| lifeless | I think its worth doing | 01:28 |
| jelmer | yeah, I think that makes sense in that this is something to keep in mind for the future | 01:28 |
| spiv | lifeless: reviewed | 01:29 |
| lifeless | jelmer: now is a good time as we have a new format in beta | 01:29 |
| lifeless | jelmer: if you act fast --development7-rich-root could do this | 01:29 |
| jelmer | lifeless: I doubt I'd have enough time for that, unfortunately | 01:30 |
| lifeless | jelmer: well, you never know :) | 01:31 |
| jelmer | hmm, that reminds me | 01:49 |
| jelmer | it looks like bundlebuggy is ignoring my rio serializer patch | 01:49 |
| jelmer | abentley: ping | 01:54 |
| xiaohui | Hi , when I use 'bzr branch lp:opencog', I got an sokcket error, it said that that 'Connection timed out' | 02:04 |
| xiaohui | but I can connect to lp:opencog using browser | 02:04 |
| spiv | xiaohui: do you have an HTTP proxy perhaps? | 02:05 |
| spiv | you may need to set the http_proxy environment variable so that bzr uses the same proxy as your browser. | 02:05 |
| xiaohui | yeah, I use the HTTP proxy | 02:05 |
| xiaohui | I have set this enviroment variable | 02:06 |
| xiaohui | hi, spiv, the tracback is : | 02:09 |
| xiaohui | File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 846, in run_bzr_catch_errors | 02:09 |
| xiaohui | return run_bzr(argv) | 02:09 |
| xiaohui | File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 797, in run_bzr | 02:09 |
| xiaohui | ret = run(*run_argv) | 02:09 |
| xiaohui | File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 499, in run_argv_aliases | 02:09 |
| xiaohui | return self.run(**all_cmd_args) | 02:09 |
| spiv | xiaohui: please, use a pastebin for tracebacks, not the channel. | 02:11 |
| lifeless | xiaohui: you should set http_proxy to "http://PROXY:PORT/" | 02:12 |
| xiaohui | oh ,sorry spiv | 02:12 |
| xiaohui | lifeless, that is it. | 02:12 |
| === xiaohui_ is now known as xiaohui | ||
| lifeless | spiv: 9 less ;) | 02:48 |
| xiaohui | I used ' bzr branch http://bazaar.launchpad.net/~opencog-dev/opencog/trunk', it worked | 02:58 |
| lifeless | spiv: ping | 03:00 |
| spiv | lifeless: pong | 03:00 |
| lifeless | my ptch failed | 03:00 |
| lifeless | incremental change: | 03:00 |
| lifeless | mm, one more sec :P | 03:00 |
| spiv | Heh. | 03:00 |
| bob2 | what was the initial count you knocked 14 and 9 off? | 03:01 |
| lifeless | bob2: 6 and 9, 43 | 03:01 |
| lifeless | === modified file 'bzrlib/tests/bzrdir_implementations/test_bzrdir.py' | 03:01 |
| lifeless | --- bzrlib/tests/bzrdir_implementations/test_bzrdir.py2009-03-23 14:59:43 +0000 | 03:01 |
| lifeless | +++ bzrlib/tests/bzrdir_implementations/test_bzrdir.py2009-04-15 02:01:15 +0000 | 03:01 |
| lifeless | @@ -1712,13 +1712,17 @@ | 03:01 |
| lifeless | def test_get_config(self): | 03:01 |
| lifeless | my_dir = self.make_bzrdir('.') | 03:01 |
| lifeless | config = my_dir.get_config() | 03:01 |
| lifeless | - if config is None: | 03:01 |
| lifeless | - self.assertFalse( | 03:01 |
| lifeless | - isinstance(my_dir, (bzrdir.BzrDirMeta1, RemoteBzrDir)), | 03:01 |
| lifeless | - "%r should support configs" % my_dir) | 03:01 |
| lifeless | - raise TestNotApplicable( | 03:02 |
| lifeless | - 'This BzrDir format does not support configs.') | 03:02 |
| lifeless | - config.set_default_stack_on('http://example.com') | 03:02 |
| lifeless | + try: | 03:02 |
| lifeless | + config.set_default_stack_on('http://example.com') | 03:02 |
| lifeless | + except errors.BzrError, e: | 03:02 |
| lifeless | + if 'Cannot set config' in str(e): | 03:02 |
| lifeless | + self.assertFalse( | 03:02 |
| lifeless | + isinstance(my_dir, (bzrdir.BzrDirMeta1, RemoteBzrDir)), | 03:02 |
| lifeless | + "%r should support configs" % my_dir) | 03:02 |
| lifeless | + raise TestNotApplicable( | 03:02 |
| lifeless | + 'This BzrDir format does not support configs.') | 03:02 |
| lifeless | + else: | 03:02 |
| lifeless | + raise | 03:02 |
| lifeless | self.assertEqual('http://example.com', config.get_default_stack_on()) | 03:02 |
| lifeless | my_dir2 = bzrdir.BzrDir.open(self.get_url('.')) | 03:02 |
| lifeless | config2 = my_dir2.get_config() | 03:02 |
| lifeless | spiv: ^ faster than pastebin ;> | 03:02 |
| lifeless | xiaohui: I'm glad its working for you | 03:02 |
| spiv | By the time your irc client pastes that at a rate of 1 line per 2 seconds it would have been quicker to just use a pastebin... | 03:02 |
| lifeless | we have a known bug with xmlrpc which is a python bug | 03:02 |
| lifeless | spiv: my browser is paged out; I have a test run indexing code by test which is making everything crawl | 03:03 |
| lifeless | spiv: it would have been several minutes to get it up to a pastebin :( | 03:03 |
| * spiv hands lifeless an ec2 instance | 03:04 | |
| lifeless | spiv: :) I need more glue for that though, its a plugin yada yada | 03:04 |
| xiaohui | lifeless: what is the difference between 'lp:opencog' and the URL | 03:04 |
| lifeless | xiaohui: lp:opencog makes a xmlrpc request to get the URL | 03:04 |
| spiv | lifeless: seems reasonable, bb:approve | 03:04 |
| lifeless | xiaohui: and the xmlrpc library in python does not support proxies :( | 03:04 |
| xiaohui | so ,you mean that I should always use the URL | 03:07 |
| lifeless | xiaohui: I think you will need to until we work around the bug yes | 03:08 |
| xiaohui | lifeless: I see , thank you | 03:08 |
| lifeless | spiv: and a new patch up, set_parent_location, push down to 28 | 03:09 |
| xiaohui | lifeless: that will be more convienent if it support the proxies:) | 03:10 |
| lifeless | xiaohui: indeed, we want to fix it; need someone to have the time | 03:10 |
| lifeless | spiv: [BzrDir.open, mkdir, mkdir, BzrDirFormat.initialize, BzrDir.open, BzrDir.find_repositoryV3, BzrDir.create_repository, Repository.set_make_working_trees, Repository.lock_write, Repository.has_revision, Repository.get_parent_map, Repository.get_parent_map, Repository.insert_stream, Repository.insert_stream, Repository.get_parent_map, Repository.insert_stream, BzrDir.create_branch, Branch.lock_write, Branch.set_config_option, Branch.un | 03:10 |
| lifeless | spiv: do you see what I see | 03:10 |
| xiaohui | lifeless: It doesn't matter, thank you:-) | 03:12 |
| spiv | lifeless: I see a cut-off line :P | 03:13 |
| lifeless | spiv: oh foo | 03:13 |
| spiv | lifeless: ...Branch.set_config_option, Branch.un | 03:13 |
| lifeless | , Branch.unlock, Branch.lock_write, Branch.last_revision_info, Branch.set_last_revision_info, Branch.unlock, Branch.lock_write, | 03:14 |
| lifeless | Branch.set_parent_location, Branch.unlock, Branch.get_stacked_on_url] | 03:14 |
| spiv | Nice. | 03:14 |
| lifeless | spiv: or more, do you see what *isn't* there | 03:14 |
| spiv | No vfs aside from two mkdirs. | 03:14 |
| lifeless | yup | 03:14 |
| lifeless | I'm going to drive this to vfs-free today I think | 03:14 |
| spiv | Which, presumably, is doing the ensure_prefix or makedirs or whatever we call it. | 03:14 |
| lifeless | yes | 03:14 |
| lifeless | patch to get to what I pasted there is up for review now | 03:15 |
| === timchen1` is now known as nasloc__ | ||
| * igc lunch | 04:02 | |
| poolie | lifeless: google ads tell me "registry fixes are a rip off" | 05:34 |
| poolie | :) | 05:34 |
| lifeless | heh | 05:34 |
| lifeless | have you tried ec2 test or parallel testing yet? | 05:34 |
| poolie | nup | 05:42 |
| poolie | i think it was not merged when i left and i haven't run tests since i've been back | 05:43 |
| * lifeless encourages | 05:43 | |
| lifeless | spiv: I think we're sending too much data still | 05:47 |
| BasicOSX | hmph, no python 2.6.2 dmg installer | 06:10 |
| lifeless | spiv: look in bzrlib.tests.lock_helpers for __dict__ for some special code | 06:24 |
| poolie | igc, when you say "6 seconds to branch emacs" i'm presuming that's without building a tree | 06:38 |
| poolie | lifeless: hi, we may be getting disconnected regarding registries | 06:40 |
| poolie | it seems to me like centralizing them may be best i guess | 06:41 |
| lifeless | call? | 06:41 |
| lifeless | poolie: I don't really like centralising as an option, even though I raised it; because its hostile to plugins amongst other things | 06:43 |
| lifeless | I'm searching for a single root cause fix. | 06:43 |
| poolie | i'd kind of rather not have a call, at least today | 06:47 |
| lifeless | k | 06:47 |
| lifeless | vila: ec2test broken again for knownfailure... this thing is cursed | 06:48 |
| lifeless | spiv: poolie: I'd like a review for the patch I'm sending right now | 06:48 |
| lifeless | it passes everything, finally | 06:48 |
| lifeless | [sent] | 06:49 |
| igc | poolie: no - that's 6 seconds *including* the tree build | 06:51 |
| lifeless | igc: shared repo yes? | 06:51 |
| poolie | wow, so that makes the multiplier even more extreme | 06:51 |
| igc | lifeless: yes | 06:51 |
| igc | lifeless: and an existing tree already built for the trunk/mirror branch | 06:52 |
| lifeless | poolie: so, registries. defer till we're face to face? | 06:58 |
| poolie | unless it's blocking you severely | 06:58 |
| poolie | i want to reply to igc and then get out of mail etc | 06:58 |
| lifeless | its not blocking me | 06:59 |
| lifeless | the review I asked or is much more urgent :) | 06:59 |
| vila | hi all | 07:02 |
| vila | lifeless: :) | 07:02 |
| lifeless | it may be an old branch of bzr.dev, but I don't htink so :( | 07:03 |
| BasicOSX | Going to be using bzr on win32 over the next 18 weeks. Windows dev wanna see how this tool I rave about works on their platform (I work linux and osx side of things normally) | 07:06 |
| lifeless | BasicOSX: good luck! | 07:06 |
| BasicOSX | I tend to need luck when I work on a windows box | 07:07 |
| * vila sends more luck to BasicOSX | 07:14 | |
| lifeless | 'the luck is in the mail' | 07:14 |
| BasicOSX | cool, brisbane can serialize luck now? | 07:15 |
| === thekorn_ is now known as thekorn | ||
| lifeless | bah | 08:08 |
| lifeless | provenance, not providence | 08:08 |
| lifeless | need dinner | 08:08 |
| * lifeless shuts down ec2 | 08:08 | |
| lifeless | poolie: I'm done for the day | 08:15 |
| poolie | ok, good night | 08:16 |
| lifeless | modulo one last email I'm drafting | 08:16 |
| poolie | i need to do some personal sysadmin stuff so will sign off in a bit to do that | 08:16 |
| igc | me dinner | 09:36 |
| jelmer | nice | 10:48 |
| jelmer | new estimated import time for ooo.org: 4 hours | 10:49 |
| bob2 | wow | 10:55 |
| * bob2 remebers when it was a trillion years | 10:55 | |
| jelmer | I'm sure the git folks have never been able to achieve speed improvements of that factor :-P | 10:56 |
| lifeless | thumper: so that thread I was tugging on has been pulled - 1.15 <-> 1.15 will do 23 roundtrips (down from over 40) to push a new stacked branch | 10:57 |
| lifeless | jelmer: what did you chnage | 10:57 |
| jelmer | lifeless: various speed improvements to bzr-svn over the last couple of months, and --development6-rich-root | 10:58 |
| lifeless | its always nice when a basic-analysis + design + turns out well ;) | 10:59 |
| jelmer | lifeless: I think this has worked out really well | 11:02 |
| jelmer | lifeless: what's the next hot topic? | 11:08 |
| jelmer | subtrees? parallel imports? | 11:08 |
| lifeless | network | 11:08 |
| lifeless | and working area ease of use | 11:08 |
| jelmer | ah | 11:08 |
| * jelmer mutters something about colocated branches | 11:08 | |
| lifeless | I'd like to do file copy support too but thats lower return and higher investment | 11:08 |
| jelmer | lifeless: file copy as in file copy tracking or merge using that tracking as well, etc? | 11:09 |
| jelmer | lifeless: ISTM file copy tracking and the mode bit stuff we talked about yesterday could well be collated | 11:09 |
| lifeless | jelmer: I don't think they are that separated;) | 11:10 |
| cody-somerville | lifeless, thank you thank you thank you | 11:37 |
| cody-somerville | I hate git so much with a passion | 11:38 |
| cody-somerville | It is so horrible | 11:38 |
| cody-somerville | I don't know how I could live without bzr | 11:38 |
| * pygi shoots cody-somerville | 11:39 | |
| cody-somerville | Do I merge --squash or do I rebase? Do I patch-format or do I diff? Do I checkout, clone, or branch? To see changes in the working tree, what options must I pass to diff? -- git is confusing. | 11:41 |
| pygi | cody-somerville, once you get accustomed to it, no its not | 11:42 |
| pygi | and it has books to cover it up | 11:42 |
| pygi | free ones even | 11:42 |
| cody-somerville | bzr just works the way one expects | 11:42 |
| cody-somerville | thats what I like about it | 11:42 |
| stbuehler | with git i know what git is doing. with bzr i just hope it does what i want. | 11:45 |
| pygi | each DVCS have its use-cases, and their pros and cons | 11:46 |
| stbuehler | yep :) i still use bzr for committing to svn, i never liked the git svn support | 11:47 |
| pygi | I like git submodules for example ... and since a lot of projects use git, I use it too | 11:48 |
| pygi | I'm still not sure of nested branches support in bzr (and if they are in fact supposed to be something like svn:externals && submodules) | 11:48 |
| * Kinnison uses git when forced to | 11:48 | |
| jelmer | pygi: subtrees are landing at the moment | 11:50 |
| pygi | jelmer, oh? Bzr.dev then? 1.15 release? | 11:51 |
| jelmer | pygi: they're similar to svn:externals and submodules | 11:51 |
| lifeless | cody-somerville: :) | 11:51 |
| lifeless | pygi: when complete they should be similar to gits subprojects | 11:51 |
| jelmer | pygi: it's always hard to say, but I would guess 1.15 (Aaron has submitted nested trees for review, and review is happening atm) | 11:51 |
| lifeless | not 1.15 | 11:51 |
| jelmer | lifeless: oh, ok - why not? | 11:52 |
| lifeless | there are performance implications and design decisions to finalise | 11:52 |
| lifeless | it will be a 2.0 feature | 11:52 |
| pygi | lifeless, will that happen this year? | 11:54 |
| jelmer | lifeless: when would 2.0 be due? | 11:54 |
| lifeless | jelmer: when development6-rich-root has evolved to production ready | 12:02 |
| lifeless | 2-3 months probably, maybe less | 12:02 |
| pygi | lifeless, weren't git subprojects a "weaker" form of today's submodules? | 12:04 |
| lifeless | pygi: dunno | 12:05 |
| pygi | hhhhm | 12:06 |
| pygi | stbuehler, you know perhaps? :) | 12:06 |
| stbuehler | i did not use submodules myself yet, i only have to deal with them for debian cgit packaging | 12:07 |
| jelmer | pygi: depends on what you mean by weak | 12:07 |
| jelmer | pygi: they're less integrated into the core commands than the bzr subtrees afaiu | 12:08 |
| pygi | jelmer, right... | 12:17 |
| mgedmin | files named *.~1~ and *.~2~ -- bzr debris? | 14:08 |
| jelmer | mgedmin: hi | 14:09 |
| jelmer | mgedmin: yeah, bzr revert creates those files | 14:09 |
| mgedmin | hi, jelmer | 14:09 |
| mgedmin | ah, revert | 14:09 |
| jelmer | mgedmin: you can use --no-backups to prevent it from creating those files | 14:09 |
| mgedmin | use case: user cd's to a project working dir, types bzr st to make sure it's clean, types ls to look around and is scared by files named *.~1~ | 14:10 |
| mgedmin | I honestly thought there was a failed merge with conflicts or something | 14:10 |
| mgedmin | but then remembered bzr uses .THIS and .THAT or something like that | 14:10 |
| jelmer | a lot of editors also use files ending in ~ to indicate backups | 14:10 |
| mgedmin | ... I don't remember running bzr revert on at least some of those files | 14:10 |
| mgedmin | vim doesn't | 14:11 |
| jelmer | mgedmin: if you "set backup" it will | 14:11 |
| mgedmin | "sample-graph.png.~1~" -- I'm pretty sure I didn't edit it with a *text* editor | 14:11 |
| mgedmin | oh, right -- this thing (lp:objgraph) was created by the setup.py script | 14:11 |
| mgedmin | I might've run bzr revert on it | 14:11 |
| * mgedmin looks at his sentence and wonders if it can be understood by anyone else | 14:12 | |
| mgedmin | there's a project (lp:objgraph) with a README.txt that generates graphviz graphs and wants to include sample images | 14:13 |
| mgedmin | so the setup.py has a couple of lines to extract the doctests from the README and pipe the output through dot to produce pngs | 14:13 |
| mgedmin | ... iirc | 14:13 |
| mgedmin | it's a bit of a hack, really | 14:14 |
| mgedmin | I must've run it several times (to produce new images), which overwrote some of the original images, which bzr probably noticed (png has creation time as metadata inside?) and I reverted | 14:15 |
| vila | mgedmin: have a look at 'bzr help clean-tree', experiment with bzr clean-tree --dry-run | 14:15 |
| mgedmin | thanks | 14:19 |
| mgedmin | so, I've some code in my working tree I want to check in and push to a new branch on launchpad without touching the old branch | 14:23 |
| mgedmin | what should I do? | 14:23 |
| mgedmin | in git/svn I'd create a new branch, switch in-place, then commit | 14:23 |
| hsn_ | is there way to remove branch/project from launchpad? i would like to use lp for converting CVS into bzr | 14:24 |
| james_w | is it just me that finds the last shelve question defaulting to "No" really odd? | 14:36 |
| james_w | and also infuriating at times? :-) | 14:36 |
| jelmer | james_w: no, it's not just you | 14:37 |
| jelmer | I tend to want to shelve just one piece of code often | 14:37 |
| jelmer | so I press "n" until I get there, then press y a couple of times | 14:37 |
| jelmer | and then enter my way until the end | 14:37 |
| jelmer | but often I hit enter one time too much | 14:37 |
| james_w | yeah | 14:39 |
| james_w | it's not a destructive operation | 14:39 |
| james_w | at least not with --destroy | 14:39 |
| mgedmin | how do I make bzr forget the last push location? ie. make bzr status not show a push branch? | 15:24 |
| * mgedmin is about to edit .bzr/branch/branch.conf with trepidation, there's a scary "do not touch anything here" notice in .bzr/README | 15:25 | |
| vila | mgedmin: you can use 'push --remember <new_location>' to replace the existing one but you can't *clear* the existing one | 15:28 |
| * mgedmin dislikes | 15:29 | |
| Tak | can you remember '.'? | 15:29 |
| mgedmin | interesting question | 15:30 |
| * Tak master of hackish workarounds | 15:31 | |
| mgedmin | yes you can | 15:32 |
| mgedmin | "no new revisions to push" | 15:32 |
| mgedmin | hey, my bzr ci --fixes lp:NNN appears to have silently ignored the '--fixes lp:NNN' bit, what gives? | 15:43 |
| beuno | mgedmin, no, it's stored as meta-data | 15:44 |
| beuno | not sure how you can see it with the bzr client | 15:44 |
| beuno | but if you push to Launchpad | 15:44 |
| beuno | you'll see Launchpad will link that bug with that branch | 15:44 |
| mgedmin | oh, user error: bzr ci --fixes; look at list of files; abort; bzr revert file1 file2; bzr ci<enter> | 15:45 |
| NfNitLoop | mgedmin: oops! | 15:47 |
| NfNitLoop | :) | 15:47 |
| NfNitLoop | huh, I didn't know about the --fixes flag. that's cool. | 15:48 |
| mgedmin | yeah, well, I still blame bzr :) | 15:48 |
| === Tak|work is now known as Tak | ||
| glen__ | does anyone know how to use bzr-gtk? I have it installed but no clue how to "use" it | 16:01 |
| === glen__ is now known as billybob | ||
| === billybob is now known as fizzy | ||
| === fizzy is now known as fizzyone | ||
| fizzyone | hello | 16:03 |
| beuno | fizzyone, run: bzr-gtk | 16:03 |
| beuno | in your terminal | 16:03 |
| fizzyone | that is what I thought | 16:03 |
| mgedmin | not changing your nickname every 3 seconds might work better if you want an answer | 16:03 |
| beuno | in the directory where you have a branch | 16:03 |
| fizzyone | no command found | 16:03 |
| beuno | fizzyone, actually, ignore that | 16:03 |
| beuno | you should have new commands in bzr | 16:03 |
| fizzyone | sorry about that... just wrestling with the client | 16:03 |
| mgedmin | bzr viz is one of the commands provided | 16:03 |
| beuno | "bzr help" | 16:03 |
| mgedmin | I've never used any of the others (assuming there are some, which there probably are) | 16:04 |
| beuno | you've also got gcommit | 16:05 |
| beuno | again, 'bzr help commands' should say | 16:05 |
| fizzyone | awesome thanks | 16:05 |
| fizzyone | I have the gui up now | 16:05 |
| beuno | all the g* stuff is bzr-gtk | 16:05 |
| mgedmin | launchpad rules | 16:10 |
| beuno | it does! | 16:11 |
| === trmanco_ is now known as trmanco | ||
| jelmer | vila: ping | 17:51 |
| marcoil | Hi, while commiting to a svn server I get "bzr: ERROR: Please upgrade your Subversion client libraries to 1.5 or higher to be able to commit with Subversion mapping v4", although I do have libsvn 1.5.1 | 17:54 |
| vila | jelmer: pong (not really there so except high lag:) | 17:56 |
| vila | s/except/expect/ | 17:56 |
| jelmer | marcoil: you have 1.5.1 locally ? | 17:58 |
| jelmer | marcoil: is subvertpy linked against 1.5.1? | 17:58 |
| jelmer | vila: I'm trying to think of a way to avoid that 401 on POST | 17:58 |
| marcoil | jelmer: libsvn1 1.5.1dfsg1-1ubuntu2 | 17:59 |
| marcoil | jelmer: how do I check what's subvertpy linked against? | 18:00 |
| marcoil | jelmer: in any case, it's the one in the bzr ppa for hardy | 18:01 |
| jelmer | marcoil: what is the server running? | 18:05 |
| marcoil | jelmer: 1.4, I'm afraid | 18:06 |
| jelmer | marcoil: hmm | 18:07 |
| jelmer | marcoil: that might have something to do with it | 18:07 |
| marcoil | jelmer: it did work last week, I'm sure of it, but I'm not sure which packages I've updated since | 18:08 |
| vila | jelmer: hmm, 401 should be ConnectionError, I don't they are yet. From there.... ConnectionErrors may/should (need to be discussed ?) be translated into NotAbranch errors during probes... or something like that, but that should still allow prompting user :) | 18:09 |
| jelmer | marcoil: no idea which things are out of date, sorry :-/ | 18:11 |
| jelmer | marcoil: it does work, but you probably need to upgrade some of the packages on your client machine | 18:11 |
| jelmer | vila: so we'd have to do two passes or something like that? | 18:11 |
| marcoil | jelmer: I'm trying to compile subvertpy, let's see if that works | 18:11 |
| vila | jelmer: I didn't look closely at the code since that mail thread, I'm not sure doing two passes (one without auth one with) is the way to go (ISTR that we probe recursively until root for some cases, so we already have a two-dimensions probe...) | 18:13 |
| marcoil | jelmer: manually compiling and installing subvertpy 0.6.5 did the trick! thanks | 18:15 |
| jelmer | marcoil: np | 18:16 |
| vila | jelmer: may be the solution is to change or allows changes to the probe mechanism, I'm not that sure we can address all the funny ways an http server can be configured.... | 18:16 |
| jelmer | vila: yeah, that's what I'm worried about too | 18:17 |
| jelmer | vila: the quick solution for now is to probe for svn repositories before bzr repositories | 18:17 |
| vila | I thought the quickest was to use nosmart+ :-) | 18:18 |
| jelmer | vila: nosmart doesn't work, though svn+http does | 18:19 |
| vila | jelmer: ? You got POST with nosmart+ ??? | 18:19 |
| vila | that's a bug in nosmart then | 18:20 |
| jelmer | vila: no, nosmart doesn't trigger svn | 18:20 |
| vila | that's a bug too ! | 18:20 |
| jelmer | it would even be wrong if that worked since svn is a smart server protocol too ;-) | 18:21 |
| vila | jelmer: ha come on :-) Anyway dinner time here, I may come back later, but I think what we need is a better control of what probe does, being auto should remain the default, but having some way to tweak it by remote server will be needed in the end (whatever the smarts we put in the auto mode) | 18:22 |
| vila | jelmer: ... and nosmart+ and svn+http are just two examples of why this is needed... | 18:32 |
| jelmer | vila: re | 18:45 |
| jelmer | vila: yeah, we do indeed need better control of probe | 18:45 |
| jelmer | vila: also, for svn it's only necessary to probe the bottom-layer | 18:45 |
| jelmer | vila: if /foo/bar/bloe/bloe is not a svn smart server then even if we can open /foo/bar/ it won't be a valid path | 18:46 |
| jelmer | :q | 18:52 |
| vila | jelmer: violent agreement I see :) | 18:59 |
| ddaa | Hey jelmer | 19:01 |
| ddaa | I'm having trouble using bzr-hg. | 19:01 |
| ddaa | I have hg branch here, that I can do "hg st" in. | 19:01 |
| ddaa | And I have trunk bzr-hg from launchpad with bzr 1.13.1 from jaunty. | 19:02 |
| ddaa | But the branch directory (that contains the .hg directory) is not recognized by bzr as a branch. | 19:03 |
| ddaa | (In case jelmer is unavailable at the time, anybody with a clue is welcome to help, too) | 19:03 |
| jelmer | ddaa: hi | 19:04 |
| ddaa | hi jelmer | 19:06 |
| ddaa | I'm afraid I'm not going to be able to follow up on the test for bzr-svn. I have just quit that job at the bank. | 19:06 |
| ddaa | Any suggestion how to debug that problem with bzr-hg? | 19:07 |
| ddaa | I have a special hate for branch detection problems, they provide no feedback at all besides "NotABranch, get stuffed". | 19:08 |
| ddaa | s/NotABranch/NotBranchError/ | 19:08 |
| jelmer | ddaa: pushed a fix | 19:08 |
| jelmer | ddaa: yeah, the probe stuff could use some improvement | 19:09 |
| jelmer | ddaa: was just talking about that with vila :-) | 19:09 |
| ddaa | Did you push on bzr+ssh://bazaar.launchpad.net/~bzr/bzr-hg/trunk/ ? | 19:09 |
| ddaa | Because the last commit I see there is "merge new bzr-foreign" date Sun 2009-03-22 00:33:57 +0100. | 19:11 |
| jelmer | ah, no - pushed to my private repo | 19:11 |
| jelmer | pushing to lp now | 19:11 |
| jelmer | done | 19:11 |
| jelmer | please be aware that bzr-hg is still highly experimental, moreso than bzr-svn or bzr-git :-) | 19:11 |
| * jelmer dinner | 19:13 | |
| ddaa | When *I* was a kid, bzr was highly experimental ;( | 19:13 |
| ddaa | I mean ;) | 19:13 |
| ddaa | I just have a one-time import to do. | 19:14 |
| ddaa | Gotta go offline. | 19:14 |
| ddaa | BBL | 19:14 |
| rotty | can I move a shelved collection of changes to another repo? | 19:47 |
| LarstiQ | rotty: I don't know if/how to do that directly | 19:48 |
| LarstiQ | rotty: but in combination with `bzr unshelve; bzr merge --uncommitted; bzr shelve` you could do something like it | 19:49 |
| LarstiQ | jelmer: do you know what the impact of Standard-Version: 3.8.1 is on Ubuntu packaging? | 19:51 |
| LarstiQ | it looks to me like I should stick with 3.8.0 | 19:52 |
| LarstiQ | jelmer: any reason you're not using compat level 7? | 19:54 |
| rysiek|pl | hi guys | 20:03 |
| rotty | LarstiQ: this doesn't cut it if the repo is on another machine: bzr merge --uncommitted bzr+ssh://192.168.10.1/home/rotty/src/tekuti/r6rs | 20:04 |
| rotty | bzr: ERROR: bzr+ssh://192.168.10.1/home/rotty/src/tekuti/r6rs/.bzr/ is not a local path. | 20:05 |
| LarstiQ | rotty: right | 20:05 |
| rysiek|pl | guys, does bzr support https? | 20:05 |
| rysiek|pl | as in | 20:06 |
| rysiek|pl | bzr co https://example.com/bzr/project/branch | 20:06 |
| LarstiQ | rotty: if you're feeling very adventurous you could try copying .bzr/checkout/shelf | 20:06 |
| LarstiQ | rysiek|pl: yes | 20:06 |
| LarstiQ | rotty: but that's mucking with the internals, so no guarantees there | 20:06 |
| rysiek|pl | hmmm... | 20:07 |
| rotty | seems I must branch into a full blown repo do the --uncommited merge, rsync that whole repo over, and merge --uncommited again, or transfer a diff and do the metadata changes by gand | 20:07 |
| LarstiQ | rysiek|pl: maybe you have a more pointed question? :) | 20:07 |
| LarstiQ | rotty: eh no, that's very suboptimal | 20:08 |
| rysiek|pl | LarstiQ: deugging my apache+bzr installation, I'll try managing myself, but thanks ;) | 20:08 |
| rotty | hmm, I could also use commit/uncommit | 20:08 |
| rysiek|pl | LarstiQ: although if you know of any specific requirements bzr has in regards to read-only access to a branch through apache2, please do tell | 20:08 |
| LarstiQ | rysiek|pl: read-only? You could get away with just using file backing for apache. Bit slower than possible, but very low on requirements. | 20:10 |
| LarstiQ | rotty: the shelved changes aren't fit for commit yet? | 20:11 |
| rysiek|pl | LarstiQ: exactly what I am trying to do | 20:11 |
| rysiek|pl | $ bzr co https://brama.elka.pw.edu.pl/bzr/parkour/AltiShock | 20:11 |
| rysiek|pl | bzr: ERROR: Not a branch: "https://brama.elka.pw.edu.pl/bzr/parkour/AltiShock/". | 20:11 |
| rotty | LarstiQ: yes | 20:11 |
| rysiek|pl | aaargh | 20:11 |
| rysiek|pl | nevermind, I am dumb beyond recognition | 20:11 |
| rotty | it's only one incomplete changeset | 20:12 |
| rotty | (moving ongoing development from laptop to desktop) | 20:12 |
| LarstiQ | rotty: commit/uncommit actually isn't that bad an idea to transfer them | 20:12 |
| rotty | LarstiQ: I've done so now. | 20:12 |
| rysiek|pl | LarstiQ: works AOK now. | 20:13 |
| * rysiek|pl bangs his head agains a nearby wall | 20:13 | |
| * rysiek|pl does that - repeatedly | 20:13 | |
| LarstiQ | rysiek|pl: awww :) | 20:14 |
| rysiek|pl | LarstiQ: using *nixes for 5+ years now and *still* run into those dumb lowercase/uppercase problems | 20:15 |
| ronny | being conservative at naming files helps | 20:20 |
| ronny | all things i do end up with lowercase alhpanum + spaces/dashes/underlines/points | 20:21 |
| * LarstiQ tries to stay away from spaces. | 20:22 | |
| ronny | LarstiQ: those are for non-code things i dont track in a vcs | 20:23 |
| LarstiQ | ronny: I grudgingly admit them in .ogg files, but as a shell user I'm leary of abusing the token seperator. | 20:25 |
| ronny | LarstiQ: well, all stuff i consider important is in safe filenames | 20:26 |
| beuno | man, bb hates me | 20:39 |
| bpierre | hi | 20:44 |
| bpierre | I'm testing EOL support in bzr.dev, and I'm having issues | 20:45 |
| bpierre | my test can be seen here: http://pastebin.com/m6b49c245 | 20:45 |
| beuno | jelmer, we should go into a merging spree for bzr-gtk soon :) | 20:47 |
| beuno | I keep wanting to do that | 20:47 |
| jelmer | LarstiQ: I don't think there was anything particularly important in 3.8.1 | 20:48 |
| jelmer | LarstiQ: so makes sense to stay with 3.8.0 | 20:48 |
| LarstiQ | jelmer: I'm guessing you switched to silence lintian? ;) | 20:48 |
| jelmer | LarstiQ: which package? | 20:48 |
| LarstiQ | bzr-svn | 20:49 |
| bpierre | updated test: http://pastebin.com/m503e6b6f | 20:49 |
| jelmer | LarstiQ: that's lintian-clean on sid | 20:55 |
| jelmer | LarstiQ: what sort of errors are you getting? | 20:56 |
| LarstiQ | beuno: bzr-svn 0.5.4 uploaded to bzr-beta-ppa in case you want to test it. It's still Pending publishing. | 20:57 |
| LarstiQ | jelmer: oh I'm getting none. | 20:57 |
| LarstiQ | jelmer: Just inspected the diff, and noticed 3.8.1 is very recent. | 20:57 |
| beuno | LarstiQ, on my hardy server? | 20:58 |
| LarstiQ | beuno: yes please | 20:58 |
| beuno | LarstiQ, sure. Will try as soon as it publishes. What was that svn I could use to test again ? | 20:58 |
| LarstiQ | beuno: svn://svn.gnome.org/svn/gnome-specimen/trunk | 21:00 |
| * beuno waits for PPAs' cron to run | 21:00 | |
| LarstiQ | jelmer: do you think I should look into gutsy and dapper too? | 21:01 |
| jelmer | LarstiQ: dapper will be hard as it has the old python infrastructure | 21:05 |
| jelmer | I'm not sure about gutsy - are there still many people running it? | 21:05 |
| LarstiQ | johnf built packages for them | 21:06 |
| beuno | LarstiQ, it seems to me working perfectly. Taking a while to copy the revisions, but no explosions | 21:08 |
| LarstiQ | beuno: for that I direct you to either jelmer, the svn repo admins, or your isp ;) | 21:08 |
| LarstiQ | beuno: thanks! | 21:08 |
| LarstiQ | jelmer: have you seen this specific KnitCorrupt error before http://rafb.net/p/Uq2Hw948.html ? | 21:10 |
| jelmer | LarstiQ: nope | 21:13 |
| === beuno_ is now known as beuno | ||
| LarstiQ | bpierre: did you make any EOL progress? | 22:02 |
| bpierre | LarstiQ: nope, files are correctly changed to CRLF, but my problem is they show as modified | 22:05 |
| LarstiQ | bpierre: sounds like a bug | 22:06 |
| bpierre | yeah, it makes EOL unusable | 22:06 |
| * LarstiQ will peek at EOL status tomorrow, sleep now | 22:07 | |
| bpierre | I'm going to enter a bug with my test script | 22:07 |
| bpierre | can I put rules somewhere not in ~/.bazaar/rules? or does it always have to be this file? | 22:09 |
| jam | bpierre: there is discussion on how to handle per-tree sort of rules, *right now* we only have the global rules | 22:13 |
| jam | also, what format are your files *now* | 22:13 |
| jam | and what are you setting eol to? | 22:13 |
| bpierre | jam: http://pastebin.com/m503e6b6f | 22:14 |
| bpierre | the format of the files is what I expect | 22:14 |
| bpierre | the problem is status/diff showing them as modified | 22:14 |
| jam | bpierre: IIRC, crlf == crlf in the working tree *and* in the repository | 22:15 |
| jam | I think you want | 22:15 |
| jam | crlf:lf | 22:15 |
| jam | or "native" but on your current system, I think native == lf | 22:15 |
| bpierre | mmm, are you sure? I'm using the latest help | 22:15 |
| bpierre | bzr help eol | 22:15 |
| bpierre | crlf:lf was the previous proposed format | 22:16 |
| jam | I see what you mean, that was just the last I saw on the discussion | 22:16 |
| jam | I'll check the internal | 22:16 |
| jam | internals | 22:16 |
| jam | I know there was a bug where the eol stuff wasn't getting loaded | 22:16 |
| bpierre | yeah | 22:16 |
| jam | I'm not sure how that compares with the version of bzr you are testing | 22:16 |
| bpierre | I got that with a previous version | 22:16 |
| bpierre | it works now | 22:16 |
| bpierre | I do see a change in EOL when switching from lf to crlf | 22:17 |
| jam | so.... I do see in the internals that 'crlf' => _to_lf in repo and _to_crlf in tree | 22:17 |
| jam | so that seems right | 22:17 |
| bpierre | how does detection of file changes is handled? | 22:18 |
| bpierre | mtime and sha1? | 22:18 |
| jam | bpierre: I assume this is doing "bzr init --1.14" or whatever, right? | 22:18 |
| jam | bpierre: we use mtime to avoid computing the sha1 | 22:18 |
| jam | but if mtime is updated, we should then be computing the sha1 of the text as it would be put in the repo | 22:19 |
| bpierre | so the problem is content filtering needs to be applied before calculating the sha1 | 22:19 |
| bpierre | no? | 22:19 |
| bpierre | or cache both sha1 (lf and crlf)L | 22:19 |
| bpierre | s/L/? | 22:19 |
| bpierre | because, at the end of the test, if I do a dos2unix on my file, then it's not modified anymore | 22:20 |
| jam | bpierre: when we see an mtime miss, we should read the file and apply the filter | 22:20 |
| bpierre | or rather it doesn't appear as modified | 22:20 |
| jam | and hash the result | 22:20 |
| jam | I know I've seen the patch that was supposed to change it | 22:21 |
| bpierre | and compare to the repo sha1? | 22:21 |
| jam | we may have missed something | 22:21 |
| jam | bpierre: right | 22:21 |
| jam | bpierre: out of curiosity, have you done "make" in your version of bzr? | 22:21 |
| bpierre | mmm, I do: for cmd in config build "install --prefix=$HOME/progs"; python ./setup.py ${(s| |)cmd} | 22:21 |
| bpierre | I checked earlier, and seems some C files are getting compiled | 22:22 |
| bpierre | do I really need to do a make? | 22:22 |
| jam | shouldn't have to, 'install' should do 'build' etc | 22:22 |
| jam | you should see .so files in bzrlib | 22:22 |
| bpierre | ah | 22:22 |
| bpierre | make did something! | 22:22 |
| jam | bpierre: make builds locally | 22:22 |
| jam | you can run bzr directly from the source dir, without installing | 22:23 |
| jam | the .so files I'm talking about should be somewhere in $HOME/progs | 22:23 |
| bpierre | ok, so I should have everything | 22:23 |
| jam | or run from source | 22:23 |
| jam | :) | 22:23 |
| jam | anyway, eol *should* work with or without compiling | 22:23 |
| jam | I just wanted to check, as there are 2 code paths | 22:23 |
| bpierre | ok | 22:24 |
| jam | bpierre: can I ask you to run from source, so I can ask you to do some minor tweaks? | 22:25 |
| bpierre | sure | 22:25 |
| bpierre | I just need to set PYTHONPATH ? | 22:25 |
| jam | http://pastebin.com/m5a2c1d93 | 22:25 |
| jam | bpierre: ~/path/to/bzr status | 22:26 |
| jam | no need to set anything | 22:26 |
| jam | just give the full path to the bzr | 22:26 |
| jam | you can set PATH if you want to make it shorter | 22:26 |
| jam | or you could just set $(BZR) in your script | 22:26 |
| jam | etc | 22:26 |
| bpierre | ok | 22:26 |
| bpierre | jam: http://pastebin.com/m4bb3a281 | 22:29 |
| jam | bpierre: something seems to be wrong with your rules, etc after the second co | 22:31 |
| jam | note that it doesn't give the filters during 'checkout' like it did the first time | 22:32 |
| bpierre | ? | 22:32 |
| jam | bpierre: line 19 | 22:32 |
| jam | well 18 + 19 | 22:32 |
| jam | versus 31 | 22:32 |
| jam | during the "bzr co" I see "computing stat_and_sha1 ...." | 22:33 |
| bpierre | yeah, but they are applied somewhere | 22:33 |
| jam | but I *don't* see that in the second half | 22:33 |
| bpierre | since the content changes to CRLF | 22:33 |
| jam | bpierre: sure, can you try doing a "touch test/work/text" ? | 22:33 |
| jam | just to force the mtime to change | 22:33 |
| jam | (followed by "bzr status test/work" | 22:33 |
| jam | ) | 22:33 |
| jam | bpierre: Also, if I understand your result, it claims that "text" is modified, but then shows *0* line changes, right? | 22:34 |
| bpierre | ok, I just tried to remove the file and then revert it | 22:34 |
| bpierre | and it's now lf | 22:34 |
| bpierre | jam: yes, no changes in the diff | 22:34 |
| jam | bpierre: so it seems the hash check is missing but the content itself is getting filtered | 22:36 |
| bpierre | it's weird, revert doesn't seem to apply the filter | 22:37 |
| bpierre | I changed for a non-lightweight checkout, to test a remove-tree+co | 22:37 |
| bpierre | and the file dosn't change to crlf | 22:37 |
| sabdfl | well done folks | 22:37 |
| sabdfl | commit on bzr.dev seems fantastically faster | 22:38 |
| sabdfl | lifeless told me why the perf improvement hasn't trickled down to commit file1 file2 file3 | 22:38 |
| sabdfl | but i thought i should say what a great impression this will make when it lands as the default format | 22:39 |
| lifeless | morning sabdfl | 22:41 |
| ddaa | indeed it will be great when the standard answer to "bzr is too slow" will involve neither "you need to use the very very latest release from last week" nor "you need to use the latest non-default archive format, trust me, it's reliable". | 22:47 |
| ddaa | actually, it will be great when people stop saying "bzr is too slow", but I expect this meme is going to take a few years to die out. | 22:48 |
| sabdfl | lifeless: does the new commit still do, effectively, status-then-commit? | 22:52 |
| jam | sabdfl: I believe it acts effectively like: for entry in status: record(entry) | 22:59 |
| sabdfl | where "entry" is "something changed or added"? | 22:59 |
| jam | sabdfl: right | 22:59 |
| sabdfl | ok, so it's doing all the work of status, then recording | 22:59 |
| jam | right. I don't quite remember why partial commits weren't faster | 23:00 |
| sabdfl | what's cool is that the time delta for status vs commit is really negligible on large trees now | 23:00 |
| sabdfl | jam: something to do with iter_changes needing a spit and polish | 23:00 |
| kkubasik | I was wondering, we have a bzr tree that has some (relatively large) binary files tracked in it | 23:00 |
| kkubasik | they don't change very often, and its not a big deal | 23:00 |
| kkubasik | but they seem to have majorly impacted the performance of most operations | 23:01 |
| kkubasik | any advice/suggestions | 23:01 |
| kkubasik | will bzr pack help? | 23:01 |
| sabdfl | if this is all true, then any improvements to status will be highly visible, they straight to the commit bottom line | 23:01 |
| sabdfl | kkubasik: doesn't hurt to try that | 23:01 |
| sabdfl | i believe the new format would help more though, try that and report back | 23:01 |
| kkubasik | I had read that people shouldn't run 'pack' just wanted to be sure ;) | 23:02 |
| pygi | :P | 23:02 |
| kkubasik | which format? | 23:02 |
| sabdfl | kkubasik: bzr branch lp:bzr bzr.dev | 23:02 |
| pygi | kkubasik, development6-rich-root | 23:02 |
| sabdfl | inside there, make | 23:02 |
| sabdfl | then use that bzr to make a new branch of your code | 23:02 |
| kkubasik | will do | 23:03 |
| kkubasik | 1 sec | 23:03 |
| sabdfl | and upgrade that to what-pygi-said | 23:03 |
| thumper | hi sabdfl | 23:03 |
| sabdfl | then try a few commits in there for fun | 23:03 |
| sabdfl | howdy thumper | 23:03 |
| beuno | kkubasik, how large are the files? | 23:03 |
| jam | kkubasik: I'm not sure why you "shouldn't run 'pack'" | 23:03 |
| beuno | kkubasik, also, if you're on Ubuntu, you can get the latest bzr from a PPA: https://edge.launchpad.net/~bzr-nightly-ppa/+archive | 23:03 |
| kkubasik | beuno: Not massive, 2 30MB .air files | 23:03 |
| jam | It shouldn't be something you *need* to do, but there shouldn't really be harm in it. | 23:03 |
| pygi | sabdfl, is "what-pygi-said" a new name for a bzr format? :D | 23:04 |
| kkubasik | and 4 mpeg4's | 23:04 |
| sabdfl | could be. dontcha love plugins :-) | 23:04 |
| jam | the bigger question is what was actually "majorly impacted" | 23:04 |
| pygi | I'll start loving them once jelmer renames local-branches to duck branches :p | 23:04 |
| jam | stuff like "branch" I could understand | 23:04 |
| jam | stuff like "bzr status" shouldn't be effected | 23:04 |
| jam | (much) | 23:04 |
| kkubasik | jam: primarily commit and stat | 23:05 |
| beuno | but, pull/merge will, because it brings in almost the full binary | 23:05 |
| kkubasik | not incredably | 23:05 |
| kkubasik | but like, i notice a pause now | 23:05 |
| jam | kkubasik: what platform? | 23:05 |
| kkubasik | and when the disk is being thrashed, you notice it much more ;) | 23:05 |
| kkubasik | ubuntu (last LTS) and mac os x 10.5 | 23:05 |
| jam | I at least get the feeling that somehow we are missing a mtime cache, which is causing us to read the file and compute its sha1 again. | 23:05 |
| jam | can you do a "stat" on the file and see if there is something strange | 23:06 |
| jam | like its timestamp is set 3 days in the future | 23:06 |
| * spiv yawns | 23:06 | |
| kkubasik | jam: yeah will do, actually, cool if i bring this on the mailing list | 23:07 |
| lifeless | sabdfl: the new commit is layered on the same generate that status is layered on | 23:07 |
| kkubasik | I gotta run, but would love some help | 23:07 |
| jam | kkubasik: sure | 23:07 |
| jam | I'll mention that it will take a bit longer to diagnose on the list, because of latency :) | 23:07 |
| lifeless | jam: partial commits depend on iter_changes returning parents of new entries | 23:07 |
| lifeless | s/generate/generator/ | 23:08 |
| kkubasik | jam: many thanks! | 23:08 |
| jam | lifeless: ah right, I remember the thread now | 23:08 |
| lifeless | sabdfl: thinking of it as status + commit is fine; though we skip the status UI code when doing a commit | 23:09 |
| lifeless | sabdfl: for instance, in status we need to diff two files when there is a stat cache miss, so if we actually did layer on status we'd end up doing more sha calculations; because we just sharing the core worker | 23:10 |
| lifeless | we just know that that file *may* have changed, and instead pass the content down to the storage layer with a flag saying 'and if it is this sha1, dont store it' | 23:10 |
| lifeless | sabdfl: what size tree are you testing on? | 23:11 |
| sabdfl | lifeless: you know my benchmark | 23:17 |
| sabdfl | 1k, 5k, 10k, 50k, 100k files | 23:17 |
| lifeless | yup | 23:19 |
| lifeless | I remember we went sour > 10K | 23:20 |
| lifeless | I'm wondering if that is still the case | 23:20 |
| === RAOF_ is now known as RAOF | ||
| BasicOSX | bzr.dev revision 4294 throws all sorts of error, reported in bug 362021 | 23:21 |
| ubottu | Launchpad bug 362021 in bzr "bzr: ERROR: No such file: '<random>.pack'" [Undecided,New] https://launchpad.net/bugs/362021 | 23:21 |
| lifeless | BasicOSX: windows? | 23:22 |
| BasicOSX | osx | 23:22 |
| BasicOSX | testing on linux now | 23:23 |
| lifeless | BasicOSX: tried ulduar out? | 23:24 |
| BasicOSX | heh, guess my bug report points me out as a wow player | 23:25 |
| BasicOSX | Yes, attempted 25-man last night | 23:25 |
| lifeless | either that or its a serious coincidence :) | 23:25 |
| BasicOSX | server stability issues caused us to give up | 23:25 |
| lifeless | we had a 2 hour break while they rebooted it | 23:25 |
| lifeless | got flame down before hand, had trouble with both xt and razor | 23:26 |
| lifeless | BasicOSX: you're missing the directory upload | 23:26 |
| BasicOSX | hmm, I did not do anything but install new addon, bzr add, bzr commit | 23:27 |
| lifeless | mkdir the upload directory | 23:27 |
| lifeless | try again | 23:28 |
| beuno | spiv, has the AbsentContentFactory fix landed in bzr.dev yet? | 23:32 |
| lifeless | beuno: yes | 23:33 |
| lifeless | beuno: remember you need to repush branches to fix them | 23:33 |
| lifeless | beuno: the fix only stops bzr *creating* the situation, it doesn't let it deal with it | 23:33 |
| beuno | lifeless, ah! that's the second part that's in progress? | 23:33 |
| lifeless | beuno: no | 23:34 |
| lifeless | beuno: there is no deal with it planned | 23:34 |
| beuno | lifeless, uhm, why not? if bzr 1.13 deals with it just fine? | 23:34 |
| lifeless | beuno: andrew is now working on a fix for the server to get unfixed clients to upload more data | 23:34 |
| lifeless | beuno: 1.13 does not deal with it | 23:34 |
| lifeless | beuno: 1.13-client just does not call the verb when pulling from stacked branches | 23:35 |
| beuno | I half-understand | 23:35 |
| beuno | the end result is that I can pull/branch from it | 23:36 |
| lifeless | beuno: but the change to the server will not affect people that don't stream up, or use sftp | 23:36 |
| spiv | beuno: older clients don't ask the server to stream a set of revisions from a branch | 23:36 |
| beuno | ah, I see | 23:36 |
| lifeless | beuno: do you want to understand? if so, details coming.. | 23:36 |
| beuno | lifeless, no, gotcha | 23:36 |
| spiv | beuno: which means the client is executing that logic, and the client has access to the fallback repository, which means it can calculate all the data | 23:36 |
| beuno | adding a check for that specific case to not stream is not very wise overhead | 23:36 |
| lifeless | beuno: basically there is a design flaw in stacking's 'what data goes in the stacking repo' logic since 1.6 | 23:37 |
| lifeless | beuno: that we found when we got 'stream from stacking branches' working | 23:37 |
| beuno | understood | 23:38 |
| lifeless | beuno: we're going to supply a script for lp to run to fixup branches hosted on lp | 23:38 |
| beuno | makes heaps more sense now | 23:38 |
| beuno | perfect | 23:38 |
| beuno | just perfect | 23:38 |
| beuno | thanks for the splainin' | 23:38 |
| lifeless | beuno: you should run nightlies so you don't create bad branches | 23:38 |
| lifeless | but there is nothing you can do about other peoples until we have that fix out and running after people push | 23:38 |
| beuno | lifeless, I do run nightlies, but they break when branching, so I constantly downgrade. I could use sftp, but you know how lazyness works... | 23:39 |
| lifeless | beuno: when you find something you can't branch from, for now, get that person to delete and repush using nightlies | 23:40 |
| beuno | will do | 23:40 |
| poolie | hello | 23:53 |
| pygi | poolie, hi | 23:54 |
| pygi | did you ever get a chance to read that short excerpt I gave you? | 23:54 |
| poolie | hey there | 23:54 |
| poolie | i didn't get to it before i left on holidays but it's high on my list today | 23:54 |
| poolie | sorry for the delay | 23:54 |
| pygi | hehe, no worries | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!