[00:02] At least Freenode isn't read-only too. :D [00:03] hahaha [00:23] is there a standard Python way of parsing a __version__ string like '1.5.1'? [00:27] jml: parsing in to parts, or parsing for comparison? [00:27] I think the standard way would be to beat the originating app over the head until it provides a version tuple [00:27] comparison [00:27] jml, not that i know of but there is often a tuple-based version [00:28] you can compare it as a Debian version number, but modules for that aren't likely to be available everywhere [00:28] I don't know of a standard python one [00:28] ok, thanks guys. [00:28] * jml proceeds to beat the app over the head [00:29] oh crap [00:29] launchpad is going to make that hard [00:32] * jml splits and map ints for the time being [01:07] jam: Is there supposed to be a test in lp:~jameinel/bzr/2.0.4-495000-win32-autopack? Cuz there ain't. [01:17] you know [01:17] bzrlib is nice [01:18] it's a bit of a wart that there are errors with "NotFound", "NotPresent" and "Missing" in their names. [01:19] jml: Also, "Absent" [01:20] jml: But we're lacking an error with "Lacking" [01:22] spiv, good catch. [01:23] are those at least subclasses of lookuperror? [01:23] raise errors.LackingConfusingErrorClass. [01:23] ;D [01:23] ronny, no, I don't think so. [01:23] ronny, and I'm not sure they should be. [01:24] hmm, it woud certainly give more meaning [01:24] man [01:25] ronny, e.g. DependencyNotPresent -- is that _really_ a lookup? [01:25] jml: im not yet at that one [01:26] I'd be pretty hesistant to use LookupError for anything that wasn't implementing the __getitem__ operator [01:26] jml: but for example NoSuchId/NoSuchIdInRepository [01:26] spiv, yeah [01:27] spiv, I've never really found much value in rich exception hierarchies anyway, still less ones inheriting from the stdlib exceptions. [01:27] Yeah. [01:27] i like to put more meaning in things [01:28] ronny, I like motherhood and apple pie. [01:29] i grender-missmatch for the first one, but i agree on the second one [01:37] how can I tell bzr which key to use to sign revisions? [01:40] spiv, may I encourage you to do something about https://code.edge.launchpad.net/~spiv/pyflakes/detect-broken-string-formatting/+merge/580 [01:40] jml: you may [01:40] spiv, If you do something about your pyflakes branch, you will help thousands. [01:41] onox: hmm, not sure. Maybe you can specify it on the command line in the gpg_signing_command option in bazaar.conf? [01:58] poolie: are you happy with my fixes to the subunit branch? === mario_ is now known as pygi [02:50] lifeless: i haven't reread your patch but based on what you said it sounds good === mwhudson_ is now known as mwhudson [02:54] python-testtools is in the bzr beta ppa [02:54] for hardy intrepid jaunty karmic [03:00] is there a test decorator for feature availability. [03:01] no [03:01] either set _test_needs_features [03:02] or call self.requireFeature(feature) [03:03] thanks. [03:03] spm: you have mail; I suspect you can't do it? can pjdc? [03:03] pjdc is away this week [03:05] anything you can do to expedite it would be appreciated ;) [03:06] lifeless: when/where did you send this email? > 5-10 mins ago? [03:06] about that [03:06] you and rt [03:07] I hope this DDos gets shut down soon [03:09] lifeless: tada. arrived. :-) [03:09] lol === arkanes_ is now known as arkanes [03:44] you know what would be cool to do once this branch lands? [03:45] a branch directory service that takes launchpad bug numbers and looks up the corresponding branch [04:01] oh [04:01] yeah [04:01] more useful for push than for pull [04:01] or indeed a bzr command (something like diff -rsubmit: ) that gives you the diff [04:01] spiv, so, patch piloting... [04:01] if i take next week will you do the 1st week back? [04:02] subject to chestbursters [04:02] poolie: sure [04:39] ok. [04:39] one completely distracted day later, I've replied to the last comment on lp-login-oauth-2 [04:39] that only took four hours :( [04:42] * jml -> router replacement [05:33] * jml is back w/ adsl2 goodness. [05:34] remind me, are there any conventions for pqm submit messages? [05:36] Nothing like lp [05:36] we often put our name in [05:37] 'bzr log -n1' would give you a hint :) [05:37] "(author) One line description (#bugnum)" is pretty common. [05:38] jam: aww man, and here's me being proud for RTFMing first :) [05:39] It'd be nice to improve the PQM process enough that the "(author)" bit is unnecessary, probably by making PQM set the author property. [05:39] spiv, that's been discussed in the past. [05:39] spiv, it's philosophically unclear who the author of the merge is. === sdboyer_ is now known as sdboyer [05:40] spiv, and anyway, we should look up the authors of the merged revisions. [05:40] spiv, or at least, that's what I recall from the last time this went round the rounds. [05:41] jml: it's whoever I say it is when I do "bzr pqm-submit --the-author-is=..." :P [05:42] spiv, you're such a relativist. [07:14] All lines of log output:Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.dev [07:15] which branch should I submit to? [07:19] its in the docs [07:25] got to go, anniversary date [07:25] good night [07:26] ciao [07:29] jml: did that help you [07:36] lifeless, not yet. [07:38] lifeless, given that the URL in my error message matches the URL in the docs. [07:42] jml: I'll check with a losa if you *still* have access to that branch, I'm pretty sure there have been some updates when we switched [07:43] well, the assumption here is that you didn't use pqm since you were RM, if you did, I'm wrong :) [07:45] lifeless: You broke my toy >-/ I have persistent failures on babune for hardy, jaunty. karmic, gentoo related to _StringException: lost connection during test [07:45] To be honest, I don't think you (or rather your patch) are directly responsible for that but yet... [07:46] jml: http://bazaar-vcs.org/bzr/bzr.dev isn't in the docs now I think [07:46] The selftest run stops with 4 ERRORs like the above but only after running 4135 tests [07:46] It completes for FreeBSD[78] though [07:48] ugh [07:48] HACKING.txt specifies http://bazaar-vcs.org/bzr/bzr.dev still [07:48] lifeless: You did fix the verbose output for SKIP/XFAIL is was it that random that it doesn't occur anymore ? [07:48] jml: it should be http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev [07:48] vila: it is actually meant to be verbose [07:48] vila: so I deliberately broke it. [07:48] vila: (it will no longer show the backtrace to you) [07:49] lifeless: thanks ! [07:49] the reason it wasn't showing it without --subunit was ... [07:49] that the ui factory was replaced by the tests [07:49] global state ftw [07:49] I read tht in the comment >-/ [07:50] I knew I wasn't comfortable with that global stuff but until it break... [07:50] About ' lost connection during test', any idea about when it could occur ? [07:51] lost connection means [07:51] s/when/& why how anything/ [07:51] subunit saw: [07:51] test: FOO [07:51] EOF [07:51] so, possibilities are: [07:51] endless ;-( [07:53] given the vbox behaviours I'm observing these days... up to a VM responding to a click and then going flat, nothing in any log I can think of, leading to... a reboot :-( [07:53] not flushing a file [07:53] process termination [07:54] what test is it erroring on [07:54] !pate [07:54] !paste [07:54] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic [07:54] On hardy32: http://paste.ubuntu.com/343356/ [07:55] On jaunty64: http://paste.ubuntu.com/343357/ [07:56] On karmic64: http://paste.ubuntu.com/343358/ [07:56] how many cpus does the vm think it has? [07:56] Also on karmic64: http://paste.ubuntu.com/343359/ :-( [07:56] 4 for all 3 [07:57] On gentoo: http://paste.ubuntu.com/343360/ 4 CPUs too [07:59] this is using =fork or =subprocess [07:59] =fork [07:59] so [07:59] try =subprocess [07:59] its worrying similar numbers [08:00] I'd kindof like to see the end of the stream [08:00] does anything show up on stderr? [08:01] Nothing special, but SKIP tests verbose on hardy too :-/ [08:01] does it [08:01] revno 4905 for bzr [08:02] so for that one [08:02] changing addSkip to take details [08:02] is the best way to fix it [08:02] I don't really want to keep tweaking the patch :) [08:03] You landed it so now is not tweaking is writing new ones :-D [08:03] s/is/it's/ [08:04] * vila feels babune citizens will undergo massive reboots just because [08:04] * vila kills one more chicken first [08:04] vila: I haven't landed it [08:04] vila: waiting on pqm to have testtools installed in it [08:05] wowwwwww, backtrack, backtrack [08:05] what you are seeing is bzr.dev without the patch + newer subunit [08:05] Exactly ! [08:05] pfew, I prefer that ! [08:06] sorry for the confusion but suddenly seeing SKIP verbose tricked me [08:06] you are seeing verbose skip because thats what trunk does [08:07] I don't think we should spend time understanding this weird config, unless you're really interested... I'd prefer coming back to the SKIP/XFAIL verbose stuff [08:12] * vila redirects babune to lifeless branch and updates it [08:15] lifeless: it's amazing that mix works on FreeBSD and nowhere else.... new bug family: raising when they want just because they can [08:30] lifeless: http://paste.ubuntu.com/343390/ [08:37] vila: I think its likely an environmental bug [08:38] lifeless: So, SKIP/XFAIL is indeed random [08:38] such as not flushing stdout on _exit [08:38] vila: its very deterministic for me :) [08:38] hehe [08:38] random as in: I don't yet understand when it occurs :) [08:38] when ui_factory != SilentUIFactory [08:39] e.g. always with --parallel [08:39] no, I don't get it when running on saw (the real host for babune, running karmic) [08:40] ha, it may be related to babune's VM *not* running with a tty [08:41] yeah, the karmic VM output contains the versbose part but the karmic host doesn't [08:42] This is going to be a long day... [08:42] Xchat crashing (yes it's yet another VM) [08:42] :P [08:43] Well, thinking more about it, It may be a good idea to keep those outputs anyway, I would prefer to be able to control it via selftest -v, but I won't block on that. [08:44] As long as selftest finally returns success (which it does), it makes sense to be able to see why tests are skipped with more details [09:10] vila: -v has a different reporter [09:10] and in non parallel mode the things don't show anyhow [09:11] Well, I'm not sure these are good reasons to make --parallel=fork a second class citizen :-D [09:12] but its not - we're just making it the same [09:13] Where ? [09:13] Did I miss a commit ? === obstriege is now known as obst [09:25] Is there a way to checkout a branch without creating any .bzr directory at all? [09:28] Jordan_U: no [09:29] vila: 'normal' test runs try to show skip and xfail details, but fail because the ui factory is silent [09:29] lifeless: Thanks [09:29] vila: --parallel succeed at showing it because no tesets run in the parent process [09:29] vila: this disabling the attempt makes it behave the same [09:33] lifeless: this doesn't explain the difference between karmic host and karmic guest, the former being silent and the later being verbose for the *exact* same command 'bzr selftest --parallel=fork', I understand the root cause is highly obscure, I'm just saying some people may be surprised especially if it occurs *only* for --parallel=fork [09:33] I may still misunderstand who and when ui_factory is set and why I can observe such a difference... [09:34] but that's minor [09:34] lifeless: unless there are other tweaks required by others I'm ok to land it as is (with s/log_log/get_log), [09:34] babune is quite happy with that so far [09:35] lifeless: what would you think about a tool that would automatically distribute instant test runs to computers/vm's with different platforms (so each time a developer runs the suite it gets executed on all targets) [09:36] ronny: I think lifeless will point you to babune which is BAzaar BUild botNEt : a set of VM/hosts running the test suite daily :) [09:37] vila: im not talking about dayly runs but instany on demand runs [09:38] ronny: with infinite power you can achieve that, but currently it take ~6 hours wall-time to run on hardy, jaunty, karmic, FreeBSD7, FreeBSD8, gentoo, OSX 10.4, OSX 10.5 [09:38] i.e. one would need something like 24 boxes per platform to get it down to a worthwile timeframe? [09:39] If you got the boxes, I'm happy to provide help to set that up :D [09:40] im not yet the man in the middle on the international money transfer lines [09:40] vila: thanks; I am pushing your log fix now; will land when pqm is fixed ;) [09:40] lifeless: thanks, ETA ? [09:41] seconds [09:41] cool :D [09:41] ronny: so, those tools exist. I recommend using them. [09:41] there are various ones with various forms. [09:41] lifeless: im not aware of some that work for python and work on demand [09:42] so, offhand; bzr selftest --parallel=ec2 is easily tweaked to run different vms [09:42] py.test has a remoting API [09:42] pandokia too [09:42] hudson and other such CI tools have on-demand modes [09:43] lifeless: the py.test one is supposed to be massively changed (cause atm it still used local collect) [09:43] * lifeless has to go. bye [09:43] bye [09:44] hmm, pandokia looks interesting [09:45] its a bit crude [09:46] but I'm considering a subunit2pandokia for folk that want to use it :P [09:47] lifeless: we are trying to outline a new model for py.test distributed testing, with better controll about things like collect/shedule [09:47] ronny: cool; testing-in-python :) [09:47] hmm, right [09:47] a local collector isn't really an issue IMO. [09:47] oh, im actually subscribed to that ml [09:48] lifeless: it is if the collect phase is partially platform-depend [09:48] ronny: btw, subunit 0.0.3 - has structured space for stdout or whatever you want. [09:48] ronny: I may not know what you mean by collect. And while I find this fascinating, I can't focus on this right now - sorry. [09:48] ok [09:48] can you ping me later? [09:49] I'd be delighted to discuss it on the list, or perhaps later [09:49] for me, later may be 12+hours [09:49] so in case of doubt the next day [09:53] well thats the early estimate :O) [09:54] I'm on leave and bumming around etc [10:03] lifeless: hmm, ETA was about ' when pqm is fixed ', that wasn't what your replied to right ? :D [10:12] vila: What do you mean by "hpss remote repositories doesn't raise the warning locally"? [10:12] vila: Which side os "local", the client or server? [10:13] ...Oh, I get it. Since the client side just sees Remote objects, it won't know they're really deprecated... Sorry. I haven't slept much today. [10:14] client, did you observe something different ? [10:16] vila: I don't interact with deprecated repos over the hpss much, so I dunno. Besides, last time I did, _ensure_real was probably much more common. [10:16] My sleepy brain just didn't know what you meant. [10:16] ok. Thanks for caring anyway :) === loxs_wrk is now known as loxs [10:19] vila: I just tested it. I got the warning, but apparently only after VFS access was triggered. [10:19] Peng: can you redo that test with my branch ? [10:19] Erk. [10:20] vila: Does the branch need to be on the client, server or both? [10:21] good question :) [10:21] :( [10:21] Client at least, bonus points if both, extra bonus points for server only :) [10:25] ...Do I need to actually use the new setting? [10:25] no [10:25] at least to begin with we want to see the warning, then we can try to suppress it [10:28] Branch on client-side: The client displays both the warning generated on the server and the warning generated on the client. [10:28] Branch on both: Same. [10:29] Branch on server-side: Same. [10:29] vs. lp:bzr, this means two warnings instead of one, for one branch. Ick. [10:30] Presumably there would only be 1 warning of the client didn't do any VFS requests. [10:37] Peng: Weird, I can't imagine why two warnings are emitted instead of one since this is controlled by a global which means it can't be emiited twice by the same code base [10:38] vila: When using bzr+ssh, the client sees the server's stderr. Or something. [10:38] that means client and server can emit one each, but I fail to see where my changes can trigger than [10:38] s/than/that/ [10:38] * Peng shrugs. [10:39] I'm too sleepy to brainstorm. [10:39] Peng: anyway, that's certainly a bug, so please report it or comment at bug #497694 [10:39] Launchpad bug 497694 in bzr "missing features about format deprecation" [Medium,Confirmed] https://launchpad.net/bugs/497694 [10:40] the patch is on its way to pqm as we speak, so in less than an hour, the bug will be on bzr.dev [10:40] \o/ [10:41] Peng: have some rest :) [10:41] Waitwaitwait. Peng is dumb. I get the double warnings in bzr.dev too. [10:41] I initially didn't notice because I ran with -Dhpssvfs and the traceback pushed the first one off the screen... [10:41] I'm pretty sure the patch also provides a way to suppress both warnings by configuring both the client and the server:) [10:42] haaaaaaa, great ! [10:42] Sorry for the confusion. [10:42] no problem, by the way may be you're seeing the two warnings because you run the server locally and in the same terminal > [10:42] no problem, by the way may be you're seeing the two warnings because you run the server locally and in the same terminal ? [10:43] * vila yells at keyboard [10:43] vila: bzr+ssh from one machine to another. [10:43] ok [10:43] vila: eta for pushing the log_log fix [10:43] vila: pqm depends on sysadmins [10:43] lifeless: yeah, I thought so ;) [10:43] lifeless: but it's in the pipe right ? [10:44] lifeless: I ask to know if I should revert babune's subunit and testtools or not... :-/ [10:46] vila: Brushing my teeth and going to bed takes more effort than staying awake and being an IRC zombie. [10:47] * vila frantically searches what is needed against zombies [10:53] vila: I'm a tired, lazy Internet zombie. I only eat presliced brains that are within arm's reach. [10:53] hiho [10:54] have a little problem in understanding how bzr works [10:54] say i have a branch trunk/ [10:55] and a subdir trunk/somedir [10:55] how to turn trunk/somedir/ in a branch with the same revno as trunk/ ? [10:56] ad-530: You want to split somedir out into its own branch? [10:56] ad-530: Why? [10:56] for use with builder/dailydeb [10:56] in the source package i need the trunk/somedir/ not the trunk/ [10:57] but then i got trunk/somedir/ is not a branch [10:57] *get [10:58] and i need to check out the whole repository because it's a svn repos. checking out just the trunk/somedir/ results in a borked revno of trunk/somedir/ [10:59] ad-530: Well...There's "bzr split", but there might be a better solution. [10:59] ok, what's the better solution? ^^ [11:02] I have no idea. [11:02] lol [11:03] vila: I have no eta for pqm getting the library [11:04] lifeless: k, thanks, that's the worse kind of ETA :) [11:16] vila: BTW, thanks for doing this. :) I have a couple of branches intentionally using ancient formats; it'll be nice to shut the warnings up. [11:17] (And thanks to the other people who worked on it before.) [11:17] * vila redirects to fullermd and ted :) === kgoetz is now known as Kamping_Kaiser [11:33] vila: you could talk to #is if you want to steer it along [11:38] hi bzr [11:40] 'morning bialix === NEBAP is now known as xeviox [12:30] jelmer, hey [12:31] Hi Cody [12:31] How are things? [12:31] Not too shabby. How are things with you? [12:31] Good, having fun doing Launchpad hacking :-) [12:33] jelmer, I think an upstream has changed what the git master is on a particular branch and now my branches no longer have common ancestry. Do you have any suggestions? [12:34] cody-somerville: they've basically done a rebase of the full branch? [12:36] jelmer, I'm not entirely sure. It looks like they had 'master' and 'debian' where 'debian' has been merging 'master' everytime they upload to debian. Now, it seems 'master' became 'debian' when they started on version "2.0". [12:37] and yo [12:37] ur branch is based on debian? [12:37] no, it was based on master since thats where all the commits were occurring. [12:38] If I based on debian I wouldn't have been able to cherrypick revisions and what not [12:38] рш оудьук [12:38] hi jelmer [12:46] cody-somerville: I'm a bit surprised there's no common history at all in that case [12:46] cody-somerville: is your branch available somewhere? [12:48] jelmer, https://code.edge.launchpad.net/~oem-solutions-releng/live-helper/live-helper [13:03] Good morning [13:05] hi rubbs [13:42] cody-somerville: Sorry for the delay, still cloning your branch. [14:11] jelmer: ping, regarding bug #496827, what do you mean ? I'm pretty sure I fixed that and InfoHooks *calls* super().__init__ [14:11] Launchpad bug 496827 in bzr ""bzr hooks" throws AttributeError exception on Windows" [Medium,Confirmed] https://launchpad.net/bugs/496827 [14:11] vila: before 2.0.2 ? [14:12] jelmer: not sure about that, but then it's a dupe ? [14:13] vila: Yeah, it's definitely a dupe [14:13] yup, #389648 is part of 2.1.0b3 [14:13] I couldn't find the original bug report [14:13] (probably because it's marked fixreleased by now) [14:13] hey ubottu wake up, bug #389648 [14:13] Launchpad bug 389648 in bzr "internal error on bzr hooks" [Medium,Fix released] https://launchpad.net/bugs/389648 [14:13] thanks [14:15] jelmer: thanks, by the way, searching NEWS worked for me here :) [14:15] Is the push-and-update plugin still required? [14:15] vila: I probably should've tried that [14:15] vila: I honestly hadn't considered that the bug might have already been fixed [14:16] jelmer: no worries, I was just scared about a possible regression :) [14:17] mindlace: well, it's hard to tell without more context but I see no reason why it wouldn't be required if it was... [14:17] cody-somerville: Ideally you should be able to rebase your branch onto the new git import [14:19] was looking at a "bazaar in 5 minutes for web developers" … doesn't seem like push/pull is required any more [14:20] url ? [14:21] mindlace: if you used to use push/pull and didn't change your setup, bzr won't magically push/pull [14:22] if the doc changed to describe a lightweight checkout instead of a branch, then, yes you won't need push/pull anymore but the change is that your branch was local and is now remote. but even then, you'll need to update your remote working tree, so I still fail to understand :D [14:24] vila: here we go: http://wiki.bazaar.canonical.com/BazaarForWebDevs [14:25] I am migrating my devs from svn. I expect push/pull to be a manual operation they take on their branches of the "source" tree. [14:25] source branch, i guess. [14:26] yes they are, why do you say push/pull are not required anymore ? [14:26] oh, it's not required, there is no remote working tree. [14:27] emmajane: hi emmajane ! You couldn't be more timely :-D [14:27] eh? no i mean this push-and-update plugin [14:27] emmajane: mindlace have some questions about http://wiki.bazaar.canonical.com/BazaarForWebDevs [14:28] is it just merging bzr push and bzr pull into one operation? [14:28] so the working tree is where the files you versioned are, doing commit create a revision with one or more parent revisions, a repository is where revisions are storedm a branch is a pointer to the tip revisions [14:29] vila, I'm just in a meeting...can you email me, or PM me and I'll get back to you? [14:29] push and pull affect only the branches (there are exceptions we;ll forget) [14:29] emmajane: no worries, I'll explain [14:29] right but on the server I don't need a working tree… i think? [14:30] you don't need a wt on the server where the branches are [14:30] right [14:30] but you need a working tree on your *web* server [14:30] oh [14:30] ok [14:30] (You probably want bzr upload, not that tutorial...) [14:30] i see. now I get it. [14:30] no it's fine, I understand bazaar, i just was confused about why I wanted to update the remote working tree [14:30] (most normal people don't actually do changes directly on the server) [14:31] * mindlace <-normal (in this case at least) [14:31] there are roughly two solutions: 1) you have bzr on the server and you want to server your web pages from the directory where the branch is also served from, 2) you want to serve from a directory without .bzr or from a server without bzr installed [14:32] for case 1) you use push-and-update for case 2) you use bzr-upload [14:32] mindlace: does that ^ answer your questions ? [14:42] yes. it answers my question in the affirmative - I need neither plugin, as I am treating the server "as if" it were subversion [14:42] server [14:43] and I'm the only one who deploys anyhow :P [14:43] mindlace: lol, ok :) [14:43] But how do you deploy ? [14:44] oh, I can install the plugin *for me* I just didn't want to have to walk my developers through installing a plugin today, as i'm having a hard time getting them to click through the process of branching [14:45] ok [14:50] Hi all .. [14:59] KLondenberg: hello === GaryvdM_ is now known as GaryvdM [15:45] Hi there! [15:45] trac-bzr is almost ready for release 0.3.0. I'm currently researching setuptools and its metadata. [15:47] Previous releases did not include any dependency information. I'm now inclined to include install_requires = ['Trac >= 0.10, <0.12', 'bzr >= 2.0']. But as I'm not experienced with python packaging, I fear there might be adverse effects of me doing so, e.g. the package becoming unusable if deps are installed without their egg info or similar. What do you think? [15:48] I also noticed that there is no bzr classifier registered with pypi, despite the large number of bzr-related packages in the catalog. Do you know of anyone applying for a classifier like "Topic :: Software Development :: Version Control :: Bazaar" or similar? [16:33] hmm, i have a project where I ended up loading bout 100 MB of mp4's into a directory(small web videos for the site) that I don't need to bzr push to the remote repo, i bzr remoe --keep 'd the vids from the working copy, but the bzr push is obviously pushing all revisions and copies of those videos when i dont need it to :( [16:33] and at 20KB/s upload ,,, emmm , it sucks [16:34] also,, the upload seems to have hit 5615KB and i'm not seeing it update with any more info.... [16:36] NET||abuse: Are there any other revisions commited after the videos commit? [16:37] yeh absolutely. [16:37] i've had the videos there in my working copy/ [16:37] I think there is a plugin - I'm taking a look. [16:37] they were being tracked,, then i bzr ignored them and bzr remove --keep 'd them.. and commited at that point [16:37] now i'm pushing to the remote server. [16:38] but the whole repo, as i didn't have a mirror repo up there already. [16:40] ahh, 23648, i guess it's only updating when individual files in the bzr database are uploaded... [16:40] so it's doing the vids right now, and they take a few minutes each file.. ok that makes sense [16:40] so 1/5 way through, it's 130MB for the full repo. [16:40]