| crtxc | hi. Internet where I am is very very unreliable and slow. Is there a way to resume a branch that has been cut off? I am trying to branch emacs and it keeps stopping, then I have to start the whole thing over. I can't find anything via search. | 08:33 |
|---|---|---|
| vila | crtxc: you probably want to pull by batches, so: | 08:48 |
| vila | bzr init-repo emacs ; cd emacs ; bzr init trunk ; cd trunk ; bzr pull <trunk url> -r100 | 08:49 |
| vila | then 'bzr pull -r200' until you get to the tip | 08:49 |
| vila | use any increment that your connection can support 1.000 10.000 100.000 | 08:50 |
| vila | once you get the full history, things should be more reliable as you'll need to download only the new ones | 08:50 |
| vila | discussions about allowing more robust branching by automating the above occur from time to time but I don't remember anybody going ahead and implement it | 08:52 |
| mgz | morning all | 08:58 |
| crtxc | vila, oh, ok. I never came across -r200, that sounds much better for lower the probability of line failure. Ty very much. | 09:01 |
| vila | mgz: _o/ | 09:03 |
| crtxc | vila, is -r revision ARG? I am trying to find it in the man. | 09:07 |
| vila | yup | 09:08 |
| crtxc | vila, hats off to ya, that is a very clever solution. :) | 09:09 |
| crtxc | ty | 09:09 |
| vila | yeah, I learned a few tricks by lurking in this channel so these kudos are really for more than me (/me blushing) | 09:11 |
| crtxc | if you have a web site or a blog you might want to make a small post and get some traffic with that. I see a few people had trouble with that. :) Then kudos to all who have good brains. :) | 09:12 |
| crtxc | :) | 09:13 |
| * fullermd is willing to accept any and all credit. | 09:14 | |
| crtxc | :) | 09:14 |
| vila | ha, right, yeah, that's all fullermd fault, now that you mention it :) | 09:15 |
| vila | 's ? | 09:15 |
| crtxc | fullermd has been so kind for hidding the i an n between the m and d. If fullermd weren't so shy it would be fullermind for all to see. :) | 09:17 |
| fullermd | Here now. *I* handle the bad puns around here. You're on my turf, sparky! | 09:19 |
| crtxc | :) | 09:19 |
| jelmer | hah, finally figured out what the trouble was with those multiple upstream tarballs | 11:13 |
| vila | jelmer: \o/ ? | 11:14 |
| vila | planets should be well aligned, my wifi problem just... resolved itself (using canal 6 instead of 13 *cannot* be related right ? Not when the only laptop that was hanging trying to connect is mine, right ?) | 11:15 |
| mgz | wifi goes by water in france :) | 11:18 |
| quicksilver | antenna in your laptop is damaged and finds some channels easier to tune than others? | 11:23 |
| quicksilver | the breed of chicken you sacrificed was not holy enough to use channel 13? | 11:24 |
| vila | goats, I always use goats... But now that you mentioned it I may have to audit my provider... | 11:25 |
| fullermd | I guaranteed the goats for SCSI. I didn't say nuffin' about 802.11. | 11:38 |
| soren | vila: Not all wifi adapters can go up to channel 13. | 11:55 |
| soren | vila: I've had a few that only went up to 11. | 11:55 |
| mgz | I thought fullermd said he was in charge of the bad jokes... | 11:55 |
| vila | soren: good point, but the router upgrade triggered the issue while the previous was already using channel 13 | 11:55 |
| fullermd | Why don't you just raise the frequency of 10 a little, and have 10 as the top channel? | 11:56 |
| soren | vila: Oh. | 11:56 |
| soren | fullermd: lol | 11:56 |
| vila | soren: still, thanks for pointing that | 11:56 |
| vila | SCSI ? Come on ! I still have cables and even scsi drives... in my attic ! But I was clear enough when we engage on this goat deal that they won't be used outside of sabbat where virgin (and not goats) are used anyway | 11:57 |
| vila | (the scsi stuff I mean, not the goats) | 11:58 |
| vila | jelmer: what's your feeling about your reconcile proposal and bug #897487 ? | 11:58 |
| ubot5 | Launchpad bug 897487 in Bazaar "progress indication for Repository packing and reconciliation over HPSS" [Medium,Confirmed] https://launchpad.net/bugs/897487 | 11:58 |
| vila | jelmer: should the bug be a pre-requisite ? Do you think you can fix it soon ? Should we just land and see ? | 11:59 |
| vila | 4) should we raise the importance to high ? | 11:59 |
| vila | writing help thinking, so: I bumped to high and approved ;) | 12:01 |
| jelmer | vila: I wonder what the best way is to provide progress reports | 12:09 |
| jelmer | vila: if it's sufficient to just stream some data, then we can easily do that, even if it's not very useful data | 12:09 |
| vila | jelmer: I don't know the code well enough to say if multiplexing data and progress is easy or not, so if there is data you can stream, good enough | 12:10 |
| jelmer | vila: btw, on another note | 12:11 |
| jelmer | vila: if we're looking at fixing the import code in bzr-builddeb, I wonder if we could stream directly from the tarball into commit builder | 12:11 |
| jelmer | vila: I've been wondering about that previously as well, because currently we have to check out the base parent on disk, etc | 12:12 |
| jelmer | so it would improve performance, but it would also help my current work | 12:12 |
| vila | my understanding is that import is not simply a commit, there could be renames and kind changes | 12:12 |
| vila | and deletions, and so on | 12:12 |
| vila | what I don't understand though, is why we can reuse more of our existing stuff. Are renames and the like really the issue again here ? | 12:13 |
| jelmer | vila: deletions and so on shouldn't be a problem, | 12:13 |
| vila | as in: some operations cannot be automatically deduced | 12:13 |
| jelmer | vila: ? I don't see how that matters, the only difference is that we're reading the contents for the commit from a tarball rather than off disk. | 12:14 |
| vila | ha, let's sync | 12:15 |
| vila | I was referring to the actual implementation that seems to use a transform tree to better handle renames and file-id reuses | 12:15 |
| vila | you're talking about using a different source for commit, which indeed sounds like a good plan (gmta ;), but what about file-id reuse and renames ? | 12:16 |
| vila | are the existing tests good enough to cover that ? (obviously nothing covers bug 800270) | 12:18 |
| ubot5 | Launchpad bug 800270 in bzr-builddeb "import-tar incorrectly handles symlinks turned into directories" [High,Triaged] https://launchpad.net/bugs/800270 | 12:18 |
| vila | jelmer: still there ? | 12:32 |
| mgz | I think being able to do certain transforms without having a tree on disk is something we need. | 12:32 |
| jelmer | vila: sorry, back now | 12:34 |
| jelmer | vila: I'm pretty sure there are some tests for preserving file ids | 12:35 |
| vila | and renames ? | 12:36 |
| vila | mgz: wow, you're raising the bar now ;) | 12:37 |
| vila | bah, pqm not using news_merge is now really going on my nerves | 12:38 |
| vila | hmm, could it be that pqm is using a too old bzr version... | 12:39 |
| vila | ... and we don't want to upgrade until that subunit/testools compat bug is fixed, I've lost track :-/ | 12:39 |
| jelmer | vila: I think the plan also was to look at tarmac | 12:40 |
| vila | hehe, reading mgz proposals on the active review page is... funny: fix-bzr-subprocess followed by don-use-bzr-subprocess-after-all :) | 12:41 |
| vila | jelmer: yeah, better | 12:41 |
| vila | wwooooow, lunch time | 12:42 |
| mgz | hey, I said it was a bug in two halves, I just fixed both of them :) | 12:46 |
| crtxc | hi. I cloned emacs. I am not a developer. I only want to make a copy, build emacs, then use the original to update any changes on the parent repo. Did I do this right? http://codepad.org/et7ETDzS | 12:48 |
| mgz | crtxc: you don't really need any of that except `bzr branch` for your use | 12:51 |
| mgz | all I'd suggest is using the launchpad mirror rather than savannah may still be faster | 12:51 |
| crtxc | oh. So I just do bzr branch everytime I update? | 12:52 |
| mgz | no, you branch once, then you just `bzr pull` to update | 12:52 |
| crtxc | oh. I overcomplicated it. | 12:52 |
| mgz | right, but the extra bits you did aren't harmful | 12:53 |
| crtxc | ok :) | 12:53 |
| mgz | they're just for emacs developers' funny work flows. | 12:53 |
| crtxc | ok. I never did this before I only use bzr to track my text files. | 12:55 |
| crtxc | oops. I just tried to bzr and I got an error. http://codepad.org/0qXcOk71 | 12:57 |
| crtxc | tried to bzr pull^ | 12:57 |
| fullermd | unbind it | 12:57 |
| crtxc | ok. ty. unbind. | 12:57 |
| crtxc | well. Ty very, very much for your insights all. | 13:01 |
| crtxc | ok. That is it. I should do some reading on shell scripting and c++ but my eyes are burning so ty very much | 13:14 |
| fullermd | A little C++ will fix that right up. | 13:14 |
| fullermd | There's no burning left after you gouge them out. | 13:14 |
| crtxc | :) | 13:14 |
| crtxc | I am trying to learn shell scripting, python, and c++. | 13:15 |
| === gthorslund_ is now known as gthorslund | ||
| mgz | lunchtime, prize if anyone can guess where I'm going with these mps | 13:45 |
| vila | lol, I was reading it and was about to ask :) | 13:46 |
| vila | ha, I read only one | 13:46 |
| jml | what's the udd mailing list? | 13:47 |
| jml | for lp:udd in particular, I mean. | 13:47 |
| vila | ubuntu-distributed-devel@lists.ubuntu.com | 13:48 |
| vila | mgz: getting encoding right in more contexts ? | 13:49 |
| fullermd | mgz: To lunch. What do I win? | 13:49 |
| vila | mgz: rats, lunch of course | 13:50 |
| chromaticwt | why learn c++ before lisp? | 14:38 |
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| vila | mgz: I'm still holding my breath | 16:43 |
| wgz | it will be very exciting... maybe | 16:43 |
| vila | hehe | 16:43 |
| fullermd | I dunno, I think holding your breath that long is probably pretty boring. | 16:44 |
| fullermd | Maybe not for your heirs, I guess. | 16:44 |
| vila | she looks worried indeed | 16:44 |
| lamalex | jml, is there a convenient way to call testtools.run from python on all of my test_ modules? | 16:45 |
| jml | lamalex: 'testtools.run discover [package]' iirc | 16:45 |
| jml | lamalex: http://testtools.readthedocs.org/en/latest/for-test-authors.html#running-your-tests will get it righter than me :) | 16:46 |
| lamalex | jml, thats from a shell though | 16:46 |
| jml | lamalex: what are you trying to do? | 16:47 |
| jml | lamalex: or, is testtools.run.main() not convenient enough for you? | 16:48 |
| lamalex | jml, nevermind that discover thing was exactly what i needed | 16:49 |
| === supton_ is now known as supton | ||
| lamalex | jml, setUp runs for every test_ method, is there a TestCase wide set up? | 17:08 |
| jml | lamalex: no. | 17:08 |
| jml | lamalex: having such a thing is a bad idea | 17:08 |
| lamalex | why's that | 17:10 |
| jml | lamalex: because it makes test isolation very hard | 17:11 |
| jml | lamalex: which in turn makes it very easy to write tests where a failure or mistake in one corrupts the results of others | 17:11 |
| lamalex | jml, yah but we're not writing traditional unit tests | 17:12 |
| jml | lamalex: are you not interested in the results of these tests? | 17:12 |
| vila | wgz: encoding guessing... to cope with people using wrong fs encodings or not setting any ? | 17:36 |
| vila | (I had to breath .... ;) | 17:36 |
| wgz | not quite yet, but that one is on the list :) | 17:38 |
| vila | oooh, at least properly reporting the full string on unicode exceptions ? | 17:39 |
| wgz | yup, and full unicode output for all errors. | 17:40 |
| * vila whistles | 17:41 | |
| * vila hugs mgz too | 17:42 | |
| fullermd | Pah. 7 bits should be enough for anyone. | 17:43 |
| vila | now, given that nexuiz-data needs more than 24h and that we kill imports that exceed their 24h quota... we need a finer-grained configuration ;) | 17:43 |
| vila | jelmer: pretty cute failure: http://babune.ladeuil.net:24842/job/selftest-chroot-precise/lastFailedBuild/testReport/junit/bzrlib.tests.blackbox.test_checkout/TestSmartServerCheckout/test_lightweight_checkout/ | 17:50 |
| vila | jelmer: looks like you did even better than you thought ;-D | 17:50 |
| jelmer | vila: argh | 17:51 |
| jelmer | vila: we'll have to change the lower limit to 34 I guess | 17:52 |
| vila | jelmer: yup, not a problem | 17:52 |
| jelmer | vila: there's a lot of variation in a single "bzr co --lightweight" command | 17:52 |
| vila | which is not ideal for a test but meh | 17:52 |
| vila | the point is to not go up | 17:52 |
| vila | do you really need the 9 commits ? | 17:53 |
| jelmer | vila: this is before I worked my magic btw ;-) the hpss-get-inventories branch brings it down to 15 | 17:53 |
| vila | woohoo | 17:54 |
| vila | jelmer, mgz : would you mind clearing the active reviews page guys, you have 7 approved reviews ready to land there :) | 17:55 |
| wgz | I'm trying to get everything ready all at once :D | 17:55 |
| vila | hehe, beware of conflicts when landing... the more you land before hand the less conflicts you bump into ;) | 17:56 |
| vila | on top of that you have one for 2.4 that will need to be merged up ;-p | 17:57 |
| === Quintasan_ is now known as Quintasan | ||
| jelmer | hmm | 19:07 |
| jelmer | vila: I wonder if that RevisionNotPresent issue we've been hitting with the importer is related to the repository not clearing it's caching of negative revids in the parent map cache | 19:08 |
| jelmer | vila: it looks like the "PoMerger created" message made it into bzr.dev, btw | 19:33 |
| kirkland | okay, a couple of bzr fast-import questions, from git | 20:30 |
| kirkland | I've done the fast-export from git, and then fast-import into bzr | 20:30 |
| kirkland | I now have a directory of a bunch of branches/tags, I think | 20:30 |
| kirkland | I guess I'm trying to figure out what/how to do with those | 20:33 |
| jelmer | hi Dustin | 20:37 |
| jelmer | kirkland: You should be able to just use those branches like you normally would | 20:38 |
| jelmer | kirkland: if they don't have a working tree yet, you can use "bzr co" to create one | 20:38 |
| kirkland | jelmer: oh, hmm, okay | 20:38 |
| kirkland | jelmer: let me try those | 20:38 |
| kirkland | jelmer: all of them looked "empty" except for .bzr | 20:38 |
| kirkland | jelmer: i guess i just needed to co them | 20:38 |
| jelmer | kirkland: we should have bzr-fastimport hint that the branches created are tree-less, just like most other bzr import tools do | 20:42 |
| jelmer | kirkland: this is done for space reasons, btw - you don't want to end up with 20 copies of the kernel if you're fastimporting a kernel repo with 20 branches | 20:43 |
| vila | jelmer: I left it there on purpose, I still have doubts about whether it's created only once and it's the cheapest way to gather data. Once I get this feedback, I'll address the issue one way or the other (remove the message or fix the duplicated creation) | 20:56 |
| vila | jelmer: hence my reply to your review: "It's not useless noise" ;) | 20:56 |
| jelmer | vila: it should at least be hidden behind a debug flag in that case I think | 20:58 |
| jelmer | vila: it's showing up for every revision processed by the udd importer | 20:58 |
| vila | it's one line per merge and will be useless if hidden behind a debug flag... | 20:58 |
| Noldorin | what's the easiest way to run Bzr server as a Windows Service? | 20:58 |
| jelmer | vila: that's the case for lots of things | 20:59 |
| jelmer | vila: doesn't mean we have them enabled by default :_) | 20:59 |
| vila | then consider that I put a debug flag active by default and that this will be revisited | 21:00 |
| jelmer | vila: sure, I'll file a bug | 21:00 |
| vila | if you're really searching to reduce the size of the import logs, there are far bigger targets though | 21:01 |
| jelmer | vila: sure, I'm just saying it's noise unless you're actually trying to debug something related to pomerge | 21:04 |
| vila | I *am* :) | 21:04 |
| vila | I mentioned that I've seen at least one case where the message where there twice for the same merge | 21:05 |
| vila | but to avoid chasing ghosts for too long I submitted without digging further (nothing in my proposal should trigger such a behavior) | 21:06 |
| vila | and there is one spurious merge in this sentence | 21:06 |
| vila | ghaa, where not merge | 21:06 |
| vila | way past EOD ;) | 21:07 |
| jelmer | vila: I still don't think that's a good reason, by that reasoning we might as well enable a whole bunch of things because they will help with debugging - like -Dhpss and -Devil | 21:08 |
| jelmer | vila: if there was a -Dpo_merge flag, *you* could enable it | 21:08 |
| jelmer | anyway, it is indeed well past EOD :-) | 21:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!