[08:33] <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:48] <vila> crtxc: you probably want to pull by batches, so:
[08:49] <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:50] <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:52] <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:58] <mgz> morning all
[09:01] <crtxc> vila, oh, ok.  I never came across -r200, that sounds much better for lower the probability of line failure.  Ty very much.
[09:03] <vila> mgz: _o/
[09:07] <crtxc> vila, is -r revision ARG?  I am trying to find it in the man.
[09:08] <vila> yup
[09:09] <crtxc> vila, hats off to ya, that is a very clever solution. :)
[09:09] <crtxc> ty
[09:11] <vila> yeah, I learned a few tricks by lurking in this channel so these kudos are really for more than me (/me blushing)
[09:12] <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:13] <crtxc> :)
[09:14]  * fullermd is willing to accept any and all credit.
[09:14] <crtxc> :)
[09:15] <vila> ha, right, yeah, that's all fullermd fault, now that you mention it :)
[09:15] <vila> 's ?
[09:17] <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:19] <fullermd> Here now.  *I* handle the bad puns around here.  You're on my turf, sparky!
[09:19] <crtxc> :)
[11:13] <jelmer> hah, finally figured out what the trouble was with those multiple upstream tarballs
[11:14] <vila> jelmer: \o/ ?
[11:15] <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:18] <mgz> wifi goes by water in france :)
[11:23] <quicksilver> antenna in your laptop is damaged and finds some channels easier to tune than others?
[11:24] <quicksilver> the breed of chicken you sacrificed was not holy enough to use channel 13?
[11:25] <vila> goats, I always use goats... But now that you mentioned it I may have to audit my provider...
[11:38] <fullermd> I guaranteed the goats for SCSI.  I didn't say nuffin' about 802.11.
[11:55] <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:56] <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:57] <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:58] <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:59] <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 ?
[12:01] <vila> writing help thinking, so: I bumped to high and approved ;)
[12:09] <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:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:18] <vila> are the existing tests good enough to cover that ? (obviously nothing covers bug 800270)
[12:32] <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:34] <jelmer> vila: sorry, back now
[12:35] <jelmer> vila: I'm pretty sure there are some tests for preserving file ids
[12:36] <vila> and renames ?
[12:37] <vila> mgz: wow, you're raising the bar now ;)
[12:38] <vila> bah, pqm not using news_merge is now really going on my nerves
[12:39] <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:40] <jelmer> vila: I think the plan also was to look at tarmac
[12:41] <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:42] <vila> wwooooow, lunch time
[12:46] <mgz> hey, I said it was a bug in two halves, I just fixed both of them :)
[12:48] <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:51] <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:52] <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:53] <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:55] <crtxc> ok.  I never did this before I only use bzr to track my text files.
[12:57] <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.
[13:01] <crtxc> well.  Ty very, very much for your insights all.
[13:14] <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:15] <crtxc> I am trying to learn shell scripting, python, and c++.
[13:45] <mgz> lunchtime, prize if anyone can guess where I'm going with these mps
[13:46] <vila> lol, I was reading it and was about to ask :)
[13:46] <vila> ha, I read only one
[13:47] <jml> what's the udd mailing list?
[13:47] <jml> for lp:udd in particular, I mean.
[13:48] <vila> ubuntu-distributed-devel@lists.ubuntu.com
[13:49] <vila> mgz: getting encoding right in more contexts ?
[13:49] <fullermd> mgz: To lunch.  What do I win?
[13:50] <vila> mgz: rats, lunch of course
[14:38] <chromaticwt> why learn c++ before lisp?
[16:43] <vila> mgz: I'm still holding my breath
[16:43] <wgz> it will be very exciting... maybe
[16:43] <vila> hehe
[16:44] <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:45] <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:46] <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:47] <jml> lamalex: what are you trying to do?
[16:48] <jml> lamalex: or, is testtools.run.main() not convenient enough for you?
[16:49] <lamalex> jml, nevermind that discover thing was exactly what i needed
[17:08] <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:10] <lamalex> why's that
[17:11] <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:12] <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:36] <vila> wgz: encoding guessing... to cope with people using wrong fs encodings or not setting any ?
[17:36] <vila> (I had to breath .... ;)
[17:38] <wgz> not quite yet, but that one is on the list :)
[17:39] <vila> oooh, at least properly reporting the full string on unicode exceptions ?
[17:40] <wgz> yup, and full unicode output for all errors.
[17:41]  * vila whistles
[17:42]  * vila hugs mgz too
[17:43] <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:50] <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:51] <jelmer> vila: argh
[17:52] <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:53] <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:54] <vila> woohoo
[17:55] <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:56] <vila> hehe, beware of conflicts when landing... the more you land before hand the less conflicts you bump into ;)
[17:57] <vila> on top of that you have one for 2.4 that will need to be merged up ;-p
[19:07] <jelmer> hmm
[19:08] <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:33] <jelmer> vila: it looks like the "PoMerger created" message made it into bzr.dev, btw
[20:30] <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:33] <kirkland> I guess I'm trying to figure out what/how to do with those
[20:37] <jelmer> hi Dustin
[20:38] <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:42] <jelmer> kirkland: we should have bzr-fastimport hint that the branches created are tree-less, just like most other bzr import tools do
[20:43] <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:56] <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:58] <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:59] <jelmer> vila: that's the case for lots of things
[20:59] <jelmer> vila: doesn't mean we have them enabled by default :_)
[21:00] <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:01] <vila> if you're really searching to reduce the size of the import logs, there are far bigger targets though
[21:04] <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:05] <vila> I mentioned that I've seen at least one case where the message where there twice for the same merge
[21:06] <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:07] <vila> way past EOD ;)
[21:08] <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 :-)