[00:00] is there a new bzr-svn for 1.12? [00:00] mxpxpod, 0.5.0 [00:01] jelmer: thanks [00:13] jelmer: where do I pick up bzr-rebase 0.4.3? [00:18] mxpxpod, http://samba.org/~jelmer/bzr [00:18] jelmer: I only see up to 0.4.2 [00:18] mxpxpod, try refresh :-) [00:18] nice [00:18] thanks [00:18] jelmer: will that eventually be in the ppa? [00:19] mxpxpod: I don't think rebase is part of the packages in the PPA [00:19] mxpxpod: (I don't upload to the PPA) [00:19] jelmer: gotcha [00:25] jelmer: now, to upgrade all of my branches ;) [00:26] jelmer: does 0.5 use any svn props? [00:27] mxpxpod: it uses svn:executable [00:27] and it will set svn:mergeinfo in some cases [00:27] but no bzr: [00:27] mxpxpod, you mean whether it will write them?> [00:28] mxpxpod: it will set bzr:... revision properties if the server supports them (svn >= 1.5), otherwise it will use file properties like 0.4.x [00:28] jelmer: right... it used to set bzr:revison-info, bzr:file-ids, bzr:revision-id:v3-trunk1, etc [00:29] mxpxpod, it will still do that if the server doesn't support setting revision properties [00:29] jelmer: gotcha [00:30] jelmer: thanks [00:30] jelmer: one last thing... is there any way to set other svn: props thru bzr? [00:30] for instance, svn:eol-style [00:31] mxpxpod: no, that would require bzr to support eol-style itself first [00:31] doesn't bzr just use the native eol-style on each platform? [00:31] mxpxpod, no, bzr doesn't convert eol-characters atm [00:31] jelmer: ah, gotcha [00:32] there are some plans to support it, not sure how far along they are [00:35] jelmer: oh, one last thing... does it support svn:external yet? [00:35] mxpxpod, no, same thing - bzr itself doesn't support nested trees yet [00:35] k [00:35] so there's no way for bzr-svn to do so [00:35] thanks for answering all of my questions [00:35] np [00:46] jelmer: does svn-upgrade upgrade the cache from ~/.bazaar/svn-cache? or does it grab the revisions fresh? [00:46] mxpxpod, it cache format has changed a bit so it will create a new cache [00:46] jelmer: ok [00:52] jelmer: thanks for all the help [00:56] jelmer: one thing that kind of frustrates me is that when I push revisions from bzr, I can't see the svn revision in the log of that check-in [00:57] mxpxpod: it should show up if you run "bzr log" against the remote server [00:58] mxpxpod: It won't show up in the log of the revision you have pushed, since that would be problematic: [00:58] it would require "bzr push" to change the source branch (which it doesn't do, by definition) [00:58] what would happen if you "bzr push"'ed to multiple svn repositories? [00:58] jelmer: ah, so bzr log :parent do what I'm talking about? [00:59] jelmer: makes sense [00:59] mxpxpod: Yep [00:59] jelmer: heh, bzr log :parent takes a long time on a repo with lots of revs ;) [01:02] mxpxpod, 0.5.1 should be a bit better in that regard [01:02] jelmer: cool [01:03] jelmer: here's something strange... when I svn-upgrade one of my branches, it tells me there are conflicting tags (which there aren't) and bzr tags tells me it can't find revisions for some of the tags [01:03] jelmer: but, a fresh branch of the repo doesn't have any conflicting tags [01:03] could it find revisions for the tags previously? [01:03] not sure [01:04] mxpxpod, any chance you can file a bug about that? [01:04] jelmer: if I can reproduce it on a repository that's public, yes [01:05] jelmer: will 0.5.1 help with pull speed? [01:05] mxpxpod, yes [01:05] cool [01:06] jelmer: any compat issues between bzr-svn 0.5.0 and bzr 1.12, or would it be sane to requestsync 1.12 for jaunty? [01:07] maxb: no, 1.12 should be fine [01:07] jelmer: does svn-upgrade migrate revprops? [01:08] mxpxpod, what do you mean exactly? [01:08] jelmer: does it do bzr svn-set-revprops ? [01:08] mxpxpod, no, it only changes the local branch, never the svn repository [01:08] ok [01:10] jelmer: is there a way to get tags to list the correct revision rather than "?" ? [01:10] mxpxpod: Generally not, because the ? would be shown because the tag is on a revision that is not in the branch [01:11] jelmer: ah, ok [01:11] --show-ids will show the "raw" revision id [01:14] jelmer: hmm... some of the tags are still pointing to svn-v3-trunk0 ids [01:15] mxpxpod, that could be correct if you used bzr-svn to push revisions into svn in the past [01:15] jelmer: ok [01:19] jelmer: ok, so I have a branch of an svn branch that I do work for a release in... if I do bzr tags --show-ids, it shows some tags as svn-v3-trunk0 which show up as v4 in the svn branch [01:19] mxpxpod, was this the branch that you got the conflicts on earlier? [01:19] mxpxpod, what happens if you do a clean copy? [01:21] jelmer: here what I did: with 0.4.x I did this... bzr branch http://somerepo/trunk trunk; bzr branch trunk 1.3.4 [01:21] then when I got 0.5, I did this: mv trunk trunk.old; bzr branch http://somerepo/trunk trunk [01:22] jelmer: make sense? [01:22] mxpxpod, yeah [01:22] jelmer: now, bzr tags --show-ids show v3 ids in 1.3.4 [01:23] and trunk shows v4 ids ? [01:23] jelmer: yup [01:23] but you have the same amount of "?"'s in 1.3.4 and trunk? [01:24] yes [01:24] but when I do a pull in 1.3.4, it says there are conflicting tags for the tags that are v3 [01:24] mxpxpod, that's correct [01:24] jelmer: how do I get those tags to point to the v4 equivalent? [01:24] if you run "bzr svn-upgrade" in 1.3.4 it should fix those tags [01:25] if it doesn't then that's a bug [01:25] it says trunk is not a foreign repository [01:25] mxpxpod, you need to specify the svn repository [01:26] jelmer: awesome! thanks [01:29] jelmer: and if I run that same command in trunk, it upgrades the old v3 ones to v4 [01:29] mxpxpod, Ouch, that's wrong [01:31] it does the same thing in 1.3.4 [01:32] it doesn't keep the v3 ones that are supposed to be v3 as v3 [01:35] mxpxpod, should be fixed in the 0.5 branch [01:40] jelmer: will it fix the v4 thing? [01:40] mxpxpod, v4 thing? [01:40] jelmer: where 1.3.4 had v3 ids and then I ran svn-upgrade and got v3 ids... will it fix that? [01:40] mxpxpod, it will make sure svn-upgrade doesn't upgrade some revisions to v4 unnecessarily [01:41] jelmer: also, are you talking about the lp:bzr-svn branch? [01:42] mxpxpod: Where did you get v3 ids in the 1.3.4 branch exactly? [01:42] for some tags I made with the old bzr-svn a while back [01:43] mxpxpod: It's not incorrect if it leaves some v3 revisions [01:43] jelmer: right [01:43] jelmer: but it changed the v3 ones that I made to v4 [01:43] mxpxpod: But it should only do that for tags that are not "?" tags [01:44] mxpxpod, that bit should be fixed now (upgrading some to v4 incorrectly) [01:44] jelmer: in lp:bzr-svn? [01:44] mxpxpod, bzr-svn's main branch is at http://people.samba.org/bzr/jelmer/bzr-svn/0.5 [01:44] lp is usually out of date [01:44] ah, ok [01:47] jelmer: ok, so is there a way to fix a branch from svn-upgrade changing them to the wrong thing in 0.5.0? [01:48] mxpxpod: Fix the tags after bzr-svn all changed them to v4 tags? [01:48] jelmer: yes [01:48] mxpxpod, if the tags are in svn, you can just "bzr pull" from svn [01:49] that doesn't change them from v4 back to v3 [01:50] aha! [01:50] bzr pull --overwrite [01:51] ah [01:52] and that fixed it [01:52] jelmer: thanks for the help [01:53] mxpxpod, once again, np :-) [01:53] jelmer: now you know what to tell people that have the same problem as me :D [01:53] and thanks for helping fix that bug in svn-upgade [01:53] jelmer: not a problem [01:54] alright, gotta go [01:54] have a good nige [01:54] night [03:19] I'm attempting to install flup to get bzr-smart.fcgi to work on win32. Does anyone knwo if I can drop a flup egg into c:\Python25\lib\site-packages and expect it to work? [03:22] nevermind. I'm stupid. just copy fcgi.py along size bzr-smart.fcgi is easier. [05:02] anyone using bzr-smart.fcgi with modwsgi? [05:05] google is amazing, looks like someone had my same issue, very recently: http://pastebin.com/m533f12af [05:44] ok, that issue is fixed, now I can't auth on windows, but I can auth on linux with the same config :( === tchan1 is now known as tchan [11:47] hi, how to get branch from LP when it reports: "bzr: ERROR: The API for "" is not compatible with "(1, 10, 0)". It supports versions "(1, 11, 0)" to "(1, 11, 0)"." ? [11:49] That's probably nothing to do with LP. [11:49] You've got a 'bzr' (the 'bzr' script itself, specifically, not the whole package) from 1.10 around, that's finding the 1.11 bzrlib. [11:49] hmm, i'm running 1.11 [11:49] Or bzr-svn or some other plugin is doing it. [11:50] I think "bzr" itself raises a different error. [11:50] Oh, I forgot bzr-svn had that quirk in a version or two. That sounds more likely. [11:50] hmm, ok..let me check bzr-svn [11:51] thanks. rm-ing bzr-svn did it :-) [11:51] That's a wee bit extreme. [11:52] sure it is, but, well [11:52] ... [14:31] Is this a known issue: http://paste.pocoo.org/show/104115/ [14:31] It happened when I bzr unshelve'd [14:44] Leonidas: Yes, that's bug #328148. [14:44] Launchpad bug 328148 in bzr "Less spaff from unshelve, please" [Undecided,Confirmed] https://launchpad.net/bugs/328148 [14:45] It's just a problem in the progress bar, nothing to worry about. [14:47] Odd_Bloke: Thanks. I thought that it wasn't really important, just wanted to make sure the developers know about it :) [14:51] Leonidas: Thank you. :) [18:17] you know what'd be nice? if there were a way to have a bound branch which did the pushes asynchronously, so I could get back to hacking after a "bzr commit" quickly but also have the peace of mind of knowing that I can't forget to push. [18:18] oh, that idea might be nice fir pida, too [18:18] of course, there would need to be some other mechanism for dealing with asynchronous conflicts. Ideally, some GUI window would pop up (or even just a desktop notification) if I'm in the appropriate environment. [18:18] but barring a GUI, I guess it could just notify you of the conflict next time you ran a bzr command, or something. [18:19] sorry, I'm saying "conflicts" but I actually mean "divergent branches" [18:19] i think seting up per-user push branches is helpfull [18:19] just an idle thought while waiting for a 'bzr commit' to complete in a hotel room :) [18:19] keeps conflicst out of the way till one chooses to do [18:20] that would need another async checker that ckecks for changes on the pull path [18:20] ronny: yeah, sure, but I have the same branches bound on my desktop and my laptop machine [18:20] and then pops up a notification [18:20] radix: ah i see [18:20] but you dont work at both at the same time? [18:21] I'll switch back and forth and often forget to update before changing something [18:21] so asnc update checking might be helpfull, too [18:21] but yeah, something that automatically *pulls* would also help that [18:21] I could just set up a few cron jobs I guess [18:21] i'll have to remember that [18:22] it would certainly be a nice addition to pida [18:22] (an ide) [18:22] ah, I was just about to ask what it is. [18:24] jelmer: is there any documentation about bzr's current storage formats other than the source? [18:24] im stil a bit lost on figuring where those weird xml things are needed [18:27] ok [18:27] now i figured it [18:31] sad, just sad [18:49] ronny, xml things? [18:49] ronny, there shouldn't be a need for you to bother with internals.. [18:50] jelmer: well, i know the git and hg internals, now i want to know the bzr ones [18:52] and i get more and more unhappy with that stuff [18:54] ronny: ah [18:54] ronny, there's some docs in doc/developers/ [18:54] ronny, what makes you unhappy though? [18:55] the kiss principle seems to be missing [18:56] it seems pretty simple to me - one store for revisions, one for inventories, one for texts, that's it basically [18:58] gtg, back later [18:58] everything seems striple if you strip the details out [19:22] is there a way to iterate over all versioned files of a wt, on a specific dir? [19:26] edcrypt_: there is WorkingTree.list_files, but it doesnt filter, maybe there is an better api im not aware of [19:29] ronny: the sdocstring says it list unversioned dirs, no mch better than WT.iter_entries_by_dir [19:32] edcrypt_: there is the filter_unversioned_files method [19:34] ronny: thanks, I'll take a look. [19:34] bbl [19:52] helloo [19:55] bzr push bzr+ssh bzr+ssh://login@bazaar.launchpad.net/~registrant/project/branch <---> bzr: ERROR: Not a branch: "C:/program files blablablablal" [19:56] seems like bzr+ssh unknown command [19:58] any help? [20:07] hello. i made a stupid merge, how can i delete that commit? or how can i fix it? xD [20:08] hmmmm [20:09] i installed bazaar on ubuntu,, but same error occures [20:09] turns out i deleted the upstream changes, not mine [20:09] well.. seem like to not be an error [20:09] knitt1: hi [20:10] hi yea [20:10] * yeonhoo [20:10] yes im new here.. im having problem [20:10] ok, i'll try to help you. but i'm not so fit with bazaar either [20:10] go ahead :) [20:10] bzr push bzr+ssh <-- is this command always output " bzr: error: not a branch" ? [20:10] ok :) [20:11] yeah, that command makes no sense [20:11] bzr push bzr+ssh://mylogin@bazaar.launchpad.net/~mylogin/+junk/myproject [20:11] even this? [20:11] that one is ok [20:12] but it does not work [20:12] even on ubuntu or windows haha... [20:12] but you can simply do bzr push lp:~yeonhoo/+junk/yourproject [20:12] do you have an launchpad account? :p [20:12] yes i have [20:12] what is lp command? [20:12] it's just a shorthand [20:13] for launchpad branches [20:13] ok... same error [20:13] very strange [20:15] wait … did you upload your public ssh key to lp? [20:15] you need to do that, otherwise you cannat push [20:15] upload my public ssh key? [20:15] no.. [20:15] i uploaded to launchpad [20:16] yes, but you need to add your ssh key to launchpad before you can push to it [20:16] yes i add to launchpad already [20:16] but i have to add it to bzr ? something like that? === thumper_laptop is now known as thumper [20:17] should work out on the box with ubuntu [20:17] on windows you need pageant for it to work [20:17] even on ubuntu doesnt work [20:17] the same error [20:18] yeonhoo@yeonhoo-desktop:~$ bzr push lp:~yeonhoo/+junk/teste [20:18] bzr: ERROR: Not a branch: "/home/yeonhoo/". [20:19] its something like that [20:19] huh [20:19] ouch … [20:19] you need to create a bzr repo first [20:19] bzr init [20:19] :/ [20:20] Of course, you probably don't want to do that in $HOME... [20:23] well, yes, you don't want to do that in ~ === spm_ is now known as spm [20:26] yeonhoo_ub: have you come right yet? [20:28] yeonhoo: have you done a `bzr lp-login`? [20:28] opss im back [20:28] thumper: im logged yes [20:28] isn't there todo's en-masse on the net? *scnr* [20:29] yeonhoo: I mean have you typed the command `bzr lp-login`? [20:29] thumper yes [20:29] yeonhoo: Where is the branch you are pushing from? [20:29] yeonhoo: have you got things sorted yet? [20:29] yes it seems to be working now [20:30] as knitt1 said i did bzr init [20:30] * thumper nods [20:30] yeonhoo: now you are pushing a empty branch? is that correct? [20:31] !?... [20:31] yes i think... [20:31] is branch a kind of project box yea? [20:31] Yes [20:31] yes i created an empty branch called "teste" [20:32] ok [20:32] and im now "push" to it [20:32] is push command just for access the branch yea? [20:33] You would use push to copy your work form your computer to launchpad. [20:33] You would use pull to copy from launchpad to your computer... [20:34] yea.. maybe im asking stupid question..... [20:34] yea..ok [20:34] it is asking for password [20:35] On windows? [20:35] i think it is askin for ssh keys [20:35] yes [20:35] i have to put all the ssh !!... [20:35] !?...wow [20:35] Information about games on Ubuntu can be found at https://help.ubuntu.com/community/Games and http://www.icculus.org/lgfaq/gamelist.php [20:36] Are you running pageant? [20:36] no im not [20:36] pageant? [20:36] On windows, you need to run pageant, and load your private key [20:36] ah.. [20:36] ok.. im on way [20:37] http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html [20:38] yeah..it authenticate automatically [20:38] good...! [20:39] thank you :) [20:48] wow... im surprised with such tool... === ajmitch_ is now known as ajmitch [21:17] is branch name can be changed? [21:17] sure [21:18] lifeless: could you give me keyword? [21:18] yeonhoo: 'mv' [21:18] thank you ! :) [21:22] hum [21:23] i think i need an exemple [21:23] to mv existe branch on net what should i do? [21:24] i was trying "bzr mv lp:~blbalbalbal/source lp:~blablabla/destinatino [21:24] oh [21:24] you have to do that on the website [21:26] oh. [21:27] yeonhoo: if it was on your disk it would be 'mv source destinatino' [21:27] yeonhoo: but launchpad isn't a file system :) [21:27] yeonhoo: if you go to the branch page you should be able to rename it [21:36] yeonhoo: you can rename a branch on launchpad by clicking on the edit link (a yellow pencil IIRC) [21:44] How do I set up a bzr ignore rule so that when I add a git project I don't get any of the .git folders? [21:44] tristil: 'bzr ignore .git' [21:48] lifeless, cool thanks. I was trying /.git/ */.git/*, etc. [21:48] tristil: we do support a regex syntax and zsh's magic syntax, but thats only needed rarely :) [21:49] I guess I was using bash wildcards, but I thought the first one should have worked. [21:51] sorry :) [22:03] lifeless, hi [22:04] hi jelmer [22:04] lifeless: What format from brisbane-core should I use when importing large rich-root repositories (OOO) ? [22:05] development4 [22:05] erm [22:06] you need rich root yeah? you'll need to add a rich root variant of dev4, or use dev4-subtree [22:07] thanks [22:16] If I want to test merge a remote branch into another remote branch programmatically, what's the best way to approach that? Get a checkout of the target (for the working tree) and merge in source? [22:16] spiv: so, my place or yours? (please say 'lifeless' place') [22:17] rockstar: PreviewTree [22:17] lifeless, well, what if the end goal is committing? [22:17] rockstar: in principle you could commit a PreviewTree [22:18] no idea about practice :) [22:19] Alright, I'll go digging. [22:19] MutableTree.commit() is the entry point [22:19] lifeless: yours is fine, but I can't get there until midday or so. I have an errand to take care of. [22:20] spiv: cool. I have 'target_versionedfile.insert_record_stream(NetworkRecordStream([record.get_bytes_as(record.storage_kind) for record in source_versioned_file.get_record_stream()).read())' working [22:21] spiv: just let me know eta - sms or whatever. I'll try to get sprint tickets and other housekeeping done before you arrive [22:21] Ok. [22:21] I have resumed write groups committing successfully. [22:21] sweet [22:22] de alchemy progresses [22:24] sup [22:25] what are the plans for performance? compared to git/hg bzr still tends to feel a bit slugish [22:26] ronny: extensive :) [22:27] ronny: lifeless and I are tackling network performance at the moment, and other folk are working on building a faster repository format. [22:27] another one again? [22:29] btw, whats the reasoning behind xml in the repos? [22:30] the sources have sarcastic comments about that [22:31] There's a brief note about it at http://doc.bazaar-vcs.org/obsolete-docs/yaml.html [22:31] I'm not sure if there's a more extensive discussion somewhere else. [22:32] in comparisation git has some pretty neat optimized fieldsets there that can be parsed rather simple [22:32] ronny: xml was chosen because it was 'standard' - but we didn't appreciate how much of a burden it would turn out to be [22:33] vila, ping? [22:33] ronny: the reason for another repository format is to remove much of the xml we parse. As a datapoint, bzr.dev's repository has 3.3GB of xml inventory data [22:33] beuno, ping too :) [22:33] ronny: (after zlib and delta decompression) [22:33] ronny: thats a huge amount of data to parse and process, and its nearly entirely dead weight [22:34] spiv: success! [22:34] spiv: I can cleanly networkise and unnetworkise a knit's record_stream with delta_closure=False [22:35] lifeless: will the xml gradually go away with new repo formats? [22:35] ronny: I imagine so, there is no reason to keep it; revision's for instance have problems with some legacy commit messages that can't be encoded in xml sanely [22:36] so doing away with it will fix bugs/ickyness [22:36] ronny: its just not worth doing a repo format solely to remove it [22:36] ah, k [22:37] for instance, several folk did repo formats that were just yet-another-line-based-format, but not enough of a difference to force people to transcode their data [22:37] the brisbane-core format is really very different though; massively less raw data to process, so log -v and other commands should be a lot faster [22:37] igc is working on that aspect of brisbane-core at the moment [22:38] any eta on when it will land? [22:38] we're hoping to have a beta (--developmentX) format for early adopters and benchmarkers in late march [22:38] good [22:39] once we find and fix any issues from them we'll make a long term supported version of it [22:40] lifeless: Where can I find docs/branch for brisbane-core? [22:40] lp:~bzr/bzr/brisbane-core [22:40] lifeless, I can notice the recent speed improvements in brisbane-core [22:41] jelmer: cool; what are you doing that you notice? [22:41] another thing that makes me wonder - why different stores for revs, inventories and texts? [22:41] lifeless, importing 1k revisions from OOo [22:42] ronny: legacy; we're moving to a single key space. We nearly did at 1.6 but I was a bit of a stick in the mud at the time. [22:42] ah, i see [22:42] you gradually kill all points that i actually dislike [22:42] ronny: way way way back poolies prototype had seperate directories for each kind of thing [22:43] lifeless: the last 2 things i actually miss is content addressing and custom objects [22:43] tla didn't even have stores so its not even worth mentioning, other than to say it did have three 'kinds' of things, and I think that coloured the bzr prototype somewhat [22:43] ronny: brisbane-core uses CHK (content hash key's - a reasonably widely used term) for the elements of its inventories [22:44] content addressing per-se isn't terribly useful IMO [22:44] re: custom objects, what system allows that? [22:44] none atm [22:44] ah :) [22:44] well, in git i can actually create them [22:45] but then the repo is fscked [22:45] the network stream won't be able to handle them [22:45] just setting a type byte isn't enough :) [22:45] ronny: I'd like to understand a bit more about these things, how you want them to behave [without your plugin], how they should connect(or not) to revisions and inventories and so on [22:45] lifeless: i would be ok if there was some kind of "rich" type that supported referencing + custom data [22:46] lifeless: i'd like to use them for stuff like approvals for comits or testresults [22:46] lifeless, importing 1k revisions of OOo SVN takes 270 seconds on my 3-year old thinkpad, down from > 4000 seconds a few months ago [22:47] lifeless, admittedly bzr-svn has also improved since [22:47] jelmer: thats a nice improvement [22:47] jelmer: what tree adding api are you using? [22:47] lifeless, I'm using .texts directly, and calling Repository.add_inventory_by_delta() [22:48] jelmer: texts.insert_record_stream() ? [22:48]