[00:05] lifeless, about the locking behaviour we talked about yesterday. That special case 'LockResult(file:///tmp/testbzr-J2pcy2.tmp/.bzr/branch-lockc4au55ppz8wdym11z1aq)', you can never get this if you install your own hook, right? (i.e. you will only find it if you use _lock_actions directly) [00:06] dvheumen: you can get it, but only if you install your hook before creating a bzrdir [00:07] aha okay, so that's the idea. Okay in that case I'll add that case to the documentation too. [00:08] bzrdir is the '.bzr' directory right? [00:08] so in essence a newly created checkout/branch/repository [00:08] jelmer: so feed-pqm worked for you, it seems? [00:09] dvheumen: bzrdir is the .bzr directory, yes [00:09] poolie: no, unfortunately the email it generated in the end was rejected because of the gpg signature [00:09] huh [00:09] the signature was invalid? [00:10] dvheumen: yes [00:10] is feedpqm in the bzr-pqm plugin [00:10] ? [00:11] poolie: I'm not sure - it's very cryptic in its error messages: "PQMException: 'Failed to verify signature: gpgv exited with error code 1' [00:11] " [00:11] lifeless: it's in hydrazine [00:13] jelmer: :/ [00:13] what if you pipe it through gpgv yourself? [00:13] could it be that you have multiple secret keys and it's using the wrong one? [00:14] No, I'm sure this is the right key [00:14] it seems like it might be related to the from address - does pqm rely on that ? [00:14] i don't know [00:14] (feed-pqm uses the email address to do a proper CC but it doesn't override the actual from address) [00:14] jelmer: the key's primary UID *I think* [00:14] that could well be the problem though [00:14] jelmer: check the code. [00:15] lp:pqm [00:15] so you could try forwarding the message from the right from address and see what happens [00:15] lifeless: feed-pqm is i presume what you were just asking me about [00:15] lifeless: Thanks, but I've wasted too much hours of my life in pqm source code already :-) [00:15] poolie: nope [00:15] poolie: the queue API stuff you found [00:16] it uses the queue api [00:25] good [01:00] poolie: Things seem to work quite a bit better if I use bzrlib's email API [01:00] poolie: Are you opposed to having hydrazine depend on bzrlib for sending email ? [01:00] nup [01:00] it's probably much better to do that [01:00] awesome; one mp coming up :-) [01:01] i'd like to teach it to ignore mps from people who can merge their own [01:01] thanks [01:01] poolie: I think its great to have it submit other ppls mps ;) [01:01] poolie: yeah, I agree that'd be nice (except for the current user, of course) [01:02] or we could do that [01:02] but it gets more into 'almost ready' vs 'actually read' [01:02] ready* [01:21] jelmer: are you using hydrazine to triage bugs? [01:21] because all you comments are coming wrapped in "s [01:21] mwhudson: yes [01:21] mwhudson: oops, I was assuming I had to quote arguments to the comment command :-) [01:21] mwhudson: thanks, I'll avoid that from now on [01:22] * jelmer thinks he also added a comment '--help' somewhere [01:22] heh [01:22] is that working again? [01:22] for a while most bug operations were broken because of an etag bug [01:22] but it was marked critical so maybe it's fixed [01:22] i guess adding a comment would still work [01:22] I did get "precondition" exceptions on some changes [01:23] other than that it worked quite well [01:24] I think the CP may have gone through today [01:24] but I'm not sure if that was production/edge [01:44] heh, i see your "--help i'm trapped in a bug" message :) [01:44] also for some reason it no longer exits cleanly on ^D [01:44] um [01:44] i'd like to have a way to go into $editor to add a comment [01:45] probably most easily done by calling bzrlib [02:00] igc is https://bugs.edge.launchpad.net/bzr/+bug/524162 still open in bzr itself? [02:01] Launchpad bug 524162 in bzr "bzr-explorer don't work if installing by bzr-2.1.0 standalone installer." [Critical,Confirmed] [02:02] poolie: yes. It's waiting on https://code.edge.launchpad.net/~ian-clatworthy/bzr/plugin-packaging-524162/+merge/20858 being reviewed and landed [02:04] k thanks [02:08] * igc lunch [02:10] poolie: does the bzr-grep textfile.text_file approach for checking binary seem reasonable to you? https://bugs.launchpad.net/bzr-grep/+bug/531336/comments/4 [02:10] Launchpad bug 531336 in bzr-grep "bzr grep does not handle binary files cleanly" [High,Fix released] [02:12] parthm: isn't there something in osutils or similar to already do this? [02:13] oh obviously that's what you're doing [02:13] poolie: yes. i am just using a bzrlib implementation. [02:13] yes that looks good then [02:14] poolie: ok. thanks. === wash is now known as wash-away === Kilroo1 is now known as Kilroo === fullermd_ is now known as fullermd [03:39] hi igc, lunched? [04:04] igc are you already doing something similar to bug 534320 [04:04] Launchpad bug 534320 in bzr "Disable plugins for given command" [Undecided,New] https://launchpad.net/bugs/534320 [04:12] hello, is there any explaination of stacked branches besides the documentation? [04:13] the secion "using stacked branches" in the bzr manual doesn't explain it well, and many examples in it don't work [04:16] echo-area: those docs are the best I know of, but I'm happy to answer questions here [04:18] echo-area: the primary use case is pushing to a server where a trunk already exists (so most of your branch's revisions are already on the server), but you don't have write access to that repository [04:19] echo-area: so you can push (using the --stacked and --stacked-on options, or specially configure the remote .bzr directory) just the revisions unique to your branch to the server. [04:20] echo-area: launchpad for instance creates those specially configured .bzr directories automatically, so if I push a new branch to ~spiv/bzr/..., it will automatically be stacked on the bzr trunk. [04:20] spiv: but I can't commit to a stacked branch [04:21] echo-area: yes, unfortunately :( [04:21] That's bug 375013 [04:21] Launchpad bug 375013 in rosetta "Cannot commit directly to a stacked branch" [High,Triaged] https://launchpad.net/bugs/375013 [04:22] We'd like to fix that, but it will be a surprisingly large amount of work :/ [04:22] Oh, does the "Using stacked branches" doc suggest that you can commit to a stacked branch? Eek :( [04:22] That is confusing, I'm sorry. [04:23] spiv: that's the main source of my confusion. I've created a stacked branch, by following the documentation, via the command "bzr branch --stacked source branch" [04:23] spiv: but after making some changes, I can't commit them, nor can I push them. [04:24] echo-area: Right, because of that bug. [04:24] So, if you want to commit, you can't use a stacked branch yet, sorry :( [04:24] I'll submit a clarification to the docs now [04:25] In the meantime you'll probably be better off using a shared repository and unstacked branches. [04:25] spiv: umm, stack branches aren't usable before we can commit to it, are they? [04:26] * fullermd suspects stacking should be rather more hidden... [04:31] echo-area: There are uses for branches that don't involve committing to them [04:32] and pushing is different to committing [04:32] echo-area: e.g. the scenario I described earlier (pushing to a server that has a suitable repository for stacking-on, but that you do not have permissions to write to) [04:32] which is in fact why you can't commit to stacked branches. [04:34] I just don't worry too much about stacked branches unless they make things go too slowly when I try and push something to launchpad ... [05:19] hello. i am planning to suggest the lp:parrot owner to upgrade the repo format to 2a. whats the suggested way to upgrade an lp branch. l believe lp:parrot is an svn imported branch. [05:20] https://launchpad.net/parrot [05:23] I think the owner of the branch can click an "upgrade format" button in the web UI now. [05:25] spiv: thanks. i will suggest that. === BasicPRO is now known as BasicOSX [05:39] spiv: I have not reproduced that scenario successfully yet. I did this: [05:39] bzr init-repo --no-trees test-repo [05:39] bzr init test-repo/trunk [05:39] bzr init-repo test-branch [05:40] bzr branch test-repo/trunk test-branch/trunk [05:41] cd test-branch/trunk <-- and work here, commit [05:42] then I did (in test-branch/trunk) bzr push --stacked ../../test-repo [05:43] I got messages like these: [05:43] Ignoring request for a stacked branch as repository already exists at the destination location. [05:43] All changes applied successfully. [05:43] Pushed up to revision 4. [05:44] hmm. i did suggest lp:parrot to upgrade the branch http://groups.google.com/group/parrot-dev/browse_thread/thread/1cc2f0bbb18b76fc [05:44] but as I made another branch of test-repo/trunk, I didn't see the new revisions unique to test-branch/trunk [05:45] but i see the branch owner listed as 'VCS Imports' https://code.launchpad.net/~vcs-imports/parrot/trunk so is the upgrade to be done by the project owner or branch owner? [05:46] lp:parrot project owner is ~parrot-dev while branch owner is ~vcs-imports. [05:47] echo-area: that's not the scenario I was referring to [05:48] echo-area: because in that scenario you can (and did) push directly into the original repo (test-repo) [05:49] echo-area: I'm referring to a case like a server shared by several developers, but only one (or perhaps a non-human system account, like a gatekeeper bot) has access to the integration branch everyone branches off [05:50] spiv: should I make test-repo a stacked branch, and so that pushing onto it is the same as pushing to the stacked-on branch of test-repo? [05:50] echo-area: e.g. if the trunk is on /srv/project/trunk on a host, and /srv/project is a repo made with init-repo, but you don't have access to write to /srv/project [05:52] echo-area: but you can read from it, so you can do e.g. "bzr branch sftp://host/srv/project/trunk local-branch", work on that, and then push it up with "bzr push sftp://host/home/myuser/my-branch --stacked --stacked-on=sftp://host/home/myuser/my-branch" [05:53] echo-area: in that case making local-branch will still copy the full history, but you don't have to push the full history back to the server, you use stacking to point to the history the server already has [05:54] (and also you don't waste space on the server by keeping a second copy of the history) [05:54] echo-area: does that make sense? [05:55] spiv: I'm reading and understanding. It definitely makes sense. Thanks [05:56] Cool. Glad I could help :) [05:56] It's an optimisation that most people don't need, I think. [07:07] thumper: will lp crash if we set merge proposal queue fields using APIs ? [07:07] 'try it' is a good answer. [07:18] hi all ! [07:23] spiv: please take a look at this, does it elaborate the scenario you mentioned: [07:23] bzr init-repo test-repo [07:23] bzr init test-repo/trunk [07:23] bzr init-repo stacked-repo [07:24] bzr branch --stacked test-repo/trunk stacked-repo/trunk [07:24] bzr init-repo local [07:24] bzr branch test-repo/trunk local/trunk [07:24] cd local/trunk <--- work here [07:24] echo-area: it doesn't make much sense to create a stacked branch in a shared repo (i.e. a directory you've made with init-repo) [07:25] (in local/trunk) bzr push ../../stacked-repo/trunk [07:26] spiv: so a stacked branch is better put in its own directory? [07:26] (I guess I can imagine uses for it, but it's certainly not how I would choose to explain it) [07:26] echo-area: I'd ignore init-repo entirely, really [07:27] echo-area: (for explaining how stacking works, not in general) [07:28] I'm not sure what you're asking, exactly. [07:29] I guess you're trying to test your understanding of stacking by constructing a scenario that uses it? [07:33] spiv: in your last example, "bzr push sftp://host/home/myuser/my-branch --stacked --stacked-on=sftp://host/home/myuser/my-branch", are the following statements true or not? 1) sftp://host/home/myuser/my-branch contains the full history too; 2) only the local revisions that have not been synced will be transfered during that push, the previous history will come from my-branch on host; and 3) full history will be tran [07:33] sfered in a normal push. [07:34] spiv: kind of. I want to figure out the things not explained explicitly in your example, hoping to help myself fully understand stacked branches [07:37] 1) no, it only contains the history not in the stacked-on location (plus some small overhead), b) yes, only the history not already in sftp://host/home/myuser/my-branch and not already in its stacked-on location is pushed, 3) it depends; full history is transferred in a normal push when there is no shared repository (or that shared repository is empty or otherwise contains none of the relevant history) [07:38] spiv: so sftp://host/home/myuser/my-branch is a stacked branch too? [07:39] To clarify for 3, I mean a normal *initial* push. Obviously subsequent pushes to the same branch don't have to re-transfer data that was already transferred. [07:39] echo-area: what do you mean "too"? I think that's the only stacked branch in my example. [07:40] echo-area: oh, I see I made a silly typo in my example [07:40] echo-area: that command ought to have been "bzr push sftp://host/home/myuser/my-branch --stacked --stacked-on=sftp://host/srv/project/trunk" [07:40] echo-area: I guess that was rather confusing! [07:41] spiv: should be bzr push --stacked --stacked-on=sftp://host/srv/project/trunk sftp://host/myuser/myproject, right? [07:42] echo-area: right [07:42] spiv: whoa, I think I understand that now. Thank you! [07:45] spiv: I think your example is the one that clarifies much about stacked branches. Maybe you can add it to the documentation. What do you think? [07:46] echo-area: or you could :) [07:46] Patches are always welcome :) [07:47] More seriously, I'm finishing up for the day, and will likely to have forgotten by tomorrow, so please file a bug asking for that, feel free to paste my IRC comments into it. [07:48] spiv: okay, let me try to write one. I'll do what you said. Thank you very much. [07:48] echo-area: Btw, is the patch I wrote to that doc earlier. [07:49] spiv: ok [07:49] echo-area: thank you, feedback on docs are very welcome, and offers to write them even more so! [08:10] lifeless: I don't advise it === tro|| is now known as tro [08:45] * igc dinner [09:21] thumper: is staging sufficient to tell if its a problem? [09:22] lifeless: probably, but what are you trying to accomplish? [09:22] thumper: streamline landing stuff [09:24] lifeless: I can't guarantee it won't be a problem [09:24] lifeless: but staging should be good enough [09:25] * lifeless makes a memo [09:27] lifeless: if I lock a working tree for writing, does that take a lock on the branch as well? [09:45] thumper: yes [09:45] thumper: lock_tree_write will lock the tree only (and take a read lock on the branch) [09:46] lifeless: I'm trying to write a test that uses a working tree [09:46] lifeless: and I want some files in that working tree [09:47] is build_tree_contents the right thing to use? [09:47] it doesn't seem to take enough params [09:47] using TestCaseWithTransport [09:47] self.build_tree_contents([(path1, content1), (path2, content2)]) [09:47] there are a few similar thigns [09:48] if you want versioned files, you need to also add them [09:49] lifeless: does that only work if you use make_branch_and_tree with '.'? [09:49] lifeless: also, where are the internal methods for working out if a fileid is a directory? or binary? [09:49] thumper: just adjust the paths [09:49] ok [09:50] tree.inventory[fileid].kind - internalish [09:50] tree.kind() or something like that - public [09:50] ta [09:52] thumper: alternatively, you can provide a transport to build_tree_contents, damn, no, you can't, that works for build_tree only, shame [09:52] but if you're ok with arbitrary content and have a tree from make_branch_and_tree, you can then use transport=tree.bzrdir.root_transport and you don't need to prefix your paths anymore [09:53] I'm having trouble finding the options for return values for tree.kind() [09:54] vila: if you want arbitrary, MutableTree.set_file_content is better [09:54] thumper: 'file', 'directory', 'symlink', 'absent' [09:54] thumper: osutils._kind IIRC [09:55] it'd be really helpful if that was part of the docs for the method :) [09:56] someone told me that bzrlib uses looks for a null withing 'x' amount of the content to determine if a file is binary [09:56] thumper: patches loved [09:56] is that method public(ish)? [09:56] yes [09:56] tis in osutils [09:56] * thumper looks again [09:59] lifeless: set_[file_]content ENOTFOUND [10:01] vila: meh; look at MemoryTree using tests. [10:02] thumper: bzrlib/textfile.py ? [10:04] ah yes [10:04] thumper: ^ [10:04] ta [10:04] reading now [10:14] vila: sanity check: bzrlib.textfile.check_text_path is bust [10:14] vila: or perhaps just unclear [10:15] lifeless: as in not mentioning that it checks the *content* of the path ? [10:16] well [10:16] looking at it, it looks like it calls a generator and discards it [10:16] which isn't generally useful [10:17] It calls an iterator and discards it, but happily the constructor of the iterator contains the relevant check. [10:17] it would be clearer, I think as [10:17] 'if '\x00' in f.read(1024): raise BinaryFile()' [10:17] So, a little unclear, but given the overall simplicity of the module not a big deal either. [10:18] what is the right way to call check_text_path with a path and a working tree? [10:18] spiv: I hope you and Mary will be available on the 27th [10:19] the method assumes the path is relative to the current working dir [10:19] thumper: tree.get_file() -> check_text_file [10:32] lifeless: in my test, I want to have fines in the tree [10:33] lifeless: how do I add the files ? [10:33] tree.add() ? [10:36] smart_add perhaps [10:37] tree.add([path, path], [id ,id]) [10:37] usually [10:37] or smart_add(['pathtotree']) if you just want versioned [10:37] but at this point I'd smell aa case where branchbuilder might be ready [10:40] branchbuilder? [10:45] yah [10:46] self.make_branch_builder('relpath') [10:46] grep for make_branch_builder in bzrlib.tests; its not well described yet [10:47] ok [10:47] prolly not tonight [10:47] 'tis getting late [10:48] remember to add the root as the first thing you do with the branch builder [10:48] or you will get very confused [10:57] * thumper puts laptop down [11:00] lifeless: we are, yeah [11:13] google invites ftw [11:13] spiv: ^ [11:14] vila: ping [11:15] parthm: pong [11:15] vila: hi. i have closed most of the review comment on https://code.launchpad.net/~parthm/bzr/376388-dot-bazaar-ownership/+merge/19691 [11:16] vila: regarding, the testing, i updated the tests as we discussed the other day ( http://pastebin.com/CKhiAgL4 ) but it seems a regular user doesn't have permissions to chown ( http://pastebin.com/ZPk2XGvv ) [11:17] * bialix waves hi all [11:17] vila: i am out of ideas on the testing front. [11:18] * vila waves back at bialix [11:21] parthm: weird [11:21] argh, my X server is... acting weird too [11:23] ha, no, it was only FF [11:25] vila: how do you suggest we take this forward? the earlier _dummy_chown approach seems reasonable to me as os.chown is the lowest layer. [11:27] parthm: if chown can't be used, then it's sure sign that *not* using it in tests... shows why it should be used in tests :) [11:28] vila: :-) [11:32] ... that's the first time I see chown failing in a directory where I have write access... did posix changed overnight ??? [11:33] vila: i am not sure :-) ... generally i tend to use chown with sodo so i never really tried this before. [11:33] s/sodo/sudo [11:36] vila: i have also updated https://code.launchpad.net/~parthm/bzr/262450/+merge/19483 as per the review comments. so do i need to resubmit that? [11:37] parthm: as a rule, if you modify a branch, you just push again and then check that the status is 'Needs review' [11:38] vila: thanks. i will do that. [11:38] parthm: then you nag the patch pilot if nothing occur :) [11:38] vila: sounds like fun :-) so i will nag poolie this week. [11:40] vila: so for https://code.launchpad.net/~parthm/bzr/376388-dot-bazaar-ownership/+merge/19691 should i just put it up for review for now? we can discuss it further over review. [11:41] its 'work in progress' now. [11:42] parthm: as you feel, we at least to understand why os.chown doesn't work or your fix won't either anyway [11:42] vila: yes. we do have a better understand of the tests now. will do that. thanks. [11:43] regarding https://code.launchpad.net/~parthm/bzr/262450/+merge/19483 i have updated the code based on your comments. feel free to relook at it anytime :-) [11:47] vila: hmm. you raise a good point. normally chown won't work so a user foo can't chown to bar. however in this case we are going to chown to based on the containing folder which would be users home (and owned by the user). [11:47] so that should work i think. unfortunately we don't seem to have a thorough way of testing it. [11:51] parthm: it would be quite risky to introduce untested code especially code for .bzr.log and .bazaar access... [11:52] vila: i agree. i does seem somewhat brittle. i will set the status to 'Needs Review' in case there are any more ideas. i would be happy to work some more if something comes up or we can reject it. [11:53] parthm: sounds fine, don't forget to mention the chown problems you encountered in a comment [11:53] a comment on the merge proposal I mean [11:53] vila: will do that. [11:53] vila: thanks for taking the time to review this. === mrevell is now known as mrevell-lunch [12:36] does bzr have a shorthand for doing 'bzr merge -r N..(N-1) .' [12:37] in svn, I think you can do 'svn merge -c -N .' [12:37] where N is a revno [12:40] jml: if you want to merge a specific revision then '-r N' should work IIRC. [12:41] parthm, unmerge [12:41] parthm, I want to revert a particular revision [12:42] jml: ah. :-) maybe 'bzr revert -r N'? I haven't tried it though. [12:42] jml: I suppose -r N..before:N [12:42] jml: which is shorthand if N is sufficiently long :) [12:43] jml: I think a --reverse/-R switch would probably be a reasonable addition to 'bzr merge', although I haven't thought about it carefully. [12:44] We already use -c as shorthand for -r (N-1)..N [12:45] jml: I'm off to bed... if you like the -R idea please file a bug asking for it :) [12:46] spiv, ok [12:48] (And if you think it should be --backwards or --unmerge or something instead, do bikeshed in the bug report as appropriate) [13:37] Best place to report packaging bugs still the bugs for bzr? [13:37] awilkins: hmm? [13:37] which packaging specifically? [13:40] Windows [13:40] The current 2.1.0-2 package contains bug 526740 [13:40] Launchpad bug 526740 in bzr-xmloutput "XML-RPC service broken by bzr-2.1" [High,Fix committed] https://launchpad.net/bugs/526740 [13:44] I guess bzr-windows-installers [13:48] hello. i am trying to create a series 0.0.1-final for lp:bzr-grep. i have already created series 0.0.1-final via web ui. [13:49] when i try to push my trunk (with tag 0.0.1-final) to lp:bzr-grep/0.0.1-final I get the error bzr: ERROR: Invalid url supplied to transport: "lp:bzr-grep/0.0.1-final": 0.0.1-final has no default branch. [13:49] what am i missing? [13:56] partm: you need to create a bracnh first, then assign it via series interface [13:57] there is no magic lp:bzr-grep/0.0.1-final branch created when you created a series [13:57] so just push to lp:~user/bzr-grep/0.0.1-final first [13:58] then assign this branch as *the* branch for the series [13:58] not vice versa [13:58] parthm: ^ === mrevell-lunch is now known as mrevell [14:01] bialix: I knew I was missing something silly :P thanks. that worked out fine. [14:01] silly milly === kirkland` is now known as kirkland === salgado is now known as salgado-lunch === oubiwann` is now known as oubiwann === IslandUsurper is now known as IslandUsurperAFK === salgado-lunch is now known as salgado [17:27] I have a file listed as modified in bzr status, but the filename has a * after it, which I don't normally see. What does that mean? [17:30] rioch: Exec bit changed. [17:30] I think. [17:31] ahhhh yeah that's true I did a chmod as well :) [17:32] I'm pretty sure the * is explained somewhere [17:39] lifeless: doing the needful on the extra_headers patch; stuck now because I can't figure out how to *run* the test suite to verify that the test works :) [17:39] i have a local bzr checkout of emacs. where should i look to know which url it is pointing too? [17:40] i had a try through the .bzr directory but found nothing useful.. === abentley_ is now known as abentley [17:42] swathanthran: try 'bzr info' [17:43] slangasek: "bzr selftest bzrlib.plugins.email" [17:43] jelmer: thanks :) [17:44] jelmer: http://bzr.savannah.gnu.org/r/emacs/trunk/ is this trunk "proper" at the moment? [17:44] oh neat, my patch makes *other* tests fail :) [17:44] tests are great! === beuno is now known as beuno-lunch [17:44] jelmer: assuming it can be said by looking at there or something.. [17:45] bzr: ERROR: No WorkingTree exists for "http://bzr.savannah.gnu.org/r/emacs/.bzr/checkout/". and bzr: ERROR: No WorkingTree exists for "http://bzr.savannah.gnu.org/r/emacs/trunk/.bzr/checkout/". as i tried bzr update http://bzr.savannah.gnu.org/r/emacs/ and bzr update http://bzr.savannah.gnu.org/r/emacs/trunk [17:45] bzr update says Tree is up to date at revision 99318. === IslandUsurperAFK is now known as IslandUsurper [17:50] bzr pull does it:) [17:51] swathanthran: specifying a URL to 'bzr update' will try to update that remote URL :-) [17:54] uh:) i thought it the opposite way:) [17:57] slangasek: 'bzr selftest -s bzrlib.plugins.email' should be faster [17:57] slangasek: you can also do 'bzr selftest -s bp.email -s bt.' [17:58] slangasek: 'bp' and 'bt' are known shortcuts [18:00] vila: ok, cheers :) [18:01] (FYI, 'bzr selftest foo' loads the entire list of tests and then filters it. 'bzr selftest -s foo' only loads those tests starting with the module 'foo'.) [18:06] slangasek: I'm not sure what you're working on, but be aware that part of the plugin has been moved to bzr-core but the plugin still has that code (mostly the smtp connection stuff from memory) [18:06] slangasek: But if you're modifying something else, no worries [18:07] 'evening vila [18:07] vila: hum, I'm adding a new feature to the plugin, and basing my work on lp:~bzr/bzr-email/trunk/; where would I see that things have moved? [18:07] jelmer: hey :) [18:07] slangasek: nothing has moved from the plugin yet, that's the point :-/ Some code has been taken from there, put in core, and enhanced there [18:08] ok... :) [18:08] slangasek: let me check [18:08] vila: lp:~vorlon/bzr-email/extra-headers/, if you want to comment on the appropriateness [18:08] but lifeless mentioned nothing to me yesterday about this code moving :) [18:08] slangasek: ok, so you should be fine :) [18:12] slangasek: hmm, smtp_connection.py seems to have diverged, I can't be more precise at first glance [18:12] ok [18:13] * vila looks at lp:~vorlon/bzr-email/extra-headers [18:20] slangasek: hmm, well, it's late, but it looks like your additions will be welcome in bzrlib/email_message.py ... [18:20] slangasek: bah, one more thing to backport from the plugin ... === beuno-lunch is now known as beuno [18:32] vila: mumble; well, I'm at least going to wait until lifeless is satisfied with the merge on bzr-email first [18:33] vila: fwiw, this patching is all tied to moving the Debian Samba team off of svn, greatly simplifying the workflow we discussed at UDS :) [18:33] slangasek: sure, that's what I meant. I didn't imply you had to do the backport [18:33] slangasek: great news, thanks === radoe_ is now known as radoe [19:09] Is there a way to get bzr to eliminate unnecessary .bzr/ files? (Say, for example, in the case of using rsync or scp independently of bzr with different versions of bzr, or upgrades that didn't quite go as planned.) === zekopeko_ is now known as zekopeko [20:09] * kfogel is away: bbiab [20:28] slangasek: bzr selftest email [20:28] slangasek: or, to be a bit faster, the less discoverable 'bzr selftest -s bp.email' [20:29] lifeless: done - merge request resubmitted. Good morning :) [20:29] slangasek: good morning :) === salgado is now known as salgado-afk [22:24] can somebody help me understanding the bzr 2a format? [22:25] I've seen that there is a folder called "branch" that holds basic information like the last revision [22:25] I've also seen that there is a "repository" folder that seems to hold the data [22:27] as far as I can understand the contents are stored in the "packs" subfolder of "repository" [22:27] xeviox: Some data is stored in the indices as well. [22:27] ok [22:28] FWIW, the basic meta dir format (.bzr/branch, .bzr/repository, .bzr/checkout) has been around for ages. [22:28] how is the information stored in indices and packs? [22:28] Cleverly. [22:28] .bzr/repository/{packs,indices} have existed since pack-0.92, though the actual format has changed several times. [22:28] it seems to be compressed, but I don't see using what .. [22:28] zlib. [22:29] are you a developer of the project? [22:29] Not really. [22:29] k [22:29] anyways thanks for the background info :D [22:29] It's not super-simple, and even if I wasn't half-asleep, I don't know all of the answers. [22:30] so there is some metadata in front of the data, any idea what it is? [22:30] There is documentation, at the very least in the code, developer docs and mailing list. [22:30] Look up btrees, packs and groupcompress. [22:31] "records" look like "gcblz\n324\n442\nData... [22:31] Peng: ok I'll check [22:31] the problem is that the project is very complex [22:31] and my skills in python are very basic :( [22:32] I just try to build up a readonly script in php [22:32] as there a few people that want to share there codes but couldn't use bzr on their webpages .. [22:33] Trying to re-implement bzr is not a fun task. [22:34] Peng: sure :), but I hope that a read-only script is not that hard .. [22:34] It is that hard. :P [22:34] :( [22:34] What exactly are you trying to build? [22:35] I just want to build a script that is able to "read" a bazaar respository [22:36] a little web interface for bazaar [22:36]