[00:17] 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] I am using bzr 1.13 and bzr-svn 0.5.3 [00:21] ricardokirkner: I assume that --subversion will create a bzr shared repo, in the format recommended for storing svn branches. [00:21] I'll check [00:23] * fullermd wouldn't be so sure. [00:24] ricardokirkner: Who all needs to be able to access it, and how ancient are their bzr versions? [00:24] 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] 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] Which is sounds like is the case. [00:26] fullermd, anybody accessing what? the shared repo I am creating? [00:26] I could do that, as it will be only me [00:27] what's the difference between 1.9-rich-root and rich-root / -rich-root-pack? [00:27] (featurewise) [00:30] Feature-wise? None. [00:30] 1.9-rich-root is a variant of the 1.9 format that supports rich roots. [00:31] 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] It doesn't serve any practical purpose. [00:36] fullermd, alright... so, right now the best format (regarding performance and future compatibility) for svn branches [00:36] is 1.9-rich-root [00:36] i will use that.. [00:36] thank you [00:36] Yah. [00:37] Only reason to back up would be to handle older bzr versions. [00:37] ok, no prob... I can dictate bzr>1.9 for this [00:37] thanks [01:16] Is there a way to see how big a branch is on launchpad before you fetch (branch) it? [01:20] 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] bzr info -vv might [01:22] its abot 600MB [01:22] Eish! [01:22] * garyvdm hits ctrl-c [01:29] 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:29] Launchpad bug 349673 in qbzr "MYSQL/BZR P3: "bzr qlog FILE" misses many revisions" [Undecided,New] https://launchpad.net/bugs/349673 [01:30] perhaps ask on the list? at least some of the mysql folk read it, I believe [01:31] ok [01:38] garyvdm: do you think it'd be a good feature to have the repo size shown in LP? [01:38] * thumper wonders [01:38] garyvdm: if so, plz file a bug on launchpad-bazaar :) [01:38] Ok [01:48] thumper: bit tricky with stacking :) === abentley1 is now known as abentley [03:42] vila: https://code.edge.launchpad.net/bzr-ec2test [03:42] jml: https://code.edge.launchpad.net/bzr-ec2test [03:42] how fast? [03:43] with 2 instances, if they are already up and running, 1m35 [03:43] spiffy [03:44] yeah [03:44] next month I'll do another 20 instance trial [04:57] hi === garyvdm_ is now known as garyvdm === abentley1 is now known as abentley [08:44] does anyon eknow how to delete a bazaar revision from launchpad/ [09:07] bzr: ERROR: Could not install revisions: meoblast@aol.com-20020101213319-n82drkov5a6ct5st [09:07] how do i fix that [09:24] how did you trigger it? [09:29] bob2: modifying .bzr files and trying to push [09:29] don't worry... i fixed it [09:30] ! [09:34] * wgrant points out .bzr/README [09:35] wgrant: yeah... i thought i had to fix something in there [09:36] but i ended up backing up revision 11 [09:36] fixing the whoami [09:36] reverting to revision 10 [09:36] overwritting in launchpad; then restoring backup and pushing [09:37] i've gtg [09:37] bye [10:14] 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] alf: No - it will upgrade on the 1st of April. [10:23] Then things should speed up, or so I hear. [10:37] 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] 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] cammoblammo: its not frozen, just we haven't polished the new fetch codes progress marker [10:49] the spinner will be spinning [10:49] if it is frozen please be sure to get a backtrace when you intererupt it [10:55] 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] nothing for an hour certainly seems borked :P [10:55] hit ctrl-\ [10:55] then type [10:55] bt [10:57] wgrant: thanks, I just used bzr.dev and it seems to perform better than 1.13 on a non-1.13 server [10:58] yes, we fixed a long standing bug which 1.13 made more obvious, in 1.14 [10:58] lifeless: Where should I paste the backtrace? [10:58] however when lp upgrades on the first it will run a totally different code path, which streams and is much faster [10:58] cammoblammo: somewhere I can see it :) [10:59] cammoblammo: if this is happening regularly, I suggest a bug report [11:03] 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] 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] alf: strange! [11:50] alf: I'll try that. [11:52] alf: hmm, I think it's the recent get_parent_map RPC changes. [11:53] 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] lifeless: weirdly it doesn't fail until the 4th get_parent_map call [11:54] (on the 3rd with a non-empty request body) [11:55] alf: thanks for the bug report, that does seem to be a regression in bzr.dev [11:55] alf: Oh, in case I wasn't clear, yes I can reproduce it too. [12:16] spiv: ok, thanks! === Spaz is now known as Kittens === thunderstruck is now known as gnomefreak === thunderstruck is now known as gnomefreak === thunderstruck is now known as gnomefreak [16:30] Hi, guys! [16:30] 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] what's the equivalent in git to bzr revert -r -2? [16:42] something with reset I think === Kittens is now known as Spaz_ === Spaz_ is now known as init === serg__ is now known as qqqbaka [18:23] hiya, bzr just started dying on serve [18:23] it's the ipv6 sockname problem again [18:23] I remember it happening before [18:24] http://pastebin.com/m1b93a98c === serg is now known as serg_ === serg_ is now known as serg === serg_ is now known as serg [19:26] has the bzr.dev format changed? [20:02] lifeless: have you encountered tokyo cabinet in your data persistence travels? [21:45] Does bzr do anything intelligent with inter-line whitespace changes? and/or, where can i read more about this. :) thanks [21:46] 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] gah, typos. "inter-line" in the beginning, and "foo bar-prime baz" in the third quoted string [22:33] jelmer: hello [22:34] jelmer: i think bzr-git is generating corrupt data [22:45] jelmer: http://pastebin.ubuntu.com/139834/ [22:46] mwhudson: I hadn't no [22:46] lifeless: i don't know how relevant it is for bzr-search etc [22:46] spiv: interesting [22:46] mwhudson: its not :) [22:47] but it makes a heck of a lot more sense for what i'm doing with sqlite in loggerhead than sqlite [22:47] 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] lifeless: there's python bindings called pytc [22:47] ah ok [22:47] lifeless: no idea of kwality [22:48] sqlite has benched faster than similar things; I wouldn't assume its worse [22:48] and might make sense for jelmer too [22:48] i dont know what it's concurrency behaviour is like [22:48] tokyo cabinet is one-process per db [22:49] ah [22:49] i guess their concurrency story is "tyrant [22:49] " [22:49] hmm I may be wrong [22:50] its hard to read janglish [22:50] 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] it does explicitly support concurrent threads [22:52] 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] found it [22:52] so, one process per db full stop, but there is a server [22:53] 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] sadness [22:56] i guess the file is deleted in tip or something [22:57] in tree None is a hint [22:58] speaking of unit test frameworks - http://bazaar.launchpad.net/%7Elifeless/subunit/polish/annotate/head%3A/c//check-subunit-0.9.6.patch [22:59] lifeless: gnu check? [23:00] http://check.sourceforge.net/ [23:04] hello for everyone [23:04] 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] someone have idea how fix? [23:05] install the standard certificates for curl [23:05] I don't know how to do that on gentoo [23:06] I will check lifeless , thx [23:13] lifeless, how you do in other distros? [23:14] lifeless, found :), instal ca-certificates [23:14] thx [23:19] spiv: yes, smells like our change is at fault [23:36] vila: tentative ping?