| === mark2 is now known as Guest98545 | ||
| mpt | jam, success! | 00:07 |
|---|---|---|
| jam | mpt: so does bzr check on your original branch work? | 00:10 |
| poolie | lifeless: can you join us if you're still around? | 00:12 |
| mpt | jam, I'll get back to you on that, it's checking revision 117/38124 :-) | 00:12 |
| jam | mpt: if it didn't fail right away, that is, indeed a good sign | 00:12 |
| mpt | jam, however, "bzr log" gives me a KeyError in a different branch | 00:12 |
| jam | mpt: well, then you need to do the 'bzr branch' with *that* revision, too :) | 00:13 |
| mpt | woohoo | 00:13 |
| mpt | ok | 00:13 |
| mpt | this could be a long night | 00:14 |
| mpt | thanks for your continued help jam | 00:15 |
| jam | mpt: I'll be off in a bit, but you can poke at spiv or igc I think | 00:16 |
| mpt | ok | 00:16 |
| pickscrape | Well, I've got bzr diff --stat working | 00:21 |
| tufloc | is there a way to enable user authentication for the dedicated bzr server? | 00:27 |
| mneptok | tufloc: serve the branch over ssh/sftp | 00:45 |
| tufloc | I'm starting to miss svn | 00:47 |
| tufloc | the dedicated server doesn't allow write operations? | 01:01 |
| mwhudson | it can do | 01:03 |
| bob2 | pickscrape: yay | 01:05 |
| === Guest98545 is now known as markh | ||
| jml | igc: <3 | 01:47 |
| nhandler | 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 |
| cody-somerville | bzr help whoami | 01:53 |
| nhandler | Thanks cody-somerville, that did it | 01:54 |
| tufloc | 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:06 |
| mwhudson | tufloc: what was the command line ? | 02:08 |
| tufloc | bzr init-repo --no-trees sftp://dir | 02:08 |
| lifeless | 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 |
| lifeless | only happening on remote tests. .. | 02:11 |
| lifeless | oh; punicode | 02:11 |
| lifeless | jam: ping | 02:12 |
| tufloc | mwhudson, nevermind | 02:13 |
| lifeless | tufloc: you want sftp://host/absolute_path | 02:14 |
| tufloc | yeah | 02:14 |
| lifeless | tufloc: or sftp://host/~/homedirpath | 02:14 |
| lifeless | ok, fetch.py converted | 02:45 |
| lifeless | well, nearly | 02:46 |
| igc | lifeless: wrt the Development1 format, currently it says "(needs bzr.dev from before 1.3)" and ... | 02:56 |
| igc | "This format should be retained until the second release after bzr 1.2." | 02:56 |
| igc | What do you want those strings to say now? | 02:56 |
| lifeless | the idea is they roll | 02:56 |
| lifeless | so if this lands in 1.6 it will say from 1.6 | 02:57 |
| lifeless | (from before 1.6) | 02:57 |
| igc | and retain until 1.6 + 2? | 02:57 |
| lifeless | 1.5 + 2 | 02:58 |
| lifeless | so we delete it after 1.7 is released | 02:58 |
| igc | ok | 02:58 |
| lifeless | this gives users of a dev format 2 development cycles to toy with it | 02:59 |
| igc | lifeless: so what's the relationship between development1 and BzrBranch7 if any? | 02:59 |
| lifeless | development1 incorporates BzrBranch7 | 02:59 |
| lifeless | as well as the new pack format | 03:00 |
| bob2 | does dev1 support rich roots atm? | 03:00 |
| igc | is development1 needed for stacked branches to land (sorry if that's a dumb Q)? | 03:00 |
| lifeless | dev1 *is* stacked branches | 03:00 |
| igc | ok | 03:00 |
| igc | I wasn't sure if one was a copy of the other or dependent on the other | 03:01 |
| lifeless | so: | 03:01 |
| igc | (yet to look at the code in dpeth) | 03:01 |
| lifeless | development is an alias to the tip of the dev series | 03:01 |
| lifeless | dev1 is the first dev format to support stacking | 03:01 |
| lifeless | dev refers to branch7 and packs-that-stack | 03:01 |
| lifeless | sorry, last line should read dev1 refers .... | 03:01 |
| lifeless | bob2: no it doesn't - we do need to stack on existing non rich root repos | 03:02 |
| lifeless | development-rich-root however should (I think I skipped that for development-subtree, this should likely be fixed) | 03:02 |
| bob2 | ah, right - just hanging out for the unification ;) | 03:03 |
| lifeless | there won't be a unification, but there will be a pivot on the default | 03:03 |
| pickscrape | 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:04 |
| pickscrape | That is, without copying and pasting the code from cmd_log, which doesn't strike me as being at all clever :) | 03:05 |
| lifeless | pickscrape: you may well need to change log to be more hookable | 03:06 |
| pickscrape | 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 |
| pickscrape | lifeless: so I'd need to hack on bzr itself and send to the mailing list etc? | 03:07 |
| pickscrape | It jsut occurred to me that such a hook would allow glog -p (patch) to be implemented as a plugin also. | 03:08 |
| pickscrape | s/glog/log/ | 03:08 |
| spiv | lifeless: hmm | 03:12 |
| lifeless | http://mail.python.org/pipermail/python-dev/2004-July/046416.html | 03:12 |
| lifeless | is enough for me | 03:12 |
| spiv | lifeless: I don't recall off the top of my head | 03:12 |
| lifeless | I don't know if 'sorted()' has the same guarantee, but I happen to have a list | 03:12 |
| spiv | lifeless: it would, yeah | 03:12 |
| lifeless | would or does :P | 03:12 |
| spiv | I would be shocked if sorted() was not stable but list.sort() was. | 03:13 |
| lifeless | given the impact is more than your shock :) | 03:13 |
| lifeless | I will use list.sort | 03:13 |
| * spiv nods | 03:14 | |
| lifeless | also pydoc sorted blows | 03:14 |
| spiv | pydoc blows. | 03:14 |
| spiv | file:///usr/share/doc/python2.5/html/lib/built-in-funcs.html#l2h-68 is where it's at. | 03:15 |
| spiv | (although even that doesn't mention stability) | 03:15 |
| lifeless | yah, thus my not depending on it | 03:16 |
| lifeless | pydoc has the potential to be extremely useful, it is saddening that it is not | 03:16 |
| spiv | Sure. | 03:16 |
| pickscrape | 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:16 |
| lifeless | 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:17 |
| lifeless | pickscrape: so I'd think of it as selecting which filter to pass tree deltass through during log | 03:18 |
| lifeless | pickscrape: -> a registry of filters, and the core code calls into that | 03:18 |
| pickscrape | lifeless: Bearing in mind that the user might be asking for more than one filter at the same time. | 03:18 |
| pickscrape | Could quite legitimately want to do bzr log -p --stat | 03:19 |
| lifeless | pickscrape: sure. may need some infrastructure work to allow selecting multiple items from a registry | 03:19 |
| pickscrape | The existing formats could also be rewritten as filters in this registry too. | 03:20 |
| lifeless | pickscrape: the ones that do tree deltas yes - thats exactly what I'm suggesting | 03:20 |
| lifeless | --line vs the default is already registry based | 03:20 |
| lifeless | they select what revisions are shown and ordering; somewhat different part of the code path for log | 03:21 |
| pickscrape | I'll have a think about that then. It certainly seems that log --stat is impossible without it. | 03:22 |
| kumi_ | Just curious, what benefits does rich-root have over pack-0.92? | 03:32 |
| kumi_ | Or rich-root-pack (what's the difference with rich-root?) | 03:32 |
| poolie | 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:33 |
| * kumi_ looks up svn externals | 03:34 | |
| poolie | basically so that you can link an external library into a subdirectory of your project | 03:35 |
| kumi_ | Nice. I can think of several places where that would be useful to me | 03:38 |
| * igc lunch | 03:41 | |
| lifeless | abentley: around? | 03:41 |
| abentley | lifeless: Hi. | 03:41 |
| lifeless | I have a question about rich root root id generation during fetch | 03:42 |
| jfro | 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 |
| abentley | lifeless: Okay. | 03:42 |
| lifeless | the parents list for the new root text is the revisions parent list - revisions with different root ids, and including ghosts | 03:42 |
| lifeless | 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 |
| abentley | That doesn't sound like a good idea. | 03:43 |
| lifeless | which line are you replying to :) | 03:43 |
| abentley | The first. | 03:43 |
| abentley | I wasn't considering root ids changing. | 03:44 |
| lifeless | the first was a paraphrase of the comment in the existing code | 03:44 |
| abentley | Oh, well maybe I was. I don't remember that... | 03:44 |
| lifeless | fetch.py line 390 in bzr.dev | 03:44 |
| kumi_ | Is it possible to try rich-root in version 1.5? | 03:45 |
| lifeless | 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 |
| abentley | lifeless: That says we *drop* parents with different file_ids. | 03:45 |
| lifeless | abentley: yes, I meant drop with my use of '-', sorry for confusion | 03:45 |
| lifeless | revisions_parent_list.subtract(changed_ids) | 03:46 |
| abentley | lifeless: It looked like a dash to me. | 03:46 |
| lifeless | kumi_: it is, there are some caveats: its a one way conversion | 03:46 |
| lifeless | kumi_: we plan to make it the default soon | 03:46 |
| kumi_ | I think I'll wait, thanks lifeless | 03:46 |
| lifeless | 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 |
| kumi_ | btw I fixed that windows problem you helped with yesterday. thanks again | 03:47 |
| lifeless | kumi_: excellent | 03:47 |
| lifeless | kumi_: I saw the comment in the bug; I wonder if we can make the error nicer/more clear | 03:47 |
| abentley | lifeless: I don't think I did. | 03:47 |
| kumi_ | lifeless: yes, if it mentioned where the error came from "plink.exe", that would be enough | 03:48 |
| lifeless | 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 |
| lifeless | abentley: (well, I have to rephrase the code to new apis,but I'm not changing the intent of the code) | 03:48 |
| abentley | Sure. | 03:49 |
| abentley | What I was aiming for was a conversion that was reasonably hi-fi, but definitely with good performance. | 03:49 |
| abentley | And definitely reproduceable. | 03:50 |
| lifeless | 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:51 |
| abentley | lifeless: Not a tragedy, though, since only experimental versions of Bazaar could get into that situation. | 03:53 |
| lifeless | abentley: couldn't converters ? e.g. arch could have an id be root one commit elsewhere another in theory | 03:55 |
| abentley | I don't think converters touched root ids. | 03:55 |
| abentley | Not until bzr-svn went dirstate-with-subtree on us. | 03:56 |
| lifeless | mmm, I'd need to check | 03:56 |
| lifeless | anyhow, I'm not fussed, you know the implications at least as well as I do | 03:56 |
| lifeless | 19 references to weave_store in bzrlib/*.py to go | 03:57 |
| lifeless | argh! | 03:57 |
| lifeless | weave_modifed_revisions = set(file_weave.versions()) | 03:57 |
| lifeless | all-of-history calls die die die | 03:57 |
| poolie | lifeless: we need something stronger than -Devil i think | 04:21 |
| poolie | cutely name though it is | 04:21 |
| lifeless | poolie: what d you mean by stronger? | 04:21 |
| pickscrape | -Dsatanic | 04:26 |
| jamesh | -Dponies | 04:30 |
| lifeless | but we have one | 04:30 |
| poolie | lifeless: i mean one that's harder to ignore | 04:33 |
| lifeless | poolie: e.g. output to console not just log? | 04:34 |
| poolie | i guess the only thing is to actually fix them then make them fail the tests | 04:35 |
| lifeless | I think thats the only workable approach | 04:38 |
| lifeless | some O(history) operations are necessary | 04:38 |
| lifeless | I really should tackle log at some point | 04:38 |
| lifeless | but I want to cry when I see the code | 04:38 |
| mwhudson | log.py needs a lot of love | 04:49 |
| mwhudson | (also, revision numbering) | 04:49 |
| beuno | +1 to revision numbering :) | 04:50 |
| lifeless | users seem to really like it | 04:58 |
| igc | lifeless: is there a reason why add_falback_repository in repository.py checks for format compatibility but ... | 04:58 |
| igc | the one is remote.py does not? | 04:58 |
| lifeless | igc: yes | 04:58 |
| igc | and it is ...? | 04:59 |
| lifeless | its only a proxy object | 05:00 |
| thumper | 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 |
| lifeless | or perhaps its oversight. But I think that was my thinking in february | 05:00 |
| igc | thumper: your alias patch is merged to bzr.dev now | 05:24 |
| thumper | igc: w00t | 05:24 |
| igc | pqm seems much faster today. Thanks to whomever enabled the 'go-fast' option. | 05:40 |
| * igc pick up kids | 05:46 | |
| lifeless | 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:57 |
| kumi_ | Hmm, I have an error when I try bzr st: KeyError: 'pop(): dictionary is empty' | 05:59 |
| lifeless | kumi_: there was a bug in merge, it is fixed in mainline I believe | 06:00 |
| lifeless | kumi_: you have just done a merge haven't you ? | 06:00 |
| kumi_ | oh dear | 06:00 |
| kumi_ | yeah I just did | 06:00 |
| lifeless | just revert | 06:00 |
| kumi_ | Alrighty | 06:00 |
| kumi_ | Is there any way to get around this? | 06:00 |
| lifeless | well, you probably did merge and then merge --force? | 06:01 |
| kumi_ | Nope, just bzr merge -c 161 | 06:01 |
| abentley | lifeless: That makes sense. | 06:02 |
| lifeless | kumi_: its probably already merged; I think grabbing the latest bzr.dev may be the most straight forward solution | 06:02 |
| abentley | lifeless: At some point, if we're brave, we might allow multiple file ids :-) | 06:02 |
| lifeless | abentley: I'm trying to balance scope creep, and updating apis towards that as I go | 06:02 |
| lifeless | but yeah :) | 06:02 |
| kumi_ | lifeless: unfortunately I can't do that (on Windows and I don't know how to compile) | 06:03 |
| lifeless | kumi_: oh, there is no need to compile | 06:03 |
| lifeless | 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 |
| kumi_ | Yeah, I have Python 2.5 | 06:03 |
| lifeless | then bzr branch http://bazaar-vcs.org/bzr/bzr.dev <some-path-here> | 06:04 |
| lifeless | I think there is a bzr.bat included in there by default | 06:04 |
| kumi_ | Cheers, I'll try that | 06:04 |
| kumi_ | is bzr.dev usually in a stable state? | 06:05 |
| lifeless | if there isn't say so and I'll help you | 06:05 |
| lifeless | we run all our regression tests before every merge - we try to keep it immediately releasable | 06:05 |
| kumi_ | nice :) | 06:05 |
| lifeless | (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:06 |
| kumi_ | Out of curiosity, is there a way to branch the point releases? | 06:12 |
| lifeless | I think there are tags, there are also separate branches for each release | 06:12 |
| kumi_ | gotcha | 06:12 |
| kumi_ | 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:25 |
| kumi_ | I will try the start_bzr.bat that is in bzr.dev (have to modify it because it uses bzr.exe) | 06:27 |
| poolie | abentley: hitchhiker is very cool | 06:28 |
| abentley | poolie: thanks. | 06:28 |
| * jml was thinking the same thing. | 06:28 | |
| abentley | poolie: I deliberately left out write commands for now. | 06:29 |
| abentley | I | 06:29 |
| abentley | I'm not sure any good would come of that. | 06:29 |
| kumi_ | Where is the BZR_HOME environmental variable supposed to point to? | 06:30 |
| bob2 | kumi_: normally it's unset and HOME is used | 06:30 |
| spiv | kumi_: generally you don't want to set it | 06:30 |
| kumi_ | the location of bzr, tools, doc, contrib, etc? Or the location where bazaar.conf etc are located? | 06:30 |
| kumi_ | OK | 06:31 |
| poolie | kumi_: if it's not set it defaults to ~/.bazaar on unix | 06:32 |
| poolie | not sure where on Windows but bzr --version should show it | 06:32 |
| kumi_ | That's why I asked, it doesn't explicity mention "home" | 06:33 |
| kumi_ | only "Bazaar configuration" and "Bazaar log file" directories. All looks fine, though | 06:33 |
| poolie | i think it's the first | 06:34 |
| abentley | poolie: It looks like it defaults to ~/ on unix | 06:35 |
| kumi_ | me too | 06:35 |
| kumi_ | 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:41 |
| lifeless | hitchhiker? | 06:50 |
| poolie | lifeless: a text-mode client for bzr transports | 06:52 |
| lifeless | lftpesque? | 06:52 |
| poolie | yes | 06:54 |
| kumi_ | lifeless: it worked! Thanks a million | 07:00 |
| lifeless | kumi_: cool | 07:01 |
| === BasicTheProgram is now known as Basic | ||
| kumi_ | hm, automirror doesn't seem to work when a revision is pushed | 07:09 |
| lifeless | igc: you have removed the use of chain, but kept the import :P | 07:13 |
| === gour is now known as gour|afk | ||
| igc | lifeless: o damn - I'll fix that | 07:26 |
| igc | lifeless: any further thoughts on that RemoteRepository check of fallback issue? | 07:27 |
| lifeless | no | 07:27 |
| igc | I'm just wrapping up my review of the Development1 thread and the rest is ok I think | 07:28 |
| lifeless | I don't think we want to merge the formats just yet, because they are so limited | 07:29 |
| lifeless | but perhaps I'm wrong | 07:29 |
| igc | as in the development1 formats? | 07:30 |
| lifeless | yes. | 07:31 |
| lifeless | lets start at the bottom and work up | 07:31 |
| lifeless | get them fully ready to merge at minimum | 07:31 |
| igc | lifeless: so some quick Qs if you have time | 07:32 |
| igc | the new init method in BzrBranch6? | 07:33 |
| igc | it's saving development1... as the metadir | 07:34 |
| * igc pulls up the diff | 07:34 | |
| igc | def __init__(self): | 07:35 |
| igc | super(BzrBranchFormat6, self).__init__() | 07:35 |
| igc | self._matchingbzrdir.repository_format = \ | 07:35 |
| igc | RepositoryFormatPackDevelopment1Subtree() | 07:35 |
| lifeless | yes | 07:36 |
| lifeless | thats for testing | 07:36 |
| igc | lifeless: any side-effects from that? | 07:36 |
| lifeless | yes, tests run with old branches, new repositories. Its good :) | 07:36 |
| poolie | i'm trying to page back in the countedlock refactoring | 07:37 |
| poolie | which is meant to eventually help Remote objects stay in sync with their vfs objects | 07:37 |
| poolie | want to finish it off anyhow | 07:37 |
| igc | lifeless: and is all_revision_ids() still meant to return a list? Or just a sequence now? | 07:38 |
| * igc wondering why check.py needed the list() added around all_revision_ids() | 07:39 | |
| lifeless | igc: well, if you remove it and it fails, it needs it ;P | 07:39 |
| igc | some tests were updated to put set() around things which is fine of course | 07:39 |
| igc | lifeless: the code change is harmless enough but I'll update the al_revision_ids docstring if it's no longer correct | 07:41 |
| lifeless | what does it claim ? | 07:41 |
| igc | I guess it would need to be added to API CHANGES/BREAKS as well if it no longer aways returns a list | 07:41 |
| igc | "Returns a list ..." | 07:41 |
| lifeless | yeah thats false now, lists are very slow at duplicate detection | 07:42 |
| igc | ok - I'll tweak that docstring | 07:43 |
| igc | and update NEWS | 07:43 |
| igc | poolie, spiv: is one of you able to review the external_references tests patch please? | 07:48 |
| lifeless | igc: I can review your changes if they are busy | 07:49 |
| igc | lifeless: in this case, they had already reviewed that code | 07:49 |
| lifeless | igc: ah, k | 07:50 |
| poolie | i can | 07:50 |
| igc | poolie: thanks. you had voted tweak earlier though it may need some more given spiv's comments | 07:50 |
| poolie | it's a good time, i just worked out what patch i want to do but haven't started | 07:50 |
| poolie | is this | 07:50 |
| poolie | igc hm the only patch about that i see was in february | 07:51 |
| poolie | ok i see it | 07:51 |
| poolie | http://bundlebuggy.aaronbentley.com/request/<48474354.1040103@canonical.com> right? | 07:51 |
| igc | poolie: https://lists.ubuntu.com/archives/bazaar/2008q1/037703.html is the earlier thread | 07:51 |
| igc | poolie: that's the one | 07:51 |
| poolie | +from bzrlib.tests import ( | 07:53 |
| poolie | + adapt_modules, | 07:53 |
| poolie | not a big deal but can you make them just indented by 4 spaces in future, as the others are | 07:54 |
| poolie | (might not even be your code) | 07:54 |
| lifeless | I think the rest of the others were deep | 07:56 |
| lifeless | or something | 07:56 |
| poolie | i wish the boilerplate in load_tests wasn't proliferating the way it is | 08:02 |
| poolie | igc, sent | 08:09 |
| igc | poolie: thanks | 08:17 |
| igc | lifeless: please let me know if you have any comments on poolie's requested tweaks | 08:18 |
| lifeless | so, they seem fine | 08:20 |
| lifeless | the scenario tuple is name, dict_of_things | 08:20 |
| igc | lifeless: and vila has voted resubmit | 08:20 |
| poolie | i'll reply to vincent | 08:20 |
| lifeless | the multiply_ method is different, I did look at reusing but its at the wrong level | 08:20 |
| lifeless | - it does too much | 08:21 |
| igc | poolie: thanks. Did you mind submitting this to pqm as well, once tweaks are agreed? | 08:22 |
| lifeless | vila: ping; please look at bzrlib/tests/*_implementations/__init__.py | 08:25 |
| vila | lifeless: regarding adapt_modules ? or regarding defining adapter classes ? | 08:27 |
| lifeless | regarding the need | 08:27 |
| lifeless | to adapt many modules identically | 08:28 |
| lifeless | (we do it *all the time*) | 08:28 |
| vila | I'm fine with using adpat_modules, I'm not with gettind rid of adapter classes | 08:28 |
| lifeless | vila: I want to nuke them all | 08:29 |
| vila | the adpater classes ? | 08:29 |
| lifeless | yes, there should only be one | 08:29 |
| lifeless | application and generation of scenarios are different responsibilities | 08:29 |
| lifeless | this became clear some time after first creating the ability to adapt at all | 08:30 |
| lifeless | tests.TestScenarioApplier is meant to be used as an instance, not subclassed; its subclassable for historic reasons onl | 08:30 |
| lifeless | y | 08:30 |
| vila | hence my tendency to call the classes adapters not appliers :) | 08:31 |
| lifeless | its fine to have a class for generating scenarios that you reuse and extend, but it shouldn't subclass the applier | 08:31 |
| lifeless | instead have it provide the scenarios and use them with a stock applier | 08:32 |
| vila | lifeless: I never thought about it but I fully agree, just apply that sentence to my comments | 08:33 |
| vila | ..with the stock applier of course ;) | 08:33 |
| lifeless | (which it uses :P) | 08:33 |
| vila | so adap_tests and adapt_modules will become methods ? Sounds coherent. | 08:34 |
| lifeless | errr | 08:35 |
| lifeless | I'm scrambled now | 08:35 |
| lifeless | this is 4 month old code and I'm deep updating merge | 08:36 |
| lifeless | can I come back to this? | 08:36 |
| poolie | hello vila | 08:38 |
| vila | hi poolie ;) | 08:38 |
| poolie | i sent mail wihch i think robert will agree with | 08:39 |
| poolie | bit i can never tell | 08:39 |
| poolie | oh the scrollback does make it look like he would agree | 08:39 |
| lifeless | thats why there is you, and me, vive la difference! | 08:39 |
| poolie | but* | 08:39 |
| poolie | vila, i may be missing the point somehow | 08:43 |
| === gour|afk is now known as gour | ||
| vila | 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:50 |
| vila | 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 |
| vila | but may be that's specific to http | 08:51 |
| lifeless | vila: I think you would find the repository_check_reconcile permutations enlightening | 08:54 |
| lifeless | they do a cross product test permutation | 08:55 |
| lifeless | nearly done | 08:56 |
| lifeless | 17 references to go outside of tests | 08:56 |
| * jml always wants to say "cartesian product" not "cross product". | 08:57 | |
| lifeless | fine | 08:57 |
| jml | but I guess the latter makes sense. | 08:57 |
| * vila always translate 'cross product' into 'produit cartesien' ;-) | 08:58 | |
| jml | heh heh | 08:58 |
| RAOF | Not to be confused with the _actual_ operation 'cross product' :) | 08:58 |
| * vila also has no trouble translating applier into 'adapteur' hence he missed lifeless point ;) | 08:59 | |
| vila | lifeless: url ? grep repository_check_reconcile bzr.dev gives no matches :) | 09:00 |
| poolie | :) | 09:01 |
| lifeless | test_check_reconcile.py | 09:02 |
| lifeless | and __init__.py | 09:02 |
| lifeless | in repository_implementations package | 09:02 |
| lifeless | back soon -> atm | 09:02 |
| lifeless | poolie: ringing you for brief chat | 09:02 |
| poolie | jml, hm, Cartesian product seems more correct | 09:03 |
| jml | poolie: especially since the ordering doesn't matter, since they are unit tests. | 09:04 |
| poolie | lifeless: ready whenever | 09:04 |
| jml | iirc, cross product makes sense if you define multiplication as 'cons' | 09:05 |
| spiv | Ah, I just accidentally found the bug in the test suite that allowed bug 237067 to happen. | 09:08 |
| ubottu | Launchpad bug 237067 in bzr ""bzr check" on bzr+ssh:// branch returns ObjectNotLocked error" [Undecided,New] https://launchpad.net/bugs/237067 | 09:08 |
| poolie | spiv, good for you | 09:13 |
| lifeless | mobiles work better with battery power | 09:16 |
| * igc dinner | 09:26 | |
| vila | lifeless: class RepositoryTestProviderAdapter(TestScenarioApplier): explains my confusion I would say :) Or are you referring to a newer, yet unknown to me, implementation ? | 09:31 |
| vila | lifeless: hmm, no, I think you meant: broken_scenario_applier = TestScenarioApplier() | 09:31 |
| vila | broken_scenario_applier.scenarios = broken_scenarios_for_all_formats | 09:31 |
| vila | which better illustrates your point | 09:31 |
| vila | poolie, igc, lifeless: I just realized I did class ServerAdapter(tests.TestScenarioApplier): in my local_test_server plugin just to define a dict :-) | 09:35 |
| === yacc__ is now known as yacc | ||
| lifeless | vila: yes :) | 09:47 |
| lifeless | vila: this is the point really | 09:47 |
| lifeless | also | 09:47 |
| lifeless | crying tiger++ | 09:47 |
| vila | lifeless: consider me enlightened then :) But not for the tiger though... | 09:49 |
| lifeless | its thai food | 09:49 |
| awilkins | It's the new filem "Crying Tiger, Sulking Dragon" | 10:27 |
| proppy | Hi, I get the following when installing bzr on ubuntu-hardy | 10:30 |
| proppy | http://pastebin.com/m76595733 | 10:30 |
| proppy | is this a known problem ? | 10:30 |
| Peng | I don't think scrollkeeper is related to bzr. | 10:32 |
| poolie | oops | 10:33 |
| poolie | proppy: please report a bug against scrollkeeper | 10:33 |
| proppy | poolie: thanks for the direction :) | 10:33 |
| proppy | poolie: https://edge.launchpad.net/scrollkeeper/+filebug ? | 10:34 |
| proppy | or scrollkeeper package in ubuntu ? | 10:34 |
| proppy | https://bugs.edge.launchpad.net/ubuntu/+source/scrollkeeper/+filebug | 10:35 |
| poolie | the second is better but either will do | 10:35 |
| proppy | poolie: reported https://bugs.edge.launchpad.net/ubuntu/+source/scrollkeeper/+bug/237579 | 10:41 |
| ubottu | Launchpad bug 237579 in scrollkeeper "/usr/bin/scrollkeeper-update: corrupted double-linked list on apt-get install bzr" [Undecided,New] | 10:41 |
| strk | is this the #bzr branch ? :) | 11:21 |
| strk | ok, serious question: does bzr support aliases for locations ? | 11:22 |
| jamesh | strk: there is a bzr bookmark plugin you might want to try | 11:22 |
| Peng | Ooh, you were just barely too fast for me. | 11:22 |
| jamesh | https://edge.launchpad.net/bzr-bookmarks | 11:22 |
| jamesh | https://launchpad.net/bzr-bookmarks | 11:23 |
| nasloc__ | anyone know how to update partial (like only doc directory) in a checkout? | 11:23 |
| nasloc__ | I wanna update part of working tree, not full of them. | 11:24 |
| Peng | nasloc__: I don't think you can do that. | 11:24 |
| Peng | nasloc__: You can revert only parts of a tree, but that doesn't help if you want to update to a new revision.. | 11:24 |
| nasloc__ | Peng, oh :( because svn can do that and my partner says he would use bzr over svn if bzr supports that. | 11:25 |
| nasloc__ | Peng, thanks anyway. | 11:26 |
| Peng | nasloc__: With Bazaar, you'd finish your work and commit, then merge new changes. Not sure how that translates to checkouts though.. | 11:26 |
| jamesh | nasloc__: you can always use multiple branches | 11:27 |
| jamesh | if you generally edit a subset of a tree as a unit, then perhaps it should be its own branch | 11:27 |
| nasloc__ | jamesh: ok I'll check if that works. thanks | 11:30 |
| james_w | yay! Bazaar shirt. | 12:05 |
| gour | james_w: where, what, how... | 12:23 |
| === andrea-bs is now known as andrea-bs___ | ||
| === andrea-bs___ is now known as andrea-bs | ||
| james_w | gour: it just arrived in the post. | 12:33 |
| james_w | they were a gift for all contributors to celebrate the 1.0 release. Mine just took a bit of time to arrive. | 12:33 |
| gour | heh...next time let's think to better contribute...well, we're still news with bzr | 12:37 |
| gour | s/news/new | 12:37 |
| === kiko-afk is now known as kiko | ||
| j^ | jam, regarding the bzr_access cleanup, i put a patch at http://oil21.org/~j/patches/bzr_access.permission_fix.bundle | 13:23 |
| strk | we're doing some tests with bzr. I get: | 13:31 |
| strk | Path conflict: a_silent_test_file / RENAMED_TEST | 13:31 |
| strk | how to resolve such conflicts ? | 13:31 |
| james_w | strk: put the file that you want at the path and then "bzr resolve <path>" | 13:36 |
| james_w | I've never had to deal with one, so I can't be more specific, sorry. | 13:36 |
| strk | mm, I did bzr resolve a_silent_test_file | 13:37 |
| strk | resolved, but kept the other :) | 13:37 |
| igc | abentley: if you're around, can you help me with some subtree Qs? | 14:28 |
| abentley | igc: Okay. | 14:29 |
| igc | looking at sprout() in bzrdir.py, what's the recurse_branch bit about? | 14:29 |
| igc | the variable isn't used ... | 14:29 |
| igc | which might well be a bug | 14:29 |
| igc | Also, do you think shallow=shallow ought to be passed? | 14:30 |
| igc | (in lifeless' branch that is) | 14:30 |
| lifeless | igc: I would say shallow should propogate to child trees, yes. | 14:33 |
| igc | thanks. I could see why they wouldn't | 14:34 |
| igc | s/could/couldn't/ | 14:34 |
| abentley | igc: Nesting generally requires a tree and a branch. | 14:34 |
| abentley | Because the location of the nested tree's branch is determined by the current tree's branch. | 14:35 |
| igc | ok | 14:36 |
| abentley | So it looks like the loop at 1009 may be buggy. | 14:37 |
| abentley | If buggy, it's buggy for a scenario where a lightweight checkout is being sprouted. | 14:39 |
| abentley | Actually, I'm not sure source_branch can ever be None when branching. | 14:42 |
| abentley | In the lightweight checkout scenario, I think it would be set to the lightweight checkout's branch. | 14:43 |
| igc | abentley: I'd expect so. | 14:43 |
| igc | So do you think recurse_branch can be safely deleted? | 14:44 |
| abentley | I think so. | 14:44 |
| igc | me too. It looks like it was going to be used by then wasn't needed ... or something like that. | 14:45 |
| igc | s/by/but/ | 14:45 |
| igc | abentley: thanks. | 14:45 |
| abentley | igc: What's the purpose of your branch for shallow branch support? | 14:46 |
| igc | I'm just reviewing Robert's work and making any minor tweaks as I go | 14:46 |
| abentley | Are you working with Robert's prototype or the final one based on VersionedFiles? | 14:48 |
| igc | the one lifeless asked me to merge bzr.dev into | 14:49 |
| igc | I've run export-loom and I'm working my way up the stack | 14:49 |
| igc | reviewing each thread | 14:49 |
| igc | lifeless has agreed to review my tweaks and then I'll merge the pieces, giving him time to continue on the VersionedFile stuff | 14:50 |
| abentley | igc: Would it be appropriate to land my stacking policy stuff on that? | 15:28 |
| igc | abentley: sure | 15:29 |
| igc | I'm just putting up the next patch now fwiw | 15:29 |
| abentley | igc: Are you in Sydney? | 15:34 |
| igc | Brisbane | 15:34 |
| abentley | Well, that's dedication. | 15:39 |
| igc | and deadlines :-) | 15:40 |
| igc | that's it from me today - night all | 15:51 |
| === lamont` is now known as lamont_ | ||
| === lamont_ is now known as lamont__ | ||
| === lamont__ is now known as lamont | ||
| barry | hi bzr hackers. i'm having some trouble integrating setuptools_bzr with looms. i'm wondering if anybody is available to lend some help | 16:15 |
| * khaeru bleats | 16:30 | |
| khaeru | Anyone home? | 16:30 |
| abentley | barry: I can help later, but I'm putting out fires right now. | 16:32 |
| barry | abentley: thanks! no rush, i have a hackaround in place right now. ping me when you're free? | 16:33 |
| abentley | will do. | 16:33 |
| barry | abentley: thx! | 16:34 |
| === barry is now known as barry-away | ||
| proppy | regarding testing deferToThread addition | 17:05 |
| proppy | here is the failing test | 17:05 |
| proppy | http://proppy.aminche.com/hg/service-test/rev/583aae136706 | 17:05 |
| proppy | and the patch that make test pass http://proppy.aminche.com/hg/service-test/rev/1c8716677930 | 17:05 |
| proppy | someone care to parse it ? | 17:05 |
| proppy | oops wrong channel | 17:08 |
| proppy | :) | 17:08 |
| === kiko is now known as kiko-fud | ||
| abentley | barry-away: What can I do for you? | 17:22 |
| plexq | how do I list what changes where in a revision? | 17:37 |
| Kinnison | how do you mean? | 17:43 |
| === mthaddon_ is now known as mthaddon | ||
| === barry-away is now known as barry | ||
| barry | abentley: https://bugs.edge.launchpad.net/setuptoolsbzr/+bug/237652 | 18:09 |
| ubottu | Launchpad bug 237652 in setuptoolsbzr "setuptools_bzr does not work with looms" [High,Confirmed] | 18:09 |
| abentley | barry: from bzrlib.plugin import load_plugins; load_plugins() | 18:10 |
| barry | abentley: that'll load the loom plugin and install any necessary hooks? | 18:10 |
| abentley | barry: Right. Especially, in this case, it will register the loom branch formats. | 18:11 |
| barry | abentley: awesome, thanks | 18:11 |
| * barry is trying it... | 18:11 | |
| barry | abentley: works like a charm. thanks! | 18:16 |
| abentley | You're welcome. | 18:16 |
| === mw is now known as mw|food | ||
| === kiko-fud is now known as kiko | ||
| radix | Stacked branches sound awesome. It sounds like it'll make using launchpad code hosting much more practical. | 19:18 |
| gour | radix: they won't be in 1.6? | 19:24 |
| radix | gour: what? | 19:24 |
| gour | stacked branches | 19:25 |
| radix | gour: Was that meant to be a statement? | 19:25 |
| radix | I don't understand the question. | 19:26 |
| gour | stacked branches will not be ready for bzr-1.6, right? | 19:26 |
| radix | gour: I don't know, I'm not a bazaar developer. | 19:27 |
| radix | gour: I just read jam's blog about them. | 19:27 |
| radix | http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar_29.html | 19:27 |
| gour | i'm speaking based on what i heard here, iirc | 19:27 |
| pygi | shhh gour again :) | 19:28 |
| === yacc_ is now known as yacc | ||
| gour | pygi: ;) | 19:29 |
| jam | gour: well, we are reviewing the changes to hopefully get it landed today | 19:40 |
| jam | at least as a dev format | 19:41 |
| gour | jam: great. you working tirelessly to improve bzr | 19:54 |
| gour | i'm waiting to finish some written assignments (still under darcs) and then we'll conduct a big darcs --> bzr migration | 19:55 |
| jam | we try, I do get tired sometimes :) | 19:55 |
| kumi_ | wow, more sexy new features :) | 19:55 |
| === mw|food is now known as mw | ||
| pickscrape | The rate and quality of work done on this project astounds me. | 19:56 |
| gour | jam: hopefully you don't code too much when getting tired ;) | 19:57 |
| * gour agrees with pickscrape | 19:57 | |
| pickscrape | I think that's testament to the tool too, which presumably helps a great deal :) | 19:57 |
| jam | naw, that's when I review code :) | 19:57 |
| jam | pickscrape: well, we have some decent processes in place. Though honestly as a developer it is a slightly different view | 19:58 |
| jam | *big* changes are easy because of our process | 19:58 |
| jam | *small* changes end up with a lot of process overhead versus their actual impact | 19:58 |
| * gour hopes to become somewhat familiar with python to be able to help a bit in the future. for now we're busy working on a haskell (project) | 19:59 | |
| jam | 11,000 unit tests can be a great thing, and can be a bit of a pain at the same time :) | 19:59 |
| pickscrape | :) | 20:04 |
| pickscrape | Our developers have a simple solution to that problem: don't write them and don't bother to run them. | 20:04 |
| schierbeck | you guys know if there's a bzr-svn ppa? | 20:40 |
| Peng | bzr-svn is in the main bzr PPA. | 20:41 |
| beuno | AFAIK, that version doesn't work the bzr 1.5, which is the version in PPA | 20:42 |
| beuno | but jelmer would know best | 20:42 |
| schierbeck | ok | 20:42 |
| schierbeck | i was hoping there was a more recent version | 20:42 |
| Peng | Yeah, ppa compatibility sucks. | 20:42 |
| Peng | Well, in this case, it's not the ppa's fault really, but still. :P | 20:42 |
| jelmer | bzr-svn isn't in PPA anymore | 20:42 |
| Peng | Oh? | 20:42 |
| Peng | Where is it? | 20:43 |
| jelmer | the only packages available are my packages for Debian Sid (http://samba.org/~jelmer/debian) | 20:43 |
| schierbeck | cool | 20:44 |
| schierbeck | what about bzr-avahi? | 20:48 |
| schierbeck | can't find a ppa for that either | 20:49 |
| jam | new this week post | 21:12 |
| jam | for those who want there news right away | 21:13 |
| jam | http://jam-bazaar.blogspot.com/ | 21:13 |
| pickscrape | jam: an interesting read, and something for us to think about when we come to migrate to bzr | 21:21 |
| bimberi | jam: Thankyou. I look forward to seeing how Elliot is described each week. ;) You've invented "pair-blogging"! | 21:29 |
| jam | yeah, statik is pretty creative in that regard | 21:30 |
| jam | In our case, the pairing is mostly out of necessity, I tend to write too much or too little | 21:30 |
| jam | statik is good about helping to make sure it isn't all just a stream-of-consciousness out of me | 21:31 |
| jam | and he is certainly better about humor | 21:31 |
| statik | aw shucks | 21:32 |
| bimberi | :) | 21:33 |
| pickscrape | I tend to ramble bit time when I write. | 21:37 |
| pickscrape | big time | 21:37 |
| === kiko is now known as kiko-afk | ||
| === thumper-office is now known as thumper | ||
| lifeless | moin | 22:32 |
| * beuno hugs bzr shelve/unshelve | 22:46 | |
| * pickscrape wonders why the shelf isn't core | 22:47 | |
| beuno | mwhudson_, howdy :) | 23:05 |
| mwhudson_ | beuno: i hate my isp | 23:05 |
| beuno | mwhudson_, I think most people here do :p | 23:05 |
| beuno | ever thought about irssi on a server somewhere stable? | 23:06 |
| mwhudson_ | as of this morning, we're moving house though, hopefully the connection will be more stable there | 23:06 |
| mwhudson_ | beuno: yes i have, but not done anything about it | 23:06 |
| beuno | mwhudson_, if you don't like irssi, there is ircproxy, which is client-agnostic | 23:06 |
| beuno | but, if you're moving, that may help | 23:06 |
| bob2 | irssi_proxy is quite spiffy | 23:07 |
| beuno | mwhudson_, anyway, I've been poking at loggerhead from a "clean it up" point of view, and I've found that it uses args/kwargs quite inconsistently. I'd like to mode everything to kwargs, unless you have something against me doing thath | 23:08 |
| mwhudson_ | beuno: you mean in urls? | 23:08 |
| beuno | mwhudson_, yes | 23:08 |
| beuno | in some cases, it uses /revision/, and, in some /revision?values=random | 23:09 |
| mwhudson_ | yeah, it's not great | 23:09 |
| mwhudson_ | beuno: on a call now, i'll get back to you in a few minutes | 23:10 |
| beuno | (as a side effect, using args let's you use wget/curl, but there has to be a better way around it) | 23:10 |
| beuno | mwhudson_, sure, no hurry | 23:10 |
| lifeless | beuno: ? is less likely to be cached in general | 23:13 |
| lifeless | beuno: and you can use wget/curl with ? just fine | 23:13 |
| beuno | lifeless, in respect to ?, do you mean that as a good thing, or as something bad? | 23:16 |
| beuno | and, I can't seem to get loggerhead to recieve any ? parameters from wget/curl | 23:17 |
| beuno | actually, looking deeper into it | 23:19 |
| beuno | I only get the first parameter | 23:19 |
| beuno | not the subsequent ones with & | 23:19 |
| lifeless | beuno: put '' around the url | 23:21 |
| lifeless | & is a shell metachar | 23:21 |
| lifeless | :) | 23:21 |
| mwhudson_ | beuno: i bet this is a shell issue or something | 23:21 |
| beuno | lifeless, argh, thank, works. mwhudson_ told me yesterday, but it didn't seem to work, so I may of had a problem in the code | 23:22 |
| beuno | ok, good, back to more reliable benchmarks now :) | 23:23 |
| mwhudson_ | beuno: so, i actually quite like having the revision, at least, in the path part of the url | 23:27 |
| mwhudson_ | if i was starting again, i'd probably have: | 23:28 |
| mwhudson_ | /branch/path -> changelog view | 23:28 |
| mwhudson_ | /branch/path/$revno -> revision view | 23:28 |
| mwhudson_ | /branch/path/$revno/path/to/file -> annotate view | 23:28 |
| mwhudson_ | /branch/path/$revno/path/to/dir -> inventory view | 23:29 |
| mwhudson_ | i think having the "restrict to revisions that touch some file" as a query arg makes some kind of sense | 23:29 |
| beuno | ok, 3 sec to generate a 36k line diff in bzrlib, 20sec to apply the template and return. It outputs a 7mb file, which is considerable. We should be able to cut that down with proper CSS/HTML. | 23:30 |
| lifeless | >< | 23:30 |
| beuno | mwhudson_, that sounds like a good structure, and add kwargs for any filters we may want/need | 23:31 |
| mwhudson_ | beuno: what are the comparable numbers for trunk? | 23:32 |
| mwhudson_ | (if you have the RAM to repeat the benchmark...) | 23:32 |
| beuno | mwhudson_, well, I can't compare, since trunk generates a diff for each file, twice | 23:32 |
| lifeless | so | 23:32 |
| lifeless | nested trees | 23:32 |
| beuno | mwhudson_, my PC chokes at ~20k diffs with trunk, if that serves for comparison | 23:33 |
| mwhudson_ | beuno: heh heh | 23:35 |
| === mwhudson_ is now known as mwhudson | ||
| beuno | the diff uses 100-150 RES memory, and it's mainly the templating engine | 23:37 |
| beuno | we could probably improve it a *lot* if, instead of a per-line loop, we had a per-column loop (3 columns) | 23:37 |
| beuno | but I'd expect some work would need to be done in order to get CSS to show that properly in many scenarios | 23:38 |
| beuno | anyway, lots of room for improvement, but, the current branch is a major improvement over trunk, in resource usage | 23:39 |
| mwhudson | right | 23:41 |
| mwhudson | i'm sure our admins would like a three orders of magnitude improvement more than a three fold improvment | 23:42 |
| mwhudson | but they'll be happy with what we've got already, i'm sure | 23:42 |
| beuno | mwhudson, I have many ideas, so it's hard not to drift away. I'll focus on getting this approach cleaned up for review, and plan the next step after that | 23:43 |
| mwhudson | thanks | 23:43 |
| beuno | I even have the html/css for the new theme partly ready, which I will play around with until we can adapt it's current design to what will actually be used | 23:44 |
| mwhudson | so why does bzr push-ing a new branch very very occasionally create a branch reference instead? | 23:49 |
| igc | morning | 23:53 |
| lifeless | mwhudson: bleep, it shouldn't because you can't actually open a branch reference | 23:55 |
| lifeless | (they resolve at open) | 23:55 |
| lifeless | there was, once, a bug | 23:55 |
| mwhudson | lifeless: yeah, it certainly shouldn't | 23:56 |
| mwhudson | lifeless: https://pastebin.canonical.com/5889/ (apologies for the private url) | 23:57 |
| lifeless | you should apologise for openid instead | 23:57 |
| lifeless | your bash history may help reproduce | 23:58 |
| mwhudson | i deleted the branch and pushed again, it worked fine this time | 23:58 |
| poolie | good morning lifeless, all | 23:58 |
| mwhudson | i know this happened to thumper a week or so ago | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!