[00:00] <mwhudson> is there a ppa with a newer pqm in it somewhere?
[00:52] <mwhudson_> hey guys
[00:53] <mwhudson_> unlock really shouldn't raise an exception
[00:53] <lifeless> details details details
[01:02] <mwhudson_> also sftp sucks
[01:06] <lifeless> mwhudson_: details please
[01:07] <lifeless> mwhudson_: unlock should raise some exceptions
[01:07] <mwhudson_> lifeless: the problem was that the unlock in a finally block was raising and obscuring the reason we ended up in the finally
[01:08] <lifeless> mwhudson_: yes, that combination is annoying; OTOH its probably raising becuse the network is gone and an attempt to unlock failed
[01:09] <spiv> Hmm, ISTR Martin was working on fixing that, based on a hack I did.
[01:09] <mwhudson_> lifeless: well actually it's because of much more complicating things than that :)
[01:09] <mwhudson_> i'll probably be complaining in here when we've worked out what the details are
[01:10] <spiv> https://bugs.edge.launchpad.net/bzr/+bug/125784 is a bug report about that; I have an untested fix in the associated branch.
[01:18] <mwhudson_> the problem appears to be that unix hates me
[01:21] <lifeless> what did you do to unix?
[01:23] <mwhudson__> lifeless: fail to understand symlinks
[01:25] <lifeless> mwhudson: oops
[01:28] <mwhudson> aka the famous 'not running the code you thought you were'
[01:33] <Mez> Is there a way with bzr so that I can make it update revision numbers within the file?
[01:33] <Mez> like svn's keywords things
[01:34] <lifeless> its being developed at the moment
[02:12] <Vadi> My bzr is hosted on launchpad, and for some reason after I've commited & pushed a new revision, and the launchpad page updated properly, when people do "bzr update" it says they're OK while they're at an older revision. But if they checkout from scratch, they get the latest one fine. What can be wrong?
[02:13] <RAOF> Vadi: 'bzr update' doesn't do what you think it does.
[02:14] <Vadi> Oops. But I read the help file and thought I was getting it right. What's the proper way to update then?
[02:14] <RAOF> 'pull' (or possibly merge) is the complement of 'push'.
[02:15] <RAOF> bzr update makes sure that the working tree matches the repository.  Since their working trees already match their (local) repository, it doesn't do anything.
[02:15] <Vadi> Ohh
[02:16] <Vadi> heh, I see. Thank you
[02:16] <RAOF> _Unless_ they're using 'checkout' rather than 'branch'.
[02:16] <Vadi> It's whatever launchpad says... moment
[02:16] <RAOF> But checkout gives SVN-like behaviour, and is not what most people do with bzr branches.
[02:19] <Vadi> ﻿RAOF: Got it, thank you!
[02:48] <lifeless> hmm, someone broke test reporting.
[02:56] <lifeless> spiv: thanks
[03:04] <lifeless> spiv: its on its way
[03:24] <Vadi> Is there any way to download a file from a bzr branch without bzr? (like on a web server?)
[03:24] <lifeless> if the web server is running loggerhead or bzr-webserve
[03:24] <lifeless> then yes
[03:25] <Vadi> It is running loggerhead.
[03:26] <Vadi> Is it possible to get the file at it's latest revision though? The only links I could find on loggerhead are tied to a specific revision.
[03:27] <spiv> You can use HEAD in the URL, IIRC.
[03:28] <Vadi> Could you please give an example? Newbie here.
[03:29] <lifeless> for instance: http://bazaar.launchpad.net/~bzr-loom-devs/bzr-loom/trunk/annotate/head:/HOWTO
[03:31] <spiv> Or http://bazaar.launchpad.net/~bzr/bzr/trunk/download/head:/README-20050309040720-8f368abf9f346b9d/README
[03:33] <lifeless> spiv: can we not avoid the file-id like I did
[03:33] <lifeless> ?
[03:33] <Vadi> Is the README-2005 and whatnot part of the filename?
[03:34] <lifeless> no its a nasty url generation
[03:34] <lifeless> coming from the internal database
[03:35] <Vadi> hrm. So I turned http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/download/vadi%40ubuntu-laptop-20080505020006-hkitvfgtqoqiw2ry/imap-20080225191626-smuh5chmryg7edgm-1/IMap into http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/download/head:/IMap
[03:35] <Vadi> But that gives a 500 error
[03:35] <Vadi> And the annonate just takes forever, launchpad doesn't respond
[03:36] <spiv> lifeless: for annotate URLs, yeah, but apparently not for download URLs.
[03:36] <spiv> mwhudson: ^
[03:36]  * mwhudson is not surprised
[03:37] <mwhudson> but also not really paying attention
[03:37] <spiv> Vadi: so you'd need http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/download/head:/imap-20080225191626-smuh5chmryg7edgm-1/IMap I think.
[03:40] <spiv> Vadi: oh, and you can use "bzr cat http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/IMap" as well I think.
[03:45] <Vad1> Sorry, I got disconnected. Are there logs available for this channel somewhere?
[03:46] <poolie> Vad1: um, yes, i wonder where?
[03:47] <poolie> http://irclogs.ubuntu.com/
[03:47] <poolie> Vad1: ^^
[03:47] <spiv> Vadi: so you'd need http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/download/head:/imap-20080225191626-smuh5chmryg7edgm-1/IMap I think.
[03:47] <spiv> Vadi: oh, and you can use "bzr cat http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/IMap" as well I think.
[03:48] <Vad1> Excellent, thank you
[05:27] <bignose_> What does 'bzr cdiff' emulate?
[05:28] <bignose_> I had the impression that it was implementing behaviour from some external diff tool
[05:30] <spiv> bignose: colordiff, IIRC
[05:34] <bignose> spiv: that's the one, thank you
[06:04] <berto-> i'm trying to use the fast-import plugin to import a git repository using git-fast-export v1.5.4 and v1.5.5.1  I get a MemoryError at File "/Users/berto/.bazaar/plugins/fastimport/parser.py", line 225, in read_bytes.  Any ideas?
[06:18] <jamesh> berto-: looks like https://bugs.edge.launchpad.net/bzr-fastimport/+bug/194572
[06:20] <jamesh> berto-: the method in the last comment might help you
[06:41] <lifeless> tchau, I'm done for the day
[07:26] <berto-> jamesh: i tried dumping the info to a .cfg file, but that didn't work.  but, i read it worked on a linux box and just did it that way.
[07:27] <berto-> jamesh: thanks!  i now have my git repo migrated.  :)
[07:27] <berto-> my repo had two branches which were empty and I ran bzr update on them, now they have the files.  is there a way to empty them again?
[07:28] <jamesh> berto-: "bzr remove-tree" will remove the working tree files, leaving the branch data behind
[07:29] <berto-> jamesh: wonderful!  thanks.
[07:38] <berto-> i'm liking this already, bzr makes branches directories and i can see more than one at a time!  :-D
[08:18] <vila> lifeless: regarding pqm hanging, I've filled bug #226769 and sent a mail to the bzr ML, feedback welcome
[08:37] <berto-> i installed paramiko and python-crypto, but keep getting, "ERROR: Not a branch"
[08:37] <berto-> any ideas?
[08:38] <berto-> uhh, sorry, can't explain my problem tonight.  I'm using an sftp:// url
[08:40] <berto-> ah, figured it out.  I had to fully path my repository rather than relative to my home dir.
[08:40] <bob2> how sure are you that it is a branch?  ie does 'echo "ls /path/to/branch/.bzr" | sftp hostname' show it contains a 'branch' dir?
[08:48] <spiv> berto-: you can use "sftp://host/~/path" for an sftp URL relative to your home dir.
[09:01] <berto-> spiv: cool, i'll remember that.
[09:04] <berto-> my sftp:// connection keeps on failing with a "server connection dropped".  is there anything I need to configure for sftp to work properly?
[09:07] <berto-> odd.  i had to fully define user@<full hostname> instead of using the name setup in my .ssh/config file.
[09:08] <Peng> (Why doesn't the ~ thing work for bzr+ssh? Would it be difficult to add?)
[09:21] <berto-> what's the best way to import an svn repository?
[09:25] <poolie> Peng: not sure why technically, it should be straightforward
[09:30] <lifeless> Peng: just needs someone to do it
[09:34] <Peng> After the path issues with bzr+http, I was afraid it would be really complicated somehow.
[09:34] <Peng> Not that this means I'm going to volunteer..
[09:35] <Peng> berto-: Probably bzr-svn.
[09:43] <berto-> peng: i'm getting a maximum recursion error.  :(
[10:00] <Peng> berto-: Latest version of bzr-svn? 0.4.9, I think.
[10:00] <berto-> Peng: yep, just downloaded it.
[10:01] <berto-> actually, it's 0.4.10exp0
[10:01] <Peng> Heh, ok.
[10:01] <Peng> That sounds like you're using a bzr branch of it directly. I didn't know that was in working order.
[10:02] <berto-> hmm ..
[10:06] <berto-> looks like svn2bzr is working.
[10:25]  * mtaylor is away: I'm not here right now
[10:26] <Peng> berto-: But bzr-svn is much cooler. And more powerful.
[10:26] <berto-> peng: i'm sure it is, but it's broken [for me at least].  so it's not an option.
[10:27] <berto-> peng: as long as i get the data migrated, i don't need two-way communication.
[10:29] <Peng> berto-: Well, I still think you should see if you can get help from I-don't-want-to-highlight-him-again. Does this absolutely have to be finished right now?
[10:29] <Peng> bzr-fastimport also looks nifty.
[10:29] <Peng> Anyway, whatever.
[10:29] <berto-> peng: yep, tried that one too, but svn2bzr actually worked better.
[10:29] <berto-> Peng: i really appreciate you helping.
[10:30] <berto-> Peng: and, no, it doesn't have to be finished right now.  i'm just researching.
[10:30] <Peng> berto-: Ok.
[10:30] <Peng> berto-: You should file a bug for the error you got with bzr-svn. https://bugs.launchpad.net/bzr-svn
[10:31] <berto-> yeah, i will.  thanks.
[10:38] <berto-> nite, all.
[10:38] <berto-> peng: thanks again.
[10:42] <Peng> What exactly is he thanking me for?
[10:43] <poolie> for pointing him to the bug tracker i guess
[10:56] <emgent> morning
[10:57] <poolie> hello
[13:04] <jelmer> dato, ping
[13:04] <dato> haha, pong
[13:04] <dato> ("haha", because I just arrived home after being from irc many many hours :P)
[13:04] <jelmer> wow, that was quick :-)
[13:04] <dato> being away I meant
[13:05] <jelmer> heh
[13:05]  * jelmer is psychic
[13:06] <jelmer> dato, any chance you can sponsor an upload of bzr-gtk at some point?
[13:07] <dato> sure
[13:07] <dato> I can add D-U-A as well
[13:07] <jelmer> dato, thanks, that'd be useful
[13:07]  * dato thought it was already there
[13:08] <jelmer> I added it yesterday in the bzr branch
[13:08] <dato> ok
[13:08] <dato> so, uhm, is the branch ready for an upload?
[13:08] <jelmer> but nothing has been uploaded with it yet
[13:09] <jelmer> yep
[13:09] <dato> ok, noted in TODO
[13:10] <dato> I'll need to catch up with other stuff first, though
[13:11] <jelmer> no hurry :-) Thansk
[13:15] <dato> jelmer: btw in debian/control you have to write "XS-DM-Upload-Allowed: yes", not just "DM-Upload-Allowed: yes"
[13:16] <jelmer> dato: afaik DM-Upload-Allowed is in the properly defined control fields list now
[13:16] <dato> ah
[13:16] <dato> ok
[13:18] <jelmer> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453400)
[13:19] <jelmer> ooh, ubottu supports debian bugs as well now?
[13:23] <dato> for a long long time I think
[13:30] <poolie> hello dato, jelmer
[13:31] <jelmer> hey poolie
[13:37] <poolie> night
[14:16] <ChristopheT> Is there somewhere some documentation about the various formats as well as rationale for them?
[14:17] <jam> good morning
[16:47] <cr3> if I bzr removed a file and I can't remember the exact path and I don't remember the log message I used, how can I track which revision I need to recover?
[16:47] <andrea-bs> cr3: do you know the revision number?
[16:47] <andrea-bs> argh, no :D
[16:48] <cr3> andrea-bs: heh, of course not :)
[16:48] <andrea-bs> cr3: what do you know of this file?
[16:48] <cr3> andrea-bs: the file name, and I can confirm the name is under the .bzr directory
[16:49]  * fullermd shrugs
[16:49] <fullermd> bzr log -v | less    [search for filename]
[16:51] <cr3> fullermd: that worked! it just so happened I did not the path name of the file but bzr log only returned an error message: Path does not have any revision history:...
[16:52] <cr3> fullermd: just in case I typoed, I pasted the path from bzr log -v and I still get the same error message
[16:52] <cr3> is bzr log supposed to work with files which have been deleted?
[16:52] <fullermd> Well, supposed to or not, it doesn't.  It uses the path to look up the file-id from the current tree, so on deleted files...
[16:53] <fullermd> You may be able to `revert -r<revbeforeremoved> $FILE` and then `log $FILE`, I'm not sure.  You can do a lightweight checkout of the rev before it was removed, then log from that checkout.
[16:54] <fullermd> See https://bugs.launchpad.net/bzr/+bug/175520  (which has nothing other than a "hey, this doesn't work", sadly, but it's filed anyway)
[16:54] <fullermd> I'm of the opinion that you should be able to pass a file-id into `log` so you can unambiguously refer to a specific file, regardless of renames or deletions, from any point.
[16:55] <dato> jelmer: I uploaded bzrtools, also with d-u-a
[16:56] <cr3> hm, I can appreciate the problem where a file may have been removed and then created again, at which point log perhaps should or should not encompass the previous file
[16:56] <jelmer> dato, ah, awesome.
[16:56] <jelmer> dato, I'm working on bzr-svn atm, I guess that just leaves bzr-builddeb outdated
[16:56] <dato> jelmer: hm
[16:57] <fullermd> cr3: Well, there are 2 distinct cases.  One is where a file exists, is removed, and another file with the same name (but a different file) is added.  The other is when a file exists, is removed, and is resurrected (e.g. by 'revert'), so it's the same file, it just didn't exist in some revs in the middle.
[16:57] <dato> jelmer: I guess I forgot to add you as a bzrtools uploader
[16:57]  * jelmer wonders where james_w went
[16:57] <fullermd> cr3: 's where the file-id is useful to disambiguate.
[17:45] <hsn_> its recommended to use bzr pack in production? does it any noticeable good
[18:01] <fullermd> Hm.
[18:02] <fullermd> % time HEAD http://bazaar-vcs.org/
[18:02] <fullermd> [...]
[18:02] <fullermd> 0.212u 0.141s 2:59.30 0.1%      1+583k 11+0io 0pf+0w
[18:02] <fullermd> That's usually a bad sign...
[18:02] <vila> phanatic: ping
[18:09] <phanatic> vila: pong
[18:09] <vila> phanatic: what is the status of the po/ directory in gtk ?
[18:09] <vila> I had a look at genpot.sh but it seems rather out of date
[18:10] <phanatic> vila: it can be translated via the olive product in rosetta.
[18:10] <phanatic> yes, it is outdated :)
[18:10] <phanatic> we should care more about translations
[18:10] <vila> I've update it to include all .py files in all relevant directories
[18:10] <vila> s/update/updated it/
[18:10] <phanatic> oh, thank you :)
[18:10] <vila> I was wondering if po/olive-gtk.pot was still the base for the translations...
[18:12] <phanatic> it is the version that was last uploaded to rosetta
[18:13] <vila> I don't know how this works, but as long as I left the msgid and msgstr untouched I can modify the rest ? The order ? Add new ones ?
[18:13] <vila> I,m searching a way to check that renaming '_' to '_i18n' doesn't blow everything
[18:14] <vila> nevermind, I found a way
[18:16] <phanatic> vila: the pot file should be generated automatically
[18:16] <vila> yes, but it appears that xgettext updates it a bit too smartly to allow me to use it as a check :)
[18:17] <vila> i.e. if branch.py uses _("_Branch") and I change it to _i18n("_Branch") I can't know if xgettext updated it or not :)
[18:17] <vila> I'll generate different pot files for that before and after my patch to check
[18:25] <vila> phanatic: do you know the irc nick of daniel ?
[18:26] <fullermd> vila: You mean Odd_Bloke?
[18:26] <phanatic> vila: schierbeck?
[18:27] <vila> lol, Odd_Bloke *is* daniel schierbeck ?
[18:27] <vila> Odd_Bloke: ping
[18:28] <Odd_Bloke> I'm Daniel Watkins.
[18:29] <vila> haaa, hi Daniel :)
[18:29] <Odd_Bloke> vila: o/
[18:30] <vila> Sorry for the confusion, sometimes on IRC you receive bad advices :)
[18:31] <vila> well, anyway, I was wondering why the other daniel was using '# -*- coding: encoding -*-' constructs which are obsolete in emacs.... and I realized  that it's still the recommanded way to instruct python about the source file encoding...
[18:32] <vila> The nice thing about standards.... is when two communities use the same forgetting to inform the other one about the changes :)
[18:47] <fullermd> Ah, well.  Obviously there are too many Daniels around   :p
[18:47] <beuno> anyone know what this might be?  bzr: ERROR: bzrlib.errors.KnitCorrupt: Knit <bzrlib.knit.KnitGraphIndex object at 0x861860c> corrupt: attempt to add line-delta in non-delta knit
[18:48] <vila> beuno: search the nailing list, I'm pretty sure there is a patch for that
[18:49] <vila> s/nail/mail/ :-P
[18:49] <beuno> vila, aaah, cool, thanks  (maybe the bug should be reported?)
[18:50] <fullermd> I'm pretty sure it's fixed in .dev.
[18:50]  * beuno tries
[18:57] <beuno> vila, fullermd, it's fixed in .dev, thanks  :)
[18:57] <vila> yv
[18:58] <beuno> it's odd that got into 1.4
[19:27] <jelmer> hmm. fetching from a remote subversion server to rich-root-pack is faster than from local pack-0.92-subtree to rich-root-pack !?
[19:31] <Peng> * is faster than fetching from pack-0.92-subtree to rich-root-pack.
[19:31] <Peng> Converting to git and back, recommitting each revision, ...
[19:52] <sidnei> anyone can help me debug why bzr commit to a svn master branch (using bzr-svn plugin) seems to hang only with a certain repository?
[19:53] <jelmer> sidnei: What version are you using?
[19:53] <sidnei> of the plugin or bzr?
[19:54] <jelmer> both
[19:55] <sidnei> Bazaar (bzr) 1.3.1
[19:55] <sidnei>   Python interpreter: C:\Program Files\Bazaar\python25.dll 2.5.2.final.0
[19:55] <sidnei>   Python standard library: C:\Program Files\Bazaar\lib\library.zip
[19:55] <sidnei>   bzrlib: C:\Program Files\Bazaar\lib\library.zip\bzrlib
[19:55] <sidnei>   Bazaar configuration: C:\Documents and Settings\Sidnei\Application Data\bazaar\2.0
[19:55] <sidnei>   Bazaar log file: \\.PSF\.Home\Documents\.bzr.log
[19:56] <sidnei> svn plugin is 0.4.9
[19:59] <jelmer> can you try running with -Dtransport ?
[20:00] <jelmer> It should tell you what it's doing in ~/.bzr.log
[20:00] <sidnei> ok
[20:02] <sidnei> jelmer:  i see lots of 'svn ls -r X <path>'
[20:03] <sidnei> jelmer: where X is an incrementing number and <path> seems to be each project in that repository + tags/branches/trunk
[20:03] <jelmer> sidnei, yeah, that's probably correct
[20:04] <sidnei> jelmer: apparently its going throw revisions, the problem is that this is a large repo with 300 projects 60k+ revisions
[20:04] <sidnei> s/throw/through
[20:04] <sidnei> jelmer: why is it doing that? to discover the repo layout?
[20:04] <jelmer> sidnei: it's going to do this once and will cache the results
[20:04] <jelmer> 0.4.10 will be better in this regard
[20:04] <sidnei> oh, ok.
[20:04] <sidnei> at this speed its going to take about a day though :)
[20:16] <sidnei> jelmer: there's no way to make it skip that?
[20:16] <jelmer> sidnei: not in 0.4.9, no
[20:17] <sidnei> jelmer: ok, i guess i will just let it finish then
[20:52] <_paneb> a repository is where i can store many branches right?
[20:54] <MattCampbell> Yes, if it's a shared repository created with "bzr init-repository".
[21:00] <_paneb> i am looking at "Choosing a shared repository layout" but i am confused about how to actually create those layouts. it all starts by doing bzr init-repo MyRepo?
[21:01] <_paneb> section 5.2 (Publishing a branch) is how to do it, right?
[21:20] <MattCampbell> I wonder how easily one could port bzr to IronPython.  I was thinking that might be useful for the Visual Studio integration package, which is currently written in C#.
[21:25] <Peng> MattCampbell: People have looked into this. Mainly, isn't IronPython startup horribly slow? Also, it's missing several modules from the stdlib that bzr uses.
[21:26] <sidnei> look at fepy (ironpython + stdlib)
[21:33] <sidnei> jelmer: seems like it finished with the svn ls thingie, 89 minutes :)
[21:35] <sidnei> jelmer: now the process is at 90% and there's lots of io going on, i guess it's writing the cache?
[21:36] <sidnei> (90% cpu that is)
[21:40] <MattCampbell> Peng: One would need to measure the startup time of IronPython (or FePy) in an already running application that uses in .NET.  Also, consider that in a long-running app with a plug-in, such as Visual Studio, the startup overhead would only be incurred once per session, not once per action as with the command line.
[21:43] <MattCampbell> Anyway, it was just a tought; I thought it would be useful to be able to write the Visual Studio integration in Python, with less glue code than the current C# implementation.
[21:44] <wam> I'm using bzr all over and want to give my customers access to their bzr repository via www. Is loggerhead the best choice? At least I find it beautiful ;)
[21:45] <jam> wam: if you just want them to have access, you only need plain Apache
[21:46] <wam> jam: I want them to make diffs and see logs
[21:46] <jam> if you want them to be able to browse the repository with a web browser, then yes, loggerhead is probably the best choice
[21:46] <jam> It is the most actively maintained, IIRC
[21:46] <wam> jam: is there active development? I see the last log is from 2007...
[21:46] <jam> wam: I believe so, I'm not sure where the latest changes are
[21:47] <wam> jam: ok, thanks
[21:47] <jam> wam: according to: https://edge.launchpad.net/loggerhead/trunk
[21:47] <jam> there was a release of 1.2.1 on 2008-03-06
[21:47] <wam> jam: wow - I didn't know that url
[21:48] <jam> And https://code.edge.launchpad.net/~loggerhead-team/loggerhead/trunk says that there were 3 changes in the last month
[21:48] <jam> wam: what url were you using?
[21:48] <wam> jam: http://www.lag.net/loggerhead/
[21:48] <jam> just to make sure we update a pointer
[21:48] <jam> wam: right, robey has given over development to others
[21:48] <wam> jam: i see
[21:48] <jam> wam: where did you get the link to lag.net
[21:49] <jam> wam:  I believe the latest version is running at: http://bazaar.launchpad.net/~bzr/bzr/trunk/changes
[21:50] <wam> jam: search "web" on http://bazaar-vcs.org/ and the 4th hit is http://bazaar-vcs.org/WebInterface?highlight=%28web%29
[21:50] <wam> jam: alright, thanks. I'll try that
[22:02] <lifeless> moin jam
[22:03] <jam> lifeless: morning
[22:06] <_paneb> how would i create the shared repository used for distributed development? like so? 1- on a server: bzr init-repo X; bzr init foo, and 2- on a workstation: bzr branch stfp://server-address/foo?
[22:08] <Peng> _paneb: The sftp path is relative to the root of the server, but otherwise, yeah.
[22:09] <Peng> _paneb: You'd also probably want/need to specify a user.
[22:09] <_paneb> right right, i was just wondering about the commands
[22:10] <_paneb> so when creating the main repository, there is not difference with creating the main repo. for centralized development?
[22:10] <_paneb> it is just the way you work with the main repo which changes?
[22:11] <Peng> _paneb: Yeah.
[22:11] <_paneb> ok
[22:18] <MattCampbell> Given that bzr-cvsps-import claims to only support local CVS repositories so far, is it possible to import the CVS repository of a project for which you're not an administrator?  I'm wondering specifically about SourceForge.net projects that never switched to svn.
[22:32] <lifeless> MattCampbell: sf publish tarballs of the cvs repositories anonymously
[22:45] <lifeless> jam: ping
[22:45] <jam> lifeless: pong
[22:45] <lifeless> jam: how do you feel about removing the C knit parser?
[22:47] <jam> lifeless: Seems ok. As knits performance is sort of going down the tubes anyway, it probably won't help much soon.
[22:47] <lifeless> (It doesn't feel like _load_data is relevant for packs, and for older code I weight maintenance clarity much more)
[22:48] <jam> lifeless: well, ATM I feel like pack index performance is penalized by something other than the time to parse them
[22:48] <jam> I don't know if when we fix it we will find we want something there as well
[22:48] <poolie> hello jam
[22:48] <jam> but certainly loading knit indexes isn't going to be a primary concern going forward
[22:48] <jam> hi poolie
[22:48] <poolie> hello lifeless
[22:49] <poolie> lifeless: that would further increase my desire to give people a warning to upgrade
[22:49] <lifeless> poolie: I thought we agreed on the list to do such a warning a couple weeks back :)
[22:50] <poolie> someone should write it hey? :)
[22:50] <lifeless> yup
[22:51] <poolie> vila has a patch that disables some strace tests, is that ok with you in principle?
[22:53] <lifeless> mmm
[22:53] <lifeless> why?
[22:53] <jam> lifeless: because it hangs the test suite when you have a thread lying around
[22:54] <lifeless> jam: I remember we had issues with that; so why are we leaving a thread lying around?
[22:55] <jam> lifeless: it is one of the bugs we have open
[22:55] <jam> I think there is even a FIXME about it
[22:55] <jam> if you look at vincent's recent posts he talks about it
[22:56] <lifeless> I'd really rather not have disabled tests; if a separate bug is the core issue, can we not fix that?
[22:57] <lifeless> can we check that there is only one thread in the process before the strace test, and fail the test in that case?
[22:59] <MattCampbell> Is it even possible to count the threads in a process in Python?
[22:59] <lifeless> MattCampbell: doesn't matter if it isn't possible
[22:59] <lifeless> MattCampbell: we can at worst manually track them
[23:00] <jam> I believe there is something in the threading package
[23:00] <jam> lifeless: threading.activeCount()
[23:00] <poolie> lifeless: the thing is that the strace functions are not even used at present
[23:04] <lifeless> poolie: I use them from time to time
[23:04] <lifeless> poolie: its like saying lsprof isn't even used. Its not used except when it is used.
[23:05] <lifeless> Its really quite useful being able to strace a single function call
[23:05] <MattCampbell> Given that bzr itself doesn't use the strace functions, and they're probably only intended as instrumentation for performance tuning anyway, I don't think it makes sense to run the strace tests by default.  But of course, I'm new here and just a bzr user, so what I say probably doesn't have much weight.
[23:05] <lifeless> MattCampbell: untested code is broken code
[23:06] <lifeless> MattCampbell: most code isn't run by most users most of the time, so by the same style of argument we shouldn't run tests for most of our code
[23:09] <lifeless> vila: please don't merge it for a little bit
[23:10] <lifeless> vila: I'm not going to veto, but I want time to suade people
[23:10] <jam> lifeless: you should probably reply to the thread, since poolie has bb:tweak ed it
[23:10] <lifeless> jam: I have replied
[23:10] <jam> lifeless: just got it :)
[23:11] <lifeless> anyhow, I think all tests should check for the activeCount at the start of the test, and assert its unchanged at the end
[23:11] <lifeless> this will catch faulty tests and avoid the error condition breaking the strace test
[23:13] <MattCampbell> Of course, this assumes that all threads in the process except the main thread are started via the threading module.
[23:13] <jam> MattCampbell: sure, but I believe for the threads we care about, that is true
[23:14] <lifeless> MattCampbell: given that we have complete control over the environment
[23:14] <lifeless> MattCampbell: I think this is a fair assessment
[23:17] <jam> i feel like there might be extra threads, but they should have been spawned by one of our own threads
[23:18] <lifeless> the most likely one I can think of is sftp access threads
[23:18] <lifeless> but AFAICT paramiko is pretty darn good at housekeeping
[23:26] <poolie> lifeless: maybe we should change the strace function itself to assert there are no threads?
[23:26] <poolie> well, no more than 1 thread
[23:26] <poolie> :)
[23:29] <MattCampbell> I think it would be better to check the count before and after each test; that should make it easier to find the culprit.
[23:34] <poolie> MattCampbell: well, yes but very little code runs _between_ one test and the next
[23:36] <MattCampbell> But how far away in the sequence of tests is the strace test from the test that's leaving a thread lying around?  Do we know?
[23:40] <lifeless> poolie: between is not needed, just the last things done in tearDown()/cleanUp()
[23:40] <lifeless> poolie: the first cleanup added can be a lambda to check the count
[23:59] <poolie> lifeless: exactly
[23:59] <poolie> ok, that sounds nice