[00:21] hi... has anyone thought of a bit better support of autorenaming in either bzr or bazaar explorer? [00:22] I mean bzr move --auto is great, but when files are moved into new folders, I have to add those new folders by hand (bzr add --norecurse) [00:22] and that's the most annoying thing about renaming files [00:23] mnn: that seems like something that could be fixed. Want to try writing the patch to do it? :) [00:24] well, I could... but I would like to do it a "proper" way... because I hack my own code pretty bad :) [00:25] first - at what level should this be implemented? bzr or explorer? I'm thinking of bzr... but then it would have to scan new folders if files in them were moved [00:26] Yes, in bzr. [00:34] bzr explorer is a plugin for bzr so do it there [00:34] so what's it gonna be then? [00:35] hmm? [00:35] for me, I could just use adding folders without recurse... just add folders (if necessary) and then auto rename [00:35] mgrandi: spiv suggested that this should be done in bzr itself [00:36] yeah [00:36] bzr explorer uses bzr [00:36] I know :) [00:36] so doing it in bzr means that bzr explorer can also use it [00:36] =P [00:37] yeah, but I'm not very familiar with internal structure of bzr or explorer.. that's why I had to ask :) [00:41] also explorer could get an UI for move --auto [00:43] im not familiar with it either >.> [02:05] I'm curious. with bzr, you can basically just cp the directory to create another branch yet actually running bzr branch on the same local branch takes significantly longer. Why is that? [02:11] cody-somerville: if its inside a repo, it shoudn't. [02:11] cody-somerville: if its cross-repos, its cloning the repo, which validates all the internal data. [02:12] Ok, good to know. [02:16] I was playing around with git and bzr the other to see how they compare performance wise these days. I found that it took 10 minutes to do a local bzr branch of launchpad but only 30 seconds to git clone local copy of linux. I am using version of bzr from beta PPA though. Does that sound right or is it possible there could be a performance regression in the version I'm using? [02:18] its possibly git clone locally just hardlinks or something [02:18] its valid to do that for bzr too. [02:18] bet you that doing an actual validating clone would be more than 30 seconds for linux :) [02:21] lifeless, I bet it did do something clever because just cping the git repo took 1m55s [02:21] (whereas cping the launchpad bzr branch only took 30 seconds since it's only 312M vs. linux's 1.1G) [08:01] morning all! [09:54] vila: how is `bzr resolve --all` different from `bzr resolve --done`? === yofel_ is now known as yofel [09:55] mgz: looking at the code is the fastest way to get it, but roughly, --all == rm .bzr/checkout/conflicts [09:56] probably there to cover early bugs and get out of them [09:56] the code paths look equivalent, apart from using a different working tree function to gather the files [09:56] which is why I'm asking if there's an intended difference :) [09:58] ha right, looking at the code again it's not obvious from the command itself, so, from memory, 'done' means 'I did what was needed, forget about the conflict' [09:59] with no check [10:02] vila: okay, seems you've done all the hard bits, just needs some refactoring and deprecation of cruft [10:04] bug 383396 is not what this comment intended... [10:04] Launchpad bug 383129 in xserver-xorg-video-intel (Ubuntu) "duplicate for #383396 x server dies with a SIGSEGV when gnome screen saver blanks the display" [Undecided,Fix released] https://launchpad.net/bugs/383129 [10:05] I'm guessing bug 389396 [10:05] Launchpad bug 389396 in Bazaar "bzr resolved does not resolve shape conflicts" [High,Confirmed] https://launchpad.net/bugs/389396 [10:30] mgz: you're right [10:31] 3 6 9, too many multiple of 3 for my brain ;) [10:32] hehe [10:36] okay, I've bascially got this fixed. [10:36] main fun bit is keeping compat with old oddness for now [10:37] mgz: what do you have fixed, the resolve stuff? [10:37] have we got a bug for making 'auto' an allowable resolve action, or for making bzr resolve FILE not default to --done? [10:38] yeah, I was ignoring the thread, but read it this morning and had the "this can't be that hard to just fix" feeling [10:38] and how to we deprecate params to commands normally? [10:38] mgz: I think we add a bit of code that spews to standard error inside of the command if the option ws specified [10:39] okay, 10 failures from change to semantics [10:54] vila: TestResolveUnversionedParent methods test_take_this and test_take_other... don't actually use those args [10:54] that's just a mistake, or am I missing something? [11:19] hm, I understand it now, it's test_take_this is not like test_resolve_take_this, it'd doing the same actions manually [11:41] mgz: just back from launch, question still pending or ok now ? [11:50] okay, I'll put up some mps shortly which should cover the remaining queries [13:57] ...think I might just fix some of these old conflict bugs while I'm in the area [14:02] I'm having trouble with making a test - assertRaises doesn't "catch" the exception thus making the test fail [14:05] mnn: pastebin me some stuff? [14:05] ok [14:05] generally the form is: self.assertRaises(UnicodeError, str.decode, "\xff", "ascii") [14:06] yeah, I already found that out by searching already written tests [14:07] if the error raised is not a subtype of the first arg, it propogates [14:11] http://pastebin.com/w4fjEm2p [14:11] http://pastebin.com/TBAS98PX [14:11] http://pastebin.com/xhCFU6b3 [14:11] and simple patch, if you wanted to try it out: [14:11] http://pastebin.com/eija9Y1d [14:13] you're giving assertRaises an instance not a class [14:13] yeah... I found it out just now :) [14:13] thanks anyway [14:14] checking e is the right thing to validate the details [14:14] I'd assert on the attributes of the exception rather than its stringification in those kinds of tests [14:14] yeah, I noticed that other tests do this when they test if right exception is raised [14:14] and add a test in bt.test_errors that the stringification is sane [14:19] mnn: some suggestions [14:20] I'd look at avoiding the need for an actual sftp transport for the test too [14:20] is/can _translate_io_exception be made a classmethod or staticmethod [14:24] mnn: you need to name the extra string param somthing other than 'msg' which is used by the base error class [14:25] ah... I wasn't aware of that [14:25] thanks [14:25] ....well, you probably don't, some of the other subclasses use that, but it would be less confusing [14:25] yeah I noticed that too [14:27] looks like you're making good progress [14:31] well thanks... I wasn't sure if I should dive into all this, because of my lack of knowledge/experience with Python (the only dynamic language I have experience is Lua)... and lack of Bazaar exprience :) but it seems it works so far [14:35] mgz: well I'm not sure about making _translate_io_exception static/classmethod... it calls _translate_error from its super/base class [14:35] however that doesn't use anything from the instance [14:35] right, just checking that [14:35] Transport._translate_error also does not use self [14:36] I'd decorate both with @staticmethod [14:36] ok, thanks for advice [14:36] but self has got to go away, right? [14:36] they have the leading underscore as a private hint, so fiddling is fine [14:36] right, you remove it from the arg list [14:37] def method(self, arg): ... [14:37] -> [14:37] @staticmethod [14:37] def method(arg): ... [14:37] ^^ and that's what I didn't like about python, when I stumbled upon it a few years back... something as "private" doesn't really exist there [14:38] then you can just use the base TestCase from bzrlib.tests and skip lots of transport setup [14:38] mnn, it's amazing how much time it saves, not being strict about stuff [14:38] makes it really hard to write robust libraries, but such are the tradeoffs [14:39] yeah sometimes it really is handy to access private stuff of the class [16:00] mgz: so, I've finished the tests... I've read online that it is possible to rebase my branch to reorganize my commits... however the are opinions on not doing rebase at all [16:03] mnn: IMO, *not* rebasing means the readers of your code will have a better way to understand your intent [16:03] well from what I've read I think you're right [16:03] mnn: I wouldn't worry about it, unless you have a couple of messy commits on the end that you've not pushed up yet, then I tend to uncommit and tidy up [16:03] however as I said opinions differ [16:14] hm, the help for bzr st doesn't document 'missing' === zyga is now known as zyga-afk [19:29] does anyone know, if it is somehow possible for a branch to override user ignore config? [20:14] mnn: not sure what you mean here, 'bzr add FILE' will start versioning FILE *even* if FILE is ignored (i.e. 'bzr add' won't add FILE automatically) [20:28] oh, thanks, you're right... I'm still new to all this stuff, so I occasionally miss simple things like this