=== mark2 is now known as Guest98545 [00:07] jam, success! [00:10] mpt: so does bzr check on your original branch work? [00:12] lifeless: can you join us if you're still around? [00:12] jam, I'll get back to you on that, it's checking revision 117/38124 :-) [00:12] mpt: if it didn't fail right away, that is, indeed a good sign [00:12] jam, however, "bzr log" gives me a KeyError in a different branch [00:13] mpt: well, then you need to do the 'bzr branch' with *that* revision, too :) [00:13] woohoo [00:13] ok [00:14] this could be a long night [00:15] thanks for your continued help jam [00:16] mpt: I'll be off in a bit, but you can poke at spiv or igc I think [00:16] ok [00:21] Well, I've got bzr diff --stat working [00:27] is there a way to enable user authentication for the dedicated bzr server? [00:45] tufloc: serve the branch over ssh/sftp [00:47] I'm starting to miss svn [01:01] the dedicated server doesn't allow write operations? [01:03] it can do [01:05] pickscrape: yay === Guest98545 is now known as markh [01:47] igc: <3 [01:53] Could someone explain to me how to modify the email address that is used by bzr? It shows up as username@host (where username is my current username and host is the host of my computer). [01:53] bzr help whoami [01:54] Thanks cody-somerville, that did it [02:06] any idea what's wrong here? when I try to init-repo the central repository I get this error "bzr: ERROR: No such file: '/dir': [Errno 2] No such file" (using sftp) [02:08] tufloc: what was the command line ? [02:08] bzr init-repo --no-trees sftp://dir [02:11] spiv: ping; any idea what would trigger InvalidURL: Invalid url supplied to transport: "2e/%2554%2552%2545%2545_%2552%254f%254f%2554.kndx" [02:11] only happening on remote tests. .. [02:11] oh; punicode [02:12] jam: ping [02:13] mwhudson, nevermind [02:14] tufloc: you want sftp://host/absolute_path [02:14] yeah [02:14] tufloc: or sftp://host/~/homedirpath [02:45] ok, fetch.py converted [02:46] well, nearly [02:56] lifeless: wrt the Development1 format, currently it says "(needs bzr.dev from before 1.3)" and ... [02:56] "This format should be retained until the second release after bzr 1.2." [02:56] What do you want those strings to say now? [02:56] the idea is they roll [02:57] so if this lands in 1.6 it will say from 1.6 [02:57] (from before 1.6) [02:57] and retain until 1.6 + 2? [02:58] 1.5 + 2 [02:58] so we delete it after 1.7 is released [02:58] ok [02:59] this gives users of a dev format 2 development cycles to toy with it [02:59] lifeless: so what's the relationship between development1 and BzrBranch7 if any? [02:59] development1 incorporates BzrBranch7 [03:00] as well as the new pack format [03:00] does dev1 support rich roots atm? [03:00] is development1 needed for stacked branches to land (sorry if that's a dumb Q)? [03:00] dev1 *is* stacked branches [03:00] ok [03:01] I wasn't sure if one was a copy of the other or dependent on the other [03:01] so: [03:01] (yet to look at the code in dpeth) [03:01] development is an alias to the tip of the dev series [03:01] dev1 is the first dev format to support stacking [03:01] dev refers to branch7 and packs-that-stack [03:01] sorry, last line should read dev1 refers .... [03:02] bob2: no it doesn't - we do need to stack on existing non rich root repos [03:02] development-rich-root however should (I think I skipped that for development-subtree, this should likely be fixed) [03:03] ah, right - just hanging out for the unification ;) [03:03] there won't be a unification, but there will be a pivot on the default [03:04] I'm looking at getting --stat working as an option to bzr log, but can't find an obvious way to hook it in [03:05] That is, without copying and pasting the code from cmd_log, which doesn't strike me as being at all clever :) [03:06] pickscrape: you may well need to change log to be more hookable [03:07] What I really need is a hook that is called after each log entry, which passes the revision and/or tree that can be worked with [03:07] lifeless: so I'd need to hack on bzr itself and send to the mailing list etc? [03:08] It jsut occurred to me that such a hook would allow glog -p (patch) to be implemented as a plugin also. [03:08] s/glog/log/ [03:12] lifeless: hmm [03:12] http://mail.python.org/pipermail/python-dev/2004-July/046416.html [03:12] is enough for me [03:12] lifeless: I don't recall off the top of my head [03:12] I don't know if 'sorted()' has the same guarantee, but I happen to have a list [03:12] lifeless: it would, yeah [03:12] would or does :P [03:13] I would be shocked if sorted() was not stable but list.sort() was. [03:13] given the impact is more than your shock :) [03:13] I will use list.sort [03:14] * spiv nods [03:14] also pydoc sorted blows [03:14] pydoc blows. [03:15] file:///usr/share/doc/python2.5/html/lib/built-in-funcs.html#l2h-68 is where it's at. [03:15] (although even that doesn't mention stability) [03:16] yah, thus my not depending on it [03:16] pydoc has the potential to be extremely useful, it is saddening that it is not [03:16] Sure. [03:16] lifeless: how would you recommend making cmd_log more hookable? Using a mechanism like post_push etc or something more raw like an overridable method of cmd_log? [03:17] pickscrape: well, I think the general concept here is that log -v, log --diff, log --stat all need the same minimum data: a tree delta [03:18] pickscrape: so I'd think of it as selecting which filter to pass tree deltass through during log [03:18] pickscrape: -> a registry of filters, and the core code calls into that [03:18] lifeless: Bearing in mind that the user might be asking for more than one filter at the same time. [03:19] Could quite legitimately want to do bzr log -p --stat [03:19] pickscrape: sure. may need some infrastructure work to allow selecting multiple items from a registry [03:20] The existing formats could also be rewritten as filters in this registry too. [03:20] pickscrape: the ones that do tree deltas yes - thats exactly what I'm suggesting [03:20] --line vs the default is already registry based [03:21] they select what revisions are shown and ordering; somewhat different part of the code path for log [03:22] I'll have a think about that then. It certainly seems that log --stat is impossible without it. [03:32] Just curious, what benefits does rich-root have over pack-0.92? [03:32] Or rich-root-pack (what's the difference with rich-root?) [03:33] kumi_: this format puts a unique id on the root directory, so it can be used with versioned subtrees (like svn externals) and split/join- [03:34] * kumi_ looks up svn externals [03:35] basically so that you can link an external library into a subdirectory of your project [03:38] Nice. I can think of several places where that would be useful to me [03:41] * igc lunch [03:41] abentley: around? [03:41] lifeless: Hi. [03:42] I have a question about rich root root id generation during fetch [03:42] hey all, quick question, is there a way to edit a file in a past revision, like say if you accidentally committed a hard-coded password in your code =P [03:42] lifeless: Okay. [03:42] the parents list for the new root text is the revisions parent list - revisions with different root ids, and including ghosts [03:43] did you consider looking up the root id in the revision tree of revisions with different roots, to find root-renames done in those trees? [03:43] That doesn't sound like a good idea. [03:43] which line are you replying to :) [03:43] The first. [03:44] I wasn't considering root ids changing. [03:44] the first was a paraphrase of the comment in the existing code [03:44] Oh, well maybe I was. I don't remember that... [03:44] fetch.py line 390 in bzr.dev [03:45] Is it possible to try rich-root in version 1.5? [03:45] anyhow, It seems to me that running reconcile after generating these texts could find mismatched parents with the current code, because it does look at the full inventory of each tree [03:45] lifeless: That says we *drop* parents with different file_ids. [03:45] abentley: yes, I meant drop with my use of '-', sorry for confusion [03:46] revisions_parent_list.subtract(changed_ids) [03:46] lifeless: It looked like a dash to me. [03:46] kumi_: it is, there are some caveats: its a one way conversion [03:46] kumi_: we plan to make it the default soon [03:46] I think I'll wait, thanks lifeless [03:47] abentley: ok, with the confusion sorted, the next line was my actual question: did you consider looking for that id elsewhere in the other tree [03:47] btw I fixed that windows problem you helped with yesterday. thanks again [03:47] kumi_: excellent [03:47] kumi_: I saw the comment in the bug; I wonder if we can make the error nicer/more clear [03:47] lifeless: I don't think I did. [03:48] lifeless: yes, if it mentioned where the error came from "plink.exe", that would be enough [03:48] abentley: ok. I'm not going to change this code, I just wondered while looking. Could you think about it at some point? [03:48] abentley: (well, I have to rephrase the code to new apis,but I'm not changing the intent of the code) [03:49] Sure. [03:49] What I was aiming for was a conversion that was reasonably hi-fi, but definitely with good performance. [03:50] And definitely reproduceable. [03:51] right, which we have. It seems a shame if (and I think it does) reconcile and check were to find things to do post-conversion ;). [03:53] lifeless: Not a tragedy, though, since only experimental versions of Bazaar could get into that situation. [03:55] abentley: couldn't converters ? e.g. arch could have an id be root one commit elsewhere another in theory [03:55] I don't think converters touched root ids. [03:56] Not until bzr-svn went dirstate-with-subtree on us. [03:56] mmm, I'd need to check [03:56] anyhow, I'm not fussed, you know the implications at least as well as I do [03:57] 19 references to weave_store in bzrlib/*.py to go [03:57] argh! [03:57] weave_modifed_revisions = set(file_weave.versions()) [03:57] all-of-history calls die die die [04:21] lifeless: we need something stronger than -Devil i think [04:21] cutely name though it is [04:21] poolie: what d you mean by stronger? [04:26] -Dsatanic [04:30] -Dponies [04:30] but we have one [04:33] lifeless: i mean one that's harder to ignore [04:34] poolie: e.g. output to console not just log? [04:35] i guess the only thing is to actually fix them then make them fail the tests [04:38] I think thats the only workable approach [04:38] some O(history) operations are necessary [04:38] I really should tackle log at some point [04:38] but I want to cry when I see the code [04:49] log.py needs a lot of love [04:49] (also, revision numbering) [04:50] +1 to revision numbering :) [04:58] users seem to really like it [04:58] lifeless: is there a reason why add_falback_repository in repository.py checks for format compatibility but ... [04:58] the one is remote.py does not? [04:58] igc: yes [04:59] and it is ...? [05:00] its only a proxy object [05:00] poolie: I just want to make sure you are aware of the bzr client side stacking policy stuff that abentley has and its need to be in 1.6 with the other stacking stuff. [05:00] or perhaps its oversight. But I think that was my thinking in february [05:24] thumper: your alias patch is merged to bzr.dev now [05:24] igc: w00t [05:40] pqm seems much faster today. Thanks to whomever enabled the 'go-fast' option. [05:46] * igc pick up kids [05:57] abentley: I plan to add a file_id parameter to PlanMerge, does that seem ok? (vf is now a VersionedFiles so we need a prefix [05:59] Hmm, I have an error when I try bzr st: KeyError: 'pop(): dictionary is empty' [06:00] kumi_: there was a bug in merge, it is fixed in mainline I believe [06:00] kumi_: you have just done a merge haven't you ? [06:00] oh dear [06:00] yeah I just did [06:00] just revert [06:00] Alrighty [06:00] Is there any way to get around this? [06:01] well, you probably did merge and then merge --force? [06:01] Nope, just bzr merge -c 161 [06:02] lifeless: That makes sense. [06:02] kumi_: its probably already merged; I think grabbing the latest bzr.dev may be the most straight forward solution [06:02] lifeless: At some point, if we're brave, we might allow multiple file ids :-) [06:02] abentley: I'm trying to balance scope creep, and updating apis towards that as I go [06:02] but yeah :) [06:03] lifeless: unfortunately I can't do that (on Windows and I don't know how to compile) [06:03] kumi_: oh, there is no need to compile [06:03] kumi_: if you have python already installed you can just branch bzr and run it; if you don't then its more tricky. Do you have python installed ? [06:03] Yeah, I have Python 2.5 [06:04] then bzr branch http://bazaar-vcs.org/bzr/bzr.dev [06:04] I think there is a bzr.bat included in there by default [06:04] Cheers, I'll try that [06:05] is bzr.dev usually in a stable state? [06:05] if there isn't say so and I'll help you [06:05] we run all our regression tests before every merge - we try to keep it immediately releasable [06:05] nice :) [06:06] (except for occasional massive feature drops, they tend to cause issues no matter how hard we try - but even then its still passing tests) [06:12] Out of curiosity, is there a way to branch the point releases? [06:12] I think there are tags, there are also separate branches for each release [06:12] gotcha [06:25] I branched bzr.dev and I put it in a directory away from my 1.5.0 files. If I run C:\bin\Python25\python.exe G:\temp\bzrdev\bzr version, it's not using it's own path for bzrlib [06:27] I will try the start_bzr.bat that is in bzr.dev (have to modify it because it uses bzr.exe) [06:28] abentley: hitchhiker is very cool [06:28] poolie: thanks. [06:28] * jml was thinking the same thing. [06:29] poolie: I deliberately left out write commands for now. [06:29] I [06:29] I'm not sure any good would come of that. [06:30] Where is the BZR_HOME environmental variable supposed to point to? [06:30] kumi_: normally it's unset and HOME is used [06:30] kumi_: generally you don't want to set it [06:30] the location of bzr, tools, doc, contrib, etc? Or the location where bazaar.conf etc are located? [06:31] OK [06:32] kumi_: if it's not set it defaults to ~/.bazaar on unix [06:32] not sure where on Windows but bzr --version should show it [06:33] That's why I asked, it doesn't explicity mention "home" [06:33] only "Bazaar configuration" and "Bazaar log file" directories. All looks fine, though [06:34] i think it's the first [06:35] poolie: It looks like it defaults to ~/ on unix [06:35] me too [06:41] On Windows, if you set BZR_HOME to c:\foo, it will put configuration files in c:\foo\bazaar\2.0, and the log file in c:\foo\.bzr.log [06:50] hitchhiker? [06:52] lifeless: a text-mode client for bzr transports [06:52] lftpesque? [06:54] yes [07:00] lifeless: it worked! Thanks a million [07:01] kumi_: cool === BasicTheProgram is now known as Basic [07:09] hm, automirror doesn't seem to work when a revision is pushed [07:13] igc: you have removed the use of chain, but kept the import :P === gour is now known as gour|afk [07:26] lifeless: o damn - I'll fix that [07:27] lifeless: any further thoughts on that RemoteRepository check of fallback issue? [07:27] no [07:28] I'm just wrapping up my review of the Development1 thread and the rest is ok I think [07:29] I don't think we want to merge the formats just yet, because they are so limited [07:29] but perhaps I'm wrong [07:30] as in the development1 formats? [07:31] yes. [07:31] lets start at the bottom and work up [07:31] get them fully ready to merge at minimum [07:32] lifeless: so some quick Qs if you have time [07:33] the new init method in BzrBranch6? [07:34] it's saving development1... as the metadir [07:34] * igc pulls up the diff [07:35] def __init__(self): [07:35] super(BzrBranchFormat6, self).__init__() [07:35] self._matchingbzrdir.repository_format = \ [07:35] RepositoryFormatPackDevelopment1Subtree() [07:36] yes [07:36] thats for testing [07:36] lifeless: any side-effects from that? [07:36] yes, tests run with old branches, new repositories. Its good :) [07:37] i'm trying to page back in the countedlock refactoring [07:37] which is meant to eventually help Remote objects stay in sync with their vfs objects [07:37] want to finish it off anyhow [07:38] lifeless: and is all_revision_ids() still meant to return a list? Or just a sequence now? [07:39] * igc wondering why check.py needed the list() added around all_revision_ids() [07:39] igc: well, if you remove it and it fails, it needs it ;P [07:39] some tests were updated to put set() around things which is fine of course [07:41] lifeless: the code change is harmless enough but I'll update the al_revision_ids docstring if it's no longer correct [07:41] what does it claim ? [07:41] I guess it would need to be added to API CHANGES/BREAKS as well if it no longer aways returns a list [07:41] "Returns a list ..." [07:42] yeah thats false now, lists are very slow at duplicate detection [07:43] ok - I'll tweak that docstring [07:43] and update NEWS [07:48] poolie, spiv: is one of you able to review the external_references tests patch please? [07:49] igc: I can review your changes if they are busy [07:49] lifeless: in this case, they had already reviewed that code [07:50] igc: ah, k [07:50] i can [07:50] poolie: thanks. you had voted tweak earlier though it may need some more given spiv's comments [07:50] it's a good time, i just worked out what patch i want to do but haven't started [07:50] is this [07:51] igc hm the only patch about that i see was in february [07:51] ok i see it [07:51] http://bundlebuggy.aaronbentley.com/request/<48474354.1040103@canonical.com> right? [07:51] poolie: https://lists.ubuntu.com/archives/bazaar/2008q1/037703.html is the earlier thread [07:51] poolie: that's the one [07:53] +from bzrlib.tests import ( [07:53] + adapt_modules, [07:54] not a big deal but can you make them just indented by 4 spaces in future, as the others are [07:54] (might not even be your code) [07:56] I think the rest of the others were deep [07:56] or something [08:02] i wish the boilerplate in load_tests wasn't proliferating the way it is [08:09] igc, sent [08:17] poolie: thanks [08:18] lifeless: please let me know if you have any comments on poolie's requested tweaks [08:20] so, they seem fine [08:20] the scenario tuple is name, dict_of_things [08:20] lifeless: and vila has voted resubmit [08:20] i'll reply to vincent [08:20] the multiply_ method is different, I did look at reusing but its at the wrong level [08:21] - it does too much [08:22] poolie: thanks. Did you mind submitting this to pqm as well, once tweaks are agreed? [08:25] vila: ping; please look at bzrlib/tests/*_implementations/__init__.py [08:27] lifeless: regarding adapt_modules ? or regarding defining adapter classes ? [08:27] regarding the need [08:28] to adapt many modules identically [08:28] (we do it *all the time*) [08:28] I'm fine with using adpat_modules, I'm not with gettind rid of adapter classes [08:29] vila: I want to nuke them all [08:29] the adpater classes ? [08:29] yes, there should only be one [08:29] application and generation of scenarios are different responsibilities [08:30] this became clear some time after first creating the ability to adapt at all [08:30] tests.TestScenarioApplier is meant to be used as an instance, not subclassed; its subclassable for historic reasons onl [08:30] y [08:31] hence my tendency to call the classes adapters not appliers :) [08:31] its fine to have a class for generating scenarios that you reuse and extend, but it shouldn't subclass the applier [08:32] instead have it provide the scenarios and use them with a stock applier [08:33] lifeless: I never thought about it but I fully agree, just apply that sentence to my comments [08:33] ..with the stock applier of course ;) [08:33] (which it uses :P) [08:34] so adap_tests and adapt_modules will become methods ? Sounds coherent. [08:35] errr [08:35] I'm scrambled now [08:36] this is 4 month old code and I'm deep updating merge [08:36] can I come back to this? [08:38] hello vila [08:38] hi poolie ;) [08:39] i sent mail wihch i think robert will agree with [08:39] bit i can never tell [08:39] oh the scrollback does make it look like he would agree [08:39] thats why there is you, and me, vive la difference! [08:39] but* [08:43] vila, i may be missing the point somehow === gour|afk is now known as gour [08:50] poolie: well, I'm waiting for your mail, but seeing Robert comments, I think I need to re-read the code with the idea of separating scenario generation and application, I'm deep into other subjects right now. I remember being uneasy with the adap_test and adpat_modules functions but not *why* I thought subclassing applier was the best solution [08:51] I remember it vastly simplified the http tests where many combinations were required between transport implementation/proxy/auth schemes with tests needing various combinations [08:51] but may be that's specific to http [08:54] vila: I think you would find the repository_check_reconcile permutations enlightening [08:55] they do a cross product test permutation [08:56] nearly done [08:56] 17 references to go outside of tests [08:57] * jml always wants to say "cartesian product" not "cross product". [08:57] fine [08:57] but I guess the latter makes sense. [08:58] * vila always translate 'cross product' into 'produit cartesien' ;-) [08:58] heh heh [08:58] Not to be confused with the _actual_ operation 'cross product' :) [08:59] * vila also has no trouble translating applier into 'adapteur' hence he missed lifeless point ;) [09:00] lifeless: url ? grep repository_check_reconcile bzr.dev gives no matches :) [09:01] :) [09:02] test_check_reconcile.py [09:02] and __init__.py [09:02] in repository_implementations package [09:02] back soon -> atm [09:02] poolie: ringing you for brief chat [09:03] jml, hm, Cartesian product seems more correct [09:04] poolie: especially since the ordering doesn't matter, since they are unit tests. [09:04] lifeless: ready whenever [09:05] iirc, cross product makes sense if you define multiplication as 'cons' [09:08] Ah, I just accidentally found the bug in the test suite that allowed bug 237067 to happen. [09:08] Launchpad bug 237067 in bzr ""bzr check" on bzr+ssh:// branch returns ObjectNotLocked error" [Undecided,New] https://launchpad.net/bugs/237067 [09:13] spiv, good for you [09:16] mobiles work better with battery power [09:26] * igc dinner [09:31] lifeless: class RepositoryTestProviderAdapter(TestScenarioApplier): explains my confusion I would say :) Or are you referring to a newer, yet unknown to me, implementation ? [09:31] lifeless: hmm, no, I think you meant: broken_scenario_applier = TestScenarioApplier() [09:31] broken_scenario_applier.scenarios = broken_scenarios_for_all_formats [09:31] which better illustrates your point [09:35] poolie, igc, lifeless: I just realized I did class ServerAdapter(tests.TestScenarioApplier): in my local_test_server plugin just to define a dict :-) === yacc__ is now known as yacc [09:47] vila: yes :) [09:47] vila: this is the point really [09:47] also [09:47] crying tiger++ [09:49] lifeless: consider me enlightened then :) But not for the tiger though... [09:49] its thai food [10:27] It's the new filem "Crying Tiger, Sulking Dragon" [10:30] Hi, I get the following when installing bzr on ubuntu-hardy [10:30] http://pastebin.com/m76595733 [10:30] is this a known problem ? [10:32] I don't think scrollkeeper is related to bzr. [10:33] oops [10:33] proppy: please report a bug against scrollkeeper [10:33] poolie: thanks for the direction :) [10:34] poolie: https://edge.launchpad.net/scrollkeeper/+filebug ? [10:34] or scrollkeeper package in ubuntu ? [10:35] https://bugs.edge.launchpad.net/ubuntu/+source/scrollkeeper/+filebug [10:35] the second is better but either will do [10:41] poolie: reported https://bugs.edge.launchpad.net/ubuntu/+source/scrollkeeper/+bug/237579 [10:41] Launchpad bug 237579 in scrollkeeper "/usr/bin/scrollkeeper-update: corrupted double-linked list on apt-get install bzr" [Undecided,New] [11:21] is this the #bzr branch ? :) [11:22] ok, serious question: does bzr support aliases for locations ? [11:22] strk: there is a bzr bookmark plugin you might want to try [11:22] Ooh, you were just barely too fast for me. [11:22] https://edge.launchpad.net/bzr-bookmarks [11:23] https://launchpad.net/bzr-bookmarks [11:23] anyone know how to update partial (like only doc directory) in a checkout? [11:24] I wanna update part of working tree, not full of them. [11:24] nasloc__: I don't think you can do that. [11:24] nasloc__: You can revert only parts of a tree, but that doesn't help if you want to update to a new revision.. [11:25] Peng, oh :( because svn can do that and my partner says he would use bzr over svn if bzr supports that. [11:26] Peng, thanks anyway. [11:26] nasloc__: With Bazaar, you'd finish your work and commit, then merge new changes. Not sure how that translates to checkouts though.. [11:27] nasloc__: you can always use multiple branches [11:27]