[06:08] <poolie> back
[06:16] <beuno> igc, now that I think of it, was in inapropriate for me to use your slides?   it just occured to me you might not of wanted them out yet
[08:00] <poolie> spiv, hi?
[08:08] <spiv> poolie: hello
[08:08] <spiv> poolie: I'm just replying to your review; it'll be on the list in a moment.
[08:10] <spiv> poolie: sent.  I'm a bit unclear about what you wanted done to the test_suite generation.
[08:13] <poolie> ok
[08:13] <poolie> i guess basically i would rather that test_suite() methods were not using testloaders and so on them selves
[08:14] <spiv> So you'd like the loader.loadTestsFromModuleNames to be elsewhere?
[08:15] <poolie> hm
[08:16] <spiv> And maybe direct calls to scenario_applier.adapt too?
[08:16] <poolie> am i correct in thinking that the test_check_reconcile tests are meant to be run once per (format, scenario) pair?
[08:16] <spiv> Right.
[08:17] <poolie> why can't you do two calls to multiply_xxx
[08:18] <poolie> one for the reconcile tests, and one for everything else?
[08:18] <spiv> I can, although that means figuring out what the interface to mulitply_xxx should be :)
[08:19] <poolie> what is wrong with the current one?
[08:19] <spiv> It also means leaving a "# test_check_reconcile is intentionally omitted from this list because it is parameterised further down." comment in the main list of modules.
[08:20] <poolie> ok
[08:20] <spiv> (that was one of the minor annoyances that lifeless' suggestion avoided)
[08:20] <spiv> By the current one you mean "adapt_modules"?
[08:20] <poolie> though, really to me that suggests
[08:21] <poolie> maybe it's bad to have an exception here to the rule that every test within a subdirectory is run through the same parameters
[08:21] <spiv> Yeah, that's a good point.
[08:21] <poolie> i mean multiply_tests_from_modules
[08:22] <poolie> but since this isn't a different implementation, just a different test, it doesn't seem to need its own directory
[08:22] <spiv> Well, I'm not sure what you meant the interface for multiply_tests_from_modules to be, precisely.
[08:22] <poolie> that function already exists in tests/__init__
[08:22] <spiv> Oh.
[08:23] <poolie> i think adding such a comment that test_check_reconcile is special
[08:24] <spiv> I can certainly use that to at least improve the way I combine the disk format scenarios and the remote scenario.
[08:24] <poolie> is no worse than the current list with [format_applier]  repeated for each module but that
[08:25] <poolie> right, you can just pass in the concatenated lists rather than making an applier object
[08:25] <poolie> then
[08:25] <spiv> But multiply_tests_from_modules doesn't do the cross product I need for the other part.
[08:25] <poolie> no, you need to generate the cross product in making your scenario list
[08:25] <spiv> it multiplies tests by scenarios.
[08:25] <poolie> for scenario_class in brokenness_scenarios:
[08:25] <spiv> Right, I need to make a cross product of the scenarios.
[08:26] <poolie>   for repo in all_repo_scenarios:
[08:26] <spiv> I can do that too, it just didn't occur to me and I didn't realise that's what you were suggesting :)
[08:26] <poolie>      scenarios.append(..., )
[08:26] <spiv> Ok, I understand now :)
[08:26] <poolie> ok
[08:26] <poolie> that actually makes it easier to trim out the repositories that don't make sense to test
[08:26] <spiv> I'm not sure why I didn't know about multiply_tests_from_scenarios sooner.
[08:27] <poolie> well, it's relatively new and not used everywhere
[08:27] <spiv> Yeah, rather than generating a bunch of tests that are doomed to skip.
[08:27] <poolie> i think it's a lot simpler than the lower level code though
[08:27] <spiv> Yeah, that will be an improvement.
[08:27] <poolie> i should probably go and update the existing callers to make them use this
[08:27] <poolie> um
[08:28] <spiv> (and it deals with my concerns about the coupling of module loading and scenario application in adapt_modules too)
[08:28] <poolie> i think it might actually be nicer if the applicability of scenarios was described on the class, not in test_suite()
[08:28] <poolie> so your brokenness tests would just be
[08:28] <lifeless> mmm
[08:28] <poolie> class:
[08:28] <lifeless> I think that couples things still wrongly
[08:28] <poolie>   repeat_per_scenario = [every_repository, every_brokenness] 
[08:29] <lifeless> it couples the interface of the scenario with the application
[08:29] <lifeless> I think that would be a mistake
[08:29] <poolie> what is 'that'?
[08:29] <poolie> putting them in the class?
[08:29] <lifeless> yes
[08:30] <poolie> i don't understand you
[08:30] <lifeless> uhm
[08:31] <lifeless> I'm focused on my refactoring right now
[08:31] <lifeless> I'll try to express myself better tomorrow or something
[08:48] <lifeless> k folk, I'm off
[08:48] <lifeless> poolie: 60% now I think.
[09:38] <raddy> Hello Everybody
[09:38] <raddy> Is it possible to browse and download latest commits via browser?
[09:41] <zorg_the_false> raddy: yes there are several web front-end on the website
[09:42] <zorg_the_false> in the 3rdpartyapps section if i remember correctly
[09:43] <mwhudson> i'm not sure what downloading a commit involves
[09:43] <raddy> zorg_the_false: is the web front end needs to be installed in the server or in client?
[09:43] <mwhudson> but browse, sure
[09:44] <zorg_the_false> raddy: dunno
[09:47] <thumper> raddy: what do you mean exactly?
[09:48] <raddy> thumper: see, i want to download latest code from bzr using project, is it possible via web browser?
[09:49] <thumper> raddy: and what do you hope your web browser will show you?
[09:50] <raddy> thumper: the file. or latest changes, kind of websvn
[09:50] <thumper> ok, and you want to see the latest changes of bzr?
[09:50] <raddy> thumper: also want to download the specific file
[09:51] <thumper> raddy: http://codebrowse.launchpad.net/~bzr/bzr/trunk/changes
[09:52] <zorg_the_false> hehe go look  on the site
[09:52] <zorg_the_false> you got screenshots and all
[10:12] <i386> lifeless: ping
[10:17] <lucasvo> hi
[10:17] <lucasvo> my bzr doesn't run because of unsupported locales settings
[10:18] <poolie> hi lucasvo
[10:18] <poolie> i386, he's left
[10:18] <poolie> lucasvo, well, you should either set your locale to one that's supported on your machine
[10:19] <poolie> eg by LANG=C or LANG=en_AU.utf-8 or something
[10:19] <poolie> or enable that locale
[10:19] <poolie> on linux, that's often controlled by /etc/localegen.conf or something similar
[10:20] <lucasvo> poolie: http://pastebin.com/m578c789e
[10:21] <poolie> are you on ubuntu or debian?
[10:21] <poolie> sudo dpkg-reconfigure locales?
[10:21] <lucasvo> poolie: ubuntu dapper
[10:21] <poolie> what locale do you want to use?
[10:22] <lucasvo> en_USA
[10:22] <poolie> i think you mean en_US
[10:22] <poolie> or rather en_US.utf-8
[10:22] <poolie> not sure
[10:23] <lucasvo> yes
[10:24] <lucasvo> poolie: the dpkg-reconfigure did not work
[10:26] <poolie> is en_US.utf-8 working in other situations on your machine
[10:26] <poolie> ?
[10:30] <i386> poolie: ahh thanks
[10:34] <lucasvo> poolie: how can I set it?
[10:39] <poolie> to set the locale for your shell, just do
[10:40] <poolie> export LANG=en_US.utf-8
[10:40] <ubotu> New bug: #151208 in bzr "util/configobj should be deleted" [Undecided,New]  https://launchpad.net/bugs/151208
[10:40] <poolie> to set it for your whole session, which is generally what you want, choose the right thing from the gdm language menu
[06:03] <smartgpx> Is the author of the mini tutorial online and available, please?
[07:40] <ubotu> New bug: #151353 in bzr-eclipse "Package renaming fails" [Undecided,New]  https://launchpad.net/bugs/151353
[07:45] <ubotu> New bug: #151356 in bzr-eclipse "Invalid value in project properties" [Undecided,New]  https://launchpad.net/bugs/151356
[07:56] <ubotu> New bug: #151357 in bzr-eclipse "Better detection of lack of bzrxml plugin" [Undecided,New]  https://launchpad.net/bugs/151357
[08:35] <ubotu> New bug: #151371 in bzr-eclipse "bad char at end of log messages" [Undecided,New]  https://launchpad.net/bugs/151371
[08:44] <jam-laptop> wow, I finally come back to #bzr and nobody is around talking
[08:44] <jam-laptop> Has the conversation gone away since I left?
[08:46] <Peng> ubotu's still talking. :)
[08:57] <Peng> [14:46:28]  <ubotu> Error: I am only a bot, please don't think I'm intelligent :)
[08:57] <Peng> Huh.
[08:57] <Peng> I should start saying that to people/
[09:41] <james_w> jam-laptop: hi. how are you?
[09:41] <jam-laptop> !ubotu how are you
[09:41] <ubotu> Sorry, I don't know anything about how are you - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[09:42] <jam-laptop> ubotu help me
[09:42] <ubotu> I am ubotu, all-knowing infobot. You can browse my brain at http://ubotu.ubuntu-nl.org/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots
[09:42] <jam-laptop> ubotu you rock
[09:42] <ubotu> Sorry, I don't know anything about you rock - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[09:42] <jam-laptop> james_w: Doing pretty well. Trying hard to get enough sleep :0
[09:42] <james_w> that must be tough.
[09:43] <jam-laptop> It can be, depends on the day.
[09:43] <james_w> it's good to have you back though.
[09:44] <james_w> the channel has seemed quieter on the user help front, but busier on development during .au time.
[09:45] <jam-laptop> yeah, it has been good to see Martin doing more work lately.
[09:45] <jam-laptop> :)
[09:45] <jam-laptop> He has certainly been active at bug triage.
[09:45] <james_w> it's not that questions aren't being answered, but it seems we have less easy errors to make.
[09:45] <james_w> yeah, that's been great to see, the bug list did need some tending.
[09:59] <fullermd> jam-laptop: Hey dere, welcome back.  How's the family?
[10:00] <jam-laptop> Pretty good
[10:02] <fullermd> Eggcelent.
[10:59] <bialix> !ubotu bzr
[10:59] <ubotu> bzr is Bazaar-NG, a decentralized revision control system designed to be easy for developers and end users alike. Decentralized revision control systems give people the ability to work over the internet using the bazaar development model.  See http://bazaar-vcs.org/QuickHackingWithBzr for a quickstart guide.
[11:00] <bialix> !ubotu windows
[11:00] <ubotu> For help with Microsoft Windows, please visit ##windows or your nearest mental health institute. See http://launchpad.net/distros/ubuntu/+bug/1 http://linux.oneandoneis2.org/LNW.htm and !equivalents
[11:00] <bialix> nice
[11:00] <bialix> !ubotu python
[11:00] <ubotu> Sorry, I don't know anything about python - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[11:08] <bialix_> jam?
[11:08] <jam-laptop> bialix_: hi
[11:08] <bialix_> hi
[11:09] <bialix_> do you saw new version of Pyrex announce?
[11:09] <jam-laptop> yeah, seems interesting
[11:09] <jam-laptop> I'm not really sure how to maintain compatibility
[11:10] <jam-laptop> For now, I think we just try to avoid __new__
[11:10] <jam-laptop> And live with the warning
[11:10] <jam-laptop> (maybe add a comment about why we aren't switching yet)
[11:10] <jam-laptop> The problem is that we are dependent on the platform to ship the right version of pyrex
[11:10] <jam-laptop> to go along with bzr
[11:10] <jam-laptop> so it is better to expect <0.9.6 until 0.9.6 has been out for a while.
[11:10] <bialix_> plaform -- you mean Ubuntu?
[11:11] <jam-laptop> or windows
[11:11] <jam-laptop> or mac
[11:11] <jam-laptop> or RH
[11:11] <jam-laptop> or ...
[11:11] <jam-laptop> Whoever is compiling Bazaar
[11:11] <bialix_> well, IIUC, the real problems occurs with 0.9.7
[11:11] <jam-laptop> right
[11:11] <jam-laptop> Is there an expected time for 0.9.7?
[11:12] <bialix_> I don't think so
[11:12] <jam-laptop> We also can ask the packagers to make it depend on <=0.9.6
[11:13] <bialix_> author of Pyrex (Greg) is very peculiar person, as I can see from Pyrex ML
[11:13] <bialix_> there is Cython though
[11:13] <bialix_> but I'm not sure how well they solve windows-compatibilty problems
[11:14] <dato> don't packagers just compile the .c files shipped in the tarballs?
[11:14] <bialix_> (and Cython use hg)
[11:14] <dato> (at least debian and ubuntu do that)
[11:14] <jam-laptop> Well, at the moment we use __new__ in a couple places, but they could just as easily be done in __init__
[11:15] <bialix_> may be switch to __init__ will be enough
[11:17] <jam-laptop> well, it will get us through for now, I think
[11:18] <bialix_> I forget: what's important difference between new and init in Pyrex?
[11:18] <jam-laptop> __new__ happens before __init__
[11:18] <jam-laptop> It gives you a chance to initialize your C structures
[11:18] <bialix_> aha
[11:18] <jam-laptop> before the Python object is created, IIRC
[11:18] <jam-laptop> But we don't really need it
[11:19] <jam-laptop> I just did a quick "s/__new__/__init__/" and "make; ./bzr selftest test_knit test_dirstate" still works
[11:20] <jam-laptop> bialix_: do you want to submit a patch to the mailing list?
[11:20] <jam-laptop> vila: ping
[11:20] <bialix_> not now
[11:20] <jam-laptop> k, I'll send something
[11:21] <bialix_> btw, just looking at cdef class Reader
[11:21] <bialix_> there is something suspicious
[11:21] <bialix_> self.text_size = PyString_Size(text)
[11:22] <bialix_> actually self.text_size is int, but PyString_Size returns ssize_t
[11:22] <bialix_> it's nitpicking though
[11:22] <jam-laptop> Except for in Python2.4 when it is still int
[11:22] <jam-laptop> So I didn't worry about it
[11:22] <bialix_> I like that Pyrex now handle ssize_t natively
[11:22] <jam-laptop> Plus it would be PySsize_t
[11:23] <jam-laptop> or something like that
[11:23] <jam-laptop> We can <int> cast it if you prefer
[11:23] <bialix_> yeah, you're right
[11:23] <jam-laptop> But until 0.9.6 or so PySsize_t wasn't a recognized size
[11:23] <jam-laptop> sorry, recognized type
[11:23] <jam-laptop> so we had other issues with it.
[11:24] <bialix_> vila seems to be AFK
[11:25] <bialix_> btw, recently there was little discussion wo flame war) in Pyrex ML about VCS for Pyrex
[11:26] <bialix_> noone argument wons
[11:29] <jam-laptop> patch sent
[11:33] <bialix> jam said: "__new__ happens before __init__.It gives you a chance to initialize your C structures" -- from this point changing name from new to cinit is reasonable and straightforward
[11:36] <mhagger> I'm the cvs2svn maintainer.  I was wondering whether there would be much enthusiasm in this community for a "cvs2bzr" based on our code.
[11:37] <mhagger> cvs2svn already has a git output module, and I don't think it would be much work to add output to bzr (given a little bit of help from somebody with bzr expertise)
[11:37] <jam-laptop> bialix: Actually I switched from __new__ to __init__ (not __cinit__) because __cinit__ doesn't work with pyrex <0.9.6
[11:38] <mhagger> cvs2svn only does one-time conversions (not incremental) but it is very robust and has *a lot* of features.
[11:38] <jam-laptop> mhagger: there will probably be some interest. I know there are a couple of ways to convert from cvs to bzr (cscvs, cvsps-import, tailor)
[11:38] <bialix> jam-laptop: right, I just thinking slow about your point
[11:38] <jam-laptop> But if your CVS parsing is superior
[11:38] <jam-laptop> then it will certainly get used
[11:38] <mhagger> [See http://cvs2svn.tigris.org/cvs2svn.html for some details] 
[11:38] <bialix> yes, yes, yes: I have too much f interest of converting my old cvsnt repo to bzr
[11:39] <jam-laptop> I personally wrote cvsps-import, which uses 'cvsps' to parse the CVS info and build up changesets
[11:39] <jam-laptop> But I don't think cvsps is all that great
[11:39] <jam-laptop> So I would be happy to use a different back end
[11:39] <mhagger> Yes, I think that cvsps has known problems
[11:39] <bialix> I rememeber cvs2svn claimed it's not supporting cvsnt. something changed in last 2 years?
[11:39] <mhagger> jam-laptop: Perhaps you are just the expert I am looking for :-)
[11:40] <jam-laptop> Though it would be nice if it could be repeated
[11:40] <jam-laptop> mhagger: most likely :)
[11:40] <mhagger> No, we still don't support CVSNT
[11:40] <jam-laptop> I know ddaa and lifeless both have cried some tears of blood trying to work on converting from CVS
[11:40] <bialix> :-(
[11:40] <jam-laptop> cscvs actually has some of the most advanced CVS work I've encountered
[11:40] <mhagger> bialix: Though if you use the --use-cvs option and make sure that the CVSNT binary is used, there might be some hope.
[11:40] <jam-laptop> in that it even keeps snapshots
[11:41] <jam-laptop> so when people do manual surgery on CVS
[11:41] <jam-laptop> it can still  recover
[11:41] <bialix> cvsnt have really killer feature: pseudo-atomic commits and merge history
[11:41] <jam-laptop> mhagger: I think bialix is also looking to support some of CVSNT's extended tags
[11:41] <bialix> mhagger: it's really works for me in the past, thanks
[11:42] <mhagger> bialix: I don't have anything against CVSNT except for the rather unpleasant very commercial community around it
[11:42] <bialix> IIUC, the main problem with cvsnt is absense of tech docs
[11:42] <mhagger> If a CVSNT expert wants to join forces, I doubt that it would be too hard to add CVSNT support to cvs2svn
[11:43] <mhagger> bialix: Exactly.  And lack of developer time over in cvs2svn-land :-)
[11:43] <bialix> time is always too little
[11:43] <mhagger> I've only read a little bit about cscvs
[11:43] <bialix> I used TortoiseCVS a lot, and it use cvsnt internally
[11:43] <mhagger> But it looked like it doesn't support branches ?!?
[11:43] <jam-laptop> mhagger: the biggest problem with cscvs is it isn't very human friendly
[11:44] <jam-laptop> mhagger: Last I knew, it can support them
[11:44] <jam-laptop> but it refuses to "guess" where the branch point occured
[11:44] <jam-laptop> so you have to give it a bit of a nudge
[11:44] <mhagger> Ah, that's good to know.
[11:44] <jam-laptop> But yeah, I think that was one of the reasons I didn't use it over cvsps
[11:45] <mhagger> There are two ambiguities about branch creation in the CVS record: when and whence
[11:45] <bialix> cvscs is not working in pure windows
[11:45] <mhagger> Branch creation does not include timestamps
[11:45] <mhagger> and it is also often ambiguous what is the parent branch of a given branch.
[11:45] <fullermd> cvsps-import has been a good friend to me...  I like the auto-handling of branches and tags.
[11:46] <mhagger> cvs2svn has heuristics for both problems, and allows the user to specify a "hints" file to help with the second problem.
[11:46] <jam-laptop> mhagger: is it possible to store some conversion information, so that if you convert a second time, you can start where you left off?
[11:47] <jam-laptop> I know I've found that cvsps isn't terribly deterministic
[11:47] <mhagger> No, not yet.  I've thought about what it would take to add that feature, but it would be a lot of work
[11:47] <jam-laptop> I've had small updates cause it to shift things around quite a bit
[11:47] <jam-laptop> mhagger: well, aren't you using an intermediate DB anyway?
[11:47] <mhagger> IMHO trying to make the conversion deterministic is not the right route
[11:47] <jam-laptop> I'm not trying for deterministic
[11:47] <jam-laptop> just recording what has happend
[11:47] <jam-laptop> ed
[11:47] <jam-laptop> so you can continue without having to start all over
[11:47] <mhagger> Yes
[11:48] <mhagger> You basically just have to remember the frontier of the last conversion
[11:48] <jam-laptop> converting 175k revisions is a bit painful
[11:48] <jam-laptop> (The Mozilla source tree has ~175k revisions across 55k files)
[11:48] <bialix> our beloved mozilla tree
[11:48] <mhagger> But the real trick is that CVS allows history to be changed; for example, branches and revisions can be deleted; tags can be moved, etc
[11:49] <jam-laptop> mhagger: which is, to my understanding, why cscvs keeps state snapshots
[11:49] <mhagger> I use the mozilla repo for testing cvs2svn.  It converts in about 17 hours on a modest computer
[11:49] <jam-laptop> so it can say "you deleted X, I can workaround that"
[11:49] <mhagger> That is converting to SVN.  Converting to git should be much faster
[11:49] <fullermd> I'd like to see what bzr does to the BSD tree after the inventory gets reworked...
[11:49] <jam-laptop> fullermd: you're just trying to make me cry, right?
[11:50] <fullermd> Well, you don't have to do it with tailor this time   ;)
[11:50] <jam-laptop> (I'm a little curious to, but that is a ways off)
[11:50] <fullermd> That alone should chop like 95% of the time off.
[11:50] <jam-laptop> yeah
[11:50] <jam-laptop> Well, Tailor using raw "cvs" to update the WT
[11:50] <jam-laptop> means you have an enforced 1s pause for each revision
[11:50] <bialix> btw, guys, when I gave a talk in Kiev this spring one guy asked me about speed of bzr comparable to baz
[11:50] <jam-laptop> though when we last tried to convert, bzr was taking 6s+ to work out the inventory
[11:51] <fullermd> Yah.  Miserable.
[11:51] <jam-laptop> so it didn't really matter.
[11:51] <fullermd> Well.  Considering that's a 1s pause for each _file_ in the revision...  it still adds up.
[11:51] <jam-laptop> bialix: I would say that bzr smokes baz in all ways possible
[11:51] <bialix> he used baz (or tla) to follow FreeBsd mainstream
[11:51] <bialix> or something similar
[11:51] <fullermd> bzr should be a lot faster now though.  That was what, aroudn 0.11 or something?
[11:51] <bialix> no, it was around 0.15
[11:51] <jam-laptop> fullermd: yeah, but it shows up as 'sleep' time, and the total %sleep was still pretty low
[11:51] <bialix> dirstate!
[11:52] <bialix> windows locking problems!
[11:52] <bialix> you remember?
[11:52] <fullermd> bialix: Nono, I mean last time jam-laptop fiddled with the BSD tree conversion.
[11:52] <jam-laptop> fullermd: I think it was 0.11
[11:52] <jam-laptop> that sounds about right
[11:52] <bialix> oh, sorry
[11:52] <mhagger> I added git output to cvs2svn a couple of months ago, and it only required two files with a total of like 300 lines of code.
[11:52] <jam-laptop> fullermd: it *might* have even been back with weaves (<0.8)
[11:52] <jam-laptop> but I don't think I would be that foolish
[11:53] <fullermd> Oh, I'm pretty sure it wasn't that far back.
[11:53] <mhagger> Of course that is using the excellent and well-documented git-fast-import tool to actually built the repository
[11:53] <bialix> fullermd: FreeBSD still uses CVS?
[11:53] <fullermd> We've still got at least one good dirstate fuggery around.  Get that fixed, then we can try it with the 150k file trees to find more   ;)
[11:53] <fullermd> bialix: Yah.
[11:53] <fullermd> See http://wiki.freebsd.org/VersionControl
[11:54] <bialix> ok, so I remember a question right
[11:54] <mhagger> So if somebody is interested to help create a bzr backend for cvs2svn, please let me know
[11:54] <fullermd> I'm just _dying_ to fill in bzr columns there.  But without inventory reworking, it'll say "bzr rocks, it's slow as molasses, and you'll need to buy a 500 gig drive to store the inventory knit"
[11:54] <bialix> mhagger: you're using some sort of pluggable architecture?
[11:54] <mhagger> Yes
[11:55] <mhagger> 90% of the work is deciphering the CVS history, and the results are easily available to the output backend
[11:55] <mhagger> (It's all Python, by the way)
[11:55] <bialix> I know
[11:55] <bialix> I read the sources occasionaly
[11:55] <bialix> just wonder how hard to add miniml cvsnt tags support
[11:56] <bialix> minimal^
[11:56] <mhagger> bialix: Discussion of the details of adding CVSNT support should probably move to #cvs2svn.  We'd be glad to have you over there :-)
[11:57] <bialix> well, I read man on RCS files, then I looking on my old cvsnt/TortoiseCVS repos, and have some ideas
[11:57] <bialix> but from first view cvs2svn parsing code seems a bit complicated
[11:58] <mhagger> How do people get content into bzr?  Is there a documented interface or tool for adding content?
[11:58] <bialix> jam, please
[11:59] <jam-laptop> sorry, I was distracted
[11:59] <mhagger> (I.e., the equivalent of "svnadmin load" or "git-fast-import"?)
[11:59] <bialix> we have bzrlib, it's written in Python
[12:00] <bialix> we have very reach API
[12:00] <jam-laptop> mhagger: generally you use the python api
[12:00] <mhagger> Is it documented?
[12:00] <bialix> yes
[12:00] <jam-laptop> If *I* were doing this work, I would probably just adapt the cvsps-import code
[12:01] <mhagger> Sure, that's probably doable.
[12:01] <bialix> at least it's a good example
[12:01] <jam-laptop> mhagger: All of the code has docstrings (part of our review process requires them). There is some higher level documentation, though some of it could be better.
[12:01] <jam-laptop> And you'll find people here to be pretty helpful
[12:01] <bialix> and jam our expert
[12:01] <mhagger> I even though about adding a cvsps-compatible output format for cvs2svn so all the other tools could use it right away.
[12:01] <jam-laptop> mhagger: well, I wouldn't recommend it
[12:01] <jam-laptop> the cvsps output has some... issues
[12:02] <mhagger> Yes, that's what I decided :-)
[12:02] <jam-laptop> Like you can have text comments that look like meta-info
[12:02] <jam-laptop> I have a parser which generally handles it