[00:00] <mgz> and the second is mostly a niggle:
[00:00] <mgz> if you look at testtools.testcase.TestCase.expectFailure, do you see any way *not* to create a cycle there?
[00:03]  * mgz heads back up a bit and branches lp:python-fixtures to look at it
[00:05] <lifeless> mgz: whats the cycle on? the frame contents ?
[00:06] <lifeless> try: raise _ExpectedFailure(exc_info) finally: del exc_info  again ?
[00:06] <mgz> yup, puts exc_info in the exception instance it's rerasing
[00:07] <mgz> ^right, that's not good enough in this case because the reraise keeps the original traceback frames alive
[00:08] <mgz> that plus _ExpectedFailure((exc_info[0], exc_info[1], None)) works,
[00:08] <lifeless> mangle the frames ?
[00:09] <mgz> that's what I'd like, I'm not sure how though.
[00:09] <lifeless> 'stabbity stabbity'
[00:10] <mgz> eheheh
[00:11] <mgz> I'll put up my testtools changes as well now (which are basically just that try/finally/del in a few places)
[00:11] <mgz> but that method stumped me.
[00:40] <lifeless> mgz: I'll look in more detail a little layer
[00:41] <mgz> python-fixtures looks shiny. I'd like to see some harder examples of things like how it'd work with testresources though.
[00:42] <mgz> ^lifeless: that'd be great.
[00:42] <lifeless> so I plan to write a decorator for testresources
[00:42] <lifeless> and deprecate testresources internal fixture-like api
[00:42] <lifeless> so a resource becomes ReferenceCounter(fixture)
[00:43] <lifeless> [roughly, mumble]
[00:43] <mgz> :)
[00:43] <lifeless> possibly even auto-do that
[00:44] <mgz> bed for me now. have guests staying and it might be considered impolite to hack late.
[00:45] <mgz> I'll try and tie up the remaining loose en...cycles this week.
[00:54] <lifeless> mgz: cool! ciao
[02:15] <m3ga> poolie: any idea how i might recover from that problem i had on friday?
[02:15] <m3ga> 'morning btw :-)
[02:38] <m3ga> poolie: don't worry about it, i managed to branch last_rev - 1
[03:46] <poolie> hi m3ga, that's just what i would have suggested
[03:47] <poolie> i think i said it on the bug
[06:44] <spiv> The divergence of the various stable branches vs. trunk was bugging me so I'm merging them up, but 2.1->2.2 is failing the trivial merge because the test for bug 192859 seems to be tripping over some sort of change in conflict handling in 2.2.
[06:52] <spiv> Ah, WorkingTree.list_files seems to need a similar fix.
[07:02] <poolie> hi spiv
[09:35] <ciss> hi, i want to temporarily version a directory that contains sub directories already versioned by svn. if i call "add", only one directory gets added (the only one not versioned by svn). if i then call "add a_versioned_directory", bzr imports the svn revisions. how can i prevent that without deleting the svn metadata?
[09:35] <fullermd> Disable bzr-svn?
[09:36] <fullermd> (via uninstalling it, or moving it aside, or use of --no-plugins, etc, depending on how drastic you care to be)
[09:42] <ciss> i have installed bazaar using the osx installer. where can i find the plugin directory?
[09:45] <fullermd> No idea.
[09:45] <fullermd> But you can use --no-plugins at any rate.
[09:45] <ciss> --no-plugins gave me a key error (?) when bazaar encountered a file name containing umlauts
[09:45] <ciss> i found the directory
[09:46] <fullermd> That's...   interesting.
[09:46] <fullermd> I know that OS X does some interesting things with character encoding.  Maybe there's a special plugin included with the installer to deal with that...
[09:49] <ciss> error and traceback: http://pastebin.com/xi2ySRAG
[09:51] <ciss> o-kay ... this is not caused by --no-plugins
[09:51] <ciss> i moved the svn plugin, added again - same error
[09:54] <ciss> found an explanation and a workaround: https://lists.ubuntu.com/archives/bazaar/2007q2/024773.html
[09:55] <ciss> so much for the "init --knit" workaround ...
[09:56] <fullermd> Without the svn plugin, I can't imagine how or why bzr would be doing anything with svn revs.
[09:56] <fullermd> You'll probably have to wait 'till jelmer is up and about.
[09:56] <ciss> this has nothing to do with the svn plugin. it's about how osx handles encoding of umlauts in file names
[09:57] <fullermd> Oh.  Yeah, that's its own little thing.
[10:00] <lifeless> NKD whatever
[10:01] <fullermd> I thought we'd handled all that in recent versions though.
[10:08] <ciss> hm ... only umlauts in directory names seem to be a problem. file names containing umlauts are added without any errors
[10:09] <fullermd> AIUI, it's not so much the presence of any particular character, but rather that OS X does normalization of the file names.
[10:09] <fullermd> So if you write a particular file name, then scan the directory, the sequence of bytes defining the file name will be different.
[10:09] <fullermd> (there being several ways you can encode various characters in Unicode)
[10:09] <lifeless> ciss: ok, so a bug in a particular code path - please do file a bug
[10:11] <ciss> lifeless, could you do that for me? i don't have a launchpad account and don't feel like registering just for a bug report
[10:11] <ciss> again, the stack trace: http://pastebin.com/xi2ySRAG
[10:12] <ciss> system is osx 10.5.8, using the 2.2 stable installer for osx leopard (python 2.5)
[10:14] <lifeless> ciss: if we don't have a reproducable test, we need to be able to contact you to work through the details until we do.
[10:14] <lifeless> so I can file a bug saying you reported the issue, but IME that means we'll eventually close it saying 'cannot reproduce or contact the reporter', which is unsatisfactory.
[10:15] <ciss> ok, i'll file one myself. might take a while though til i get to it
[10:59] <sabdfl> hi folks
[11:00] <sabdfl> http://overbenny.wordpress.com/2010/08/16/daily-builds-rock-but-bzr-imports-suck/ anybody want to lend him a hand?
[11:00] <sabdfl> are those import problems known issues?
[11:03] <jelmer> hi sabdfl
[11:04] <jelmer> sabdfl: Yes, unfortunately. The Audacious and Eclipse ones might not be too hard to fix. The Git submodules ones are harder, since they require nested tree support in bzr.
[11:09] <sabdfl> thanks jelmer
[13:01] <poolie> yeah, i think we should try to do them soon
[17:36] <knittl> hi. i tried to import an svn repository into bzr, but it crashes with a unicodedecodeerror
[17:37] <jelmer> knittl, hi
[17:37] <jelmer> knittl, can you paste the traceback?
[17:38] <knittl> just a sec
[17:38] <knittl> http://paste2.org/p/952628
[17:45]  * jelmer tries to reproduce
[17:45] <knittl> it was only in rev 1600-something
[18:11] <jelmer> knittl: fixed in bzr-svn trunk
[18:11] <knittl> that was fast
[18:11] <knittl> where's the trunk located?
[18:12] <jelmer> lp:bzr-svn
[18:12] <knittl> jelmer: thx
[18:22] <knittl> jelmer: it crashed again. i did bzr co lp:bzr-svn; cd bzr-svn; sudo python setup.py install
[18:25] <jelmer> knittl: how did it crash exactly?
[18:25] <jelmer> knittl: Are you sure it's using the bzr-svn you just installed?
[18:25] <knittl> jelmer: how can i check/select it?
[18:25] <jelmer> (bzr plugins -v will tell you, it should say "1.0.4dev")
[18:25] <knittl> it crashed the same way
[18:25] <knittl> hm no. 1.0.3
[18:25] <knittl> how can i activate the dev version?
[18:26] <jelmer> Move the checkout of lp:bzr-svn to ~/.bazaar/plugins/svn
[18:27] <knittl> i created a symlink ;) shows now the correct version. now for try 3
[18:27] <knittl> but shouldn't running setup.py install correctly set it up?
[18:28] <jelmer> knittl: Not necessarily; it picks up the first version of bzr-svn it finds
[18:28] <jelmer> you already have a system-installed bzr-svn
[18:28] <knittl> ok
[18:29] <marienz> I don't think "sudo python setup.py install" is a good idea on a package-managed system (for any python package)
[18:30] <marienz> if there's an already-installed package-managed version it'll either overwrite it (which may not work reliably if files moved or were removed) or it might install to a different directory (and the newer version might not actually be importable)
[18:31] <knittl> usually there's usr/local for that
[18:40] <jelmer> knittl, anyway, I'm off. If you can still reproduce the issue even with 1.0.4dev, please file a bug or drop me an email (jelmer at samba.dot org)
[18:41] <knittl> jelmer: it did work before. but i accidentally deleted the real folder instead of the backup :x
[18:41] <knittl> but i should get i t to work now
[18:41] <knittl> bzr: ERROR: The branch https://svn.neo-layout.org has no revision None.
[18:41] <jml> I wish WorkingTree, Branch and Repository had consistent attribute names for the base directory.
[18:50] <jml> I'd like to make a working tree that has another branch (tree?) merged into it, in order to test a script I'm writing. How would I do that most easily using bzrlib?
[18:57] <knittl> ah man. why do i use clone instead of svn-import? *facepalm*
[20:01] <lvh> Hi. In a repo with a bunch of branches, is there a bzr command I should be using instead of just rm -r for branches I no longer want to keep?
[20:02] <marienz> there's some plugin that kills unreachable revisions from the repo
[20:03] <LeoNerd> Just killing the branch won't recover much disk space, if it's a shared repo. It also wno't make the actual revisions not present any more
[20:03] <lvh> LeoNerd: I understand both of those things
[20:04] <lvh> I just dislike having a few hundred branches lying around, 99% I don't care about
[20:04] <lvh> (Mostly because they were introduced to fix a bug)
[20:04] <marienz> unfortunately I cannot find it
[20:04] <marienz> if you don't mind stale revisions still taking up some space and being recoverable if you can find their id "rm" is fine
[20:05] <lvh> They're mirrored somewhere else anyway
[20:05] <marienz> and if all those branches were merged there's nothing extra to remove
[20:05] <lvh> I was just hoping there was a bzr command that could prune a branch and get rid of the repo junk
[20:05] <marienz> remove-revisions might be it
[20:05] <marienz> but I thought there was some other thing
[20:06] <marienz> perhaps it's part of bzrtools
[20:06] <lvh> meh, it's not a big thing, I'll just rm them
[20:06] <lvh> once in a while: bzr init-repo foo & get trunk from lp :)
[20:07] <fullermd> It's probably called gc or something.  I don't think it ever got any significant distance past PoC.
[20:07] <lvh> fullermd: admittedly since the majority of those branches got merged it's not a big difference
[20:07] <marienz> yeah
[20:07] <marienz> it's only a hassle if you have a significant amount of changes that didn't get merged, or if there's something scary in those unmerged changes that you want gone from the repo
[20:10] <lvh> <- not stalin
[20:10] <lvh> I don't edit pictures or repositories for mistakes ;-)
[20:12] <fullermd> Well, it's an important thing to do in nuclear* situations.
[20:12] <fullermd> But there are plenty of conventional situations where it's more a desire than a requirement  ;p
[20:27] <rubbs> yeah, a friend of mine had to do some repo editing when his company gave him the go-ahead to open source a log analysis tool he created. Problem was he had it in the same svn repo as some of their private internal stuff. He had to manually pick out the history so he could publish it out.
[21:20] <SpookyET> Hello. Scratching my head. Is it possible to colour bzr output like hg and git?
[21:20] <SpookyET> Either through a configuration file or plugin.
[21:25] <GaryvdM> SpookyET: Which command? diff?
[21:25] <SpookyET> GaryvdM: Everything: status, diff, log, etc.
[21:28] <GaryvdM> SpookyET: There is a cdiff command from the bzrtools plugin, which you can alias to diff
[21:28] <GaryvdM> bzr shelve has color by default
[21:28] <GaryvdM> but I don't think anything else has color.
[21:28]  * GaryvdM checks if there is a bug loged
[21:28] <GaryvdM> *logged
[21:33] <GaryvdM> SpookyET: Bug 597626
[21:33] <SpookyET> Thank you.
[22:33] <poolie> good morning GaryvdM, all
[22:33] <GaryvdM> Hi poolie.