| mxpxpod | is there a new bzr-svn for 1.12? | 00:00 |
|---|---|---|
| jelmer | mxpxpod, 0.5.0 | 00:00 |
| mxpxpod | jelmer: thanks | 00:01 |
| mxpxpod | jelmer: where do I pick up bzr-rebase 0.4.3? | 00:13 |
| jelmer | mxpxpod, http://samba.org/~jelmer/bzr | 00:18 |
| mxpxpod | jelmer: I only see up to 0.4.2 | 00:18 |
| jelmer | mxpxpod, try refresh :-) | 00:18 |
| mxpxpod | nice | 00:18 |
| mxpxpod | thanks | 00:18 |
| mxpxpod | jelmer: will that eventually be in the ppa? | 00:18 |
| jelmer | mxpxpod: I don't think rebase is part of the packages in the PPA | 00:19 |
| jelmer | mxpxpod: (I don't upload to the PPA) | 00:19 |
| mxpxpod | jelmer: gotcha | 00:19 |
| mxpxpod | jelmer: now, to upgrade all of my branches ;) | 00:25 |
| mxpxpod | jelmer: does 0.5 use any svn props? | 00:26 |
| jelmer | mxpxpod: it uses svn:executable | 00:27 |
| jelmer | and it will set svn:mergeinfo in some cases | 00:27 |
| mxpxpod | but no bzr: | 00:27 |
| jelmer | mxpxpod, you mean whether it will write them?> | 00:27 |
| jelmer | 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 |
| mxpxpod | jelmer: right... it used to set bzr:revison-info, bzr:file-ids, bzr:revision-id:v3-trunk1, etc | 00:28 |
| jelmer | mxpxpod, it will still do that if the server doesn't support setting revision properties | 00:29 |
| mxpxpod | jelmer: gotcha | 00:29 |
| mxpxpod | jelmer: thanks | 00:30 |
| mxpxpod | jelmer: one last thing... is there any way to set other svn: props thru bzr? | 00:30 |
| mxpxpod | for instance, svn:eol-style | 00:30 |
| jelmer | mxpxpod: no, that would require bzr to support eol-style itself first | 00:31 |
| mxpxpod | doesn't bzr just use the native eol-style on each platform? | 00:31 |
| jelmer | mxpxpod, no, bzr doesn't convert eol-characters atm | 00:31 |
| mxpxpod | jelmer: ah, gotcha | 00:31 |
| jelmer | there are some plans to support it, not sure how far along they are | 00:32 |
| mxpxpod | jelmer: oh, one last thing... does it support svn:external yet? | 00:35 |
| jelmer | mxpxpod, no, same thing - bzr itself doesn't support nested trees yet | 00:35 |
| mxpxpod | k | 00:35 |
| jelmer | so there's no way for bzr-svn to do so | 00:35 |
| mxpxpod | thanks for answering all of my questions | 00:35 |
| jelmer | np | 00:35 |
| mxpxpod | jelmer: does svn-upgrade upgrade the cache from ~/.bazaar/svn-cache? or does it grab the revisions fresh? | 00:46 |
| jelmer | mxpxpod, it cache format has changed a bit so it will create a new cache | 00:46 |
| mxpxpod | jelmer: ok | 00:46 |
| mxpxpod | jelmer: thanks for all the help | 00:52 |
| mxpxpod | 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:56 |
| jelmer | mxpxpod: it should show up if you run "bzr log" against the remote server | 00:57 |
| jelmer | mxpxpod: It won't show up in the log of the revision you have pushed, since that would be problematic: | 00:58 |
| jelmer | it would require "bzr push" to change the source branch (which it doesn't do, by definition) | 00:58 |
| jelmer | what would happen if you "bzr push"'ed to multiple svn repositories? | 00:58 |
| mxpxpod | jelmer: ah, so bzr log :parent do what I'm talking about? | 00:58 |
| mxpxpod | jelmer: makes sense | 00:59 |
| jelmer | mxpxpod: Yep | 00:59 |
| mxpxpod | jelmer: heh, bzr log :parent takes a long time on a repo with lots of revs ;) | 00:59 |
| jelmer | mxpxpod, 0.5.1 should be a bit better in that regard | 01:02 |
| mxpxpod | jelmer: cool | 01:02 |
| mxpxpod | 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 |
| mxpxpod | jelmer: but, a fresh branch of the repo doesn't have any conflicting tags | 01:03 |
| jelmer | could it find revisions for the tags previously? | 01:03 |
| mxpxpod | not sure | 01:03 |
| jelmer | mxpxpod, any chance you can file a bug about that? | 01:04 |
| mxpxpod | jelmer: if I can reproduce it on a repository that's public, yes | 01:04 |
| mxpxpod | jelmer: will 0.5.1 help with pull speed? | 01:05 |
| jelmer | mxpxpod, yes | 01:05 |
| mxpxpod | cool | 01:05 |
| maxb | 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:06 |
| jelmer | maxb: no, 1.12 should be fine | 01:07 |
| mxpxpod | jelmer: does svn-upgrade migrate revprops? | 01:07 |
| jelmer | mxpxpod, what do you mean exactly? | 01:08 |
| mxpxpod | jelmer: does it do bzr svn-set-revprops ? | 01:08 |
| jelmer | mxpxpod, no, it only changes the local branch, never the svn repository | 01:08 |
| mxpxpod | ok | 01:08 |
| mxpxpod | jelmer: is there a way to get tags to list the correct revision rather than "?" ? | 01:10 |
| jelmer | mxpxpod: Generally not, because the ? would be shown because the tag is on a revision that is not in the branch | 01:10 |
| mxpxpod | jelmer: ah, ok | 01:11 |
| jelmer | --show-ids will show the "raw" revision id | 01:11 |
| mxpxpod | jelmer: hmm... some of the tags are still pointing to svn-v3-trunk0 ids | 01:14 |
| jelmer | mxpxpod, that could be correct if you used bzr-svn to push revisions into svn in the past | 01:15 |
| mxpxpod | jelmer: ok | 01:15 |
| mxpxpod | 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 |
| jelmer | mxpxpod, was this the branch that you got the conflicts on earlier? | 01:19 |
| jelmer | mxpxpod, what happens if you do a clean copy? | 01:19 |
| mxpxpod | 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 |
| mxpxpod | then when I got 0.5, I did this: mv trunk trunk.old; bzr branch http://somerepo/trunk trunk | 01:21 |
| mxpxpod | jelmer: make sense? | 01:22 |
| jelmer | mxpxpod, yeah | 01:22 |
| mxpxpod | jelmer: now, bzr tags --show-ids show v3 ids in 1.3.4 | 01:22 |
| jelmer | and trunk shows v4 ids ? | 01:23 |
| mxpxpod | jelmer: yup | 01:23 |
| jelmer | but you have the same amount of "?"'s in 1.3.4 and trunk? | 01:23 |
| mxpxpod | yes | 01:24 |
| mxpxpod | but when I do a pull in 1.3.4, it says there are conflicting tags for the tags that are v3 | 01:24 |
| jelmer | mxpxpod, that's correct | 01:24 |
| mxpxpod | jelmer: how do I get those tags to point to the v4 equivalent? | 01:24 |
| jelmer | if you run "bzr svn-upgrade" in 1.3.4 it should fix those tags | 01:24 |
| jelmer | if it doesn't then that's a bug | 01:25 |
| mxpxpod | it says trunk is not a foreign repository | 01:25 |
| jelmer | mxpxpod, you need to specify the svn repository | 01:25 |
| mxpxpod | jelmer: awesome! thanks | 01:26 |
| mxpxpod | jelmer: and if I run that same command in trunk, it upgrades the old v3 ones to v4 | 01:29 |
| jelmer | mxpxpod, Ouch, that's wrong | 01:29 |
| mxpxpod | it does the same thing in 1.3.4 | 01:31 |
| mxpxpod | it doesn't keep the v3 ones that are supposed to be v3 as v3 | 01:32 |
| jelmer | mxpxpod, should be fixed in the 0.5 branch | 01:35 |
| mxpxpod | jelmer: will it fix the v4 thing? | 01:40 |
| jelmer | mxpxpod, v4 thing? | 01:40 |
| mxpxpod | jelmer: where 1.3.4 had v3 ids and then I ran svn-upgrade and got v3 ids... will it fix that? | 01:40 |
| jelmer | mxpxpod, it will make sure svn-upgrade doesn't upgrade some revisions to v4 unnecessarily | 01:40 |
| mxpxpod | jelmer: also, are you talking about the lp:bzr-svn branch? | 01:41 |
| jelmer | mxpxpod: Where did you get v3 ids in the 1.3.4 branch exactly? | 01:42 |
| mxpxpod | for some tags I made with the old bzr-svn a while back | 01:42 |
| jelmer | mxpxpod: It's not incorrect if it leaves some v3 revisions | 01:43 |
| mxpxpod | jelmer: right | 01:43 |
| mxpxpod | jelmer: but it changed the v3 ones that I made to v4 | 01:43 |
| jelmer | mxpxpod: But it should only do that for tags that are not "?" tags | 01:43 |
| jelmer | mxpxpod, that bit should be fixed now (upgrading some to v4 incorrectly) | 01:44 |
| mxpxpod | jelmer: in lp:bzr-svn? | 01:44 |
| jelmer | mxpxpod, bzr-svn's main branch is at http://people.samba.org/bzr/jelmer/bzr-svn/0.5 | 01:44 |
| jelmer | lp is usually out of date | 01:44 |
| mxpxpod | ah, ok | 01:44 |
| mxpxpod | 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:47 |
| jelmer | mxpxpod: Fix the tags after bzr-svn all changed them to v4 tags? | 01:48 |
| mxpxpod | jelmer: yes | 01:48 |
| jelmer | mxpxpod, if the tags are in svn, you can just "bzr pull" from svn | 01:48 |
| mxpxpod | that doesn't change them from v4 back to v3 | 01:49 |
| mxpxpod | aha! | 01:50 |
| mxpxpod | bzr pull --overwrite | 01:50 |
| jelmer | ah | 01:51 |
| mxpxpod | and that fixed it | 01:52 |
| mxpxpod | jelmer: thanks for the help | 01:52 |
| jelmer | mxpxpod, once again, np :-) | 01:53 |
| mxpxpod | jelmer: now you know what to tell people that have the same problem as me :D | 01:53 |
| jelmer | and thanks for helping fix that bug in svn-upgade | 01:53 |
| mxpxpod | jelmer: not a problem | 01:53 |
| mxpxpod | alright, gotta go | 01:54 |
| mxpxpod | have a good nige | 01:54 |
| mxpxpod | night | 01:54 |
| evarlast | 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:19 |
| evarlast | nevermind. I'm stupid. just copy fcgi.py along size bzr-smart.fcgi is easier. | 03:22 |
| evarlast | anyone using bzr-smart.fcgi with modwsgi? | 05:02 |
| evarlast | google is amazing, looks like someone had my same issue, very recently: http://pastebin.com/m533f12af | 05:05 |
| evarlast | ok, that issue is fixed, now I can't auth on windows, but I can auth on linux with the same config :( | 05:44 |
| === tchan1 is now known as tchan | ||
| gour | hi, how to get branch from LP when it reports: "bzr: ERROR: The API for "<module 'bzrlib' from '/usr/lib/python2.6/site-packages/bzrlib/__init__.pyc'>" is not compatible with "(1, 10, 0)". It supports versions "(1, 11, 0)" to "(1, 11, 0)"." ? | 11:47 |
| fullermd | That's probably nothing to do with LP. | 11:49 |
| fullermd | 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 |
| gour | hmm, i'm running 1.11 | 11:49 |
| Peng_ | Or bzr-svn or some other plugin is doing it. | 11:49 |
| Peng_ | I think "bzr" itself raises a different error. | 11:50 |
| fullermd | Oh, I forgot bzr-svn had that quirk in a version or two. That sounds more likely. | 11:50 |
| gour | hmm, ok..let me check bzr-svn | 11:50 |
| gour | thanks. rm-ing bzr-svn did it :-) | 11:51 |
| Peng_ | That's a wee bit extreme. | 11:51 |
| gour | sure it is, but, well | 11:52 |
| gour | ... | 11:52 |
| Leonidas | Is this a known issue: http://paste.pocoo.org/show/104115/ | 14:31 |
| Leonidas | It happened when I bzr unshelve'd | 14:31 |
| Odd_Bloke | Leonidas: Yes, that's bug #328148. | 14:44 |
| ubottu | Launchpad bug 328148 in bzr "Less spaff from unshelve, please" [Undecided,Confirmed] https://launchpad.net/bugs/328148 | 14:44 |
| Odd_Bloke | It's just a problem in the progress bar, nothing to worry about. | 14:45 |
| Leonidas | Odd_Bloke: Thanks. I thought that it wasn't really important, just wanted to make sure the developers know about it :) | 14:47 |
| Odd_Bloke | Leonidas: Thank you. :) | 14:51 |
| radix | 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:17 |
| ronny | oh, that idea might be nice fir pida, too | 18:18 |
| radix | 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 |
| radix | but barring a GUI, I guess it could just notify you of the conflict next time you ran a bzr command, or something. | 18:18 |
| radix | sorry, I'm saying "conflicts" but I actually mean "divergent branches" | 18:19 |
| ronny | i think seting up per-user push branches is helpfull | 18:19 |
| radix | just an idle thought while waiting for a 'bzr commit' to complete in a hotel room :) | 18:19 |
| ronny | keeps conflicst out of the way till one chooses to do | 18:19 |
| ronny | that would need another async checker that ckecks for changes on the pull path | 18:20 |
| radix | ronny: yeah, sure, but I have the same branches bound on my desktop and my laptop machine | 18:20 |
| ronny | and then pops up a notification | 18:20 |
| ronny | radix: ah i see | 18:20 |
| ronny | but you dont work at both at the same time? | 18:20 |
| radix | I'll switch back and forth and often forget to update before changing something | 18:21 |
| ronny | so asnc update checking might be helpfull, too | 18:21 |
| radix | but yeah, something that automatically *pulls* would also help that | 18:21 |
| radix | I could just set up a few cron jobs I guess | 18:21 |
| ronny | i'll have to remember that | 18:21 |
| ronny | it would certainly be a nice addition to pida | 18:22 |
| ronny | (an ide) | 18:22 |
| radix | ah, I was just about to ask what it is. | 18:22 |
| ronny | jelmer: is there any documentation about bzr's current storage formats other than the source? | 18:24 |
| ronny | im stil a bit lost on figuring where those weird xml things are needed | 18:24 |
| ronny | ok | 18:27 |
| ronny | now i figured it | 18:27 |
| ronny | sad, just sad | 18:31 |
| jelmer | ronny, xml things? | 18:49 |
| jelmer | ronny, there shouldn't be a need for you to bother with internals.. | 18:49 |
| ronny | jelmer: well, i know the git and hg internals, now i want to know the bzr ones | 18:50 |
| ronny | and i get more and more unhappy with that stuff | 18:52 |
| jelmer | ronny: ah | 18:54 |
| jelmer | ronny, there's some docs in doc/developers/ | 18:54 |
| jelmer | ronny, what makes you unhappy though? | 18:54 |
| ronny | the kiss principle seems to be missing | 18:55 |
| jelmer | it seems pretty simple to me - one store for revisions, one for inventories, one for texts, that's it basically | 18:56 |
| jelmer | gtg, back later | 18:58 |
| ronny | everything seems striple if you strip the details out | 18:58 |
| edcrypt_ | is there a way to iterate over all versioned files of a wt, on a specific dir? | 19:22 |
| ronny | edcrypt_: there is WorkingTree.list_files, but it doesnt filter, maybe there is an better api im not aware of | 19:26 |
| edcrypt_ | ronny: the sdocstring says it list unversioned dirs, no mch better than WT.iter_entries_by_dir | 19:29 |
| ronny | edcrypt_: there is the filter_unversioned_files method | 19:32 |
| edcrypt_ | ronny: thanks, I'll take a look. | 19:34 |
| ronny | bbl | 19:34 |
| yeonhoo | helloo | 19:52 |
| yeonhoo | bzr push bzr+ssh bzr+ssh://login@bazaar.launchpad.net/~registrant/project/branch <---> bzr: ERROR: Not a branch: "C:/program files blablablablal" | 19:55 |
| yeonhoo | seems like bzr+ssh unknown command | 19:56 |
| yeonhoo | any help? | 19:58 |
| knitt1 | hello. i made a stupid merge, how can i delete that commit? or how can i fix it? xD | 20:07 |
| yeonhoo | hmmmm | 20:08 |
| yeonhoo | i installed bazaar on ubuntu,, but same error occures | 20:09 |
| knitt1 | turns out i deleted the upstream changes, not mine | 20:09 |
| yeonhoo | well.. seem like to not be an error | 20:09 |
| yeonhoo | knitt1: hi | 20:09 |
| knitt1 | hi yea | 20:10 |
| knitt1 | * yeonhoo | 20:10 |
| yeonhoo | yes im new here.. im having problem | 20:10 |
| knitt1 | ok, i'll try to help you. but i'm not so fit with bazaar either | 20:10 |
| knitt1 | go ahead :) | 20:10 |
| yeonhoo | bzr push bzr+ssh <-- is this command always output " bzr: error: not a branch" ? | 20:10 |
| yeonhoo | ok :) | 20:10 |
| knitt1 | yeah, that command makes no sense | 20:11 |
| yeonhoo | bzr push bzr+ssh://mylogin@bazaar.launchpad.net/~mylogin/+junk/myproject | 20:11 |
| yeonhoo | even this? | 20:11 |
| knitt1 | that one is ok | 20:11 |
| yeonhoo | but it does not work | 20:12 |
| yeonhoo | even on ubuntu or windows haha... | 20:12 |
| knitt1 | but you can simply do bzr push lp:~yeonhoo/+junk/yourproject | 20:12 |
| knitt1 | do you have an launchpad account? :p | 20:12 |
| yeonhoo | yes i have | 20:12 |
| yeonhoo | what is lp command? | 20:12 |
| knitt1 | it's just a shorthand | 20:12 |
| knitt1 | for launchpad branches | 20:13 |
| yeonhoo | ok... same error | 20:13 |
| yeonhoo | very strange | 20:13 |
| knitt1 | wait … did you upload your public ssh key to lp? | 20:15 |
| knitt1 | you need to do that, otherwise you cannat push | 20:15 |
| yeonhoo | upload my public ssh key? | 20:15 |
| yeonhoo | no.. | 20:15 |
| yeonhoo | i uploaded to launchpad | 20:15 |
| knitt1 | yes, but you need to add your ssh key to launchpad before you can push to it | 20:16 |
| yeonhoo | yes i add to launchpad already | 20:16 |
| yeonhoo | but i have to add it to bzr ? something like that? | 20:16 |
| === thumper_laptop is now known as thumper | ||
| knitt1 | should work out on the box with ubuntu | 20:17 |
| knitt1 | on windows you need pageant for it to work | 20:17 |
| yeonhoo | even on ubuntu doesnt work | 20:17 |
| yeonhoo | the same error | 20:17 |
| yeonhoo_ub | yeonhoo@yeonhoo-desktop:~$ bzr push lp:~yeonhoo/+junk/teste | 20:18 |
| yeonhoo_ub | bzr: ERROR: Not a branch: "/home/yeonhoo/". | 20:18 |
| yeonhoo_ub | its something like that | 20:19 |
| yeonhoo_ub | huh | 20:19 |
| knitt1 | ouch … | 20:19 |
| knitt1 | you need to create a bzr repo first | 20:19 |
| knitt1 | bzr init | 20:19 |
| knitt1 | :/ | 20:19 |
| fullermd | Of course, you probably don't want to do that in $HOME... | 20:20 |
| knitt1 | well, yes, you don't want to do that in ~ | 20:23 |
| === spm_ is now known as spm | ||
| garyvdm | yeonhoo_ub: have you come right yet? | 20:26 |
| thumper | yeonhoo: have you done a `bzr lp-login`? | 20:28 |
| yeonhoo | opss im back | 20:28 |
| yeonhoo | thumper: im logged yes | 20:28 |
| knitt1 | isn't there todo's en-masse on the net? *scnr* | 20:28 |
| thumper | yeonhoo: I mean have you typed the command `bzr lp-login`? | 20:29 |
| yeonhoo | thumper yes | 20:29 |
| garyvdm | yeonhoo: Where is the branch you are pushing from? | 20:29 |
| thumper | yeonhoo: have you got things sorted yet? | 20:29 |
| yeonhoo | yes it seems to be working now | 20:29 |
| yeonhoo | as knitt1 said i did bzr init | 20:30 |
| * thumper nods | 20:30 | |
| garyvdm | yeonhoo: now you are pushing a empty branch? is that correct? | 20:30 |
| yeonhoo | !?... | 20:31 |
| yeonhoo | yes i think... | 20:31 |
| yeonhoo | is branch a kind of project box yea? | 20:31 |
| garyvdm | Yes | 20:31 |
| yeonhoo | yes i created an empty branch called "teste" | 20:31 |
| garyvdm | ok | 20:32 |
| yeonhoo | and im now "push" to it | 20:32 |
| yeonhoo | is push command just for access the branch yea? | 20:32 |
| garyvdm | You would use push to copy your work form your computer to launchpad. | 20:33 |
| garyvdm | You would use pull to copy from launchpad to your computer... | 20:33 |
| yeonhoo | yea.. maybe im asking stupid question..... | 20:34 |
| yeonhoo | yea..ok | 20:34 |
| yeonhoo | it is asking for password | 20:34 |
| garyvdm | On windows? | 20:35 |
| yeonhoo | i think it is askin for ssh keys | 20:35 |
| yeonhoo | yes | 20:35 |
| yeonhoo | i have to put all the ssh !!... | 20:35 |
| yeonhoo | !?...wow | 20:35 |
| ubottu | Information about games on Ubuntu can be found at https://help.ubuntu.com/community/Games and http://www.icculus.org/lgfaq/gamelist.php | 20:35 |
| garyvdm | Are you running pageant? | 20:36 |
| yeonhoo | no im not | 20:36 |
| yeonhoo | pageant? | 20:36 |
| garyvdm | On windows, you need to run pageant, and load your private key | 20:36 |
| yeonhoo | ah.. | 20:36 |
| yeonhoo | ok.. im on way | 20:36 |
| garyvdm | http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html | 20:37 |
| yeonhoo | yeah..it authenticate automatically | 20:38 |
| yeonhoo | good...! | 20:38 |
| yeonhoo | thank you :) | 20:39 |
| yeonhoo | wow... im surprised with such tool... | 20:48 |
| === ajmitch_ is now known as ajmitch | ||
| yeonhoo | is branch name can be changed? | 21:17 |
| lifeless | sure | 21:17 |
| yeonhoo | lifeless: could you give me keyword? | 21:18 |
| lifeless | yeonhoo: 'mv' | 21:18 |
| yeonhoo | thank you ! :) | 21:18 |
| yeonhoo | hum | 21:22 |
| yeonhoo | i think i need an exemple | 21:23 |
| yeonhoo | to mv existe branch on net what should i do? | 21:23 |
| yeonhoo | i was trying "bzr mv lp:~blbalbalbal/source lp:~blablabla/destinatino | 21:24 |
| mwhudson | oh | 21:24 |
| mwhudson | you have to do that on the website | 21:24 |
| yeonhoo | oh. | 21:26 |
| lifeless | yeonhoo: if it was on your disk it would be 'mv source destinatino' | 21:27 |
| lifeless | yeonhoo: but launchpad isn't a file system :) | 21:27 |
| lifeless | yeonhoo: if you go to the branch page you should be able to rename it | 21:27 |
| thumper | yeonhoo: you can rename a branch on launchpad by clicking on the edit link (a yellow pencil IIRC) | 21:36 |
| tristil | 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 |
| lifeless | tristil: 'bzr ignore .git' | 21:44 |
| tristil | lifeless, cool thanks. I was trying /.git/ */.git/*, etc. | 21:48 |
| lifeless | tristil: we do support a regex syntax and zsh's magic syntax, but thats only needed rarely :) | 21:48 |
| tristil | I guess I was using bash wildcards, but I thought the first one should have worked. | 21:49 |
| lifeless | sorry :) | 21:51 |
| jelmer | lifeless, hi | 22:03 |
| lifeless | hi jelmer | 22:04 |
| jelmer | lifeless: What format from brisbane-core should I use when importing large rich-root repositories (OOO) ? | 22:04 |
| lifeless | development4 | 22:05 |
| lifeless | erm | 22:05 |
| lifeless | you need rich root yeah? you'll need to add a rich root variant of dev4, or use dev4-subtree | 22:06 |
| jelmer | thanks | 22:07 |
| rockstar | 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 |
| lifeless | spiv: so, my place or yours? (please say 'lifeless' place') | 22:16 |
| lifeless | rockstar: PreviewTree | 22:17 |
| rockstar | lifeless, well, what if the end goal is committing? | 22:17 |
| lifeless | rockstar: in principle you could commit a PreviewTree | 22:17 |
| lifeless | no idea about practice :) | 22:18 |
| rockstar | Alright, I'll go digging. | 22:19 |
| lifeless | MutableTree.commit() is the entry point | 22:19 |
| spiv | lifeless: yours is fine, but I can't get there until midday or so. I have an errand to take care of. | 22:19 |
| lifeless | 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:20 |
| lifeless | 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 |
| spiv | Ok. | 22:21 |
| spiv | I have resumed write groups committing successfully. | 22:21 |
| lifeless | sweet | 22:21 |
| lifeless | de alchemy progresses | 22:22 |
| ronny | sup | 22:24 |
| ronny | what are the plans for performance? compared to git/hg bzr still tends to feel a bit slugish | 22:25 |
| spiv | ronny: extensive :) | 22:26 |
| spiv | ronny: lifeless and I are tackling network performance at the moment, and other folk are working on building a faster repository format. | 22:27 |
| ronny | another one again? | 22:27 |
| ronny | btw, whats the reasoning behind xml in the repos? | 22:29 |
| ronny | the sources have sarcastic comments about that | 22:30 |
| spiv | There's a brief note about it at http://doc.bazaar-vcs.org/obsolete-docs/yaml.html | 22:31 |
| spiv | I'm not sure if there's a more extensive discussion somewhere else. | 22:31 |
| ronny | in comparisation git has some pretty neat optimized fieldsets there that can be parsed rather simple | 22:32 |
| lifeless | 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:32 |
| emmajane | vila, ping? | 22:33 |
| lifeless | 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 |
| emmajane | beuno, ping too :) | 22:33 |
| lifeless | ronny: (after zlib and delta decompression) | 22:33 |
| lifeless | ronny: thats a huge amount of data to parse and process, and its nearly entirely dead weight | 22:33 |
| lifeless | spiv: success! | 22:34 |
| lifeless | spiv: I can cleanly networkise and unnetworkise a knit's record_stream with delta_closure=False | 22:34 |
| ronny | lifeless: will the xml gradually go away with new repo formats? | 22:35 |
| lifeless | 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:35 |
| lifeless | so doing away with it will fix bugs/ickyness | 22:36 |
| lifeless | ronny: its just not worth doing a repo format solely to remove it | 22:36 |
| ronny | ah, k | 22:36 |
| lifeless | 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 |
| lifeless | 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 |
| lifeless | igc is working on that aspect of brisbane-core at the moment | 22:37 |
| ronny | any eta on when it will land? | 22:38 |
| lifeless | we're hoping to have a beta (--developmentX) format for early adopters and benchmarkers in late march | 22:38 |
| ronny | good | 22:38 |
| lifeless | once we find and fix any issues from them we'll make a long term supported version of it | 22:39 |
| garyvdm | lifeless: Where can I find docs/branch for brisbane-core? | 22:40 |
| lifeless | lp:~bzr/bzr/brisbane-core | 22:40 |
| jelmer | lifeless, I can notice the recent speed improvements in brisbane-core | 22:40 |
| lifeless | jelmer: cool; what are you doing that you notice? | 22:41 |
| ronny | another thing that makes me wonder - why different stores for revs, inventories and texts? | 22:41 |
| jelmer | lifeless, importing 1k revisions from OOo | 22:41 |
| lifeless | 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 |
| ronny | ah, i see | 22:42 |
| ronny | you gradually kill all points that i actually dislike | 22:42 |
| lifeless | ronny: way way way back poolies prototype had seperate directories for each kind of thing | 22:42 |
| ronny | lifeless: the last 2 things i actually miss is content addressing and custom objects | 22:43 |
| lifeless | 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 |
| lifeless | ronny: brisbane-core uses CHK (content hash key's - a reasonably widely used term) for the elements of its inventories | 22:43 |
| lifeless | content addressing per-se isn't terribly useful IMO | 22:44 |
| lifeless | re: custom objects, what system allows that? | 22:44 |
| ronny | none atm | 22:44 |
| lifeless | ah :) | 22:44 |
| ronny | well, in git i can actually create them | 22:44 |
| ronny | but then the repo is fscked | 22:45 |
| lifeless | the network stream won't be able to handle them | 22:45 |
| lifeless | just setting a type byte isn't enough :) | 22:45 |
| lifeless | 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 |
| ronny | lifeless: i would be ok if there was some kind of "rich" type that supported referencing + custom data | 22:45 |
| ronny | lifeless: i'd like to use them for stuff like approvals for comits or testresults | 22:46 |
| jelmer | 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:46 |
| jelmer | lifeless, admittedly bzr-svn has also improved since | 22:47 |
| lifeless | jelmer: thats a nice improvement | 22:47 |
| lifeless | jelmer: what tree adding api are you using? | 22:47 |
| jelmer | lifeless, I'm using .texts directly, and calling Repository.add_inventory_by_delta() | 22:47 |
| lifeless | jelmer: texts.insert_record_stream() ? | 22:48 |
| jelmer | lifeless, texts.add_lines() actually | 22:48 |
| lifeless | jelmer: ok; well if text adding starts to be important, I can suggest some refactorings to reduce duplicate work | 22:49 |
| jelmer | lifeless, and get_record_stream() to retrieve the fulltexts to apply the delta against | 22:49 |
| lifeless | jelmer: svn gives you byte deltas right? | 22:50 |
| === kiko-afk is now known as kiko-zzz | ||
| jelmer | lifeless, yeah | 22:50 |
| lifeless | shame :P | 22:50 |
| lifeless | line deltas we could nearly/probably translate directly to knit deltas, if svn gave you the sha1 | 22:50 |
| jelmer | unfortunately svn still uses md5 :-( | 22:50 |
| lifeless | jelmer: you might like to try the groupcompress plugin's --gc-subtree-chk, if I created one | 22:52 |
| lifeless | jelmer: that would give a very interesting repository size :) | 22:52 |
| lifeless | jelmer: but - you'd definitely want to use insert_record_stream, not add_lines | 22:52 |
| jelmer | lifeless, I | 22:52 |
| jelmer | 'll look at that, thanks | 22:52 |
| ronny | lifeless: do you see any reasonable way to put support for recording things like testresults/approvals into the store ? | 22:56 |
| lifeless | ronny: the former seems likely to be large | 22:57 |
| lifeless | and the latter small | 22:57 |
| lifeless | It seems like both of those would be indexed best by revision | 22:57 |
| ronny | could approvals be solved by signatures by more than one person? | 22:57 |
| lifeless | so you could say 'give me the test results for revid:XXX' | 22:57 |
| lifeless | and likewise the approvals | 22:58 |
| lifeless | so handwaving on how fetch would know to copy them, you could easily do what bzr-search does | 22:58 |
| lifeless | and use the bzr machinery to create a store containing what you want | 22:58 |
| * igc breakfast | 22:58 | |
| lifeless | I know thats probably not as integrated in as what you desire | 22:59 |
| lifeless | but we tend to find good answers after a couple of plugins start doing things outside the core, to let them hook in closer to the core | 22:59 |
| lifeless | things in the core need to move somewhat cautiously because of their broad impact on users (and the need to rev format ID's to ensure consistent handling of data etc) | 22:59 |
| lifeless | there are currently two plugins I know of annotating the core data in [technically different, but morally the same?] ways - bzr-revnocache and bzr-search | 23:00 |
| ronny | im kinda feed with enough info | 23:02 |
| ronny | i'll reevaluate bzr again once the new repo format is there | 23:02 |
| jelmer | igc, hi | 23:03 |
| jelmer | lifeless, the main overhead now is in svn itself, the bzr-svn cache (turning it off boosts performance significantly) and get_raw_records | 23:05 |
| * jelmer is happy and releases 0.5.1 | 23:06 | |
| rysiek|pl | hi guys | 23:07 |
| jelmer | hi rysiek|pl | 23:08 |
| rysiek|pl | I've got a problem - my co-worker added some *huge* (as in 100MiB+ huge) files (actually, some ~80 files, 3-4MiB each), committed and merged with my branch | 23:09 |
| rysiek|pl | those wqhere completely unneaded, so I bzr removed them | 23:09 |
| rysiek|pl | but, they are still in the packs, arent they? | 23:09 |
| bob2 | yes | 23:10 |
| rysiek|pl | this causes me to have ~400MiB branch for a code project we work on | 23:10 |
| bob2 | all you can really do is branch from before he/she did that | 23:10 |
| rysiek|pl | which is a royal PITA, as you may guess | 23:10 |
| rysiek|pl | thing is, it wasn't that bad PITA until now, so we're ~100 revisions ahead | 23:11 |
| rysiek|pl | as I understand there is no way I can simply "delete" the removed files from the branch | 23:12 |
| RAOF | IIRC you can branch to before the files were added and then replay the commits after the files were added to that branch; I think the 'bzr replay' command is what you're after, in the bzr-rebase plugin? | 23:12 |
| rysiek|pl | as bzr's purpose of life is to preserve them :) | 23:12 |
| rysiek|pl | ah | 23:12 |
| rysiek|pl | there we are | 23:12 |
| rysiek|pl | RAOF: thanks a bunch, that should work | 23:13 |
| lifeless | jelmer: get_raw_records - you mean disk IO? | 23:13 |
| RAOF | Right. It's not often that you want to expunge something from the history, but it can happen, and I've seen discussions here about precisely how to make it work nicely. | 23:13 |
| jelmer | lifeless: yes, retrieving the fulltexts to apply deltas against | 23:13 |
| rysiek|pl | ok, I'll grok some IRC logs from Teh intertubes and google some more for bzr replay | 23:13 |
| jelmer | lifeless, I might be able to avoid that a bit by keeping a LRU cache of recently generated fulltexts | 23:13 |
| rysiek|pl | that should get me on the right track, I guess :) | 23:14 |
| rysiek|pl | thanks again | 23:14 |
| jelmer | lifeless, since bzr-svn usually imports children right after their parents, and since linear history is very common in svn | 23:14 |
| jelmer | lifeless, ideal would be of course if bzr supported svn-deltas :-P | 23:14 |
| RAOF | rysiek|pl: If you run into trouble, I'm sure lifeless knows how to do what you want, when he's less busy :) | 23:15 |
| rysiek|pl | ok | 23:15 |
| lifeless | jelmer: we could look at putting a small LRU back into VersionedFiles; we had one but it was terrible in the past | 23:16 |
| lifeless | rysiek|pl: bob2 and RAOF are right | 23:16 |
| lifeless | rysiek|pl: once you've done that you won't have to copy the 400MiB around anymore, though it will be dead weight in your current repos, it won't clog up network ops or things like that | 23:17 |
| rysiek|pl | lifeless: exactly what I need | 23:17 |
| rysiek|pl | ho-humm... "At the end of the process it will appear as though your current branch was branched off the current last revision of the target." - but right now it is "as if it was branched" from that very original branch and revision | 23:17 |
| rysiek|pl | as it's just a single branch | 23:18 |
| rysiek|pl | ah, well | 23:18 |
| rysiek|pl | manpages ftw | 23:18 |
| emmajane | vila, beuno I've made a new page for the bzr-upload plugin. http://bazaar-vcs.org/BazaarUploadForWebDev I wanted some extra documentation for a talk I'm giving. Please edit as appropriate. :) | 23:22 |
| lifeless | rysiek|pl: are you stuck? | 23:23 |
| rysiek|pl | lifeless: nah, rather massively multitasking | 23:23 |
| lifeless | rysiek|pl: ok, just shout and RAOF and bob2 if you get stuck | 23:23 |
| lifeless | I've just volunteered em :) | 23:23 |
| rysiek|pl | ok, will do :) | 23:24 |
| RAOF | lifeless: No fair! I volunteered you first! | 23:24 |
| lifeless | RAOF: you did, but I'm wearing my teflon underpants today | 23:24 |
| rysiek|pl | RAOF, bob2, lifeless: that's not a problem, guys, you are simply all volounteers now :) | 23:25 |
| rysiek|pl | lifeless: no teflon underpants can save you from sharks | 23:25 |
| rysiek|pl | lifeless: ...with lasers! | 23:25 |
| lifeless | haha | 23:25 |
| RAOF | Eh. You don't need teflon underwear to deflect sharks. You just punch their nose through their skull. | 23:26 |
| rysiek|pl | RAOF: I think you missed the "with lasers" part. see, when you punch the nose of a laser-equipped shark, you actually *fire* the lasers | 23:28 |
| jelmer | lifeless, how much faster should it be to call insert_record_stream() with a single stream rather than multiple times with single items? | 23:31 |
| lifeless | jelmer: "it depends" :P | 23:32 |
| lifeless | jelmer: so GroupCompressVersionedFiles - they hold a single compressor context open during insert_record_stream() | 23:33 |
| lifeless | jelmer: so insert_record_stream([foo]), i_r_s([bar]) -> two seperate compression groups | 23:33 |
| jelmer | lifeless: in other words, it might matter if the texts were similar enough? | 23:33 |
| lifeless | i_r_s([foo, bar]) -> one compression group | 23:33 |
| lifeless | jelmer: and there is no delta compression between different groups in groupcompress today | 23:34 |
| lifeless | jelmer: so, one call per text -> you get zlib'd texts | 23:34 |
| jelmer | lifeless, ok | 23:34 |
| lifeless | one call for all texts -> you get delta compression | 23:34 |
| lifeless | for knits it doesn't make _as much_ difference | 23:35 |
| jelmer | lifeless, ok | 23:35 |
| jelmer | thanks again :-0 | 23:35 |
| jelmer | s/[0-9][)-(]/ | 23:36 |
| lifeless | its possible we should make gc hold the compression context open across inserts | 23:36 |
| lifeless | but this slight constraint seems useful IME | 23:36 |
| jelmer | will a repack change what compression context texts are in? | 23:38 |
| lifeless | repack on gc repos is currently broken | 23:41 |
| lifeless | bzr.dev changed to become more knit dependent, or something | 23:41 |
| lifeless | the intent is that gc will on autopack combine single commits into larger groups, so yes. | 23:42 |
| lifeless | but at a certain size of group it will stop fiddling ;) | 23:42 |
| jelmer | ok, in that case I won't bother overoptimizing fetch in bzr-svn | 23:42 |
| rysiek|pl | lifeless: let me get this straight: | 23:43 |
| rysiek|pl | 1. branch the crufted branch | 23:43 |
| rysiek|pl | 2. bzr revert to the revision with no crift yet | 23:43 |
| lifeless | rysiek|pl: 1. branch -r REV_BEFORE_BADNESS crufted fresh | 23:43 |
| rysiek|pl | 1 + 2 in a single step, right | 23:44 |
| lifeless | no, fundamentally different | 23:44 |
| lifeless | 'bzr revert' changes the tree only, you want to change the branch | 23:44 |
| rysiek|pl | ah, revert will leave the cruft in packs | 23:44 |
| rysiek|pl | okay | 23:44 |
| rysiek|pl | if I know the name of a bzr removed file, is there a way to easily check in what rev it was removed? | 23:45 |
| ronny | hmm, im a bit confused - is the only difference betwen normal and rich root a set of properties on the roots? | 23:45 |
| lifeless | ronny: yes | 23:53 |
| lifeless | rysiek|pl: bzr log -v | less - sorry :( | 23:53 |
| rysiek|pl | ssure | 23:53 |
| ronny | lifeless: then why the heck as normal necessary to begin with? | 23:54 |
| lifeless | ronny: it was a design bug waaay back | 23:57 |
| ronny | i see | 23:58 |
| Peng_ | The only reason rich-roots haven't been made the default long ago is backwards compatibility. | 23:58 |
| lifeless | we all want rich roots to be 'normal' and 'normal' to go away quietly | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!