[00:21] <mnn> hi... has anyone thought of a bit better support of autorenaming in either bzr or bazaar explorer?
[00:22] <mnn> 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] <mnn> and that's the most annoying thing about renaming files
[00:23] <spiv> mnn: that seems like something that could be fixed.  Want to try writing the patch to do it? :)
[00:24] <mnn> well, I could... but I would like to do it a "proper" way... because I hack my own code pretty bad :)
[00:25] <mnn> 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] <spiv> Yes, in bzr.
[00:34] <mgrandi> bzr explorer is a plugin for bzr so do it there
[00:34] <mnn> so what's it gonna be then?
[00:35] <mgrandi> hmm?
[00:35] <mnn> for me, I could just use adding folders without recurse... just add folders (if necessary) and then auto rename
[00:35] <mnn> mgrandi: spiv suggested that this should be done in bzr itself
[00:36] <mgrandi> yeah
[00:36] <mgrandi> bzr explorer uses bzr
[00:36] <mnn> I know :)
[00:36] <mgrandi> so doing it in bzr means that bzr explorer can also use it
[00:36] <mgrandi> =P
[00:37] <mnn> yeah, but I'm not very familiar with internal structure of bzr or explorer.. that's why I had to ask :)
[00:41] <mnn> also explorer could get an UI for move --auto
[00:43] <mgrandi> im not familiar with it either >.>
[02:05] <cody-somerville> 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] <lifeless> cody-somerville: if its inside a repo, it shoudn't.
[02:11] <lifeless> cody-somerville: if its cross-repos, its cloning the repo, which validates all the internal data.
[02:12] <cody-somerville> Ok, good to know.
[02:16] <cody-somerville> 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] <lifeless> its possibly git clone locally just hardlinks or something
[02:18] <lifeless> its valid to do that for bzr too.
[02:18] <lifeless> bet you that doing an actual validating clone would be more than 30 seconds for linux :)
[02:21] <cody-somerville> lifeless, I bet it did do something clever because just cping the git repo took 1m55s
[02:21] <cody-somerville> (whereas cping the launchpad bzr branch only took 30 seconds since it's only 312M vs. linux's 1.1G)
[08:01] <mgz> morning all!
[09:54] <mgz> vila: how is `bzr resolve --all` different from `bzr resolve --done`?
[09:55] <vila> mgz: looking at the code is the fastest way to get it, but roughly, --all == rm .bzr/checkout/conflicts
[09:56] <vila> probably there to cover early bugs and get out of them
[09:56] <mgz> the code paths look equivalent, apart from using a different working tree function to gather the files
[09:56] <mgz> which is why I'm asking if there's an intended difference :)
[09:58] <vila> 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] <vila> with no check
[10:02] <mgz> vila: okay, seems you've done all the hard bits, just needs some refactoring and deprecation of cruft
[10:04] <mgz> bug 383396 is not what this comment intended...
[10:05] <mgz> I'm guessing bug 389396
[10:30] <vila> mgz: you're right
[10:31] <vila> 3 6 9, too many multiple of 3 for my brain ;)
[10:32] <jelmer> hehe
[10:36] <mgz> okay, I've bascially got this fixed.
[10:36] <mgz> main fun bit is keeping compat with old oddness for now
[10:37] <jelmer> mgz: what do you have fixed, the resolve stuff?
[10:37] <mgz> have we got a bug for making 'auto' an allowable resolve action, or for making bzr resolve FILE not default to --done?
[10:38] <mgz> 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] <mgz> and how to we deprecate params to commands normally?
[10:38] <jelmer> 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] <mgz> okay, 10 failures from change to semantics
[10:54] <mgz> vila: TestResolveUnversionedParent methods test_take_this and test_take_other... don't actually use those args
[10:54] <mgz> that's just a mistake, or am I missing something?
[11:19] <mgz> 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] <vila> mgz: just back from launch, question still pending or ok now ?
[11:50] <mgz> okay, I'll put up some mps shortly which should cover the remaining queries
[13:57] <mgz> ...think I might just fix some of these old conflict bugs while I'm in the area
[14:02] <mnn> I'm having trouble with making a test - assertRaises doesn't "catch" the exception thus making the test fail
[14:05] <mgz> mnn: pastebin me some stuff?
[14:05] <mnn> ok
[14:05] <mgz> generally the form is: self.assertRaises(UnicodeError, str.decode, "\xff", "ascii")
[14:06] <mnn> yeah, I already found that out by searching already written tests
[14:07] <mgz> if the error raised is not a subtype of the first arg, it propogates
[14:11] <mnn> http://pastebin.com/w4fjEm2p
[14:11] <mnn> http://pastebin.com/TBAS98PX
[14:11] <mnn> http://pastebin.com/xhCFU6b3
[14:11] <mnn> and simple patch, if you wanted to try it out:
[14:11] <mnn> http://pastebin.com/eija9Y1d
[14:13] <mgz> you're giving assertRaises an instance not a class
[14:13] <mnn> yeah... I found it out just now :)
[14:13] <mnn> thanks anyway
[14:14] <mgz> checking e is the right thing to validate the details
[14:14] <mgz> I'd assert on the attributes of the exception rather than its stringification in those kinds of tests
[14:14] <mnn> yeah, I noticed that other tests do this when they test if right exception is raised
[14:14] <mgz> and add a test in bt.test_errors that the stringification is sane
[14:19] <mgz> mnn: some suggestions <http://pastebin.com/dPHqEyzZ>
[14:20] <mgz> I'd look at avoiding the need for an actual sftp transport for the test too
[14:20] <mgz> is/can _translate_io_exception be made a classmethod or staticmethod
[14:24] <mgz> mnn: you need to name the extra string param somthing other than 'msg' which is used by the base error class
[14:25] <mnn> ah... I wasn't aware of that
[14:25] <mnn> thanks
[14:25] <mgz> ....well, you probably don't, some of the other subclasses use that, but it would be less confusing
[14:25] <mnn> yeah I noticed that too
[14:27] <mgz> looks like you're making good progress
[14:31] <mnn> 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] <mnn> mgz: well I'm not sure about making _translate_io_exception static/classmethod... it calls _translate_error from its super/base class
[14:35] <mnn> however that doesn't use anything from the instance
[14:35] <mgz> right, just checking that
[14:35] <mgz> Transport._translate_error also does not use self
[14:36] <mgz> I'd decorate both with @staticmethod
[14:36] <mnn> ok, thanks for advice
[14:36] <mnn> but self has got to go away, right?
[14:36] <mgz> they have the leading underscore as a private hint, so fiddling is fine
[14:36] <mgz> right, you remove it from the arg list
[14:37] <mgz> def method(self, arg): ...
[14:37] <mgz> ->
[14:37] <mgz> @staticmethod
[14:37] <mgz> def method(arg): ...
[14:37] <mnn> ^^ 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] <mgz> then you can just use the base TestCase from bzrlib.tests and skip lots of transport setup
[14:38] <mgz> mnn, it's amazing how much time it saves, not being strict about stuff
[14:38] <mgz> makes it really hard to write robust libraries, but such are the tradeoffs
[14:39] <mnn> yeah sometimes it really is handy to access private stuff of the class
[16:00] <mnn> 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] <vila> mnn: IMO, *not* rebasing means the readers of your code will have a better way to understand your intent
[16:03] <mnn> well from what I've read I think you're right
[16:03] <mgz> 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] <mnn> however as I said opinions differ
[16:14] <mgz> hm, the help for bzr st doesn't document 'missing'
[19:29] <mnn> does anyone know, if it is somehow possible for a branch to override user ignore config?
[20:14] <vila> 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] <mnn> oh, thanks, you're right... I'm still new to all this stuff, so I occasionally miss simple things like this