[00:14] poolie: yes, i can reproduce with standalone trees [00:14] wow [00:14] * mwhudson biles another fiug [00:14] this is kind of surprising [00:15] yes [00:15] it's probably shallow but i'm surprised it has not been hit before [00:17] https://bugs.edge.launchpad.net/bzr/+bug/283479 [00:17] Launchpad bug 283479 in bzr "set_stacked_on_location unconditionally(?) unlocks the repository" [Undecided,New] === kiko is now known as kiko-fud [00:23] poolie: oh, i know what's going on [00:23] poolie: unlock is trying to unlock all of the repositories [00:23] yes, i know :) [00:23] for repo in self._fallback_repositories: [00:23] repo.unlock() [00:23] ok, i hadn't figured this out yet :) [00:23] the question is, why was the fallback repository not locked [00:24] or actually, why does it ever work [00:24] well, nothing locks it [00:24] i guess because we normally change it without locking the branch [00:24] which i think is actually a bug [00:24] see the other bug i filed today :) [00:28] poolie: i changed the description of the bug to be more honest :) [00:34] poolie: i guess the fix is to make set_stacked_on_location @need_write_lock and then lock the added repository somehow or other [00:34] but still leave the fallback repo unlocked when you open a branch [00:35] (unless now is the time to make "open and write lock a branch" a more primitive concept ...) [00:36] i agree up to but still leave the fallback repo unlocked when you open a branch [00:44] abentley: hey, do you know of code to go from iter_changes <-> inventory_delta ? [00:45] (that is, to transform an inventory delta into a valid iter_changes output (without include_unchanged or want_unversioned); and/or vice vera to generate an inventory delta when given a iter_changes iterator [00:47] lifeless: Can't think of anything off the top of my head. Though TreeTransform can emit both iter_changes and inventory_delta. [00:47] abentley: I'm looking at making faster deltas between inventories given the capabilities of CHKInventory [00:48] abentley: but I don't want to expose inventory centric API's :) [00:49] It would be nice if the commit command exposed the timestamp parameter of the commit object, as that way I could write my importer program using the bzr commandline. [00:49] lifeless: I always figured inventory_delta -> iter_changes was a lossy conversion, so I don't know about going backward. [00:49] I think I have a patch that should do it to builtins.py. Is there a way I can apply that to a binary windows download? [00:52] pdf23ds: if you're writing an importer I really encourage you to use the bzrlib api and python [00:52] pdf23ds: as for changing the windows binary, I think you can edit the zip contents [00:53] My converter is for svn and extremely hacky. I doubt anyone else would be interested. [00:53] abentley: so, add_inventory_delta is 20 times faster than add_inventory, currently [00:53] Would I need to compile to a .pyo? [00:53] pdf23ds: have you tried bzr-svn ? [00:54] I have a multiple repository setup with many weird renames and only a few revisions. I don't want to even bother. [00:54] Multiple project repository, that is. [00:54] ok, well up to you [00:55] anyhow, I'd remove the pyo and pyc for the file you edit in the zip [00:57] Cool, it works. [00:57] Thanks. [00:58] Mercurial has that option, but I'm not going to go with mercurial because I don't like the branching as much. [00:59] Where would I request that this feature be added? [01:00] pdf23ds: file a bug in launchpad.net/bzr [01:00] however, we want the CLI to be good for humans, for scripting we encourage the use of python directly, it helps keep the UI cleaner [01:02] Well, I program mainly in C# and don't really enjoy python. I wouldn't want to do much work in python. [01:02] I believe there are C# bindings floating around [01:02] anyhow, please file the bug [01:02] with your patch [01:03] and you've gotten your conversion done now right? which is a one-time thing [01:03] Well, it's an interactive and painstaking conversion, but it's now on its way. [01:03] I won't really need the patch after that. [01:04] Or probably need to do any other hacking on bzr. :) [01:04] But I'm glad it's python and not C or Haskell. :) [01:07] Ugh. stupid registration. [01:07] I'll do it for the sake of open source. [01:10] BTW, the view/annotate thing gives an error clicking on builtin.py from launchpad web source browser, but I can download the file. Should I report a bug on that one too? [01:17] IRC sure is useful. [02:31] abentley: if you're around [02:31] abentley: I'd love feedback on the RFC I just sent about install_deltas [02:33] lifeless: You weren't very clear on whether this was deltas for everything or just for inventories. It definitely seems reasonable if just for deltas. [02:33] if just for *inventories*. [02:35] abentley: good point; I was thinking of deltas of the inventory, and asking the tree for iter_file_bytes when new texts are needed [02:36] lifeless: And Revisions and Signatures would be fulltexts? [02:36] revision would be an object [02:36] signatures are the bytes of the signature as in install_revisions [02:37] lifeless: So is the "deltas" parameter really an iterable of tuples? [02:38] yah [02:38] each tuple contains all the data for an individual revision - revision, signature, tree, basis_rev, inventory_delta [02:39] an alternative signature Iw as thinking off [02:39] *of* [02:40] was to pass in the source repo [02:40] lifeless: It seems like you could calculate the delta from the tree itself, no? [02:40] and not pass the tree object in [02:41] abentley: you can, and I have an install_revisions version that does this, but its not as efficient, because as its currently structured we check everything in the tree, and do the delta against the target repo not the source [02:41] abentley: I'm wary of changing the behaviour of install_revisions, I'd rather add a new method that is explicitly delta based than find someone depends on a corner case of install revisions [02:42] lifeless: There's no Tree method that can calculate a delta efficiently (at least under ideal conditions)? [02:43] abentley: there are two issues; one is that the ideal tree to calculate the delta against may not be present in the set being copied [02:43] abentley: secondly is that the idea tree to calculate against may be representation dependent - that is: [02:43] time(make_delta(Tree-rev1-repoA, Tree-rev2-repoA)) may be much smaller than [02:44] time(make_delta(Tree-rev1-repoB, Tree-rev2-repoA)) [02:44] less abstractly [02:45] for xml inventories, doing a iteritems on the _byid attribute is very fast; for CHK inventories, doing that is very slow (because you page in all the pages of the two inventories) [02:45] for chk inventories, walking to common pointers is very fast [02:46] lifeless: If you take a source repository, it seems a lot like Repository.fetch [02:46] for xml_inventory <-> chk_inventory its worst case of all - you have to load the entirety of both inventories, and chk inventories require more IO to load a full single inventory (because its fragmented) [02:46] abentley: (optionally taking a source repo) it does start to look a lot like fetch; thats why I decided against doing that [02:48] abentley: on the other hand, perhaps I should just doing fetch-cleanups so that this can happen more totally within the normal fetch structure. (I'm looking at this for fetch from pack-0.92->chkinventory) [02:49] lifeless: I think that might be better. Interfaces with iterables of tuples make me nervous, for some reason. [02:50] abentley: well, install_revisions() takes a iterable of tuples [02:50] abentley: I was patterning off that in that respect [02:51] That's true. I was actually thinking of iter_changes. [02:52] lifeless: The fetch API doesn't care what two consenting repositories do behind closed doors, so I think it's a good way to achieve flexibility. [02:52] abentley: right; note that fetch() is already involved here [02:53] abentley: fetch -> InterDifferingSerializer -> install_revisions [02:53] abentley: what was in my head was to change that to fetch -> InterDifferingSerializer -> install_revision_deltas [02:53] abentley: the main thing being to move away from size_tree being embedded in the API [02:53] lifeless: But you could replace InterDifferingSerializer with InterDeltaLovingRepositories. [02:54] abentley: sure, it still will either have, or want to use, a function/method that operates on deltas [02:55] abentley: and there is no reason for it to only match delta loving repositories IMO [02:55] lifeless: Sure, but it has the option of doing *all* the file texts, then *all* the inventories, etc. [02:56] abentley: well, InterDifferingSerializer has that option too doesn't it ? [02:58] lifeless: Yes, and it would look much cleaner if install_revisions wasn't involved. [02:59] abentley: right; so thats what I'm proposing to do: to change IDS to not use install_revisions; and to use a new method that focuses on deltas instead [02:59] abentley: another approach is to start working on the repository level streaming stuff again [02:59] I don't understand why you want to do it that way, instead of implementing it directly on IDS. [03:01] abentley: I think I'm assuming that there may be some repo centric code involved to get best performance [03:01] abentley: so putting that on repo lets it be interface tested easilly [03:02] I may be drawing the lines early/wrng [03:03] abentley: also for reuse [03:04] something embedded in the inter-object is harder for e.g. importers, bundles, etc to use === kiko-fud is now known as kiko-zzz [03:04] lifeless: If Repo is an input, it's similarly difficult for importers, bundles, etc. [03:05] abentley: right; note that I didn't include Repo as an input [03:05] abentley: I *considered* it [03:09] lifeless: Yeah, and we were discussing that option, weren't we? [03:09] abentley: oh, I didn't click that it was a sub-discussion :P [03:10] abentley: anyhow, the discussion has been great [03:10] I guess, you know, a 5-tuple makes me uneasy. [03:10] yah [03:10] its close to an object is definitely better [03:11] Yup. [03:11] its one-per-rev, so object creation count is bounded by history [03:11] I'm comfortable making this objects [03:11] Or perhaps a dict with namespaces? [03:11] a dict would be faster than an object [03:12] lifeless: Yeah, object creation isn't that expensive here. [03:12] lets say a dict for now, and a private-but-tested method [03:12] once it stabilises a bit, we can go for an object if we want to [03:13] lifeless: You'll lose ordering, and lose the ability to take a generator as input. Is that okay? [03:14] abentley: oh uhm clarity: I was proposing an iterator of dicts [03:14] each dict has the data for a single revision [03:14] the transform being (5-tuple -> dict) [03:15] lifeless: I mean that the dict would hold the entire input. [03:15] abentley: oh [03:15] That's why I said "namespaced". [03:15] abentley: I think that will not work due to memory [03:15] But your approach sounds fine. [03:15] abentley: ok cool; yay compromise [03:16] thanks [03:16] lifeless: np [04:02] lifeless, spiv, i'm going to read https://code.edge.launchpad.net/~spiv/bzr-usertest/exit_codes/+merge/1309 unless you're already on it [04:03] poolie_: thanks, that would be useful [04:03] poolie_: if you're in a reviewing mood [04:03] I have a commit-uses-delta patch needs review too [04:03] lp reviews have more reasonable urls than BB [04:13] spiv, are you around? [04:17] I am. [04:29] nm, i'm replying in launchpad [04:37] spiv, it's approved with mumblings [04:55] lifeless, orcadas may be better now; i'd changed the script to separate out stderr and i think it was not getting into the right file [04:55] let me know [04:55] the pulls are still pretty slow [05:41] poolie_: yes, thts why I'm working on pull :P [05:42] :) [06:09] poolie_: could you merge http://people.ubuntu.com/~andrew/bzr/push-unlock-1.8 to 1.8 for 1.8 final? I sent a mail to the list a while back asking for someone with permission to merge it, and I just realised it hasn't happened yet. [06:09] sure [06:10] poolie_: thanks [06:39] hi all [06:49] hi vila [06:59] poolie_: ping [07:10] gnight all [07:13] night [09:05] hi [09:17] lifeless, nice explanation of formats [09:28] poolie_: thanks; felt compelled to reply to s turnbull [09:29] poolie_: ping [09:30] hi vila [09:30] lifeless: One thing worth mentioning on the subject is that everything changes [09:30] Being able to handle these changes is what matters [09:30] but overall, very nice summary, thanks for that :) [09:31] lifeless: hi [09:32] that's a good way to put it vila [09:32] lifeless: would now be a good time to get subunit and testresources into pyunit-friends? [09:32] i think the experience of upgrades and ui could be better [09:32] i think the bug about it is 90302 [09:32] not sure when we'll get to it though [09:32] btw http://benchmark.bazaar-vcs.org/ now shows the machine load [09:34] poolie_: You couldn't even dream of making such a comment if bzr haven't already experienceS in upgrades... and really, *by default* nobody *has* to care about our formats most of the time [09:34] vila: I have to care about formats most of the time. [09:34] jml: You're not the average bzr user :-) [09:34] :) [09:35] jml: Of course *you* have to care, but aren't you happy that 'bzr upgrade' exists ? [09:35] vila: very happy, actually. [09:36] Man, when bzr-1.6 begun to warn me about all my old branches still using old formats, I was just surprised there was so many, but none of the upgrades (like in None) has a single problem [09:36] is it possable to commit a "nothing changed" revision? We have several repro's and we want their revision id's to stay in sync [09:37] a_c_m: it is possible (bzr commit --unchanged) but that sounds like a strange thing to want. [09:37] a_c_m: why do you want the revnos to be the same? [09:39] ubottu: bug #90302 [09:39] Launchpad bug 90302 in bzr "Improve help-formats" [Medium,Confirmed] https://launchpad.net/bugs/90302 [09:39] jml: we have 3 repro's for each project, /code /files and /database [09:40] jml: dev's only have commit access to /code, but the dev server pushes out to /files /code /database [09:42] jml: were still trying to work out the best process for what we need to do... [09:42] a_c_m: *nod* [09:43] a_c_m: what do you hope to gain from synchronizing revnos? [09:43] jml: being able to pull a full site (code, files and db) by knowing the revision number [09:44] jml: else they will get out of sync, and it will be harder to get a stapshot [09:44] no? [09:44] a_c_m, hm, interesnting [09:45] there is commit --unchanged which will do this [09:45] you should probably also set append_revisions_only=True in the branch conf to stop people pushing over the branches and getting them out of sync [09:47] wow, i've just tested... i didnt think bzr could do partial commits ie from sub folders. That might solve the problem no? [09:48] if we just dont give write access to the /database and /files folders... [09:49] if they try to commit, from / it will just fail. but if they commit from /code - all will be well ? [09:52] a_c_m, you can do this in the working copy [09:52] the server can't enforce those permissions [09:52] ahh [09:52] though it would be feasible to write a server side hook that does check it [09:52] not so hard but you would need to learn a little bit about the bzrlib api [09:54] poolie_: it think its going to be simpler to use multi-repositories. [09:54] poolie_: ugg... [09:56] hm [09:57] how strong do you need the security to be? how about a shell hook in the non-developer checkouts that just makes sure they've only changed the files they're meant to? [09:58] poolie_: humm, could be but it needs to be really simple and cross system (mac, linux and windowS) [09:59] so just to back up a bit [09:59] if people are committing to these things independently, how do you know which version of the code goes with which version of the db? [10:00] let me back up and explain the situation [10:04] ugg its quite intricate... bear with me [10:08] 3 repro's - code, database and files. Developers need to check out all 3, but only every update code, the dev server can be triggered to sync, which means, pulling in code and committing database and files. Developers should never be able to commit to files and database, except to keep the revision numbers in sync. [10:09] looking at it, your solution of a single repro with a server side hook is probably my favorite, how long might that take someone who knows what they are doing? [10:12] hmmm how long bzr reconciel may work ? It's 10min already at and of bar .... [10:13] matkor: (is the CPU still being used, or is it idle?) [10:14] a_c_m, so what does the server do when it commits to the database and files? [10:14] i guess i'm wondering: if there's no strict dependency between them [10:15] why not just have say a 'deployment' branch of all three, and push to that when it's ready to go out [10:15] similarly for 'staging' and whatever [10:22] AfC: CPU still used [10:30] so after a quick chat with poolie_ (many thanks) i'm going to try to clarify my problem again [10:32] a_c_m, so the content in the database that's committed by the server - where does that come from? [10:32] do people also log in to the server running the master db and make changes there? [10:32] yes [10:32] via drupal's main interface [10:33] then we hope to have a sync.php script which dumps the db and performs the sync with the various repro's/folders [10:38] ok, apologies for re-iterating what i'm trying to achieve, but i think i have it in a understandable format now :) [10:39] Were building out the development process for a new Drupal site. We want the DEV server to only ever be updated by a script which pulls from BZR, so no manual editing ever happens. [10:39] Drupal is brilliant but has a challenges, it stores a lot of config information in its database, so this needs to be backed up as well. For this reason we are thinking we need 3 repros (or folders), CODE, DATABSE and FILES. [10:39] The developers should be able to check out all 3, but only every COMMIT to CODE. The DEV server will have a script on it which will dump the database and then COMMIT the user generate files to FILES and the database dump to DATABASE, after that it pulls in the CODE from bzr. [10:39] With their code now on the DEV server, they log onto it and perform any of the db changes they need via the main drupal interface, once done, they commit thier chagnes again by re-running the sync script. [10:40] Question is, how can i best achive this with BZR? [10:44] i think you should start by just having 3 branches, and committing to each of them either when you change the master db or whatever [10:44] it's possible that the code will get out of sync with the drupal config, but i don't think that problem is actually technically soluble [10:45] yeah, i'm starting to see that... [10:45] oh, how about a post commit hook on the CODE repro ? which fires off a --unchanged commit on the other 2? [10:45] (to keep the revisions in sync) [10:46] i think, it might be ok to just have CODE and FILES (and store the db in FILES) [10:47] so there would need to be the corresponding hook on FILES to trigger a --unchanged on CODE... [10:47] but that might do it ? [10:58] matkor: repository size is the main factor (overly simplifying), what is yours ? [11:10] vila: 121 [MB] .. it's now 1h of cpu time but progressbar is back in middle after "Inventory regenerated." message ... [11:11] matkor: it can take far longer than 1 hour, feel free to kill it and run it at night [13:27] guilhembi_: ping [13:28] vila: pong [14:04] jelmer: pulling from webkit svn into my bzr branch using bzr-svn 0.4.13 icw bzr 1.8rc1 is very slow [14:04] jelmer: I remember to have had performance issues before. [14:19] uws, can you run with -Dtransport and see which steps are slow (by looking at ~/.bzr.log) ? [14:19] or perhaps, just pastebin ~/.bzr.log somewhere? [14:21] jelmer: running with -Dtransport now [14:21] determining changes 23541/37602 [14:21] ^^ takes as while as well... [14:24] jelmer: each "svn update" takes time, and it's mostly cpu bound [14:24] 260.253 svn update -r36507:36508 [14:24] 267.228 svn update -r36508:36509 [14:25] jelmer: Aii... if I cancel and retry (as I did with -Dtransport) previously pulled revisions from the interrupted "bzr pull" are lost it seems... :S [14:28] uws, yes, that's right because of the way bzr works [14:29] uws, bzr-svn stores revisions in groups of 100 I think [14:31] jelmer: Ok, I'll just leave it running for a while then :) [14:32] jelmer: I'm running "bzr -Dtransport pull" right now, but there's not much debug info in .bzr.log, just the "svn update" lines and a few "XYZ copied from ABC" messages. [14:35] uws, and that's the step that's slow? [14:36] hello.. If I have pushed a code once to a branch and I add a component to one of the subfolders of the code on my hard drive, how do I make the new change? [14:37] I have done: bzr commit -m "Added plugin" [14:37] jelmer: between 5 and 15 seconds in between each svn update line [14:37] and the bzr push [14:37] uws, could it be that the server is just slow? [14:37] jelmer: sometimes even a lot more, ~30s [14:38] jelmer: could as well be... it has been faster before ;) === kiko-zzz is now known as kiko [14:48] jelmer: But if it's the SVN server being slow, why is bzr eating all my cpu :) [14:53] uws, ah, hmm [14:54] uws, I guess you'd better wait for 0.5 in that case, that should be a lot faster === kiko is now known as kiko-phone === kiko-phone is now known as kiko [16:47] vila: Is there an SSH smart server we can use for testing? [16:48] I don't think so [16:49] vila: Drat. Makes it hard to test what user bzr+ssh is using... [16:49] abentley: I know the feeling :-/ [16:49] hey all [16:50] I ahve vague plans to add some in the lp:~vila/bzr/local_test_server plugin but didn't find the time so far [16:50] anyone know why 'bzr ci -m "test" ' wouldnt work in a php exec() statment, but 'bzr status' does? [16:55] jam: ping === kiko is now known as kiko-fud === cprov is now known as cprov-lunch [17:15] vila: OTOH, maybe I don't need a successful bzr+ssh operation... [17:16] as in whitebox testing that will attempt to connect with the right user ? [17:17] s/that/& you/ [17:17] vila: right. [17:21] abentley: ha ! I just re-read the FIXME at the end of test_config.py :-/ [17:21] james_w, I can reproduce Ted's problem now as well [17:22] vila: Agreed :-/ [17:28] jelmer: do you know what the cause is? [17:29] jelmer: did you also see the bug about the notification icon not being a notification? [17:29] it's only started appearing recently so I suspect it's indeed some upstream change [17:30] abentley: I suppose your need is urgent ? Because I have less vague plans to implement http auth servers in lp:~vila/bzr/local-test-server and bzr+http, I never thought about ssh but that may be possible (but beware of the caveats I encoutered when trying to do ftp servers) [17:30] james_w, Yes, I saw it but I'm not sure I agree with the submitter [17:30] I kind of do [17:30] I think there will be more complaints about it [17:31] abentley: May be you can just plug an *existing*, running bzr+ssh server like I do in this plugin [17:31] vila: not deadly urgent, but Launchpad developers have been barking their shins on it. [17:32] * vila search for barking their shins... [17:32] barking-their-shins~=banging-their-shins [17:33] Hu hu, should be the rough equivalent of the french "pleurer leur mere" :) [17:34] Raining their mother? [17:34] crying :) [17:34] (-: [17:34] james_w: it's not just there for notification, also to allow you to e.g. enable gateway to LAN [17:34] raining is pleuvoir [17:35] james_w, perhaps it should just be disabled by default [17:35] vila: Right. [17:35] jelmer: yeah, I think that would be better. [17:45] Woohoo ! Fixing bug #277537 with bzr reconcile requires 20 h, I was down to 2h10 last night with a dedicated plugin, and now I'm down to 312 *seconds* [17:45] Launchpad bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [High,Triaged] https://launchpad.net/bugs/277537 [17:46] * vila had to share :) [17:46] jam: ping ping ^ [17:48] woh [17:48] vila: it's fair to say it wasn't entirely optimized? :) [17:48] LarstiQ: Hold on ! I didn't optimize reconcile, I did a specific reconciliation [17:49] for a specific bug applicable only on specific repos based on results acquired with a bzr check that needded 32 hours [17:49] but yet... :) [17:50] vila: seeing as I have repositories with the exact same problem, I'm still interested :) [18:03] anyone know what the return status of 3 means (or ideally where i can find a list of what the return status numbers mean?) [18:04] a_c_m: the same as diff(1), iirc 3 is modified [18:05] hmm, maybe not [18:06] a_c_m: right, 1 is modifications present in `bzr diff`, and 3 in general for bzr is an error occurred [18:06] LarstiQ: i'm trying to call bzr from php via exec... and getting that... [18:06] any ideas? [18:06] a_c_m: I'd look at the output of bzr [18:07] if bzr returns 3 you should find something in stderr (or the php equivalent) [18:07] vila: LarstiQ: bzr --version works... bzr status ... returns nothing, but when i run the same command in a shell, it works fine [18:08] a_c_m: bzrlib/errors.py, EXIT_OK=0, EXIT_ERROR=3, EXIT_INTERNAL_ERROR=4 [18:08] LarstiQ: humm ok. [18:09] a_c_m: common causes, running `bzr st` while not in a branch [18:09] a_c_m: I don't know php but you need to get back the output from stderr and stdout, that's where bzr will explain why it fails [18:09] LarstiQ: humm ok will do some exsautive testing... thanks [18:09] vila: thanks too [18:10] a_c_m: which makes sense in an exec context. Are you sure the cwd is what it is supposed to be? (In other cases, the environment might not be what you think it is) [18:12] LarstiQ: thats the thing i've tried full urls e.g. /usr/bin/bzr st /home/me/foo/dir/ [18:12] LarstiQ: still exists with 3 [18:13] a_c_m: and /home/me/foo/dir/ is actually a branch? [18:14] a_c_m: if that works in the shell, I'm not sure what is different with php [18:14] LarstiQ: yeah works in shell [18:14] :( [18:14] a_c_m: you could also check ~/.bzr.log [18:14] LarstiQ: aaah looking [18:25] LarstiQ: the plot thickens! bzr info work... === cprov-lunch is now known as cprov [19:25] LarstiQ: worked it out [19:25] a_c_m: what was it? [19:25] LarstiQ: it was due to the www-data user (who was doing the exec()) [19:25] thier home dir was /var/www [19:26] which www-data doesnt have write access to, so couldnt make the .bazzar folder [19:27] ~/.bazaar/ you mean? [19:27] yeah [19:27] ah yes [19:27] as www-data is homed to /var/www [19:31] a_c_m: how did you figure this out? [19:37] exec('whoami') [19:38] then su www-data [19:38] and then tried doing the same commands [19:38] i also get "No handlers could be found for logger "bzr"" message [19:38] but it doesnt seems to matter [21:38] w00t [21:39] "bzr svn-serve" can now natively provide svn checkouts from bzr branches [21:39] and it's *fast* [21:40] not as fast as svn itself obviously, but < 15 seconds locally for bzr.dev [21:40] jelmer: So I do 'bzr svn-serve my_branch' and then can 'svn checkout' that branch? [21:40] Odd_Bloke, yes [21:40] e.g. svn co svn://145.97.197.14/trunk bzr.dev-trunk [21:40] (that's running with bzr.dev now) [21:41] It's not as quick as locally as I haven't added zlib support yet [21:43] 21:41:58 < lamby> Has it been tested with git-svn? *g* [21:44] It provides only a subset of the svn smart server commands, but there's no reason why that shouldn't work :-) [21:44] in particular, it can't do incremental updates yet, only full checkouts [21:44] which would be a bit of an obstacle for git-svn ;-) [21:45] jelmer: why is this good? [21:45] jelmer: I'm just wondering who is going to use this functionality [21:46] thumper: It means being able to provide svn access to users while migrating to bzr [21:46] does git offer this? [21:46] thumper: E.g. you can use the netbeans svn plugin with a bzr repository [21:47] ah, that's kinda nice [21:47] thumper: ie, leverage all of the 3rd party svn tools (but I guess you already got that) [21:47] * thumper nods [21:47] thumper, also, it allows users who are already familiar with svn a way to check out the source code of a project in bzr without having to install or learn bzr [21:48] and we all know there are lots of svn users out there [21:48] this last bit was one of the concerns within the Samba team while we were considering various DVCSes [21:48] thumper, Git doesn't have anything like this as far as I know [21:50] jelmer: WOW! that's awesome! [21:55] it's also a bit faster than "bzr co --lightweight", 1m11 vs 3m07 here [21:59] jelmer: have you analysed what makes the difference? [22:01] no, but I suspect it's because bzr co --lightweight hasn't been optimised yet [22:02] LarstiQ, svn co basically means sending all the tree contents without requiring acks from the client until everything is received [22:03] jelmer: right, so I was wondering if it's over the wire roundtrips/fileformat, or perhaps that svn_serve does less work client side, or what [22:06] LarstiQ, both [22:06] the number of round trips is far less with svnserve (4) [22:07] and there's no dedicated verb for Repository.revision_tree() in the bzr smart server [22:07] jelmer: wow, cool [22:08] good day bzr hackers! [22:09]