[00:00] lifeless: record gives me an internal error [00:01] lifeless: I'm using the 1.11 package for OS X [00:06] davidstrauss: thats odd [00:06] does 'bzr selftest loom' pass? [00:06] lifeless: Also on very late code on CentOS 5 [00:06] lifeless: i'll try [00:09] lifeless: All tests pass [00:09] file a bug please [00:19] jelmer: reviewed your patch - I don't think it works [00:20] lifeless, it seems to work fine here - or do you mean it's not lazy? [00:21] I don't think it achieves your goal [00:21] because formats are probed [00:21] it will be probed anytime a miss occurs on a .bzr dir [00:21] I think that bzr-svn has to provide a lazier format object [00:25] jelmer: do I make sense? [00:26] lifeless: yeah, I see your point [00:27] lifeless, The probe functions are pretty lightweight already though [00:27] lifeless, in the instructions you gave me for branching, do I always have to log on to the server to create a branch in that manner? [00:27] then what would be gained by this? [00:27] sohail: not at all, I wanted ot check the repo because of your size concerns [00:27] sohail: just 'bzr branch url_to_master url_to_new_branch' [00:28] ah [00:28] and then remove-tree? [00:28] won't be needed remotely [00:28] cool [00:28] thanks [00:28] np [00:30] jelmer: so, you said in your mail that this would let us not load all of subversion [00:30] jelmer: do your probe functions check that svn is _possible_ before loading svn? [00:30] e.g. t.has('.svn') [00:31] lifeless, hmm [00:31] irrelevant for http [00:31] but for local.. [00:31] lifeless, yeah, my patch just saves an imports in some cases [00:31] lifeless, they actually check for isinstance(transport, LocalTransport) and transport.has(".svn") [00:31] jelmer: and the import that is saved, is it of svn itself, or bzrsvn ? [00:32] lifeless: bzr-svn/subvertpy [00:34] so you could move the probe pre-checks into __init__, avoiding that import always except when it may really be a svn tree [00:35] not sure I follow [00:35] what do you mean by pre-checks? [00:36] ah, sorry [00:36] the import that is saved is just the import of the file that the BzrDirFormat derivatives are in [00:45] I've bb:rejected based on this conversation [00:45] I think that if bzr-svn is importing to much still, the change at this point needs to be in bzr-svn [00:45] or [00:45] the change to the format code would need to be rather different [00:47] hmmok [00:48] lifeless: https://bugs.launchpad.net/bzr-loom/+bug/322557 [00:48] Launchpad bug 322557 in bzr-loom "Missing revision error on pushed loom" [Undecided,New] [00:48] lifeless: enjoy :-) [00:49] jelmer: basically the probe code has to be assumed to be executed; the bzr-svn probe is 'is it local, and is there a .svn, and does svn recognise it' [00:49] jelmer: the first two checks do not need to import subvertpy or anything; only the last check does [00:49] lifeless, Yeah, I see your point, I'm still just wondering whether the change isn't worth it [00:50] I think the change adds complexity without gaining anything in general [00:50] and its misleading to people because it will claim to be lazier than it really is [00:51] davidstrauss: looking [00:51] lifeless, it seems like my real beef is with bzr-hg anyway [00:51] as 75% of the time of running "bzr ls" is in mercurial [00:52] ouch! [00:52] well, all-in-__init__ is maybe not such a good idea :P [00:52] otoh is it import time [00:52] or something else [00:53] readconfig() is apparently 62% [00:53] from mercurial.ui [00:53] whee [01:01] lifeless, other than that, I now seem to have a bzr-svn that loads just __init__ and format [01:01] jelmer: excellent [01:02] lifeless, is there any reason we're *disabling* mercurial's demandload thingie? [01:02] jelmer: yeah, it broke [01:03] jelmer: there is a bzr-git thread on the list [01:03] from Timmie [01:13] spiv: bug 322299 smells like server autopack to me [01:13] Launchpad bug 322299 in bzr "bzr starts raising error on all actions after usin repo for a while: # ValueError: invalid literal for int() with base 10: 'None'" [High,Confirmed] https://launchpad.net/bugs/322299 [01:17] lifeless: yeah, it does seem like server-side autopack is failing, but the root cause still isn't obvious [01:30] Is it possible to pull a set of branches at once? [01:31] multipull I think [01:37] * jelmer pulls bzr-foreign into yet another bzr plugin [01:45] jelmer: what's the bzr-svn command to push back to svn? [01:46] thumper, pushing into an existing branch: "bzr push" [01:46] thumper, to a new branch: "bzr svn-push" [01:46] hmm.. [01:50] jelmer: docs say that http is supported for svn writes using webdav [01:51] thumper, yep [01:51] jelmer: does bzr-svn support https webdav writes? [01:51] thumper, yep [01:51] ok [01:51] I'm trying to help someone on #nzpug [01:51] jelmer: could I get you to pop in perhaps? [01:51] sure [01:58] igc: I just got hit by the same unrelated test failure on PQM (LockableFiles.__del__ in blackbox.test_shelve) as you. [02:00] spiv, fwiw, I've seen that issue as well [02:00] I have an existential question. [02:01] jfroy|work: There is no spoon. [02:01] Why does bzr encode ~ as %7E? [02:01] That is all. [02:03] jfroy|work: hmm, probably because urllib.quote does. [02:03] * jfroy|work wants prettier URLs. [02:03] Time to write a patch. [02:03] jfroy|work: although bzrlib.urlutils explicitly tries to declare that ~ isn't to be escaped I guess there are some places that don't go through those code paths. [02:05] Hmm, actually, bzrlib.urlutils.escape will do that too, it doesn't take the _url_dont_escape_characters/_url_safe_characters sets into account. [02:05] It basically just relies on urllib.quote. [02:05] So I guess that's why. [02:07] igc, jelmer: I guess it's to do with the UserWarnings that I get from blackbox.test_shelve when I run the tests on my laptop [02:07] ("was gc'd while locked" warnings from test_shelf_order, test_shelve_no_message, test_shelve_one) [02:07] spiv: I didn't expect you to dig that deep. Thanks for the info. [02:09] jfroy|work: not a problem [02:23] jelmer: thanks for your help [02:27] thumper, np [02:33] igc, jelmer: I think I've figured out the cause of the intermittent pqm failure, patch sent. [04:12] hi all [04:14] igc: I sent a patch that should fix that odd PQM failure. [04:14] igc: it happened to me too :) [04:17] spiv: awesome. just approved the patch btw [04:19] Yay :) [04:52] lifeless, there? [04:52] apparently [04:52] cool! [04:53] more branching questions [04:53] shoot [04:53] so now I am on another machine and did bzr switch next [04:53] but I don't seem to have the latest changes... [04:53] is the commit you want listed in 'bzr log' ? [04:54] yeah [04:54] ok... sorry for pinging you, pebkac [04:54] bug in the code [04:54] hee hee [04:54] Hooray for easy questions :) [04:54] :-) [05:16] sohail: np [05:40] jelmer: Do you still support running bzr-svn 0.4 with bzr.dev? If so, could you fix the SPEC_TYPES warning? (I think I'll switch to 0.5 anyway though.) [06:58] hi all [06:59] yo [07:35] igc: did you see my ping about usertest ? [07:41] spiv: Yeah for your fix regarding test_shelve, got bitten by it yesterday too [07:43] vila: that makes lots of us, then :) [07:44] I re-submitted immediately in anger and it went through :-) [07:44] So I knew it was transient but I had no time to go further... [07:49] vila: I missed that ping sorry [07:49] igc: ping, I have bzrlib.plugins.usertest.tests.test_blackbox.BlackboxTests.test_usertest_strict failing since a couple of days/weeks and no idea on how to fix it (the test is 3 lines long but the failure output is 800 lines long giving me little hints :-/) [07:50] igc: no problem, I have an history at my fingertips :) [07:51] vila: I'll take a look soon [07:53] igc: thanks in advance :) [08:00] vila: thanks for the reviews btw [08:00] np [08:01] Since jam gave a tweak for faster log, I didn't review, but I agree with him globally [08:01] igc: Especially the part where he said: "it seems like it would make sense to create a class [08:01] definition, and turn them into 'self.XXX'." mwhahahahaha [08:01] :) [08:08] 2899 KB to download the latest ~25-30 revisions of bzr.dev. I wonder how much bandwidth btrees would save overall? [08:15] * igc dinner === kiko is now known as kiko-afk [10:14] Um, why does bzr viz on a bound branch try to contact the server? [10:14] Shouldn't it only use the local history? [10:18] probably to check what's the latest revision of the branch [10:22] Lo-lan-do: someone else reported that bug recently, I think [10:23] It might also be something silly like looking up the branch nick. === asac_ is now known as asac [10:57] LarstiQ: I was over optimistic yesterday. Morning is smarter than evening. I'd prefer to implement subprojects for scmproj on top of new format and new layout. That said subpprojects will be there in a couple of weeks. Sorry. I hope you can play with scmproj without subprojects some time. [10:58] That's why I do all my work in the evenings; things are so much easier and get done faster ;) [10:59] hehe [10:59] you never sleep, do you? [10:59] Sleep is for wimps. [10:59] Happy, healthy, well-rested wimps, but wimps nonetheless! [11:00] :-D [11:17] hi.. is bzr:// read-only? It complains it can't commit because of that :( [11:17] bzr server --allow-writes [11:18] But it's ususally used pure read-only since there's no access control on it above the IP layer. [11:19] fullermd: Access control doesn't matter really, it's just a small office server, and you can only access it from the office [11:23] Well, strictly speaking, it DOES matter; you've just got it taken care of :) [11:25] bialix: Works, thanks :) [12:45] hello I have done a bzr push to a remote server. the ssh'd in and done bzr st and get bzr: ERROR: No WorkingTree exists for [12:45] how do i turn this into a working tree [12:46] bzr checkout . [12:46] i have done this before but can't remeber what i did [12:46] luks: perfect thanks [12:47] if i now do some changes on the server e.g. the config file then do a bzr push later from my laptop will my server changes be overwritten? [12:48] no, the working tree won't be overwritten at all [12:48] and bzr push will complain that it can't update the remote working tree [12:48] ok so then i could do bzr up right from the server [12:48] ah ic [12:48] so bzr push is really only for a one off [12:48] whats the best way to deploy to a live server then? [12:48] bzr push is for pushing bzr data [12:49] you can use the bzr-push-and-update plugin if you are using bzr+ssh and you want to automatically update the checkout [12:49] and there is a bzr-upload plugin to just upload the actual files, not bzr data [12:49] yeah i remember seeing that before [12:50] i have the situation where i have a dev server and then a live server where clients add files via a cms. [12:50] developers work on dev clients works on live via cms [12:50] but i need to take developers changes to live [12:51] at the moment i have dev and live as checkouts of a repository but i am sure this is not the best way to do it [12:52] i can't find all that much info about web dev workflow using bzr via google [12:52] which is odd [12:52] ollie: there is some info on bazaar wiki [12:58] ollie: I think that your production server should be deployed with bzr-upload... [13:25] is there away to get rid of bzr push info e.g. bzr info shows related branches [13:25] which i no longer want [13:26] I didn't find a proper way to do that, you'll need to edit the .bzr/branch/branch.conf file and remove the lines. [13:57] Hey, anyone else notice that bzr ls --unknown is listing paths to STDERR or is that just me? [14:43] i heard that loggerhead has no way of displaying information about tags... is this true? [14:52] whoa; just realized that if i have a branch diverge while i'm running tests, and i'm forced to merge the commits that slipped in with myself (therefore making them subrevisions of my commit) that when I push I can actually *reduce* the overall branch revno [14:54] phinze: in the version of loggerhead I run, I don't see tags [14:55] phinze: you would be interested in using append-only branches [14:55] phinze: Yeah, non-linear history can lead to interesting results :-) [14:56] (And you don't want to trust the revno anyway) [14:56] grrr, why launchpad still cannot upgrade hosted branches? [14:56] bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. [14:56] :-/ [14:57] I should use sftp URL? [14:57] phinze: it seems tag support is still under development: https://bugs.launchpad.net/loggerhead/+bug/246739 [14:57] Launchpad bug 246739 in loggerhead "tags are not available" [Wishlist,Confirmed] [14:57] bialix: sftp should work. bzr+ssh might with a new enough bzr? [14:58] sftp does not work either [14:58] I'm running official bzr.exe 1.11 [14:58] rats rats rats [14:58] Ah. Sorry, then. [14:59] Did you specify a format explicitly? [14:59] no [14:59] hi bialix, don't you ever work/sleep :) [14:59] bzr upgrade sftp://bialix@bazaar.launchpad.net/~bialix/bzr-x-bit/trunk [14:59] I suggest you give it a try :-) [14:59] you know something? [14:59] bzr upgrade --format=1.9-rich-root sftp://qjsdfq [15:00] I know nothing, but I suspect that upgrade without an explicit format might try to upgrade to the most recent *default* format, and the newer ones haven't been made the default yet. [15:00] yep, my bad [15:00] this branch is already upgraded [15:00] but my local branch was not [15:01] hence my confusion [15:01] but error message is confusing [15:02] why it told me about meta-directory? [15:02] AmanicA: hi [15:02] AmanicA: here 17:01 [15:02] hi [15:02] here too [15:02] why I should sleep? [15:03] because you didn't last night? [15:03] :-) no, I fall asleep after conversation with LarstiQ [15:03] :D [15:03] !summon LarstiQ [15:03] Sorry, I don't know anything about summon LarstiQ [15:03] :-P [15:03] and I hear he also fell asleap after that conversation [15:04] hehe [15:04] scmproj is better soporific ever [15:04] sweet [15:04] what you think about my latest subproj idea? [15:07] sounds good [15:07] ok [15:07] I'm glad I could convince you :) [15:07] an I didn't even have to build a prototype [15:08] I'll really try to get some of those lp-bugs ticked off soon [15:08] (to get then new format out sooner) [15:09] I'm working on new format today, have some free time [15:10] the main problem is rewriting of docs [15:19] great thanks [15:40] Hi Folks, anyone here use bzr with Dropbox? [15:42] Or, can you think of any reason why bzr wouldn't work with Dropbox? [15:45] sewmyheadon1: you plan to use it for yourself or to share the data with other people? [15:46] santagada_web: Myself, basically. I access my Dropbox from both a desktop and laptop and wonder if I'm using bzr on both, could I have my branch/repo setup in Dropbox? [15:48] Can someone please get the bzrtools package for 1.11 into the PPA? [15:48] sewmyheadon1: I can't think of anything that might go wrong, if you are not in the middle of a commit while dropbox is copying stuff [15:48] I don't know how bzr does locking during commits [15:48] but I would guess dropbox would not copy them correctly [15:49] Thanks santagada! I think we'll give it a spin and see if/how it works. [15:53] sewmyheadon1: dropbox copying is manual right? [15:53] sewmyheadon1: it doesn't start the backup automatically right? === dereine[OFF] is now known as dereine [15:56] santagada_web: It's strange. Dropbox creates a folder in your home dir and, when you copy files into it, it uses WebDAV (I think) to copy these files into 'the cloud,' which is the storage they use on Amazon servers. When you use another machine that's connected to the same DBox account, Dropbox checks periodically to make sure your files on the new machine are up to date, and will copy down any changes automatically. [15:57] So you could use Dropbox on twenty machines all connected to your Dropbox account and each machine will poll your local and remote Dropbox folders periodically looking for changes and auto sync. Make sense? [15:57] You end up with local files on each machine connected to Dropbox. [16:12] hunh. Can't install bzr in home dir, using exactly the instructions in INSTALL: [16:12] http://paste.lisp.org/display/74497 [16:14] And this grep finds no results in the tree: [16:14] find . -type f -print | xargs grep "must supply either" === fawek_ is now known as fawek === dereine is now known as dereine[OFF] [16:20] kfogel: "must supply" error from python distutils lib === dereine[OFF] is now known as dereine [16:21] bialix: thanks [16:21] kfogel: though I don't have enough experience with linux home install [16:21] try to read: python setup.py install --help [16:21] bialix: exactly what I'm doing now :-) [16:22] khm [16:22] * bialix shuts up [16:22] bialix: what does "khm" stand for? [16:23] *cough* [16:23] never mind [16:23] bialix: ?? :-) [16:23] bialix: if it's offensive, I won't take offense. I just like to keep my acronym collection up to date. [16:23] my native language is russian [16:24] sorry [16:24] I don't want to say something bad [16:24] bialix: heh. Okay. Well, thanks for the clue about distutils lib. [16:24] it was translations from russian [16:25] bialix: now you've made me *really* curious [16:25] I guess in English you using only hmm [16:25] aaaah [16:25] yes [16:25] "hmm" [16:25] variable number of "m"s [16:25] hmmmmmmmmmmmmmmmmm [16:25] hmmmmmmmmm [16:25] khm it's hmm + cough [16:25] hmmm [16:25] got it [16:25] when you don't want to say something [16:26] slightly more sarcastic, maybe, than "hmm"? [16:26] it depends on context I guess [16:26] in this case it was harmless, my hint about --help was too late [16:27] sorry [16:29] oh, nothing to apologize for [16:29] My debugging is not going very well. [16:30] Argh, why is it that every time one tries to do X, one must first debug three prerequisites of X? [16:30] (I'm just whining, you can ignore that.) [16:30] kfogel: yak shaving [16:31] santagada_web: sigh, yeah [16:31] So does 'python setup.py install --home ~' work for you? [16:31] kfogel: it might be that bzr's use of distutils breaks --home [16:31] you could perhaps use --prefix instead, but I imagine that leaves a less desirable structure [16:31] kfogel: I think I use $HOME instead of ~ (but never tried for bzr though....) [16:32] I used --prefix $HOME too [16:32] james_w: --prefix errored too, though in a different way [16:32] oh [16:32] vila: I tried with "/home/kfogel" already, which is what $HOME and ~ both expand to [16:32] kfogel: just to be sure, what say: `python -V` [16:32] bialix: Python 2.5.2 [16:33] good [16:33] IIRC bzr's C-extensions required explicit options [16:33] vila: in theory, it should *never* make a difference whether you say ~ or $HOME or /home/yourdir -- the program can't tell the difference, since the shell expands it. [16:33] something like python setup.py build_ext ... install ... [16:33] I guess jam can say more [16:34] jam: ping [16:34] kfogel: I agree with the principle :) I was trying a cheap shot... just in case [16:34] vila: heh [16:34] kfogel: why you need to *install* bzr? [16:35] vila: let me put it this way: if that made a difference, I'd have something much, much larger to debug. [16:35] kfogel: just for perspective, why do you want to install in your $HOME ? [16:35] bialix: so I can use it from anywhere [16:35] vila: because it's a shared system and we'd prefer not to install dev code system-wide [16:35] you can just make symlink for bzr script [16:35] bialix: I think I'm about to back down to that. But will it load the right libs? [16:36] kfogel: I was just about to say the same than bialix :) [16:36] kfogel: it should [16:36] "the same than bialix" -- English is hard language [16:36] I.e., if /home/kfogel/bin/bzr is a symlink -> /home/kfogel/src/bzr/bzr.dev-trunk/bzr, when I run it will it load the right libs from the latter dir, instead of from the system dir (which will be bzr 1.11)? [16:36] I have 4 or 5 such symlinks in my ~/bin [16:36] bialix: I wanted to recommend symlink, just like you :) [16:37] kfogel: yes [16:37] vila: yes, I understand [16:37] vila: it seems to yes (once I did 'hash -r') [16:37] I guess I'll just do that. [16:37] hash.... I hate it [16:37] kfogel: what say: python -c "import sys; print sys.path" [16:39] http://paste.lisp.org/display/74499 [16:39] bialix: ^^ [16:40] first entry '' -- IIRC it means current script dir [16:40] * bialix mutters: kfogel can try to install bzr at home with easy_install [16:43] bialix: oh, I've got a working solution now, so I've timed out :-(. This was all on the way to doing another more important thing. [16:43] It's a pity bzr's homedir install recipe is (apparently) broken, but if I stop to fix that, then something else doesn't get done. You know how it is. [16:43] it's ok [16:45] kfogel: Err? Shells don't always expand ~. Only when it's at the start of a word. [16:46] % echo --prefix=~/foo [16:46] --prefix=~/foo [16:47] fullermd: yes, but barring that [16:47] fullermd: there are ways to suppress ~ and $ expansion. But assuming they *are* expanded, the program cannot tell. [16:47] kfogel: oh dear, have I coaxed you into venturing into problematic territory? [16:47] maxb_: heh! Hi there. [16:47] Yes, but you were still right. [16:47] (didn't know you hung out here, maxb_) [16:49] Only recently. Ubuntu's incredibly keen on bzr, I figured I'd see what all the fuss was about :-) [16:54] maxb_: it's good. I'm not an expert yet, but starting to grok it. === fawek is now known as fawek_ === fawek_ is now known as fawek [16:59] rockstar, nice work on the graphstats command :) [16:59] jelmer, Thanks! http://media.theironlion.net/etc/graphstats-bzr.dev.png [16:59] AmanicA: finished rewrite of the project.cfg doc [16:59] That's bzr.dev It's a godo demonstration of the obvious shortcomings of the prototype. [16:59] rockstar, It would be nice if it could not print labels for people who have contributed less than 0.5 % or something [17:00] jelmer, yea, I plan on doing something like that. [17:00] rockstar, since I get a lot of text that overlaps for some projects [17:00] AmanicA: format-change branch revno.180. If you will want to look [17:00] that pqm chap looks pretty useful prolific [17:00] jelmer, I think what I'd like to do is create a new project and use the same concepts from bzr-stats, but implement them differently. [17:00] james_w, :) [17:01] rockstar: I don't think this would be bad to have in bzr-stats actually [17:01] jelmer, I'm more interested in an API for generating statistics and less of a plugin. [17:01] I assume I'd make some sort of plugin ui for it, but that's not something I much care about. [17:02] jelmer, so unless you (and jam) aren't opposed to be going to town on bzr-stats itself, it might be better to start a new project. [17:02] s/be/me [17:03] rockstar: I'm certainly not opposed to that [17:03] jelmer, I also noticed that the API needs some updating. It's got a lot of code that broke in 1.6 :) [17:04] I guess it's a plugin that not many people use. [17:04] rockstar, which branch of the plugin are you using? [17:04] I'm not seeing any problems and I use it regularly with bzr.devc [17:04] jelmer, trunk. [17:05] jelmer, try `bzr ancestor-growth` [17:05] ah, yeah [17:05] that breaks here as well [17:05] the only commands I use are stats and credits [17:06] * fullermd thinks he filed bugs around there... [17:06] jelmer, I have breakage on credits as well [17:06] jelmer, nevermind, I thought I did. [17:07] Oh, not on a-g. Just on credits and committer-stats. [17:08] lp:bzr-stats is what I package for Debian/Ubuntu === dereine is now known as dereine[OFF] [17:14] i just did an update from launchpad to my local repository and it found a conflict in a binary file. Which of the files (BASE, OTHER, THIS) is the new file from launchpad and which is the original I had locally before? [17:15] I think OTHER is the one from the repo, THIS is yours, and BASE is probably their latest common ancestor. [17:16] ok. i was leaning towards OTHER as the new one since it has the largest file size. wasn't sure on the original though [17:17] But don't trust me, I try to avoid binaries and conflicts when I can. [17:17] yeah, i'm really not sure why there is a conflict [17:18] Very complex geopolitical forces were at work. === dereine[OFF] is now known as dereine === fawek_ is now known as fawek === dereine is now known as dereine[OFF] [18:16] jelmer: Hey, are you there? [18:16] dwt, yes [18:16] Great. :) [18:16] I am trying to check out a directory from my svn server at https://ipx11390.ipxserver.de/svn/mhaecker/open-source/nsNet/trunk/ with the newest version of bzr and bzr-svn (just branched from http://people.samba.org/bzr/jelmer/bzr-svn/stable/ [18:17] It works fine, but when I run bzr check afterwards in the checkout it dies with an exception [18:17]