[12:02] lifeless, um, how would I tell gpg on command line what key to use? [12:04] AnMaster, gpg -u user@domain.ext [12:04] ah [12:05] I've wrapped my signing in a separate command file as gpg -u identity --clearsign $* seems to work fairly well [12:06] though I haven't really found a good way to see who has signed what commits [12:06] bzr: ERROR: Failed to gpg sign data with command [u'/usr/bin/gpg -u anmaster (AT) users.sourceforge.net', '--clearsign'] (it really said @ but I don't know if this channel is logged public and I hate spam) [12:06] why not some more detailed error message? [12:07] AnMaster, you have to wrap it in a separate script and give that as the gpg_signing_command [12:07] oh? that seems odd [12:07] I battled around with that for a while as well [12:07] I think it has to do with the way that python executes separate processes, but I never bothered to investigate too closely [12:08] by the way using "$@" is in 99.99% percent of the cases better than $* [12:08] don't forget the quotes [12:12] hstuart: you should not have --clearsign in your script [12:12] hstuart: bzr supplies --clearsign [12:12] lifeless, but why is a script needed at all? [12:13] lifeless, ah, well, then it gets really clearsigned ;) [12:13] AnMaster: I'd say 'its a bug', I think there is a bug open on it [12:13] k [12:14] AnMaster, right [12:14] ok, signing all current 135 commits, means I have to enter my key 135 times? === AnMaster decides to look at gpg-agent [12:14] heh [12:14] seems a lot harder to use than ssh-agent [12:14] that I use currently [12:15] AnMaster: did you try kgpg ? [12:15] lifeless, well, it didn't work as it should [12:15] ah well [12:15] lifeless, is there a good way to see who has signed what commits, btw? I've been looking for that [12:15] hstuart: hmm, don't think so [12:15] drat - anything planned? [12:15] lifeless, is seems to support it's own set of options for command line processing [12:15] it would be great to have someone step up and put some love into that [12:15] AnMaster: :( [12:16] lifeless, ok, I'll take that as a no then :) [12:16] or at least a very limited set of gpg options [12:16] hstuart: its planned in the abstract [12:16] hstuart: but I'm not aware of anyone actually wokring on it [12:16] anyway, any hints on gpg-agent? [12:16] no idea, I haven't used gpg-agent [12:16] yeah, I've seen the launchpad plan, but the gpg things haven't received any updates in forever [12:17] ah well, anyway, off to bed, 'night [12:17] gnight [12:18] vila: re [] in argument lists, i think you are a little confused [12:18] vila: try this: [12:18] >>> def foo(l=[] ): [12:18] >>> l.append('1') [12:18] >>> print l [12:18] >>> foo() [12:18] >>> foo() [12:18] got to sleep too [12:18] hopefully gpg-agent will look less complex when I wake up [12:18] :) [12:19] AnMaster: you could disable your passphrase [12:19] sign them all [12:19] reinstate it [12:19] lifeless, ugh, sounds insecure [12:19] no more than having a process that will sign a document if asked over a local socket [12:20] hm [12:20] night [12:20] (assuming you are not surfing etc at the time, don't have sshd running ...) [12:20] night [12:21] lifeless, well I don't have any server running on my desktop as the user I use in x, I do have some test ones as other users [12:21] *locks x session, switches to a vt, runs vlock -a* [12:21] there you go then, sounds fine :) [12:45] lifeless: can't sleep, but no, not confused, I perfectly understand your example [12:46] vila: so why did you say that the commands.run method will display the same behaviour? [12:47] they will not, but they are always *called* with fixes=[] , so either we make it the default value (cmd_commit uses it as read-only) or we begin by if fixes is None: fixes =[] [12:48] both will have the same result, ok, the later is less risky, but how in hell will cmd_commit decide that it knows how to fix something ? [12:48] I would use a tuple myself in this case [12:48] fixes=() [12:48] because its safe [12:48] but it would need to be changed if commit started mutating the list === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [12:49] Yeah, I see the point, was grumpy :) === mw [n=mw@189.146.27.8] has joined #bzr [12:49] hello [12:49] hi poolie [12:50] hi vila [12:52] hello, poolie, I've got a question stored for you about the translation of the bzr docs, got a minute? [12:52] sure [12:52] lifeless: in another context (still related to [] as a default value) [12:53] I'm translating it into spanish, and I was wondering how to structure a few things, for example, the index.txt [12:53] I introduced possible_transports in various methods as the way to share connections [12:53] should it be under docs as index.es.txt? in the /es/ dir? if that's the case, shouldn't the english one be moved to /en/ too? [12:55] In one review John said that since I wanted to push people to use possible_tranports (p_t) I may as well declare it with a default value of [] [12:55] beuno: index.txt in the es dir [12:55] vila: John was smoking his toenails that day then. [12:55] lifeless, and the english one stays under /doc/? [12:56] beuno: I'd mail the list Ithink actually [12:56] I'm sure igc has a plan, but hes not here yet [12:56] that would be cool to have it translated [12:56] lifeless, alright then, seems like the best place to gather opinions, will do that [12:56] beuno, do you think translating the ui is important too? [12:56] I've got about 20% translated [12:56] poolie, absolutely! [12:57] lifeless: :) not completely, it may provide local caches for the duration of a bzr command [12:57] I'm currently translating the docs to reflect what bzr will actually say (in english), but the ideal situation would be to have everything localized [12:58] vila, what may? [12:58] lifeless: still problematic for long running users as GUIs though [12:58] vila: no, it will not be weakref. It will hold sftp links etc open for the entire runtime of e.g. graphical tools using bzr. [12:58] lifeless: yup [12:58] vila: Its a terrible idea to abuse this language defect like tat. [12:58] lifeless: I didn't :) [12:58] if you're talking about mutating the paramater default as a hidden global variable i agree [12:59] Good :) [12:59] that sounds pretty bad [12:59] Apparently jam suggested that. [12:59] I claim he was smoking his toenails. === beuno was asked to give a talk on bzr in October at an open source conference, so is trying to have everything in spanish before that [01:00] and having it for me employees is a bonus === igc [n=igc@ppp59-167-96-213.lns3.bne1.internode.on.net] has joined #bzr [01:06] lifeless: my bad, John didn't propose that but instead to make it a mandatory parameter [01:07] vila: ah! [01:07] much saner [01:10] And I didn't implement it because I'm still unsure on where (in terms of code paths) the caching should be activated unconditionally === synic [n=squish@pdpc/supporter/student/synic] has joined #bzr [01:11] is there a FAQ on how to improve the performance of a larger repository? [01:11] is there a way we can mark old changes as 'obsolete' or something? [01:12] synic: we're working on changes in teh core, targeted for0.92, to massively improve that === ignas is beginning to think that bzr might be a bit difficult to use with a big project :/ [01:12] anything I can do until then? [01:13] 3+ hours to push a branch to launchpad [01:13] and it's still below 50% of the progress bar [01:13] am i doing something wrong? maybe i shouldn't have used sftp as the protocol? [01:17] swapping it out with bzr+ssh:// will definitely help [01:17] ignas: 0.92 will include bzr+ssh improvements that make it about 20% slower than rsync [01:17] ignas: don't stop it now though [01:17] ignas: when it hits 50% its actually about 80% or more done [01:17] i know, it just got to Fetch 3/4 [01:17] synic: not really sorry. Its a performance bug in bzr. [01:18] but having a 70mb repository is a bit painful, because event with maximum upload speed it still would take quire a lot [01:18] not 3 hours a lot though ;) [01:18] lifeless: thanks for the heads up though [01:22] lifeless: are the changes in 0.92 something that launchpad will be able to integrate easily? [01:24] morning all [01:25] synic: yes [01:26] poolie: calling ok ? [01:26] k === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === dewd [n=dewd@201.9.147.182] has joined #bzr [01:45] vila, were your cpu problems due to trackerd? [01:48] no, first it was... evms, I uninstalled it [01:50] vila: Do you want a reply to your post re: [] ? [01:50] then it was khubd, I went a bit bersek and deactivated services: bluetooth, powernowd, acpid, apmd, mdadm [01:50] abentley: I will add a comment explaing that I was confused as lifeless pointed out a bit earlier :) [01:50] Okay. [01:51] point (and door) closed :) [01:52] hello abentley [01:52] Hi there. [01:54] vila, thankyou for the patch for bug 140614 [01:54] Launchpad bug 140614 in bzr "selftest noise re _http_start" [Low,Fix committed] https://launchpad.net/bugs/140614 [01:54] can you explain to me briefly why this fixes it though? [01:55] why would releasing the semaphore cause the socket fd to be invalid? [01:55] I didn't double-checked, but most probably the client was already using the socket while the server try to set the timeout [01:57] as Aaron as pointed out, my previous fix, by releasing hundreds of sockets should have make the code faster (ftp tests should be even more affected as medusa relies on asyncore which use select) [01:58] the fun thing is that when I saw the bug report and look at the code I wondered why the settimeout was before the lock release... so I tried that first... it worked [02:02] poolie: does that sound convincing ? [02:03] enough for me [02:03] ok === mw is now known as mw|out [02:21] abentley, i got a reply to my request to install python-kid on the machine that serves bazaar-vcs.org [02:21] apparently it's hard because that machine runs dapper and kid is not in dapper [02:21] so our options are [02:21] - just live without it [02:21] - try to install kid from source [02:21] (not sure if there would be other problems) [02:22] - something else, like building the docs elsewhere and uploading them [02:24] I did have Kid installed from source on dapper, and had no trouble with that. [02:24] But if this is going to be a big problem, maybe we should look at another way of building pretty docs. [02:25] I just don't want to invent a new template language. [02:25] heh [02:25] yeha [02:25] i mean, yeah [02:26] New bug: #140834 in bzr "too many futex syscalls" [Undecided,New] https://launchpad.net/bugs/140834 [02:26] Realistically, I guess we can look into what docutils provides by way of customization. [02:26] maybe that would be cleaner [02:27] if you think i should install kid and it will work i'm happy to do that [02:29] I'd be surprised if it didn't work. It depends on how comfortable you are with having software on that machine not managed by apt[itude] . [02:30] personally i'm fine with it [02:30] it's more that sometimes you get into a rabbithole of missing dependencies [02:31] I installed kid with easy_install, as part of TurboGears. [02:34] It appears to have no dependencies, but if the install becomes painful, we can try a different approach. [02:35] Hm. There's a port of it. [02:35] It lists the dependancies as python, py-setuptools, and py-elementtree [02:36] 0.9.6 no longer requires elementtree, AIUI. [02:37] This is 0.9.5, so that could be [02:37] Anyway, you got elementtree around for bzr anyway, so it doesn't matter. [02:37] Yes, that was a change in 0.9.6 === corporate_cookie [n=richie@64-191-132-172.xdsl.qx.net] has joined #bzr === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === jamesh__ is now known as jamesh === J-diddy is now known as jdong === Af1 [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr === Af1 is now known as AfC [04:25] New bug: #140844 in bzr ""bzr log --line --verbose" does not work" [Undecided,New] https://launchpad.net/bugs/140844 === jml_ [n=jml@dsl-210-15-197-192-static.TAS.netspace.net.au] has joined #bzr === jml_ [n=jml@dsl-210-15-197-192-static.TAS.netspace.net.au] has joined #bzr === jml_ is now known as jml === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === igc food [04:59] lifeless: abentley's reconcile doesn't introduce that corruption when run on a hand-fixed repo. [05:00] spiv: can you confirm that it does not fix it either ? [05:01] lifeless: sure, give me ~20 min. === mthaddon_ [n=mthaddon@adsl-71-132-142-237.dsl.pltn13.pacbell.net] has joined #bzr === orospakr [n=orospakr@bas4-ottawa23-1167864665.dsl.bell.ca] has joined #bzr === Stevage [n=chatzill@mail.pfxcorp.com] has joined #bzr [05:19] hey guys, what does this mean: bzr: ERROR: Permission denied: u'C:/bzr/Tlib62/.bzr/repository/lock/held': [Error 5] Access is denied [05:20] well [05:20] it means that either th elock or unlock failed [05:20] your bzr trace file (run bzr --version to see where that is) will have a traceback [05:21] is that dir readonly for you? [05:21] do you have write access to it ? [05:23] yeah, this is during a massive sequence of commits [05:23] so like 300 commits in a row succeeded, then that one failed [05:23] Sorry, the trial version only allows 300 commits per day. You can upgrade for $39.95... [05:23] ok I have the traceback [05:24] :) [05:25] that reminds me of a bug alexander posted about recently [05:25] lifeless: confirmed: abentley's reconcile doesn't fix the corruption. [05:25] http://rafb.net/p/PAed8E45.html [05:25] i think i merged something for that [05:26] Now to fix that. [05:26] spiv: I think you have a new test case for his check and reconcile work then :) [05:26] spiv: its good to know that it doesn't introduce it. [05:26] now, WTF does. [05:28] lifeless: good question! [05:29] Stevage: are you using 0.91rc? [05:29] no, .09 [05:29] .90 [05:29] I did download .91rc2 but I wasn't sure how to merge my changes into it? [05:35] Stevage: did you make your changes in the downloaded-from-tarball tree? [05:35] Stevage: i'm not 100 [05:35] Stevage: i'm not 100% sure but i think this is fixed in 0.91 [05:35] no I haven't [05:35] is there a way to merge my changes in .90 to the .91 ver? [05:36] I mean, I know I can do it by hand, but I'm curious whether i can merge it? [05:40] New bug: #140857 in bzr ""bzr: interrupted" should say where it was interrupted" [Wishlist,New] https://launchpad.net/bugs/140857 [05:40] New bug: #140858 in bzr "when selftest is interrupted, it should show the results of all tests so far" [Medium,New] https://launchpad.net/bugs/140858 === spiv -> food [05:49] [05:49] real 1m27.526s [05:49] user 1m20.481s [05:49] sys 0m4.476s === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr [05:59] ok, done. is there a way to precompile my python source so it runs faster each time? [06:02] Stevage: that should happen automatically by producing .pyc files [06:02] as long as the directory is writable === marianom [n=marianom@ubuntu/member/marianom] has left #bzr [] [06:08] hi, i'm a little confused about bzr-cvsps-import. I did an import using 0.18 or bzr and it created a bzr and a staging directory, but I thought it would also checkout the files from CVS. From what I can see, none of the actually files are there. There is however, the a directory structure based on the branches, etc... [06:10] Vantage13: right, you can bzr checkout any of teh branches the converter created [06:11] lifeless: really? Where will it get the files from? CVS? [06:13] No, from the bzr branches it just converted. [06:13] They're there, they just don't have working trees. [06:19] fullermd: wow, that's quite cool. Thanks! === Stevage [n=chatzill@mail.pfxcorp.com] has joined #bzr [06:21] hmm, same problem: bzr: ERROR: Permission denied: "C:/bzr/Tlib63/.bzr/repository/lock/held": [Error 5] Access is denied [06:22] that's running on .91rc2 [06:22] wait, actually that's 0.92.0dev0 [06:22] whats the backtrace look like ? [06:23] like the one I pasted earlier, if you have ti [06:23] no, I don't [06:24] http://rafb.net/p/FJ0j5K59.html [06:24] (that's fresh) [06:24] I wonder if there is a fileopen withint that path ? [06:24] could you please file a bug, including what you are doing to trigger this [06:25] we care about windows, and its almost certainly a windows specific glitch [06:25] ok [06:25] hard to say what I'm doing specially though [06:25] well [06:25] I'm doing hundreds of commits, then it just falls over [06:25] just note that you are doing X commits in y timeframe [06:25] sure [06:25] are you using bzrlib or the bzr executable [06:25] bzrlib [06:26] both .90 and .92 [06:26] if you are using bzrlib, can you provide the script you are using [06:26] oh, I mean I'm calling bzr from python [06:26] it may be a articular sequence of calls neded to trigger this [06:26] so I guess I mean bzr [06:26] if you do system('bzr foo bar baz') you're not using bzrlib :) [06:27] or subprocess.foo('bzr' , ....) [06:31] heh [06:31] it's a bit more esoteric than that [06:31] I'm using a tool called finalbuilder === g0ph3r [n=g0ph3r@p57A0AD92.dip0.t-ipconnect.de] has joined #bzr [06:35] igc: got the mail? [06:36] lifeless: yes thanks [06:36] I'll try it now === ipkiss [i=ipkiss@nat/ecp/x-ce06bb5244e0631c] has joined #bzr [06:45] New bug: #140869 in bzr "Access denied for lock file" [Undecided,New] https://launchpad.net/bugs/140869 [06:51] lifeless: results on my machine emailed back now fyi [07:00] thanks! [07:16] of home time [07:16] spiv: hows it going, do you need an input from me ? [07:16] yo [07:17] sri: yoyo [07:17] sri: I'm about to go, but if you wanted to chat with me I'll be online in an hourish. [07:20] spiv: ring if you want to chat about why its not finding the corruption [07:20] ciao [07:27] rats, miss lifeless [07:28] I just saw his request to martin about cherrypicking a change into a not-corrupted bzr.dev [07:28] does that mean we should do that for all pqm submissions until further notice ? [07:38] can I copy a file within bazaar? [07:38] as in, I have a file proj1/foo/blah.c and want to copy it with history to proj1/boo/blah.c [07:48] anyone? [07:50] No, there isn't any such thing. [07:55] bugger [07:55] so you can do a rename like that, but not a copy [07:55] Yeah, you can move files, but there's no copy. [07:56] Aside from the lack of round tuits, it's a wide-open question what the proper semantics of copy should be in various situations (particularly merges), which is why there isn't one. [07:58] hmm [07:58] I can see it's going to take me a while to get used to directory-based version control [07:58] vila: not 'not corrupted', 'fresh - without packs in it' [07:58] the tool I'm migrating from is all file-based [07:58] Stevage: we're planning on copy semantics as an optional thing in the future. [07:58] lifeless: pfew, good, sry for the noise :) [07:58] Stevage: there is wide spread debate on what this means [07:59] Stevage: one way is to consider the whole project a big bag of lines and get rid of file id except for grouping lines into paths [07:59] another is to have a more flexible id system that can represent copies as we as moves [08:00] I've occasionally wished for copies as a way of simulating intra-branch branch/merge'ing. [08:02] intetresting :) [08:02] I'll have to subscribe to the list === pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr [08:03] cya everyone [08:08] I was a bit surprised that I can't seem to easily produce a diff or even list changed files between two branches, but it looks dead simple to do it with bzrlib. Am I missing something? [08:10] -rbranch: or -rancestor:? [08:11] Can I do that with two remote branches and no working trees? [08:11] I don't think so, but that's a bug. [08:14] I vaguely recall that both diff and stat beg after WT's when they have no need of them. [08:14] Ah, ok. [08:15] Regardless, Branch.open("foo").basis_tree().changes_from(Branch.open("bar").basis_tree()) seems to give me precisely what I was hoping for. :) === vila [n=vila@lec67-4-82-230-53-244.fbx.proxad.net] has joined #bzr === NamNguyen [n=namnt@203.162.163.50] has joined #bzr === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr === alfborge [n=alfborge@bacchus.pvv.ntnu.no] has left #bzr [] === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === pmezard_ [n=pmezard@dhcp26-226.enst.fr] has joined #bzr === pmezard [n=pmezard@dhcp26-226.enst.fr] has joined #bzr === mvo [i=egon@nat/canonical/x-f597534000592247] has joined #bzr === Zindar [n=erik@stockholm.ardendo.se] has joined #bzr === mneisen [n=mneisen@141.13.16.222] has joined #bzr === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr === allenap [n=allenap@delegate.plus.com] has joined #bzr === matkor [n=matkor@85.14.91.175] has joined #bzr [10:57] night all === mvo [i=egon@nat/canonical/x-50f0a08b12f37860] has joined #bzr === mvo [i=egon@nat/canonical/x-98bf37136636594b] has joined #bzr === hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr === mvo [i=egon@nat/canonical/x-94fd3a31dbadef02] has joined #bzr === mvo [i=egon@nat/canonical/x-812101a953be07c3] has joined #bzr === gabe_ [n=gabriel@91.84.56.254] has joined #bzr === gabe_ [n=gabriel@91.84.56.254] has joined #bzr === RichardL_ [n=Skippy@78.32.35.169] has joined #bzr === thumper [n=tim@125-236-193-95.adsl.xtra.co.nz] has joined #bzr === cprov-out is now known as cprov === RichardL_ [n=Skippy@78.32.35.169] has joined #bzr === fog [n=fog@debian/developer/fog] has joined #bzr === calin [n=calin@89.136.187.239] has joined #bzr === ajmitch [n=ajmitch@port166-123.ubs.maxnet.net.nz] has joined #bzr === lapthrick [n=mathrick@users.kollegienet.dk] has joined #bzr [12:46] howdy [12:46] mathrick@hatsumi:~/Dev$ bzr get svn://svn.gna.org/svn/pokersource/trunk bzr-pokersource [12:46] bzr: ERROR: libsvn._core.SubversionException: ('Malformed network data', 210004) [12:46] bzr 0.90.0 on python 2.5.1.final.0 (linux2) [12:48] http://pastebin.com/f1d0ed055 has the full backtrace [12:50] lapthrick: I'd file a bug or question on bzr-svn === RichardL_ [n=Skippy@78.32.35.169] has joined #bzr === thumper [n=tim@125-236-193-95.adsl.xtra.co.nz] has joined #bzr === mtaylor [n=mtaylor@217.194.71.122] has joined #bzr [01:02] does anyone know of anything for making bzr work with quilt? Or a bzr project to do something similar? [01:07] In what sense? Maintaining a quilt in a bzr branch? maintaining a branch for each patch of a quilt? === fog [n=fog@debian/developer/fog] has left #bzr [] === gabe__ [n=gabriel@91.84.56.254] has joined #bzr === NamNguyen [n=NamNguye@cm103.delta195.maxonline.com.sg] has joined #bzr === kanhaiya_kk [n=kanhaiya@freemap.in] has left #bzr [] === grimboy [n=grimboy@85-211-250-244.dsl.pipex.com] has joined #bzr === mvo [i=egon@nat/canonical/x-4c64cf2d99647b0d] has joined #bzr [01:57] Kinnison: I think more like maintaining a quilt in a bzr branch. one of my friends uses quilt on top of bk, but I was thinking it might be nicer if something like that was integrated with bzr or something === calin [n=calin@89.136.187.239] has joined #bzr [02:04] mtaylor: I think parts of quilt functionality are already provided by shelve, no? === Demitar [n=demitar@c-212-031-182-147.cust.broadway.se] has joined #bzr [02:05] lapthrick: yes. I think that some of them are, but I'm not sure if you can cherry pick from shelve, can you? [02:06] I believe so, AFAIK it does provide you the named changesets function, which is what's needed for cherrypicking [02:07] lapthrick: hmm. I'll go play with that then and see === corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr [02:08] "You can put multiple items on the shelf. Normally each time you run unshelve the most recently shelved changes will be reinstated. However, you can also unshelve changes in a different order by explicitly specifiying which changes to unshelve. This works best when the changes don't depend on each other." [02:08] mtaylor: from bzr shelve --help === bromios [n=bromios@rivernetworks.demon.co.uk] has joined #bzr === RichardL_ [n=Skippy@78.32.35.169] has joined #bzr [02:26] lapthrick: please file a bug report against bzr-svn [02:28] jelmer: will do as soon as I wrangle launchpad into resetting my password [02:28] which it insists on not doing [02:28] Looks like I can reproduce it here [02:28] but the server isn't responding properly [02:28] even with stock svn [02:28] svn ls svn://svn.gna.org/svn/pokersource [02:28] gives the same error [02:29] oho, finally === niemeyer [n=niemeyer@200.163.194.205] has joined #bzr [02:29] jelmer: however, my svn did checkout without any problems [02:29] maybe something changed since then [02:30] it was last Friday I believe [02:30] lapthrick: Your SVN checkout doesn't access the root of the repository (svn://svn.gna.org/svn/pokersource) [02:30] which is the bit that is causing problems [02:30] ahh [02:31] jelmer: but I was checkouting trunk/ [02:31] bzr-svn will try to look at the repository root because it tries to retrieve the history of the repository [02:31] I see [02:31] so it's NOTABUG? [02:31] and/or NOTGNOME [02:32] NOTBZR you mean? :-) [02:32] I do think it's a bug - bzr-svn should be able to avoid connecting to the repository root [02:33] at least over some protocols [02:33] jelmer: yes, but it's usually NOTGNOME where I come from, so it's a generic "not my problem" status :) [02:33] jelmer: I see, but how can you retrieve history then without looking at the root? [02:33] you mean it'll only look at the history of the dir specified? [02:34] lapthrick: there are workarounds - for example, it should be possible to connect to svn://svn.example.com/foo/trunk but then request the log for ".." or "/" [02:35] the behaviour of the get_log() call in svn differs per protocol (svn://, http://, svn+ssh://) though, which is why we try to avoid that at the moment [02:37] I think the extra code complexity is worth it, if it means we can support the pokersource repository [02:38] jelmer: I see [02:38] jelmer: hmm, svn ls worked for me right now [02:38] can you retry? [02:39] hmm, now it works for me too [02:39] mathrick@hatsumi:~$ svn --version [02:39] svn, version 1.4.4 (r25188) [02:39] but bzr still dies [02:40] is that server perhaps under heavy load or something? [02:40] dunno [02:40] http:// worked though [02:40] I will retry with svn:// once it finishes [02:41] mathrick@hatsumi:~$ svn ls svn://svn.gna.org/svn/pokersource [02:41] svn: Can't read from connection: Connection reset by peer [02:41] jelmer: I guess it might be the server at fault [02:43] copying revision 320/2895 [02:43] oh man, that's not gonna be fast === statik [n=emurphy@189.66.188.72.cfl.res.rr.com] has joined #bzr === mw|out [n=mw@189.146.27.8] has joined #bzr === radix [n=radix@70.91.133.157] has joined #bzr === allenap [n=allenap@delegate.plus.com] has joined #bzr [03:05] lapthrick: at the moment we have to fetch all historical changes. work has started to make it possible to fetch only the last few revisions [03:05] jelmer: isn't it kind of necessary to fetch the whole history to have a real bzr branch? === mrevell is now known as mrevell-lunch [03:08] lapthrick: it is possible to do "lazy" fetching - in other words, not fetch anything until the user is trying to access it [03:08] I see [03:09] jelmer: [how do you do that?] [03:10] [oh, sorry, you're talking about bzr-svn. I thought you meant Bazaar itself] [03:10] AfC: This is true for Bazaar itself as well [03:11] AfC: The idea is to make it possible to fetch just the last few revisions of a branch and store a pointer to another branch that contains more of that history [03:11] jelmer: how do you do that, then? Is there a --lightweight option to `bzr branch` as well? [03:12] Hi, I'm using bzr 0.18 w/ bzr-cvsps-import to try and import a large CVS repo, but I keep getting memory errors. Any way around this? [03:12] AfC: It's not possible yet - these are the stackedrepository / shallow branches specs [03:13] jelmer: ah. I have envisaged a modality whereby the commit messages etc were there (ie, you could run `bzr viz`) but the actual deltas between revisions wouldn't be present unless [able to be] fetched [on demand, or silent error] [03:14] AfC: something like that could be done easily once the shallow branch / stacked repository code is in [03:15] AfC: but it may involve doing things like caching diffstats for "bzr log -v' === grimeboy [n=grimboy@85-211-247-132.dsl.pipex.com] has joined #bzr [03:18] jelmer: I was more thinking "sorry, diff not available" ... where I was really going with this was trying to avoid the necessity to download / push massive amounts of revisions especially of large code drops that subsequently got deleted before merging [03:18] [this happens a lot for us] [03:19] [but if I accept the revisions, they're full of all the crap I subsequently expunge, thus traffic] === herzel53 [i=herzel@gateway/tor/x-391bdd0074dc567b] has joined #bzr [03:20] It strikes me that some sort of graft/rebase is probably the better solution to that problem... === Vantage13 [n=Vantage@www.toddcharron.com] has left #bzr ["Kopete] [03:26] AfC: Ah, I see. It should be possible to set a policy as to what bzr should do if a revision is not available in the branch itself - fetch it or consider it a ghost. === TeTeT [n=spindler@modemcable178.77-70-69.static.videotron.ca] has joined #bzr [03:29] how well does bazaar cope with binary files, e.h. PNGs? [03:32] TeTeT: well enough that I've never noticed any problems [03:32] I've heard rumors that its binary delta algorithm isn't efficient or whatever, but it doesn't concern me [03:37] i have tens of websites in a bzr repo, they have all manner of binary files, work a treat for me [03:37] radix: thx, should be fine with small pngs then [03:37] I once run into trouble with some very large files, 10+ MB [03:37] but this was an older version, I think 0.13 or so === juliank [n=juliank@f049011147.adsl.alicedsl.de] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === schierbeck [n=daniel@192.38.109.188] has joined #bzr === mw|out is now known as mw [03:52] I'm more curious than anything..how dose BZR handle binaries ? [03:53] the way i understand it ..bzr stores ...sort of a recipe of changes between versions ...it dose not actually store files them selves but rather the instructions to build those files [03:54] how would this work with a Binary file / a non text based file === mrevell-lunch is now known as mrevell [03:54] corporate_cookie: so, there's an algorithm for efficiently representing differences between text files [03:55] corporate_cookie: there's also an algorithm for representing differences between "binary" files, which doesn't rely on newline markers [03:55] Is there? [03:57] google for "binary delta" and "binary diff" :-) [03:57] radix: ..how slow / useful is this algorithm ...practically [03:57] ok : ) [03:58] Oh, I'm aware that there _are_ such algorithms. I was questioning the part where it had anything to do with bzr at the moment. [03:58] oh, I don't know [03:58] I was responding to the general question about "how would this work" [03:58]