[00:17] <ricardokirkner> hi. I am about to create a shared repo in order to track a svn project. I wanted to know, which one is the recommended repo format? (I see there is a --subversion repo format, although I am not sure how I should use it, as it really creates a subversion repository, instead of a bzr shared repository)
[00:18] <ricardokirkner> I am using bzr 1.13 and bzr-svn 0.5.3
[00:21] <garyvdm> ricardokirkner: I assume that --subversion will create a bzr shared repo, in the format recommended for storing svn branches.
[00:21] <garyvdm> I'll check
[00:23]  * fullermd wouldn't be so sure.
[00:24] <fullermd> ricardokirkner: Who all needs to be able to access it, and how ancient are their bzr versions?
[00:24] <ricardokirkner> fullermd, right now it's just for me in order to use bzr to track and contribute to a project that is hosted on a svn repo
[00:25] <fullermd> If you can assume (or dictate) that anybody accessing it uses 1.9 or later, 1.9-rich-root is what you want.
[00:25] <fullermd> Which is sounds like is the case.
[00:26] <ricardokirkner> fullermd, anybody accessing what? the shared repo I am creating?
[00:26] <ricardokirkner> I could do that, as it will be only me
[00:27] <ricardokirkner> what's the difference between 1.9-rich-root and rich-root / -rich-root-pack?
[00:27] <ricardokirkner> (featurewise)
[00:30] <fullermd> Feature-wise?  None.
[00:30] <fullermd> 1.9-rich-root is a variant of the 1.9 format that supports rich roots.
[00:31] <fullermd> Rich root pack is the similar counterpart to pack-0.92.  rich-root is something you just want to stay the heck away from.
[00:31] <fullermd> It doesn't serve any practical purpose.
[00:36] <ricardokirkner> fullermd, alright... so, right now the best format (regarding performance and future compatibility) for svn branches
[00:36] <ricardokirkner> is 1.9-rich-root
[00:36] <ricardokirkner> i will use that..
[00:36] <ricardokirkner> thank you
[00:36] <fullermd> Yah.
[00:37] <fullermd> Only reason to back up would be to handle older bzr versions.
[00:37] <ricardokirkner> ok, no prob... I can dictate bzr>1.9 for this
[00:37] <ricardokirkner> thanks
[01:16] <garyvdm> Is there a way to see how big a branch is on launchpad before you fetch (branch) it?
[01:20] <garyvdm> I need to branch lp:mysql-server/6.0 to try reproduce a bug in qbzr, but I'm worried I going to hit my adsl cap :-(
[01:22] <lifeless> bzr info -vv might
[01:22] <lifeless> its abot 600MB
[01:22] <garyvdm> Eish!
[01:22]  * garyvdm hits ctrl-c
[01:29] <garyvdm> I'm asking for someone to do a big faviour for me. If you have copy of the mysql-server/6.0 and you are running qbzr trunk, please try and confirm Bug 349673.
[01:30] <lifeless> perhaps ask on the list? at least some of the mysql folk read it, I believe
[01:31] <garyvdm> ok
[01:38] <thumper> garyvdm: do you think it'd be a good feature to have the repo size shown in LP?
[01:38]  * thumper wonders
[01:38] <thumper> garyvdm: if so, plz file a bug on launchpad-bazaar :)
[01:38] <garyvdm> Ok
[01:48] <lifeless> thumper: bit tricky with stacking :)
[03:42] <lifeless> vila: https://code.edge.launchpad.net/bzr-ec2test
[03:42] <lifeless> jml: https://code.edge.launchpad.net/bzr-ec2test
[03:42] <bob2> how fast?
[03:43] <lifeless> with 2 instances, if they  are already up and running, 1m35
[03:43] <bob2> spiffy
[03:44] <lifeless> yeah
[03:44] <lifeless> next month I'll do another 20 instance trial
[04:57] <meoblast001> hi
[08:44] <meoblast001> does anyon eknow how to delete a bazaar revision from launchpad/
[09:07] <meoblast001> bzr: ERROR: Could not install revisions: meoblast@aol.com-20020101213319-n82drkov5a6ct5st
[09:07] <meoblast001> how do i fix that
[09:24] <bob2> how did you trigger it?
[09:29] <meoblast001> bob2: modifying .bzr files and trying to push
[09:29] <meoblast001> don't worry... i fixed it
[09:30] <spiv> !
[09:34]  * wgrant points out .bzr/README
[09:35] <meoblast001> wgrant: yeah... i thought i had to fix something in there
[09:36] <meoblast001> but i ended up backing up revision 11
[09:36] <meoblast001> fixing the whoami
[09:36] <meoblast001> reverting to revision 10
[09:36] <meoblast001> overwritting in launchpad; then restoring backup and pushing
[09:37] <meoblast001> i've gtg
[09:37] <meoblast001> bye
[10:14] <alf> Hello, for some days now I am experiencing extreme slowness when pushing to lp using 1.13rc1. Has lp upgraded to a 1.13 server?
[10:23] <wgrant> alf: No - it will upgrade on the 1st of April.
[10:23] <wgrant> Then things should speed up, or so I hear.
[10:37] <cammoblammo> Is anyone havng trouble pulling from the bzr repo at http://bazaar-vcs.org/bzr/bzr.dev/ ? I seem to freeze after a few minutes.
[10:37] <cammoblammo> I had this issue a week or so ago, but deleting my branch and pulling a completely fresh one fixed it for a bit.
[10:49] <lifeless> cammoblammo: its not frozen, just we haven't polished the new fetch codes progress marker
[10:49] <lifeless> the spinner will be spinning
[10:49] <lifeless> if it is frozen please be sure to get a backtrace when you intererupt it
[10:55] <cammoblammo> lifeless: Hmm. It seemed to freeze completely. It goes for a minute or two than nothing for an hour. How do I get the backtrace?
[10:55] <lifeless> nothing for an hour certainly seems borked :P
[10:55] <lifeless> hit ctrl-\
[10:55] <lifeless> then type
[10:55] <lifeless> bt<ENTER>
[10:57] <alf> wgrant: thanks, I just used bzr.dev and it seems to perform better than 1.13 on a non-1.13 server
[10:58] <lifeless> yes, we fixed a long standing bug which 1.13 made more obvious, in 1.14
[10:58] <cammoblammo> lifeless: Where should I paste the backtrace?
[10:58] <lifeless> however when lp upgrades on the first it will run a totally different code path, which streams and is much faster
[10:58] <lifeless> cammoblammo: somewhere I can see it :)
[10:59] <lifeless> cammoblammo: if this is happening regularly, I suggest a bug report
[11:03] <alf> hmm, I just tried to branch lp:bzr using bzr.dev and it crashed with a "ErrorFromSmartServer: Error received from smart server: ('NoSuchRevision',)"
[11:14] <cammoblammo> lifeless: I'm happy to file a bug report if necessary. In the meantime, I've put up the backtrace (I think!) at http://pastebin.com/m6404b8e6
[11:50] <spiv> alf: strange!
[11:50] <spiv> alf: I'll try that.
[11:52] <spiv> alf: hmm, I think it's the recent get_parent_map RPC changes.
[11:53] <spiv> lifeless: ^ NoSuchRevision with from get_parent_map RPC doing "bzr branch lp:bzr", I guess the key count in the serialised search is wrong somehow?
[11:54] <spiv> lifeless: weirdly it doesn't fail until the 4th get_parent_map call
[11:54] <spiv> (on the 3rd with a non-empty request body)
[11:55] <spiv> alf: thanks for the bug report, that does seem to be a regression in bzr.dev
[11:55] <spiv> alf: Oh, in case I wasn't clear, yes I can reproduce it too.
[12:16] <alf> spiv: ok, thanks!
[16:30] <antoranz> Hi, guys!
[16:30] <antoranz>  know this is not a git forum, but they didn't help me an gits forum and it's a very simple question
[16:31] <antoranz> what's the equivalent in git to bzr revert -r -2?
[16:42] <james_w> something with reset I think
[18:23] <mathrick> hiya, bzr just started dying on serve
[18:23] <mathrick> it's the ipv6 sockname problem again
[18:23] <mathrick> I remember it happening before
[18:24] <mathrick> http://pastebin.com/m1b93a98c
[19:26] <gutworth> has the bzr.dev format changed?
[20:02] <mwhudson> lifeless: have you encountered tokyo cabinet in your data persistence travels?
[21:45] <johnjosephbachir> Does bzr do anything intelligent with inter-line whitespace changes? and/or, where can i read more about this. :) thanks
[21:46] <johnjosephbachir> or actually, inter-ling changes at all. for example, i change "foo bar baz" to "foo-prime bar baz", and then a merge from parent changes the same line to "food bar-prime baz", can the bazaar merge result in "foo-prime bar-prime baz" ?
[21:47] <johnjosephbachir> gah, typos. "inter-line" in the beginning, and "foo bar-prime baz" in the third quoted string
[22:33] <mwhudson> jelmer: hello
[22:34] <mwhudson> jelmer: i think bzr-git is generating corrupt data
[22:45] <mwhudson> jelmer: http://pastebin.ubuntu.com/139834/
[22:46] <lifeless> mwhudson: I hadn't no
[22:46] <mwhudson> lifeless: i don't know how relevant it is for bzr-search etc
[22:46] <lifeless> spiv: interesting
[22:46] <lifeless> mwhudson: its not :)
[22:47] <mwhudson> but it makes a heck of a lot more sense for what i'm doing with sqlite in loggerhead than sqlite
[22:47] <lifeless> mwhudson: no python bindings according to http://tokyocabinet.sourceforge.net/spex-en.html, and no obvious way to hack the backend for transports
[22:47] <mwhudson> lifeless: there's python bindings called pytc
[22:47] <lifeless> ah ok
[22:47] <mwhudson> lifeless: no idea of kwality
[22:48] <lifeless> sqlite has benched faster than similar things; I wouldn't assume its worse
[22:48] <mwhudson> and might make sense for jelmer too
[22:48] <mwhudson> i dont know what it's concurrency behaviour is like
[22:48] <lifeless> tokyo cabinet is one-process per db
[22:49] <mwhudson> ah
[22:49] <mwhudson> i guess their concurrency story is "tyrant
[22:49] <mwhudson> "
[22:49] <lifeless> hmm I may be wrong
[22:50] <lifeless> its hard to read janglish
[22:50] <lifeless> As with QDBM, the following three restrictions of traditional DBM: a process can handle only one database, the size of a key and a value is bounded, a database file is sparse, are cleared. Moreover, the following three restrictions of QDBM: the size of a database file is limited to 2GB, environments with different byte orders can not share a database file, only one thread can search a database at the same time, are cleared.
[22:50] <lifeless> it does explicitly support concurrent threads
[22:52] <lifeless> In cases that multiple processes access a database at the same time or some processes access a database on a remote host, the remote service is useful.
[22:52] <lifeless> found it
[22:52] <lifeless> so, one process per db full stop, but there is a server
[22:53] <lifeless> myself, I'd tend to use sqlite
[22:54]  * mwhudson sighs at http://bazaar.launchpad.net/~vcs-imports/nunit-2.5/trunk/changes?filter_file_id=srcnunittestservernu-20081008020403-2ajrt9spm9ob8qah-96
[22:56] <lifeless> sadness
[22:56] <mwhudson> i guess the file is deleted in tip or something
[22:57] <lifeless> in tree None is a hint
[22:58] <lifeless> speaking of unit test frameworks - http://bazaar.launchpad.net/%7Elifeless/subunit/polish/annotate/head%3A/c//check-subunit-0.9.6.patch
[22:59] <mwhudson> lifeless: gnu check?
[23:00] <lifeless> http://check.sourceforge.net/
[23:04] <chronos> hello for everyone
[23:04] <chronos> I installed now bzr on my gentoo and i getting this error when try to login on launchpad: http://rafb.net/p/prmVYo69.html
[23:04] <chronos> someone have idea how fix?
[23:05] <lifeless> install the standard certificates for curl
[23:05] <lifeless> I don't know how to do that on gentoo
[23:06] <chronos> I will check lifeless , thx
[23:13] <chronos> lifeless, how you do in other distros?
[23:14] <chronos> lifeless, found :), instal ca-certificates
[23:14] <chronos> thx
[23:19] <lifeless> spiv: yes, smells like our change is at fault
[23:36] <mwhudson> vila: tentative ping?