mnn | hi... has anyone thought of a bit better support of autorenaming in either bzr or bazaar explorer? | 00:21 |
---|---|---|
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:22 |
spiv | mnn: that seems like something that could be fixed. Want to try writing the patch to do it? :) | 00:23 |
mnn | well, I could... but I would like to do it a "proper" way... because I hack my own code pretty bad :) | 00:24 |
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:25 |
spiv | Yes, in bzr. | 00:26 |
mgrandi | bzr explorer is a plugin for bzr so do it there | 00:34 |
mnn | so what's it gonna be then? | 00:34 |
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:35 |
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:36 |
mnn | yeah, but I'm not very familiar with internal structure of bzr or explorer.. that's why I had to ask :) | 00:37 |
mnn | also explorer could get an UI for move --auto | 00:41 |
mgrandi | im not familiar with it either >.> | 00:43 |
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:05 |
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:11 |
cody-somerville | Ok, good to know. | 02:12 |
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:16 |
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:18 |
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) | 02:21 |
mgz | morning all! | 08:01 |
mgz | vila: how is `bzr resolve --all` different from `bzr resolve --done`? | 09:54 |
=== yofel_ is now known as yofel | ||
vila | mgz: looking at the code is the fastest way to get it, but roughly, --all == rm .bzr/checkout/conflicts | 09:55 |
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:56 |
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:58 |
vila | with no check | 09:59 |
mgz | vila: okay, seems you've done all the hard bits, just needs some refactoring and deprecation of cruft | 10:02 |
mgz | bug 383396 is not what this comment intended... | 10:04 |
ubot5 | 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:04 |
mgz | I'm guessing bug 389396 | 10:05 |
ubot5 | Launchpad bug 389396 in Bazaar "bzr resolved does not resolve shape conflicts" [High,Confirmed] https://launchpad.net/bugs/389396 | 10:05 |
vila | mgz: you're right | 10:30 |
vila | 3 6 9, too many multiple of 3 for my brain ;) | 10:31 |
jelmer | hehe | 10:32 |
mgz | okay, I've bascially got this fixed. | 10:36 |
mgz | main fun bit is keeping compat with old oddness for now | 10:36 |
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:37 |
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:38 |
mgz | okay, 10 failures from change to semantics | 10:39 |
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? | 10:54 |
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:19 |
vila | mgz: just back from launch, question still pending or ok now ? | 11:41 |
mgz | okay, I'll put up some mps shortly which should cover the remaining queries | 11:50 |
mgz | ...think I might just fix some of these old conflict bugs while I'm in the area | 13:57 |
mnn | I'm having trouble with making a test - assertRaises doesn't "catch" the exception thus making the test fail | 14:02 |
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:05 |
mnn | yeah, I already found that out by searching already written tests | 14:06 |
mgz | if the error raised is not a subtype of the first arg, it propogates | 14:07 |
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:11 |
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:13 |
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:14 |
mgz | mnn: some suggestions <http://pastebin.com/dPHqEyzZ> | 14:19 |
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:20 |
mgz | mnn: you need to name the extra string param somthing other than 'msg' which is used by the base error class | 14:24 |
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:25 |
mgz | looks like you're making good progress | 14:27 |
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:31 |
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:35 |
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:36 |
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:37 |
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:38 |
mnn | yeah sometimes it really is handy to access private stuff of the class | 14:39 |
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:00 |
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:03 |
mgz | hm, the help for bzr st doesn't document 'missing' | 16:14 |
=== zyga is now known as zyga-afk | ||
mnn | does anyone know, if it is somehow possible for a branch to override user ignore config? | 19:29 |
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:14 |
mnn | oh, thanks, you're right... I'm still new to all this stuff, so I occasionally miss simple things like this | 20:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!