| lifeless | jelmer: I wouldn't use chk_map unless you need updatable values | 00:16 |
|---|---|---|
| lifeless | jelmer: if you just need key:value and they are immutable use BTreeIndex | 00:16 |
| jelmer | lifeless: I need a big path -> tuple map that's different per revision but should have relatively small (line-based) differences between revisions | 00:17 |
| jelmer | lifeless: very much like an inventory | 00:17 |
| jelmer | s/line-based/path-based/ | 00:17 |
| lifeless | ok for that you want chkmap | 00:17 |
| lifeless | you may want to look at chk inventories parent_id,basename->child_id map | 00:18 |
| lifeless | as a related use of chk_map | 00:18 |
| lifeless | we use two maps | 00:18 |
| jelmer | lifeless: What about the Pack container bits from bzr-search, where should i be looking? | 00:18 |
| lifeless | one for paths | 00:18 |
| lifeless | one for the data | 00:18 |
| lifeless | b.p.search.index | 00:18 |
| lifeless | basically to work with chkmap you need a VersionedFiles object that supports hash naming | 00:19 |
| lifeless | it might be possible to convince knits to do this | 00:19 |
| lifeless | I'm not sure it would be a good idea ;) | 00:19 |
| lifeless | so the layering is: | 00:19 |
| lifeless | chkmap->VF | 00:19 |
| lifeless | (KnitVersionedFiles|GroupCompressVersionedFiles)->(collection of btreeindex + pack files) | 00:20 |
| lifeless | and its that last bit that bzr-search has a smallish implementation of | 00:20 |
| jelmer | thanks | 00:21 |
| jelmer | this is all a bit new to me, VersionedFiles are still very much an abstract thing to me | 00:21 |
| lifeless | ok | 00:26 |
| lifeless | I think you should learn about the internals here | 00:27 |
| lifeless | its hampering bug fixing | 00:27 |
| lifeless | also our layers could be better | 00:27 |
| lifeless | got 20 minutes? | 00:27 |
| lifeless | jelmer: ^ | 00:29 |
| jelmer | lifeless: if you can give a quick introduction that might help | 00:31 |
| lifeless | thats my plan | 00:31 |
| lifeless | so | 00:31 |
| lifeless | one sec | 00:31 |
| lifeless | jelmer: ok | 00:36 |
| lifeless | jelmer: so lets start with VersionedFiles | 00:36 |
| jelmer | lifeless: ok | 00:37 |
| jelmer | lifeless: fwiw I'm familiar with the API | 00:37 |
| jelmer | lifeless: just not how it works underneath | 00:37 |
| lifeless | sure | 00:38 |
| lifeless | so | 00:38 |
| lifeless | Weaves work by having a thunk class, not very interesting. | 00:38 |
| lifeless | more interesting is how Knits and Packs work for the KnitVersionedFiles clas | 00:39 |
| lifeless | bring up knit.py | 00:39 |
| lifeless | look for make_file_factory | 00:40 |
| jelmer | right, I think that's what I'm using right now for the file id map | 00:40 |
| thumper | hi people | 00:40 |
| lifeless | so this creates the two key objects KVF needs to work | 00:40 |
| poolie | hello all | 00:41 |
| lifeless | an index, which is responsible for locating bytes and storing the graph | 00:41 |
| thumper | is there documentation on using the merge sorted graph? | 00:41 |
| lifeless | and an access object, which is responsible for taking index descriptions of content and reading them back, or for writing and returning index descriptions | 00:41 |
| lifeless | hi thumper poolie no | 00:41 |
| jelmer | hi thumper, poolie | 00:42 |
| lifeless | jelmer: so _KndxIndex is the implemenetation of an index based on ,kndx files, and _KnitGraphIndex is the implementation of same building on the 'GraphIndex' interface | 00:42 |
| lifeless | likewise _KnitKeyAccess and _DirectPackAccess | 00:43 |
| * jelmer nods | 00:43 | |
| lifeless | so, to use chk_map on .kndx and .knit files, we'd create a KVF much like make_file_factory does | 00:44 |
| lifeless | now if you look at KnitVersionedFiles itself | 00:44 |
| lifeless | this is the common logic that actually cares about knit deltas, their constraints and needs and so on | 00:44 |
| mwhudson | thumper: i can probably tell you more than you want to know :) | 00:45 |
| lifeless | so it knows about delta chains (we'd want 0), annotations (0 again) | 00:45 |
| lifeless | it also knows about fallbacks to other VF objects, which is much of how stacking works on the client | 00:46 |
| thumper | what is the easiest way to get the revision_id for any mainline (non-dotted) revno? | 00:46 |
| lifeless | branch.revno2revid | 00:46 |
| thumper | lifeless: no attribute called ... | 00:47 |
| lifeless | jelmer: ok, I'm not sure where to drill down into; we can look at how _DirectPackAccess and _KnitGraphIndex work | 00:47 |
| lifeless | thumper: its roughly that | 00:47 |
| lifeless | thumper: pydoc and / for the win | 00:47 |
| thumper | lifeless: there are revision_id_to_revno | 00:47 |
| lifeless | jelmer: or we can look at actually wiring up chk_map to .knit files for you | 00:48 |
| thumper | lifeless: but not the other way around | 00:48 |
| jelmer | lifeless: let's look at the latter first | 00:48 |
| thumper | mwhudson: where is your pydoc stuff for bzr? | 00:48 |
| jelmer | lifeless: actually working with this code should help | 00:48 |
| lifeless | dotted_revno_to_revision_id and get_rev_id and | 00:48 |
| lifeless | jelmer: ok | 00:49 |
| lifeless | so | 00:49 |
| lifeless | lets pop over to chkmap | 00:49 |
| lifeless | CHKMap wants a store, root_key and a search key func | 00:49 |
| lifeless | the search key func is for hashed keys | 00:49 |
| lifeless | we can ignore that for now | 00:49 |
| === abentley1 is now known as abentley | ||
| lifeless | root_key is something you need to store elsewhere | 00:50 |
| lifeless | its the 'id' of a given version of a dict stored in a chk_map | 00:50 |
| lifeless | so you'll need someplace to put that. perhaps another knit, or whatever. | 00:50 |
| lifeless | to bootstrap, when you first start, you use from_dict | 00:51 |
| lifeless | so - | 00:51 |
| lifeless | my_map = CHKMap.from_dict(store, {}) is the minimal call | 00:51 |
| lifeless | that will get a non-splitting map with single-element tuples as keys | 00:52 |
| lifeless | what you probably want is maximum_size=4096 | 00:52 |
| lifeless | so to wire it up | 00:53 |
| lifeless | store = get_a_versioned_files() | 00:53 |
| lifeless | empty_map = CHKMap.from_dict(store, {}, maximum_size=4096) | 00:53 |
| * jelmer nods | 00:53 | |
| lifeless | then you can stash stuff in it. | 00:53 |
| lifeless | you can individually map() and unmap() | 00:54 |
| lifeless | however its much better to use apply_delta | 00:54 |
| lifeless | because map and unmap write on each change | 00:54 |
| lifeless | apply_delta applies all the changes and then writes | 00:54 |
| lifeless | the get_a_versioned_files call should return a VF whose key width is 1 | 00:55 |
| lifeless | and no graph | 00:55 |
| lifeless | so lets pop back to knit.py | 00:55 |
| lifeless | access = _KnitKeyAccess(transport, mapper); mapper=ConstantMapper('myknit'); index = _KndxIndex(transport, mapper, lambda:None, lambda:True, lambda:True) | 00:57 |
| lifeless | You want ConstantMapper because you want the same .knit and .kndx file for all keys | 00:57 |
| jelmer | ok | 00:58 |
| lifeless | the lambdas are for handling lock/unlock callbacks | 00:58 |
| lifeless | you should wire them up more carefully | 00:58 |
| thumper | kudos to the bzr developers for making an api even I find easy! | 00:58 |
| lifeless | before using with concurrent processes | 00:59 |
| lifeless | then its just | 00:59 |
| lifeless | store = KnitVersionedFiles(index, access, annotated=False, max_delta_chain=0) | 00:59 |
| jelmer | lifeless: ok, let me give that a try | 01:00 |
| jelmer | mwhudson: btw, I've "fixed" the bzr-git importing strange modes issue | 01:02 |
| mwhudson | thumper: http://starship.python.net/crew/mwh/bzrlibapi/ | 01:02 |
| mwhudson | jelmer: cool | 01:02 |
| jelmer | mwhudson: it just means it won't be able to regenerate the sha map correctly if you remove it | 01:02 |
| jelmer | mwhudson: it'll also warn if it hits strange modes | 01:02 |
| jelmer | mwhudson: same thing for the XML-invalid characters that are escaped | 01:03 |
| mwhudson | jelmer: i'm not sure i understand | 01:03 |
| mwhudson | jelmer: remove what? | 01:03 |
| jelmer | mwhudson: git.[t]db | 01:03 |
| jelmer | mwhudson: which contains the information of which bzr revid/fileid maps to which git sha | 01:04 |
| mwhudson | jelmer: ok, but i still don't understand what that has to do with strange modes | 01:04 |
| jelmer | mwhudson: git works with shas everywhere | 01:04 |
| jelmer | mwhudson: so when we talk to it we need to tell it which shas we have | 01:04 |
| mwhudson | jelmer: currently, the git.db does not persist between runs | 01:05 |
| jelmer | mwhudson: we generate those shas from the bzr data we have by converting to git objects and shaing those | 01:05 |
| jelmer | mwhudson: if we can't regenerate the exact same git object we can't find a particular sha | 01:05 |
| mwhudson | jelmer: ahh | 01:06 |
| mwhudson | jelmer: so "persisting the sha data between runs" has become a bit more important? | 01:06 |
| jelmer | mwhudson: yeah, a bit. previously we would just flat out refuse to import anything with strange file modes, now we just warn | 01:07 |
| jelmer | mwhudson: we could store the file modes in revision properties at some point | 01:07 |
| jelmer | mwhudson: in which case we could regenerate the sha map correctly again | 01:07 |
| jelmer | mwhudson: s/file modes/unusual file modes/ (they're really rare) | 01:08 |
| mwhudson | jelmer: yes but the kernel is a pretty obvious target, i think we need to support that | 01:10 |
| mwhudson | (ultimately, not necessarily in the next release) | 01:10 |
| jelmer | mwhudson: sure | 01:10 |
| jelmer | mwhudson: Storing in revision properties should fix this, and keeping the sha map around works around the problem | 01:11 |
| jelmer | there's only 3 files in the kernel with unusual modes | 01:11 |
| lifeless | jelmer: so how did that work? | 01:11 |
| jelmer | lifeless: still working on it | 01:15 |
| lifeless | ok | 01:15 |
| lifeless | apply_delta is real simple | 01:15 |
| lifeless | I'm going to start working on these presentations | 01:16 |
| lifeless | gimme a shout anytime | 01:16 |
| lifeless | jam: wow bvg is very, uhm, brief | 01:17 |
| jelmer | lifeless: Hmm, CHKMap.from_dict() returns the new root key | 01:20 |
| jelmer | lifeless: so I just use CHKMap(store, root_key) to get it out again? | 01:20 |
| lifeless | yes | 01:21 |
| lifeless | apply_delta also returns a replacement key | 01:21 |
| lifeless | (from_dict is a shim around apply_delta) | 01:21 |
| jelmer | ok, that's working now | 01:22 |
| jelmer | lifeless: in the case of inventories, what do you use the key tuples for ? | 01:22 |
| jelmer | and is there any reason why I might want e.g. the individual directory names in the tuple instead of just a 1-tuple with a path? | 01:23 |
| lifeless | jelmer: size | 01:24 |
| lifeless | we store inventories as two dicts | 01:24 |
| lifeless | (parentid, child_name)->child_id | 01:24 |
| lifeless | (fileid,) -> serialized_entry | 01:24 |
| lifeless | the former gives us 'ls /foo/bar' | 01:25 |
| lifeless | the latter gives us tree.inventory['fooid'] | 01:25 |
| lifeless | jelmer: what are you storing | 01:26 |
| jelmer | lifeless: I'm storing unicode_path -> (file_id, revision_id, created_foreign_revid) | 01:31 |
| lifeless | and on only ever lookup on path ? | 01:32 |
| jelmer | lifeless: no, lookup by file id is also possible | 01:32 |
| lifeless | s/on/you/ | 01:32 |
| lifeless | ok | 01:32 |
| lifeless | so you'll need two maps | 01:32 |
| lifeless | if you want fast lookup on fileid | 01:33 |
| jelmer | lifeless: but lookup by file id is very rare ("bzr check" uses it) | 01:33 |
| lifeless | check is getting overhauled ;) | 01:33 |
| lifeless | this is for svn ? | 01:33 |
| jelmer | lifeless: You're overhauling bzr-svn's check too ? ;-) | 01:33 |
| lifeless | no, but the api calls bzr makes are being overhauled | 01:33 |
| jelmer | lifeless: yeah, bzr-svn does check too (it checks the consistency of the bzr metadata) | 01:33 |
| lifeless | so the access pattern is going to radically change | 01:34 |
| lifeless | alrighty, we cn ignore it at your risk:) | 01:34 |
| lifeless | so | 01:34 |
| lifeless | do you need to iterate paths ? | 01:34 |
| lifeless | or is it 'give me data for X' | 01:35 |
| lifeless | amd do you need to do case-insensitive matches | 01:35 |
| jelmer | I mostly need to just look at particular items | 01:37 |
| jelmer | by path | 01:37 |
| lifeless | so if you store every path you'll have a lot of duplicate data | 01:37 |
| lifeless | the trie will reduce some/much of o that | 01:37 |
| lifeless | but not all | 01:38 |
| jelmer | duplicate in the sense that duplicate revids are used? | 01:38 |
| lifeless | in particular leaf nodes have the full key of each item to allow finding the thing you asked for | 01:38 |
| lifeless | no duplicate in the sense that foo/bar and foo/gam both have foo/ in the key | 01:38 |
| jelmer | ah, right | 01:38 |
| lifeless | so you should zcat your knit and ahve a look, we had some optimisation plans and I don't recall exactly what items jam got to | 01:39 |
| lifeless | and what we deferred/didn't do. | 01:39 |
| lifeless | anyhow | 01:39 |
| jelmer | that's not worse than what we have now though | 01:40 |
| lifeless | you could hash the keys (via the key func), you could use two dicts (parent,child)->filed, fileed->(revid, foreignid) | 01:41 |
| lifeless | or you could say 'I'm happy as it stands' | 01:41 |
| lifeless | a more important thing though | 01:41 |
| lifeless | 'knits' load the full index always | 01:41 |
| lifeless | this sucks for doing little operations | 01:41 |
| lifeless | so when you hve this working we should look at backing it onto packs+btree indices | 01:42 |
| jelmer | ok | 01:43 |
| === luke-jr_ is now known as luke-jr__ | ||
| lifeless | man, I so want to code | 01:47 |
| jelmer | what's stopping you? | 01:48 |
| === luke-jr__ is now known as luke-jr_ | ||
| mwhudson | jelmer: thinking about it, i think relying on the sha map persisting is pretty smelly :) | 01:48 |
| jelmer | mwhudson: yes, it is. that's why we're warning | 01:49 |
| lifeless | jelmer: presentations to write | 01:49 |
| jelmer | lifeless: ah. uds? | 01:49 |
| lifeless | yes | 01:49 |
| lifeless | and bzr and git are hot topics | 01:50 |
| lifeless | likely ot have a hundred folk, I suspect | 01:50 |
| jelmer | lifeless: uhm, how do I get my data out of a CHKMap? | 02:24 |
| jelmer | other than iteritems()? | 02:24 |
| lifeless | any way you want ? :) | 02:24 |
| lifeless | iteritems | 02:24 |
| jelmer | ok | 02:24 |
| lifeless | and iter_changes | 02:24 |
| lifeless | iteritems(['path1']) | 02:25 |
| lifeless | is == __getitem__('path1'), if we had it | 02:25 |
| lifeless | we don't because its not cheap and the api should reflect the reality | 02:25 |
| jelmer | ValueError: Prefix has too many nulls versus width ? | 02:26 |
| lifeless | ('path1',) | 02:27 |
| jelmer | thanks | 02:29 |
| igc | morning (at last) | 02:33 |
| lifeless | igc: just :) | 02:36 |
| igc | lifeless: :-) | 02:36 |
| igc | hi | 02:36 |
| igc | thanks for the review | 02:36 |
| lifeless | no probs | 02:36 |
| lifeless | I think its not much work to do your approach at the right layer | 02:37 |
| lifeless | And I agree we can defer really deeply integrating it. | 02:37 |
| lifeless | I do think its important to have tests, and that they are really best written against the right layer. | 02:37 |
| igc | me too | 02:37 |
| lifeless | I hope I suggested a reasonable way to do that | 02:38 |
| igc | lifeless: I did | 02:38 |
| igc | lifeless: I would really like to leverage the specfiic files masking at the layer below | 02:38 |
| igc | while perhaps keeping the parent yielding ... | 02:38 |
| igc | and exclude masking a layer above | 02:39 |
| igc | lifeless: but I got a weird error from record_iter_changes when I tried | 02:39 |
| igc | is that fixed by parent yielding do you know? | 02:39 |
| lifeless | paste the error ? | 02:40 |
| lifeless | Git pull of dulwich: 2.43 MiB in 0m53.437s | 02:40 |
| lifeless | Bzr pull of dulwich: 360KB in 0m36.602s | 02:40 |
| lifeless | woo | 02:40 |
| igc | lifeless: I'll need to change the code again and re-run. Will do later | 02:40 |
| lifeless | jml: I think jam and I have to rename our talk | 02:40 |
| lifeless | 'when bzr became faster than git' | 02:41 |
| jml | lifeless: that's a very nice result. | 02:41 |
| lifeless | igc: so, without seeing the error I can't do much more than guess | 02:41 |
| thumper | lifeless: are those numbers representitive of normal usage? | 02:42 |
| lifeless | thumper: 'bzr branch lp:~lifeless/dulwich/trunk-bbc | 02:42 |
| lifeless | thumper: vs 'git init; git pull git://gitorious.org/dulwich/mainline.git' | 02:42 |
| jml | lifeless: but were it me, I'd leave the talk with the same title and demonstrate its obsolescence with a big bar graph. | 02:42 |
| lifeless | thumper: so, I'd say yes | 02:42 |
| lifeless | jml: yes, I was jesting about the rename | 02:43 |
| lifeless | the title is nice and contentious | 02:43 |
| jml | lifeless: :D | 02:43 |
| jml | very good result though. | 02:43 |
| lifeless | I wanted to paste the result though | 02:43 |
| * jml is keen to see the results for the kernel | 02:43 | |
| lifeless | I was thinking, 'lets get some numbers'. | 02:43 |
| lifeless | and boom. | 02:43 |
| lifeless | thumper: big histories may scale differently. I don't know precisely. | 02:43 |
| thumper | lifeless: very cool | 02:43 |
| lifeless | of course, over http it took 6 minutes to get dulwich bzr | 02:45 |
| lifeless | don't mention the war | 02:45 |
| thumper | lifeless: but git isn't using http is it? | 02:45 |
| lifeless | no | 02:46 |
| lifeless | git is using its native protocol | 02:46 |
| thumper | lifeless: so we are still comparing oranges with tangerines rather than oranges to fork lifts | 02:46 |
| bob2 | is lp especially aggressive about packing things? | 02:46 |
| thumper | bob2: no | 02:46 |
| lifeless | thumper: yes, both protocols are fruity | 02:47 |
| jelmer | lifeless: nice! | 02:48 |
| jelmer | lifeless: do I explicitly have to remove entries from the chk map or is overwriting them fine as well? | 02:49 |
| poolie | thumper: want to catch up about nested trees sometime? | 02:57 |
| thumper | poolie: yes | 02:57 |
| poolie | now? | 02:57 |
| thumper | sure | 02:58 |
| lifeless | jelmer: use apply delta | 03:01 |
| poolie | thumper: call me? | 03:01 |
| johnf | lifeless: you about? | 03:02 |
| poolie | hello johnf | 03:02 |
| lifeless | johnf: sure am | 03:03 |
| johnf | poolie: howdy | 03:03 |
| johnf | lifeless: re bug https://bugs.launchpad.net/bzr/+bug/243391 | 03:03 |
| ubottu | Ubuntu bug 243391 in bzr "TooManyConcurrentRequests during commit" [High,Fix released] | 03:03 |
| lifeless | johnf: there's this theory I'm paid to do this sort of thing :) | 03:03 |
| poolie | igc: one small chore for you next week: please moderate the mailing list | 03:03 |
| poolie | it gets a ridiculous amount of spam but enough real posts are caught you do need to check it | 03:03 |
| igc | poolie: sure | 03:03 |
| johnf | I'm getting a similar error when an upstream router returns admin proibited. Would that be fixed or should I file another bug? | 03:04 |
| lifeless | johnf: bzr version ? | 03:04 |
| johnf | client 1.14.1 server 1.13 | 03:04 |
| lifeless | johnf: new bug, that was 1.8 | 03:04 |
| lifeless | johnf: I take it you've fixed your router though ? :> | 03:05 |
| johnf | lifeless: no it's normal. Happens if the VPN is down | 03:05 |
| lifeless | johnf: so, I suspect this is a variant of 'ssh tells us shit', unless you're committing over http | 03:06 |
| johnf | lifeless: this is using bzr:// | 03:06 |
| lifeless | johnf: ok. please be sure to include that detail in your new bug report ;) | 03:07 |
| lifeless | johnf: root cause will be that we try to perform an operation on the protocol object while its still thinking its busy | 03:07 |
| johnf | lifeless: I think I'll add to this bug as it seems to be the same problem https://bugs.launchpad.net/bzr/+bug/323456 | 03:08 |
| ubottu | Ubuntu bug 323456 in bzr "TooManyConcurrentRequests when committing and the smart server is offline" [Undecided,New] | 03:08 |
| lifeless | gimme a sec to read it | 03:08 |
| lifeless | yah, do it | 03:10 |
| lifeless | or just metoo the bug | 03:10 |
| lifeless | jelmer: can you suggest a midsize project with history in git and bzr - same history, as dulwich has | 03:11 |
| lifeless | jelmer: I'd like to do a slightly less 'new project' test | 03:11 |
| jelmer | lifeless: I'm using apply delta, but may be overwriting keys without removing the old data at the same key - is that a problem? | 03:12 |
| jelmer | lifeless: hmm | 03:12 |
| lifeless | jelmer: its expected | 03:12 |
| jelmer | lifeless: cool, thanks | 03:13 |
| lifeless | jelmer: you can't have a key repeated in a chkmap | 03:13 |
| jelmer | lifeless: Not sure about other projects. You could use one from gnome that's available in both svn and git | 03:13 |
| lifeless | jam: hi :) | 03:13 |
| lifeless | jam: gathering data for our talk, I found: | 03:13 |
| lifeless | 11:35 < lifeless> Git pull of dulwich: 2.43 MiB in 0m53.437s | 03:13 |
| lifeless | 11:35 < lifeless> Bzr pull of dulwich: 360KB in 0m36.602s | 03:13 |
| lifeless | jelmer: I might ask a favour, if you're willing, as you have gitorious etc accounts | 03:17 |
| lifeless | jelmer: put together a similar sample case, but something that is say 10x the size of dulwich | 03:17 |
| * lifeless binds nose to ooo | 03:21 | |
| igc | lifeless: is pqm broken? I just tried resubmitting a patch and it fails pretty well instantly grumbling about 'subunit' I think | 03:24 |
| lifeless | igc: forward to me please | 03:25 |
| lifeless | it shouldn't be, as subunit is optional. | 03:25 |
| igc | lifeless: I don't get an email either re success or failure as best I can tell | 03:25 |
| lifeless | igc: and to land a patch making it mandatory the patch would have to pass | 03:25 |
| igc | lifeless: I'll run the test suite on my integration branch and see if it's my fault | 03:27 |
| lifeless | bug in pqm | 03:27 |
| lifeless | it may be fixed i nwhich case we can just say 'spm please upgrade pqm' | 03:27 |
| lifeless | lets start with that | 03:27 |
| lifeless | spm: please upgrade pqm | 03:27 |
| poolie | igc, abentley, i read through the updated design doc and i have some comments | 03:29 |
| poolie | i know some of my questions on the user doc were answered in the design doc, but i wasn't always asking them for the sake of the answer | 03:30 |
| poolie | more to say they should be described here | 03:30 |
| igc | poolie: I'm planning to update the userdoc given the feedback from you and others | 03:31 |
| * lifeless taps the mic | 03:31 | |
| lifeless | spm: ping | 03:31 |
| lifeless | igc: I'm sorry you haven't had feedback from me yet | 03:31 |
| lifeless | igc: feeling the crunch with allhands and 1.15 | 03:31 |
| lifeless | igc: your branch is probably faulty btw, I think its a bug in pqm that you don't get told, not a bug in pqm causing it to fail | 03:32 |
| igc | poolie: but I don't think the userdoc is the critical path given abentley is working from the design doc | 03:32 |
| igc | poolie: except for how the userdoc impacts the design doc | 03:33 |
| spm | lifeless: sorry was on the phone. couple of minor family hassles atm. so upgrade pqm on balleny? I assume a bzr pull equiv would do the trick? | 03:34 |
| lifeless | spm: yeah, cd ~/source/pqm; bzr pull | 03:35 |
| lifeless | spm: then igc can try again | 03:35 |
| lifeless | and we see what breaks. | 03:35 |
| spm | oki. one sec or more... | 03:35 |
| spm | lifeless: igc: upgraded. go for it. | 03:43 |
| AfC | Is "1.9-rich-root" is the still the current public rich root format, or is there a newer one I should tell someone to use? | 03:50 |
| lifeless | AfC: its what --default-rich-root will create. | 03:52 |
| AfC | k | 03:52 |
| lifeless | AfC: if you need working tree filters you can use 1.14-rich-root, but only windows users are likely to be desperate for that | 03:52 |
| AfC | nah | 03:52 |
| lifeless | and if you want to help beta test the bbc format you can use --development-rich-root | 03:53 |
| lifeless | igc - thats what you hit in pqm https://bugs.edge.launchpad.net/pqm/+bug/340361 | 03:54 |
| ubottu | Ubuntu bug 340361 in pqm "bad format usage" [High,Confirmed] | 03:54 |
| igc | lifeless: http://rafb.net/p/dMFRc592.html | 03:57 |
| igc | lifeless: anything obviously wrong? | 03:57 |
| igc | I trying to use a new integration branch fwiw | 03:58 |
| igc | one on lp as poolie has requested | 03:58 |
| lifeless | igc: your branch url is probably the problem | 03:58 |
| lifeless | igc: two things | 03:58 |
| lifeless | firstly, ~ianc/bzr/integration would be a better url | 03:59 |
| lifeless | no point having your personal integration branch a team branch | 03:59 |
| lifeless | secondly, I don't know if balleny can talk to lp | 03:59 |
| igc | well, except lp fails whether I try to push to ~ian-clatworthy/bzr/ianc-integration :-( | 03:59 |
| lifeless | spm: can you check that pqm user on ballent, outside chroot, can do 'bzr info bzr+ssh://bazaar.launchpad.net/%7Ebzr/bzr/ianc-integration/' | 03:59 |
| lifeless | igc: it does, how ? | 03:59 |
| lifeless | igc: or rather, in what way | 04:00 |
| igc | grumbles about a read-only transport | 04:00 |
| igc | and breaklock doesn't fix it | 04:00 |
| lifeless | pastebin please | 04:00 |
| spm | lifeless: it can yes. | 04:01 |
| igc | lifeless: http://rafb.net/p/gnKmyI33.html | 04:02 |
| igc | lifeless: looks like ~ian-clatworthy/bzr/integration has worked though | 04:02 |
| lifeless | much nicer url :) | 04:03 |
| igc | lifeless: well, except for the vfs noise: http://rafb.net/p/CMcA4E84.html | 04:03 |
| lifeless | igc: yes, bzr is running 1.14 | 04:04 |
| lifeless | 1.15 will remove that for a simple push | 04:04 |
| lifeless | dunno why you get that lock error | 04:04 |
| lifeless | readonly transport means that lp thinks *you* can't write to it | 04:04 |
| lifeless | file a question on launchpad-code | 04:05 |
| lifeless | I suspect a bug | 04:05 |
| igc | lifeless: ok, I'll try a http url to that new branch | 04:05 |
| lifeless | igc: bzr+ssh should be ok, spm has confirmed it works | 04:05 |
| lifeless | igc: what commit message were you giving pqm | 04:06 |
| lifeless | ? | 04:06 |
| igc | lifeless: see http://rafb.net/p/dMFRc592.html | 04:07 |
| igc | maybe the & is causing an issue? | 04:07 |
| lifeless | I would suspect so | 04:09 |
| igc | lifeless: so neither changing to a http URL, nor changing & => 'and' fixed the problem | 04:20 |
| igc | I added 'public_branch:policy' to branch.conf but that didn't help either | 04:21 |
| igc | the full test suite passes locally | 04:21 |
| igc | I don't have push_location:policy set to norecurse. Is that likely to cause an issue? | 04:22 |
| lifeless | jml - whats up with https://code.edge.launchpad.net/~jelmer/pqm/merge | 04:22 |
| lifeless | jml: I can't access it as 'lp:~jelmer/pqm/merge' | 04:23 |
| thumper | lifeless: that is because there is nothing there | 04:23 |
| lifeless | https://code.edge.launchpad.net/~jelmer/pqm/merge/+merge/6122 seemed to find something at some point | 04:24 |
| thumper | lifeless: or broken | 04:24 |
| lifeless | jelmer: ^^^^ | 04:24 |
| thumper | lifeless: probably created with bzr send | 04:24 |
| lifeless | isn't that meant to create a working branch? | 04:25 |
| * igc lunch | 04:32 | |
| bob2 | no matter how many times I branch dulwich, git takes twice as long | 04:42 |
| thumper | did I recall seing that bbc branches stack in 1.15dev? | 04:42 |
| lifeless | yes | 04:44 |
| lifeless | bob2: :) | 04:44 |
| thumper | lifeless: cool | 04:44 |
| lifeless | or at least, jam has it mostly going and we're aiming for 1.15 | 04:49 |
| lifeless | spm: please pull bzr from people.ubuntu.com/~robertc/pqm/trunk | 04:50 |
| jml | bob2: given that the git version is almost seven times bigger, that's not surprising :) | 04:54 |
| bob2 | heh, even after a repack, it's 2x | 04:54 |
| lifeless | jml: 7 times data sent | 04:54 |
| lifeless | bob2: same history | 04:54 |
| jml | lifeless: oh. | 04:54 |
| lifeless | jml: ^ same history | 04:54 |
| jml | lifeless: that's actually quite interesting :) | 04:55 |
| spm | lifeless: balleny pqm update again? | 04:55 |
| lifeless | jml: its why I chose dulwich, jelmer keeps them in sync | 04:55 |
| lifeless | spm: please, from the url above | 04:55 |
| bob2 | hm, 5x repo size | 04:55 |
| spm | lifeless: done. ddidn't restart the ui this time, appears unchanged. | 04:57 |
| lifeless | igc: please try again | 04:57 |
| lifeless | igc: I think you managed to have a revision that had a % in it. Odd though that may be. that or your url has a % in it | 04:58 |
| lifeless | igc: and thank you for the excuse to write some code :) | 04:59 |
| igc | lifeless: anytime :-) | 05:21 |
| lifeless | igc: so on commit | 05:22 |
| lifeless | igc: I think you should spend say 2 hours just doing it. At any blockage cry for a hand | 05:23 |
| lifeless | if at the end of that it looks like indefinite deferral, stop and I'll cave or something | 05:23 |
| lifeless | OTOH its in your head, and you've already figured out the bits needed. | 05:23 |
| igc | lifeless: well, I'm not convinced the layering is right to be honest | 05:24 |
| igc | record_iter_changes ... | 05:24 |
| igc | claims to take the results of iter_changes but it doesn't | 05:24 |
| igc | so you need to do the mssing -> delete dance for example | 05:24 |
| lifeless | by which you mean iter_changes isn't compatible with it ? | 05:24 |
| igc | so I wonder whether ... | 05:25 |
| igc | record_iter_changes ought to be handling that, and the parent yielding | 05:25 |
| igc | the trouble is ... | 05:25 |
| igc | record_iter_changes is *5* pages in length | 05:25 |
| igc | not exactly easy to hack on | 05:26 |
| igc | lifeless: I've had terrible pain these last 24 hours and the pain killers aren't working ... | 05:26 |
| igc | so apologies if I'm coming across grumpy | 05:26 |
| lifeless | igc: ouch :( | 05:26 |
| lifeless | not at all | 05:27 |
| igc | dentist tomorrow but it's prably chemo frug related :-( | 05:27 |
| lifeless | you raise a good point | 05:27 |
| igc | s/frug/drug/ | 05:27 |
| lifeless | record iter changes is long, but mostly clear | 05:27 |
| igc | so, reporting aside, maybe ... | 05:28 |
| lifeless | the major data-assembly points can be turned into helpers without performance impact; its only the main loop we need to be really careful on | 05:28 |
| igc | fliter_iter_changes needs to move into commitbuilder | 05:28 |
| lifeless | commit.py needs: | 05:28 |
| lifeless | - reporting | 05:28 |
| lifeless | - awareness of missing->deleted changes so it can update the working tree | 05:28 |
| * lifeless tries to remember what 'missing' files will do when sent to ric | 05:29 | |
| abentley | poolie: While those changes might improve the userdoc, I don't see that helping us decide how to move forward with nested trees. | 05:29 |
| lifeless | get_file_with_stat will fail | 05:29 |
| lifeless | igc: ok, so ric wants something that is a subset of iter-changes (no 'missing' status) and a superset ('add parents please') | 05:30 |
| lifeless | igc: I think reporting should stay outside | 05:31 |
| igc | me too | 05:31 |
| lifeless | igc: ok, let me rephrase what I really want | 05:31 |
| lifeless | I think its gotten lost | 05:31 |
| igc | and btw, iter_changes needs to do more for commit than it currently does, e.g. unknown checking | 05:32 |
| lifeless | - specific tests for the handling of parent-adding and path-excluding | 05:32 |
| lifeless | given that the interface isn't as crystal as I recall, I won't ask that those things be in the iter_changes interface, and certainly not as a rush just before 1.15 | 05:33 |
| lifeless | so I'm fine with them outside it. | 05:33 |
| igc | and I'm happy to add those tests but ... | 05:33 |
| igc | I don't think that ought to block my interim patch :-) | 05:33 |
| lifeless | I think its easier to test those things if they are not embedded in Commit | 05:33 |
| lifeless | igc: Given I think your patch has at least one bug which such tests will catch, I think it should | 05:34 |
| lifeless | you' | 05:34 |
| lifeless | ^typo | 05:34 |
| igc | I think the parent yielding and excludes can be a decorator as you outlined and tested as such | 05:35 |
| lifeless | great | 05:35 |
| lifeless | with that done I'll be happy to approve ;) | 05:35 |
| igc | do you want the missing -> delete dance done in the same decorator | 05:35 |
| lifeless | if you want to move it across, that would be fine with me. OTOH its orthogonal to what you are trying to achieve. | 05:36 |
| igc | do we know whether a pipeline of decorators is faster than one or vice versa? | 05:36 |
| igc | I know that's ... | 05:36 |
| igc | a bit like asking how long a piece of string is | 05:36 |
| lifeless | there is a cost | 05:36 |
| lifeless | OTOH specific file commits tend to be small anyway | 05:37 |
| lifeless | commit [list of 4000 files] is rare | 05:37 |
| igc | right | 05:37 |
| igc | that's why I felt pushing the code down wouldn't gain much performance wise | 05:37 |
| lifeless | the only really-big-list commits we see that people will notice a small percentage point on is first-commit | 05:37 |
| lifeless | oh, pushing it down is about clarity and reuse for 'diff' and 'status', not about further performance wins. | 05:38 |
| igc | and that won't have excludes and specific files most likely | 05:38 |
| lifeless | exclude may gain substantially by pushing into iter_changes | 05:38 |
| lifeless | (consider -x large-directory) | 05:38 |
| === awilcox_ is now known as awilcox | ||
| lifeless | even an unchanged large directory will be a lot cheaper if you don't stat it at all | 05:39 |
| lifeless | because you won't page it in from disk etc etc | 05:39 |
| igc | lifeless: so wrt diff and status ... | 05:40 |
| igc | neither take a -x flag do they? | 05:40 |
| igc | and neither care about parent yielding? | 05:40 |
| lifeless | no, because the code is trapped in commit :) | 05:40 |
| lifeless | status should show what commit will do; it can't at the moment. | 05:40 |
| lifeless | this was an oversight when the commit -x support was accepted | 05:41 |
| igc | so, IIUIC, you're arging that status and diff ought to gain -x options once iter_changes supports an exclude parameter? | 05:41 |
| lifeless | absolutely | 05:41 |
| igc | arguing | 05:41 |
| igc | and parent yielding? That still smells like a ric special need to me | 05:42 |
| lifeless | bzr diff foo/bar -> A foo\nRM bar\n | 05:42 |
| lifeless | iter_changes can't generate valid inventory deltas without parent yielding of new parents | 05:42 |
| lifeless | that sharply limits its reuse in the core | 05:43 |
| lifeless | I appreciate your arguments for doing less, now. But I think the reasons to push these things down to iter_changes at some point are pretty strong and valid | 05:44 |
| lifeless | exclude for performance, yielding new parents for correctness in tools like fast-export, ric itself, various custom bits of code. | 05:44 |
| igc | hmm - in some ways, CommitBuilder is the inventory-delta generator | 05:45 |
| lifeless | anyhow - like I say, I've backed off from insisting you do the move to iter_changes; unless you're considering doing it, we're just idly chatting | 05:45 |
| igc | lifeless: sorry, just trying to get the right long term layering clear in my mind | 05:46 |
| lifeless | yes, thats a prime component of CommitBuilder.ric | 05:46 |
| * igc heads back to coding | 05:46 | |
| lifeless | igc: thats cool; I didn't want you to be feeling that I was still asking for it, was all. | 05:47 |
| igc | sure | 05:47 |
| lifeless | igc: have you tried pqm again? | 05:53 |
| igc | lifeless: looking much better thanks | 05:53 |
| lifeless | great | 05:53 |
| igc | thanks to spm too | 05:53 |
| spm | igc: us qlder's need to look out for each other. ;-) | 05:54 |
| igc | spm: absolutely :-) | 05:54 |
| vila | hi all | 07:01 |
| spm | morn vila! | 07:05 |
| lifeless | hi vila | 07:18 |
| lifeless | vila: how did you go with annotate? | 07:19 |
| vila | I'll really start to day, I was hoping to quickly finish fixing a bug but bmuped on a test coverage hole :-/ Then I prepared a talk for all hands... | 07:21 |
| vila | s/to day/today/ | 07:21 |
| lifeless | what talk are you giving? | 07:22 |
| vila | lifeless: I don't know if I'm the one who will be giging it, but anyway, it's about mysql users | 07:25 |
| vila | lifeless: but if you have some template around I'll buy it | 07:26 |
| lifeless | lp:~lifeless/+junk/karmic_presentations | 07:30 |
| vila | lifeless: perfect, thanks | 07:35 |
| jnz__ | Hi, bzr push --create-prefix raised an internal error after I've inserted the password: | 08:54 |
| jnz__ | bzr: ERROR: exceptions.AttributeError: 'str' object has no attribute 'get' | 08:54 |
| === Kinnison_ is now known as Kinnison | ||
| jnz__ | https://answers.launchpad.net/bzr/+question/69809 | 08:59 |
| * igc dinner | 09:20 | |
| awilkins | lifeless: The HTTP server seems to be broken for me as far back as 1.12 | 09:51 |
| awilkins | lifeless: I'm rolling back through versions to see where it starts working again | 09:51 |
| Peng_ | Whowhat is broken? | 09:51 |
| awilkins | Peng_: bzr+http:// server, on Win2k3 server / IIS / PyISAPIe | 09:51 |
| Peng_ | Oh. What goes wrong? | 09:52 |
| Peng_ | (Not that I can help, but I'm curious.) | 09:52 |
| awilkins | I'm geting "FileExists" exceptions | 09:52 |
| awilkins | When pushing | 09:52 |
| awilkins | Pulling appears to be fine | 09:53 |
| Peng_ | Oh. | 09:53 |
| awilkins | Alas, different exceptions when I turn on server-side logging | 09:54 |
| * awilkins cusses loudly | 10:06 | |
| awilkins | I upgraded the server to 1.14 and it stops working. I downgrade it back to 1.9, and it's still not working in exactly the same way. | 10:06 |
| lifeless | awilkins: file bugs | 10:06 |
| lifeless | awilkins: I'm about to start a social event, but I'll comment on them at a minumum tomorrow :) | 10:07 |
| lifeless | awilkins: [of course, debugging it yourself is great too] | 10:07 |
| awilkins | I don't think it's necessarily a bzr problem | 10:07 |
| awilkins | Yes, I think a few hours with a filesystem debugger and contemplating dark thoughts about people who install antivirus on servers is required | 10:08 |
| awilkins | It seems similar to a bug in the atomic rename thing | 10:08 |
| awilkins | Well, "bug" | 10:08 |
| awilkins | As in a "Windows is crap bug" | 10:08 |
| awilkins | Can you reindex a repository? | 10:09 |
| awilkins | I'm getting bzr: ERROR (ignored): GraphIndex('bzr+http://w ..... | 10:10 |
| awilkins | But that's not where it stops | 10:10 |
| bialix | vila: hi | 10:15 |
| vila | bialix: Hi Alexander | 10:15 |
| bialix | bonjour monsieur | 10:15 |
| bialix | I need to test some unicode thing | 10:16 |
| bialix | please, tell me how you enter accented characters in French? | 10:16 |
| jml | like in café? | 10:17 |
| bialix | yes | 10:17 |
| jml | on my computer, I use the Compose key | 10:17 |
| bialix | Hm? I don't see compose key | 10:18 |
| vila | u"Cet été au café".encode('UTF-8') | 10:18 |
| vila | 'Cet \xc3\xa9t\xc3\xa9 au caf\xc3\xa9' | 10:18 |
| jml | Compose+' Compose+e | 10:18 |
| jml | bialix: it's kind of a virtual key, mine is bound to Right Alt | 10:18 |
| vila | jml: compose key on windows ? :-) | 10:18 |
| bialix | vila: I need to test command line behaviour | 10:18 |
| jml | on Windows... who knows. | 10:18 |
| bialix | maybe Vincent knows? | 10:18 |
| jml | on OS X its Option-' e IIRC | 10:18 |
| vila | bialix: I *never* use accented letters from command line, but the trick on windows I remember it via Alt-nnn sequences | 10:19 |
| bialix | oh; I see | 10:19 |
| vila | now, the sequence for accented letters... you may know better ? :-/ | 10:20 |
| bialix | ╙ | 10:20 |
| bialix | ╙▓ | 10:20 |
| bialix | h,, | 10:20 |
| bialix | hmm | 10:20 |
| * bialix going to test alt codes | 10:21 | |
| bialix | It seems like french keyboard layout very different from qwerty | 10:21 |
| vila | oh, yes | 10:21 |
| jml | I blame Napoleon :P | 10:21 |
| bialix | :-) | 10:22 |
| vila | é is on '2' with a french layou | 10:22 |
| vila | t | 10:22 |
| bialix | yes; it is | 10:23 |
| bialix | this will be enough for me, thanks | 10:23 |
| vila | ok, np | 10:24 |
| bialix | Français | 10:26 |
| === fta_ is now known as fta | ||
| jnz__ | Hi, there are some trouble if I use python 2.6 to run bazaar? I see that there are some warning using deprecated lib and an error trying to use `get' method in `str' (that doesn't exist now). | 10:42 |
| james_w | jnz__: what's the full message? | 10:44 |
| jnz__ | AttributeError: 'str' object has no attribute 'get' https://answers.launchpad.net/bzr/+question/69809 | 10:45 |
| jnz__ | it's the same bug I've reproduced | 10:45 |
| jnz__ | (but on linux) | 10:46 |
| jnz__ | the fact is that I can't remove svn plugin | 10:47 |
| james_w | I thought that had been fixed, but I can't find the bug number now | 10:48 |
| Peng_ | That question links to the bug. | 10:50 |
| Peng_ | jnz__: The AttributeError has nothing to do with your Python version. | 10:50 |
| Peng_ | jnz__: If you're running a recent version of bzr, all of the deprecation warnings and other Python 2.6 issues should have been fixed. If you're still seeing any, they're probably in third-party libraries. In any case, file bugs if they haven't been fixed. | 10:51 |
| Spaz | 'ello | 11:38 |
| Spaz | i'm having a problem with loggerhead | 11:38 |
| Spaz | http://pastebin.ca/1421449 | 11:38 |
| awilkins | "Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'") | 11:38 |
| Spaz | i get that on every request. | 11:38 |
| awilkins | That's from LP, on doing "bzr branch lp:bzr/1.14" ; oopsie | 11:38 |
| === arjenAU2 is now known as arjenAU | ||
| Peng_ | Spaz: What version of Loggerhead? | 11:47 |
| Peng_ | Oh, trunk. | 11:48 |
| Peng_ | Spaz: As a workaround, you can revert a few revisions; that code was only added recently. | 11:50 |
| Spaz | ah ok | 11:50 |
| Peng_ | (in r335) | 11:50 |
| Peng_ | I honestly don't get it. branch_url is a method; it's defined 5 lines above! | 11:51 |
| Peng_ | My only guess is that some file, perhaps serve-branches, is from an old version that does something funny. | 11:51 |
| Peng_ | Oh, you're using start-loggerhead? I never tested that. | 11:55 |
| Spaz | yep. | 11:55 |
| Peng_ | Hmm. I don't know the start-loggerhead code at all. :\ | 11:55 |
| Peng_ | branch_url never used to be called, so if it was set to the wrong thing, it wouldn't have been noticed until I started using it in r335. | 11:56 |
| Spaz | reverting r335 fixes it | 11:56 |
| Spaz | Peng_, ^ | 11:58 |
| Peng_ | Ah, I see where it goes wrong. | 12:00 |
| Spaz | Peng_, you're a loggerhead dev? :p | 12:01 |
| Peng_ | Spaz: Allegedly. | 12:02 |
| Spaz | :P | 12:02 |
| Peng_ | Um, I'm not sure what the solution should be, though. Easiest would probably just be renaming hte "branch_url" method so it won't get clobbered. | 12:03 |
| Spaz | occam's razor :p | 12:03 |
| Spaz | the simplest solution is usually the correct one | 12:04 |
| Peng_ | Not necessarily. | 12:04 |
| Peng_ | (Well, hence it saying "usually" instead of "always"...) | 12:04 |
| Spaz | it's not always, but most of the time it is | 12:04 |
| Spaz | at least i like to think so | 12:04 |
| Spaz | :) | 12:04 |
| Peng_ | The method didn't have a great name anyway. | 12:05 |
| Peng_ | Y'know, if you used serve-branches, it wouldn't be broken. ;D | 12:14 |
| Spaz | Peng_, start-loggerhead suits my needs better | 12:15 |
| Spaz | :p | 12:15 |
| Spaz | 1) looks better, 2) extremely small amount of projects | 12:16 |
| Peng_ | It looks better? | 12:16 |
| Spaz | Peng_, see http://web-bzr.wilcox-tech.com :p | 12:16 |
| Spaz | for one project it looks a lot nicer | 12:16 |
| Spaz | oops awos-bzr.wilcox-tech.com | 12:17 |
| Peng_ | Oh, nifty. | 12:18 |
| Peng_ | But if people use start-loggerhead, I have to figure out how to use it so I can actually test it. :P | 12:19 |
| Peng_ | Spaz: I filed bug 375948. | 12:19 |
| ubottu | Launchpad bug 375948 in loggerhead "loggerhead.apps.config clobbers BranchWSGIApp.branch_url method" [Undecided,New] https://launchpad.net/bugs/375948 | 12:19 |
| jelmer | I thought start-loggerhead was going away? | 12:21 |
| Peng_ | jelmer: That's the plan. | 12:21 |
| Peng_ | jelmer: But start-loggerhead can still do some things serve-branches can't. | 12:21 |
| === vxnick_ is now known as vxnick | ||
| Peng_ | Spaz: I've pushed a workaround to lp:loggerhead | 12:36 |
| Spaz | thanks | 12:37 |
| Peng_ | Well, the good news is that from now on I'll test start-loggerhead. :P | 12:39 |
| Spaz | hehe | 12:51 |
| Peng_ | Well, after converting one branch to a stacked branch, I saved 2 MB of disk space, but I can no longer push. Perhaps not worth it? | 13:04 |
| jelmer | lifeless: ping | 13:06 |
| Peng_ | What's a simple command I can use that will lock the branch? Without having to use some "python -c 'import bzrlib'" magic? | 13:07 |
| Peng_ | (I don't want to leave the lock in place or anything, just see if one can be taken out.) | 13:08 |
| Peng_ | Never mind. | 13:13 |
| Peng_ | beuno: ping | 13:14 |
| awilkins | Peng_: I think you just need to create a file in the right place | 13:15 |
| awilkins | lifeless: ping? | 13:23 |
| awilkins | I found the problem ; it's creating the same pack twice | 13:23 |
| awilkins | Which win32 doesn't like because it's renaming a file from "upload" to "packs" but because they are named after their md5, the file is already there and on win32 you can't rename a file to an existing destination | 13:24 |
| awilkins | Deleting the pack appears to have expunged the problem. Maybe it was linked to the jailbreak thing... | 13:29 |
| awilkins | Maybe the jailbreak error puts the repo into this state. | 13:29 |
| === nevans1 is now known as nevans | ||
| beuno | Peng_, hi | 14:36 |
| Peng_ | Ah, hello. | 14:38 |
| Peng_ | beuno: I was just curious, in Loggerhead, what is BranchWSGIApp.branch_link? All it says is that it's only used by LP. | 14:39 |
| beuno | Peng_, I don't remember what we use it for | 14:39 |
| beuno | but I can find the glue code and figure it out | 14:39 |
| Peng_ | beuno: Well, it's not important, so you don't have to bother. | 14:41 |
| beuno | Peng_, I think it was something about showing the branch URL in LH | 14:42 |
| === Spaz is now known as zSpaz | ||
| === zSpaz is now known as Spaz | ||
| === serg_ is now known as serg | ||
| igc | night all | 15:01 |
| Peng_ | igc: Good night. | 15:05 |
| lifeless | awilkins: bzr is meant to not do that; ah | 15:08 |
| lifeless | awilkins: bzr hada stale pack it didn't knowabout anymore | 15:08 |
| lifeless | awilkins: thats why the rename was being attempted at all | 15:08 |
| lifeless | awilkins: please file a bug | 15:08 |
| lifeless | awilkins: we should handle this case | 15:08 |
| Peng_ | beuno: Thanks for the review. :) | 15:27 |
| beuno | Peng_, thanks for all the work | 15:28 |
| Peng_ | :) | 15:31 |
| === beuno_ is now known as beuno | ||
| luke-jr_ | blah, bzr-svn doesn't merge :< | 16:58 |
| SamB | luke-jr: say what? | 16:58 |
| luke-jr_ | SamB: I can't merge svn commits and push my stuff to it | 17:01 |
| luke-jr_ | it errors | 17:01 |
| jelmer | luke-jr_: what error do you get exactly? | 17:02 |
| luke-jr_ | I need to make a new branch of the svn, merge my bzr repo into that, then push that | 17:02 |
| luke-jr_ | bzr: ERROR: exceptions.AssertionError: Expected <CachingRevisionMetadata for revision 2422, path vxmlb/tags/no_spm_count_no_ext_grammars_no_playfile in repository 'f396537e-aa06-0410-a58a-90fff5392f0b'> got <CachingRevisionMetadata for revision 382, path tags/no_spm_count_no_ext_grammars_no_playfile in repository 'f396537e-aa06-0410-a58a-90fff5392f0b'> | 17:02 |
| luke-jr_ | oops, forgot to edit paths | 17:02 |
| luke-jr_ | don't store that in a bug report or such as-is please :) | 17:02 |
| jelmer | luke-jr_: there's an open bug about this, will be fixed before 0.6.0 (i.e. in a few days) | 17:03 |
| SamB | luke-jr: if there's some secret info in there, I can't imagine what it might be! | 17:21 |
| SamB | or are you just embarrassed? | 17:21 |
| phinze | seeking bzr one liner... how to determine when file "path/to/file" was removed? | 17:30 |
| Peng_ | "bzr log"...might work? in recent versions? if the file was deleted recently? | 17:31 |
| Peng_ | It won't be fast, since the only way to do it is to check each revision 1 at a time. | 17:31 |
| phinze | bzr: ERROR: Path unknown at end or start of revision range: .... on 1.14.1 | 17:32 |
| SamB | phinze: do you remember a revision where it was still alive ? | 17:32 |
| Peng_ | Guess not, then. | 17:32 |
| phinze | yeah i've got one rev when it was alive | 17:32 |
| SamB | maybe that can help? | 17:32 |
| phinze | i'll try a bzr log $OLDREV.. --verbose --short | grep D | grep filename | 17:34 |
| phinze | something like that | 17:34 |
| phinze | and wait :) | 17:35 |
| Peng_ | Like I said, with the current design it can't be fast. For that reason, it's not encouraged by the UI.. | 17:36 |
| phinze | looks like it was in the last 20 revs | 17:36 |
| phinze | i'll narrow it down | 17:36 |
| phinze | might look into bzr-undelete plugin in the future | 17:36 |
| phinze | https://launchpad.net/bzr-undelete | 17:37 |
| SamB | did I mention the bisect plugin yet? | 17:44 |
| bmorris | Does anybody know of a good tutorial for setting up the pqm? | 17:51 |
| Ken69267 | how does one checkout a branch from googlecode with bzr-svn? I can't seem to specify the username it wants for authentication | 18:50 |
| Peng_ | Ken69267: Yeah, that's kind of a bug. When Bazaar tries to detect what type of branch it is, it asks for .bzr/smart, and Google asks for auth. | 18:51 |
| Peng_ | Ken69267: You can use svn+http:// to work around it, depending on your version of bzr-svn. | 18:52 |
| Ken69267 | yeah I tried svn+https://, but my username is different than my shell. svn+https://username@ doesn't seem to work | 18:53 |
| Peng_ | Fortunately, I don't care about Google Code much, so I haven't bothered to solve this. Or bug jelmer much. | 18:54 |
| Peng_ | Not so fortunate for you, though. :\ | 18:54 |
| jelmer | Ken69267: if you don't specify a username bzr should ask you if you have a new enough bzr | 18:58 |
| Lo-lan-do | Hi all | 19:19 |
| jelmer | hey Lo-lan-do | 19:20 |
| Lo-lan-do | :-) | 19:20 |
| Lo-lan-do | I get different errors now... I'll pastebin them, shall I? | 19:21 |
| jelmer | Lo-lan-do: can you mail them perhaps? | 19:21 |
| Lo-lan-do | Sure | 19:21 |
| * jelmer back in ~30 min | 19:23 | |
| Lo-lan-do | Mailed. Take your time, I'm also struggling with an unrelated shared library problem :-) | 19:26 |
| Ken69267 | jelmer: bzr 1.14.1 and bzr-svn 0.5.4 here, doesn't prompt for username :/ | 19:36 |
| jelmer | Ken69267: you need bzr.dev I think | 19:50 |
| jelmer | Ken69267: does http://username@... work (no svn+) ? | 19:52 |
| Ken69267 | jelmer: no, bzr bombs out with a pycurl error | 20:01 |
| Ken69267 | (with https://user@) | 20:01 |
| jelmer | Ken69267: ah | 20:04 |
| Ken69267 | allwell, I rarely use googlecode anyway | 20:04 |
| jelmer | Ken69267: so, this should be fixed in 1.15 | 20:04 |
| jelmer | Lo-lan-do: replied | 20:07 |
| beuno | Peng_, ready for the rich-root-ization of LH? | 20:12 |
| beuno | (I won't do it *now*, but in a few hours) | 20:12 |
| Lo-lan-do | jelmer: Got it, thanks. | 20:13 |
| Peng_ | beuno: Ready as I'll ever be. | 20:13 |
| Peng_ | Upgrade stacked-on branches first, right? | 20:13 |
| beuno | Peng_, yes, the ones you care about | 20:13 |
| beuno | what I'm going to do | 20:13 |
| beuno | is upload a new branch | 20:13 |
| beuno | leave the current one as-is | 20:13 |
| beuno | and just change the developemnt focus | 20:13 |
| Peng_ | Oh, why? | 20:14 |
| beuno | *maybe* that won't break stacked-on branches | 20:14 |
| Peng_ | Ah. | 20:14 |
| Lo-lan-do | jelmer: s/graphwalker/graph_walker/ in dulwich/repo.py:231 | 20:15 |
| beuno | Peng_, this is me trying to figure out the best upgrade strategy :) | 20:15 |
| jelmer | Lo-lan-do: thanks, fixed | 20:15 |
| Peng_ | I'm really apathetic at the moment, so I won't have any opinion unless someone makes a Rich-root-tan or something. | 20:16 |
| * beuno hugs Peng_ | 20:16 | |
| Peng_ | :D | 20:17 |
| Peng_ | Anyway, switching out the branches makes sense, though it'll be inconvenient for subscribers. | 20:17 |
| Lo-lan-do | jelmer: I still get NameError: global name 'BzrDir' is not defined; did you push? | 20:17 |
| beuno | yeah, not sure what the best inconvenience is yet | 20:17 |
| Peng_ | And the linked bugs and merge proposals. | 20:18 |
| jelmer | Lo-lan-do: yeah | 20:18 |
| jelmer | Lo-lan-do: where are you pulling from? | 20:18 |
| beuno | Peng_, so what do you think? break all stacked-on branches or loose linkage? | 20:19 |
| Peng_ | I wonder if you could rename the branch, push a new non-rr branch as lp:~loggerhead-team/loggerhead/trunk, then upgrade the original branch to rr. | 20:19 |
| Peng_ | Did that make sense? | 20:19 |
| beuno | ah | 20:19 |
| Lo-lan-do | jelmer: http://people.samba.org/bzr/jelmer/bzr-git/trunk or lp:bzr-git | 20:19 |
| Peng_ | This sounds like a job for...staging.lp.net! | 20:19 |
| beuno | Peng_, that's interesting | 20:19 |
| Lo-lan-do | (And s/bzr-git/dulwich/ for dulwich) | 20:20 |
| beuno | Peng_, are you going to try that? | 20:20 |
| beuno | or want me to? | 20:20 |
| jelmer | Lo-lan-do: hmm, odd, that location should work | 20:20 |
| Peng_ | beuno: Yeah, I'll try it. | 20:21 |
| jelmer | Lo-lan-do: oops, forgot to commit | 20:21 |
| jelmer | Lo-lan-do: sorry, pushed properly now | 20:21 |
| beuno | Peng_, \o/ | 20:21 |
| Peng_ | How do staging URLs work? lp://staging/~user/project/branch? | 20:23 |
| beuno | yeap | 20:23 |
| Peng_ | Thanks. | 20:23 |
| beuno | lifeless, igc, should the traceback for VFS usage be sput out to stdout instead of .bzr.log? | 20:24 |
| Peng_ | OK, what was my plan again? :P Blinkblink. Anyway. | 20:24 |
| Peng_ | I should be doing this on my faster machine with the better connection. | 20:24 |
| beuno | Peng_, your amazing plan is: rename trunk, push a non-r-r as trunk, upgrade old-trunk, rename old-trunk to new trunk, see if everything's alright :) | 20:25 |
| ja1 | beuno: I that only happens when you use -Dhpss, IIRC | 20:25 |
| Peng_ | Crap, it tried to stack on lp:loggerhead, which obviously screwed up. | 20:25 |
| ja1 | And I think there is argument where it should go | 20:25 |
| beuno | ja1, ah, makes sense | 20:25 |
| Peng_ | Actually, it says "not a branch". | 20:25 |
| beuno | I have that set by default | 20:25 |
| ja1 | I think someone mentioned that it should be muttered(), and then realized that it also helps force us to fix things :) | 20:25 |
| beuno | rockstar, how do you push to staging? mwhudson around yet? | 20:25 |
| Lo-lan-do | jelmer: Yay, progress. New errors at http://pastebin.com/d27aef86d :-) | 20:25 |
| ja1 | otherwise, I would think it should be 'noted' so it goes to stderr + .bzr.log | 20:25 |
| Peng_ | Screw it, I won't use staging. | 20:25 |
| ja1 | brb | 20:25 |
| rockstar | beuno, bzr push lp://staging/... | 20:26 |
| beuno | wow | 20:27 |
| beuno | HPSS calls: 46 (11 vfs) SmartSSHClientMedium(connected=False, username=u'beuno', host='bazaar.launchpad.net', port=None) | 20:27 |
| beuno | argh | 20:27 |
| Peng_ | How do you force a push to not stack? Downgrade to Branch6? | 20:27 |
| beuno | I was about to ask that same thing ;) | 20:28 |
| * beuno will try pushing to +junk and then renaming | 20:28 | |
| Wyvern | Hey! | 20:31 |
| Peng_ | What will upgrading to rich-roots do to all of the stacked branches in lp:~*/loggerhead? This may be a problem. | 20:31 |
| Wyvern | Question: How can I cancel an bzr add? That is before commit. | 20:32 |
| Lo-lan-do | bzr rm --keep | 20:32 |
| Wyvern | Thank you. | 20:33 |
| Peng_ | Great, push was taking forever because I forgot that ssh-agent wasn't running! :P | 20:35 |
| Peng_ | Using Branch6 did not prevent it from stacking. | 20:36 |
| Peng_ | So I'm kind of stuck now. | 20:36 |
| Peng_ | I suppose I could dig out bzr 1.5. | 20:37 |
| jelmer | Lo-lan-do: pushed another fix | 20:39 |
| Peng_ | It may be possible to work around the default stacking policy by using a Branc6 mirrored branch. | 20:40 |
| Lo-lan-do | jelmer: Yay, cloning a git branch through bzr-upplad-pack now works :-) | 20:41 |
| jelmer | woot :-) | 20:41 |
| Peng_ | beuno: These stacking issues are really killing my attention span. :P | 20:41 |
| beuno | Peng_, https://code.edge.launchpad.net/~loggerhead-team/loggerhead/rich-trunk | 20:42 |
| beuno | :) | 20:42 |
| beuno | (pushed to +junk, then moved it) | 20:42 |
| Peng_ | Ah, clever. | 20:43 |
| beuno | Launchpad has trained me to be sneaky | 20:43 |
| Peng_ | Heheh, push peaked at 731 KB/sec. >:D | 20:45 |
| Peng_ | beuno: Wait, I didn't think this out. Could you do me a favor and subscribe to https://code.edge.launchpad.net/~mnordhoff/loggerhead/trunk ? | 20:46 |
| Peng_ | Wait. | 20:47 |
| * beuno waits twice | 20:47 | |
| Peng_ | Yeah, that branch. | 20:47 |
| Peng_ | Heh. | 20:47 |
| Peng_ | It would've been better to use staging so I could link it to a bug report, but oh well. | 20:48 |
| beuno | Peng_, done | 20:48 |
| Peng_ | beuno: Thanks. | 20:48 |
| Peng_ | brb | 20:50 |
| bialix | jam: hi | 20:51 |
| bialix | yep | 20:51 |
| bialix | jam: hi | 20:51 |
| jam | hi bialix | 20:51 |
| jam | having some networking issues here, so I may come and go | 20:51 |
| bialix | I've prepared the patch for unicode cmd line @ win32 | 20:52 |
| Peng_ | Is it just me or does branch --stacked make a painful number of ssh connections? | 20:52 |
| bialix | jam: I suspect you're busy with other patches, I'm just hope you will be able to look at my patch | 20:52 |
| bialix | Peng_: 3 or 4? | 20:53 |
| Peng_ | bialix: I killed it and fixed ssh-agent after 6. | 20:53 |
| Peng_ | OK, *maybe* 5. | 20:54 |
| bialix | it does not sound right | 20:54 |
| Peng_ | Reconciling over bzr+ssh is not so efficient. :P | 20:56 |
| beuno | Peng_, no, I did all of that locally :) | 20:57 |
| jam | bialix: I'll try to give it a shot. I'll mention that with my network going wonky, I'm not getting all of my email | 20:57 |
| Peng_ | What's the easiest way to upgrade a remote branch? Doing it remotely? If so, and you need to do reconcile too... | 20:57 |
| jam | if you want to CC my gmail account, it may be a bit more trustworthy | 20:58 |
| Peng_ | Anyway, this is just for fun anyway, and I hope LP won't mind wasting 30 MB of bandwidth. :P | 20:58 |
| jam | Peng_: *reconciling* is not so efficient | 20:58 |
| Peng_ | So far it's at 18 MB of bandwidth. :D | 20:58 |
| jam | bialix: So is this the problem that qbzr is trying to pass unicode arguments to a bzr subprocess? | 20:58 |
| jam | and is going through "OEM" encoding | 20:59 |
| bialix | jam: I'm using gmane, what about http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cguf7hb%24k3h%241%40ger.gmane.org%3E | 20:59 |
| beuno | Peng_, it's called "research" | 20:59 |
| jam | which fails for certain unrepresentable bits? | 20:59 |
| bialix | jam: AFAICT, qbzr trying to pass unicode argumets to bzr. but any python program unable to retrieve unicode right, only as plain strings | 21:00 |
| jam | bialix: but this only helps when using CreateProcessW | 21:00 |
| jam | and *doesn't* do anything for the actual command line | 21:01 |
| jam | At least, I'm pretty sure "cmd.exe" has a specific encoding | 21:01 |
| jam | and isn't generic about Unicode support | 21:01 |
| bialix | jam: I've tested manually in cmd.exe shell | 21:01 |
| bialix | GetCommandLineW is able to get right unicode | 21:02 |
| jam | bialix: sure, but it would other ways, too | 21:02 |
| jam | My question is, can you type جوجو in your Russian cmd.exe shell? | 21:02 |
| bialix | "would other ways"? | 21:02 |
| jam | bialix: if the strings are passed in as OEM, and then they are decoded from OEM | 21:02 |
| jam | things should work | 21:02 |
| bialix | I don't understand Arabic | 21:02 |
| jam | bialix: you don't have to | 21:03 |
| jam | it is just a few characters for you to try | 21:03 |
| bialix | but I've learnt French, and I can type French in my shell | 21:03 |
| jam | well, IDLE doesn't like me. Giving: Unsupported characters in input | 21:03 |
| bialix | actually I have netbook with non-Russian Windows XP | 21:04 |
| Lo-lan-do | jelmer: Minor patch: http://pastebin.com/f5f7eb376 | 21:04 |
| jam | bialix: so my point of using Arabic is that it is quite unlikely to be on a given code page | 21:04 |
| bialix | there I can type non-russian characters without problem | 21:04 |
| jam | unlike French characters | 21:04 |
| bialix | French is from cp1251 | 21:04 |
| bialix | while Russian is cp1251 | 21:04 |
| jam | bialix: well, on a 'non-Russian" windows, I would want to try Russion chars | 21:04 |
| jam | bialix: cp1251 == cp1251 | 21:04 |
| bialix | cp1251 has no room for non-cyrillic | 21:04 |
| bialix | of course it works with Russian char | 21:05 |
| jam | bialix: can you type a couple cyrillic chars for me to test with? | 21:05 |
| jam | or give me their code points | 21:06 |
| Peng_ | So far, upgrade over bzr+ssh seems disgustingly inefficient. | 21:06 |
| bialix | I'm just tested on my Russian Windows XP | 21:06 |
| bialix | I can type French here too | 21:06 |
| Peng_ | I could probably twiddle with hitchhiker or sftp to accomplish the same thing, but that takes more thinking. | 21:06 |
| bialix | jam: here is Test in Russian: Тест | 21:06 |
| jam | bialix: any chance you could put that in hex codes for me? | 21:07 |
| jam | cygwin doesn't like it, and neither does IDLE | 21:07 |
| jam | and vim just gives me ???? | 21:07 |
| jam | bialix: pasting those chars into cmd.exe gives me ???? | 21:08 |
| bialix | jam: are you using vim wit console or GUI interface? | 21:08 |
| jam | bialix: vim w/ gui | 21:08 |
| Peng_ | What will changing the developer focus do? Change what new branches automatically stack on? Will it change old branches too? Cuz that'd be a problem. | 21:08 |
| jam | It could just be Pidgin not copying them correctly | 21:08 |
| jam | If I do 'chcp 1251' in cmd.exe I at least get characters when I paste your cyryllic | 21:09 |
| bialix | jam: re cmd.exe: right-click on cmd.exe window button on task panel, select Properties -> Font -> Lucida Console | 21:09 |
| jam | but it comes out as: pi sigma +/- >= | 21:09 |
| bialix | Lucida is unicode font | 21:10 |
| Peng_ | FYI? Upgrade over bzr+ssh is horribly slow. Using hitchhiker is definitely a better idea. | 21:10 |
| jam | bialix: ok, so it works if I 'chcp 1251' and then paste | 21:10 |
| bialix | it will show you right characters | 21:10 |
| jam | And it looks like Тест | 21:10 |
| jam | but with the default chcp (437) it fails | 21:10 |
| bialix | yeah, is it | 21:10 |
| bialix | try Lucida | 21:10 |
| jam | ah, it worked this time | 21:10 |
| jam | weird | 21:10 |
| jelmer | Lo-lan-do: thanks | 21:10 |
| bialix | default is OEM font it's not unicode | 21:11 |
| jam | bialix: however, it gives me just [] for Arabic | 21:11 |
| * bialix adding Arabic keyboard | 21:11 | |
| Peng_ | beuno: This upgrade will probably take half an hour. Unless I get bored, kill it and do it more efficiently, you'll have to wait that long to see how it pans out. Although I've probably done enough now. | 21:11 |
| beuno | Peng_, I have about half a million things to do today | 21:12 |
| beuno | so I'll probably be around here forever | 21:12 |
| bialix | jam: I have not Arabic keyboard settings on my Russian XP | 21:13 |
| Peng_ | beuno: Although I'm not finished, I'm pretty sure my evil plan will work. So I'd vote for doing it on lp:loggerhead. | 21:13 |
| mwhudson | Peng_: loggerhead.apps.config is a terrible terrible thing | 21:13 |
| Peng_ | mwhudson: :D | 21:13 |
| jam | bialix: you have Cut & Paste don't you? | 21:13 |
| beuno | Peng_, I think it will. If it does, I will create a document so everyone else follows this path | 21:14 |
| beuno | I'm willing to break everything in the name of research | 21:14 |
| bialix | jam: yes, I can, but it seems my Russian XP lacks of Arabic fonts. I see 4 squares instead of real chars | 21:15 |
| bialix | but Wordpad paste them OK | 21:15 |
| mwhudson | Peng_: also i don't care about it at all from a launchapd pov, so pleae feel free to do whatever you like to it :) | 21:16 |
| bialix | jam: will try with cmdline.py script | 21:16 |
| Peng_ | mwhudson: OK, thanks. :) | 21:16 |
| jam | bialix: well, I *have* Arabic fonts installed, and I only see 4 squares in cmd.exe :) | 21:17 |
| bialix | jam: cmdline.py is able to see it! | 21:18 |
| bialix | C:\Temp>python cmdline.py جوجو | 21:18 |
| bialix | ['cmdline.py', '????'] | 21:18 |
| bialix | [u'cmdline.py', u'\u062c\u0648\u062c\u0648'] | 21:18 |
| bialix | ha! | 21:18 |
| jam | bialix: your public branch is a bit wonky | 21:18 |
| bialix | do you see it? | 21:18 |
| jam | C:/work... | 21:18 |
| jam | I don't know where 'cmdline.py' is | 21:18 |
| jam | but your paste here looks appropriate | 21:18 |
| bialix | http://launchpadlibrarian.net/26668118/cmdline.py | 21:19 |
| Peng_ | OK, I think I've got it all worked out, though I've never fully put it together. | 21:19 |
| bialix | jam: my public branch is wonky 'coz I don;t have public branch | 21:19 |
| jam | hmm... using python25 I get: | 21:20 |
| jam | NameError: global name 'WINFUNCTYPE' is not defined | 21:20 |
| Peng_ | beuno: You want the rich version of trunk to be called "trunk-rich"? | 21:20 |
| jam | ah, I know why | 21:20 |
| jam | just a sec | 21:20 |
| beuno | Peng_, I... don't care as much :) | 21:20 |
| jam | k, I get: | 21:20 |
| bialix | C:\Temp>python -V | 21:20 |
| bialix | Python 2.5.4 | 21:20 |
| jam | C:\Users\jameinel\dev\bzr\patches>C:\Python25\python cmdline.py جوجو | 21:21 |
| jam | ['cmdline.py', '????'] | 21:21 |
| jam | [u'cmdline.py', u'\u062c\u0648\u062c\u0648'] | 21:21 |
| jam | (I was accidentally just using 'python' which would be cygwin python) | 21:21 |
| jam | Anyway, I get [] in the console | 21:21 |
| jam | but it does seem to support those characters | 21:21 |
| bialix | the same here | 21:21 |
| jam | even if Lucida Console can't draw them | 21:21 |
| bialix | yep | 21:21 |
| jam | interestingly enough, I've already set my cygwin shell to use Lucida Console | 21:21 |
| jam | Though in that shell | 21:22 |
| jam | I can't write Arabic characters | 21:22 |
| jam | weird | 21:22 |
| bialix | IIRC in Vista there is another shell font used | 21:22 |
| jam | (chcp is also not found) | 21:22 |
| jam | bialix: there are only 2 choices | 21:22 |
| jam | Lucida, and RAster | 21:22 |
| jam | Raster | 21:22 |
| jam | just interesting that cygwin.bat mutates its shell enough | 21:23 |
| Peng_ | beuno: Wait, you used "rich-trunk". Anyway, *I* like "trunk-rich". :P | 21:23 |
| bialix | IMO raster is non-unicode | 21:23 |
| beuno | Peng_, you've earned the right to name it whatever floats your boat | 21:23 |
| bialix | jam: yes, cygwin does wonly things | 21:23 |
| Peng_ | beuno: Hehe, okay. | 21:25 |
| bialix | jam: just curious: how you type Arabic on Windows? | 21:26 |
| bialix | alt codes? | 21:26 |
| Peng_ | beuno or anyone interested: Here's the sequence of commands that should do it: http://paste.pocoo.org/show/117139/ | 21:29 |
| Peng_ | It's not even that crazy. | 21:29 |
| beuno | Peng_, so it's done? | 21:29 |
| beuno | thanks for that, btw | 21:30 |
| Peng_ | beuno: I haven't actually done it yet. I could, though! | 21:30 |
| Peng_ | beuno: Do you want me to? | 21:30 |
| beuno | Peng_, yes! | 21:30 |
| beuno | go for it | 21:30 |
| beuno | let me know if I need to change the dev focus | 21:30 |
| beuno | or if you can | 21:30 |
| jam | bialix: no, I have an alternate keyboard layout | 21:30 |
| jam | and switch between them | 21:30 |
| jam | Alt+Shift+0 == arabic | 21:30 |
| jam | Alt+Shift+1 == qwerty | 21:31 |
| jam | Alt+Shift+2 == dvorak | 21:31 |
| Peng_ | beuno: I've never done it before, but I probably can. Thanks, I'll ask you if I need to. | 21:31 |
| bialix | ok, I understand | 21:31 |
| jam | argh.... it seems when I contacted support to get my internet access working, they disabled my email account because I claimed not to use it | 21:31 |
| jam | which I don't | 21:31 |
| jam | but I use their server to forward my home email | 21:31 |
| jam | (relay) | 21:31 |
| Peng_ | Whoops, I left that bzr upgrade over bzr+ssh running. It's at 56 MB of bandwidth and like 2/3 of the way through! :D | 21:32 |
| bialix | jam: do you want more unicode testing from me? | 21:36 |
| jam | bialix: I don't know any more I need right now | 21:38 |
| jam | I'll play with it a bit and let you know | 21:38 |
| bialix | thank you | 21:38 |
| * bialix going offline | 21:39 | |
| bialix | bye | 21:39 |
| rockstar | abentley, I don't see a way to get a branch's repository format. | 21:41 |
| Peng_ | Um, hmm. I may have just made lp:loggerhead stack on itself. Or something equally untoward. Oops. | 21:42 |
| abentley | rockstar: branch.repository._format ? | 21:43 |
| === ja1 is now known as jam | ||
| Peng_ | beuno & mwhudson: lp:loggerhead has been upgraded to rich-roots. Here's the final list of commands, if I copied them down correctly: http://paste.pocoo.org/show/117145/ | 21:54 |
| Peng_ | ...I guess I should upgrade my local branches. | 21:54 |
| Peng_ | Wait, you upgrade stacked-on before stacked branches, right? | 21:55 |
| beuno | the other way around :) | 21:55 |
| Peng_ | Oh, oops. OK, easy to fix. | 21:56 |
| beuno | hrm | 21:57 |
| Peng_ | Yep, uh, that went disastrously. | 21:57 |
| beuno | branches still seem to work | 21:57 |
| beuno | https://code.edge.launchpad.net/~mwhudson/loggerhead/which-mainline-merged | 21:58 |
| Peng_ | They're explicitly stacked on lp:~loggerhead-team/loggerhead/trunk, and hopefully that won't get changed. | 21:58 |
| beuno | well, the UI is wronk then | 21:59 |
| beuno | but yes | 21:59 |
| beuno | \o/ | 21:59 |
| beuno | success! | 21:59 |
| beuno | Peng_, you've solved a very complicated problem for Launchpad | 21:59 |
| beuno | I will make sure you get a tshirt | 21:59 |
| beuno | please email me your address :) | 21:59 |
| james_w | hey thumper | 22:00 |
| mwhudson | yeah, unfortunately stacked on is done by url on launchpad, not branch identity | 22:00 |
| Peng_ | mwhudson: That's a good thing for us here. | 22:00 |
| james_w | launchpad has foxed me | 22:01 |
| thumper | hey james_w | 22:01 |
| james_w | https://code.edge.launchpad.net/~ubuntu-branches/ | 22:01 |
| * thumper looks | 22:01 | |
| james_w | I'm pretty sure these are supposed to be stacked | 22:01 |
| beuno | mwhudson, that's a good think ;) | 22:01 |
| james_w | but apparently they aren't | 22:01 |
| Peng_ | beuno: A t-shirt? For reals? | 22:01 |
| james_w | they're not development-rich-root | 22:01 |
| beuno | Peng_, absolutely! | 22:01 |
| mwhudson | so the thing to do now is upgrade all the stacked-on branches, then do the trunk switcheroo ? | 22:02 |
| thumper | james_w: lemmie check it out | 22:02 |
| james_w | thumper: if you can confirm that they're not stacked then I'll check my code | 22:02 |
| Peng_ | Hmm, I'm not sure what users should do now. I guess they should upgrade to rich-roots then pull --remember lp:loggerhead again. That's a bit of a pain. | 22:03 |
| * beuno sents Peng_'s instrucitons to the list | 22:03 | |
| thumper | james_w: I was just looking at the stacking code earlier | 22:03 |
| Peng_ | And, since I went to effort to avoid violently breaking their branches, they'll never know they need to do it... | 22:03 |
| thumper | james_w: I think there needs to be a branch associated with the development version of the source package | 22:04 |
| thumper | james_w: and then that is used to stack | 22:04 |
| thumper | james_w: yes not stacked | 22:04 |
| james_w | yeah, I've tried to ensure I push and link the development focus branch first | 22:04 |
| Peng_ | mwhudson: I guess so. You don't *need* to do a switcheroo, though; I'm not sure what would be best. | 22:04 |
| james_w | ok, thanks | 22:04 |
| thumper | james_w: the UI would say if it was | 22:04 |
| thumper | james_w: if it isn't stacking it is a bug | 22:05 |
| james_w | I fear that I have just done a naïve push, when I should do a push that optionally stacks | 22:05 |
| thumper | james_w: is your script using bzrlib? or shell to push? | 22:05 |
| james_w | bzrlib | 22:05 |
| thumper | james_w: it is possible then that you aren't pushing with the stacking policy | 22:06 |
| james_w | yeah | 22:06 |
| thumper | james_w: as the remote site (launchpad) suggests a stacking branch | 22:06 |
| thumper | james_w: but it is up to the client to use it | 22:06 |
| thumper | which it normally does | 22:06 |
| mwhudson | Peng_: well, you need to change the stacked on branch 'as' you upgrade | 22:06 |
| Peng_ | mwhudson: Ooh, that sounds frightening. | 22:07 |
| Peng_ | Hum. | 22:07 |
| mwhudson | https://code.edge.launchpad.net/~mwhudson/loggerhead/which-mainline-merged is now stacked on the right thing | 22:08 |
| mwhudson | but i had to fix it with sftp | 22:09 |
| Peng_ | I'm nuking and repushing my one stacked branch, but it was already broken anyways. | 22:09 |
| Peng_ | That's unideal. | 22:09 |
| mwhudson | yeah | 22:09 |
| Peng_ | mwhudson: The easiest solution is leaving old branches with plain roots. | 22:09 |
| mwhudson | yeah | 22:10 |
| Peng_ | Crap, the branch is still broken. Never mind about stacking it, then. | 22:10 |
| mwhudson | but it would be good to have a non sucky way of upgrading your launchpad branch if you wanted to | 22:10 |
| Peng_ | Yeah, I didn't think of that. :\ | 22:10 |
| mwhudson | i guess there's a plugin in our collective future! | 22:10 |
| james_w | it's pretty annoying that you have to reimplement the logic of push if you want to push a branch | 22:11 |
| james_w | and means that your code can get out of date | 22:11 |
| mwhudson | i guess you can do get_command('push').run(...) | 22:12 |
| mwhudson | (or however that's spelt) | 22:13 |
| beuno | ok, I'mm all set up to be rich and root | 22:16 |
| Peng_ | And this encouraged me to fix my broken stacky branch. :) | 22:18 |
| beuno | win-win | 22:19 |
| lifeless | moin | 22:19 |
| lifeless | beuno: yes | 22:19 |
| lifeless | beuno: -Dhpss triggers it | 22:19 |
| lifeless | beuno: end users will only be using -Dhpss on request | 22:19 |
| jelmer | lifeless: moin | 22:20 |
| jelmer | lifeless: I would be careful with the dulwich git repo, it's generated by dulwich not by git itself | 22:20 |
| beuno | lifeless, WFM. I like that you're putting the pressure on. How can I help? filing bugs when I see VFS calls? | 22:20 |
| Peng_ | Of course, due to bug whatever-it-is, the web page for lp:loggerhead won't show the new format until someone pushes to it... | 22:20 |
| jelmer | lifeless: the client that pushed it was bzr-git with dulwich I mean, not sure how much post-processing the server does | 22:21 |
| lifeless | beuno: you'll usually see them on lp when lp isn't running $today | 22:21 |
| jelmer | lifeless: actually, scrap that | 22:21 |
| jelmer | lifeless: as the server would generate a new pack when you clone it | 22:21 |
| lifeless | beuno: e.g. bug filing isn't very useful, you need to be running alpha server <-> nightly | 22:21 |
| jelmer | lifeless: please ignore the last 7 lines from me ^ | 22:21 |
| lifeless | jelmer: :) | 22:22 |
| lifeless | jelmer: you send a pack, the server keeps it and can do as it wishes :) | 22:22 |
| beuno | lifeless, gotcha. I may be able to do that with my office server, but I don't use it much these days. Maybe I can do a few tests and file them based on that (server runs nightlies) | 22:22 |
| lifeless | jelmer: did you think about another project I can test with | 22:22 |
| lifeless | beuno: sure, its mainly for spiv and I to make 'X is slow' from a user easier to diagnose | 22:23 |
| lifeless | beuno: e.g. jelmers 'pushing cross-format is slow' [which is caused by IDS] | 22:23 |
| lifeless | beuno: I don't object to you filing bugs, but be prepared for most to be either dups, or wishlist (because we're not aiming at e.g. 'bzr log lp$FOO' to be VFS free in this cycle | 22:24 |
| jelmer | lifeless: you could try with etckeeper and the bzr etckeeper clone on staging that michael made | 22:24 |
| lifeless | mwhudson: where is this thing | 22:24 |
| jelmer | lp:~vcs-imports/etckeeper/trunk IIRC | 22:25 |
| jelmer | and git://git.kitenet.net/etckeeper | 22:25 |
| beuno | lifeless, my feelings won't get hurt, just trying to see how I can help. Maybe ping you/spiv before filing? | 22:25 |
| mwhudson | it's gone now i guess | 22:25 |
| lifeless | beuno: sure | 22:25 |
| lifeless | beuno: data is good | 22:25 |
| jelmer | lifeless: just install bzr-git and clone that git URL (-: | 22:25 |
| Peng_ | Uh-oh, LP broke my mirrored branches, since they're still stacked on the non-rich-root loggerhead branch. | 22:26 |
| jelmer | lifeless: or http://people.samba.org/bzr/jelmer//etckeeper/trunk | 22:26 |
| * beuno hides | 22:26 | |
| lifeless | jelmer: is that cronn'd? | 22:26 |
| mwhudson | Peng_: oh god | 22:27 |
| jelmer | lifeless: no, it's only kept up to date as I need it | 22:27 |
| Peng_ | This may have been a bad plan. :D | 22:27 |
| Peng_ | Well, the only problem is you have to change the stacked-on location. Which is definitely a problem on LP... | 22:28 |
| jelmer | lifeless: also, I think I found a bug in CHKMap.. | 22:29 |
| mwhudson | Peng_: well, it probably makes sense to make the dev focus the new branch | 22:29 |
| mwhudson | but argh argh argh, no way to win | 22:29 |
| Peng_ | mwhudson: The dev focus is the new branch. | 22:31 |
| mwhudson | Peng_: i think the next time your mirrored branches are updated, they will be stacked on the new branch tehn | 22:32 |
| Peng_ | mwhudson: They aren't. | 22:32 |
| lifeless | jelmer: kinda needs the same DAG to be a vaguely fair test | 22:33 |
| jelmer | lifeless: bzr-git keeps the dag | 22:34 |
| mwhudson | Peng_: "Last mirrored: 5 hours ago" | 22:34 |
| lifeless | jelmer: yes, but your copy isn't kept up to date, or so you just said | 22:34 |
| jelmer | lifeless: I'm not sure I follow what that has to do with the DAG | 22:35 |
| jelmer | lifeless: or are you looking at setting up some system to do continuous performance comparisons? | 22:35 |
| lifeless | jelmer: no, I'm just doing adhoc ones now | 22:35 |
| Peng_ | mwhudson: Some of them have been mirrored. | 22:36 |
| lifeless | jelmer: but if http://people.samba.org/bzr/jelmer//etckeeper/trunk is days or weeks old | 22:36 |
| mwhudson | Peng_: got an example? | 22:36 |
| lifeless | then its rather unfair to git | 22:36 |
| * mwhudson digs out the code | 22:36 | |
| jelmer | lifeless: I just pushed to it, so it should be current atm | 22:36 |
| lifeless | jelmer: also is your copy in dev6, and has a smart server? | 22:36 |
| Peng_ | mwhudson: https://code.edge.launchpad.net/~mnordhoff/loggerhead/333797-debug-print | 22:36 |
| jelmer | lifeless: no, neither | 22:37 |
| lifeless | jelmer: :( I know the results already then ;) | 22:37 |
| lifeless | jelmer: however, I'll push a dev6 version to lp to test with | 22:37 |
| lifeless | so whats this bug | 22:37 |
| jelmer | lifeless: patch is on the way | 22:38 |
| mwhudson | Peng_: i think i'm going to take up crying as a hobby | 22:38 |
| * lifeless consoles mwhudson | 22:38 | |
| Peng_ | mwhudson: Be sure to drink lots of fluids! | 22:41 |
| Peng_ | Sorry about this. | 22:41 |
| beuno | Peng_, I've said it before, but you're a fantastic test suite | 22:42 |
| mwhudson | Peng_: not you fault, we were going to hit this sooner or later | 22:42 |
| lifeless | oh, did beuno upgrade to rich root? | 22:42 |
| beuno | lifeless, Peng_ did! | 22:43 |
| Peng_ | :D | 22:43 |
| lifeless | Peng_: :) | 22:43 |
| james_w | Peng_, beuno: you rock | 22:43 |
| jelmer | lifeless: Another good test project might be samba if you're interested in trying something larger | 22:43 |
| jelmer | lifeless: I don't think there's a lot of projects that keep mirrors in bzr *and* git as part of their daily workflow though | 22:43 |
| lifeless | jelmer: bzr mirror with same dag of same ? | 22:43 |
| jelmer | lifeless: Yeah, just give me a few minutes to update the bzr mirror and push it | 22:43 |
| james_w | beuno: though your instructions require renaming a project branch to a junk branch in the UI? | 22:44 |
| lifeless | jelmer: also re: being careful of dulwich, seems to me that something hosted on e.g. gitorious is kindof required to keep the repo in good order for the users | 22:44 |
| Peng_ | james_w: It's to get around LP's default stacking policy. | 22:44 |
| james_w | yeah | 22:44 |
| lifeless | any benchmark that starts 'now run repack --max-window --max-delta' ... | 22:44 |
| lifeless | ;) | 22:44 |
| lifeless | is broken | 22:44 |
| james_w | it's just the option to do that might be removed from the UI | 22:44 |
| beuno | james_w, yeah, and jml may remove that, but may also provide an API | 22:44 |
| jelmer | lifeless: Yeah, as I mentioned I don't think my comment earlier was valid | 22:44 |
| james_w | beuno: oh good, you're aware of it | 22:45 |
| jelmer | lifeless: If you were comparing local bzr and a local git repo created using dulwich it would be a different story | 22:45 |
| Peng_ | james_w: ...That'd be unfortunate, I guess. | 22:45 |
| beuno | jml, ^^^^ | 22:45 |
| lifeless | jelmer: dulwich doesn't generate optimal packs you mean? | 22:46 |
| jelmer | beuno: so what do I do now with my local loggerhead branches? | 22:46 |
| beuno | jelmer, either upgrade it to 1.9-r-r, or re-branch | 22:46 |
| beuno | you have a nice --recurse plugin for upgrade | 22:46 |
| beuno | which I used :) | 22:46 |
| Peng_ | jelmer: Plus, "bzr pull --remember lp:loggerhead" again; it's moved. | 22:46 |
| jelmer | lifeless: It should but might not perform as well for some reason. | 22:47 |
| jelmer | lifeless: I haven't verified that it generates packs as optimal as regular git. I know it generates valid packs though. | 22:48 |
| jelmer | beuno: thanks | 22:50 |
| jml | beuno: renaming a project branch to a junk branch? | 22:52 |
| beuno | jml, yes, and visa-versa | 22:53 |
| jml | beuno: yeah, so we'll add an API for that -- what's the use case? | 22:54 |
| beuno | jml, read the bzr mailing list | 22:54 |
| beuno | the "upgrade story" :) | 22:54 |
| jml | it's already sounding uncompelling :) | 22:55 |
| beuno | jml, . | 22:56 |
| beuno | jml, At the same time, and only because I know lp won't have been getting | 22:56 |
| beuno | people to stack as there was only a 'mirrored' copy, it is migrating | 22:56 |
| beuno | directly to --development-rich-roots. | 22:56 |
| beuno | er | 22:56 |
| beuno | fail | 22:56 |
| beuno | http://paste.pocoo.org/show/117145/ | 22:56 |
| beuno | that's what I get for selecting textg when reading | 22:56 |
| === ja1 is now known as jam | ||
| beuno | and linux clipboard stupidness | 22:57 |
| jam | beuno: I replied to you message, btw | 22:57 |
| jam | There is a bit of LP renaming trickery that you don't really need | 22:57 |
| beuno | jam, I saw | 22:57 |
| beuno | jam, part of the renaming | 22:57 |
| beuno | is to keep merge proposals and bugs linkage | 22:58 |
| jam | I suppose you might have to do something to avoid the recursive stacking problem | 22:58 |
| * beuno hasn't replied because he wants to vreify first | 22:58 | |
| jam | beuno: oh, so you want bugs linked to .../trunk to now be linked to .../trunk-rich ? | 22:58 |
| beuno | jam, yeap | 22:59 |
| beuno | merge proposals, more importantly | 22:59 |
| beuno | subscriptions, etc as well | 22:59 |
| Peng_ | jam: Pushing to +junk avoids the default stacking policy; that's the workaround I used. | 23:00 |
| * Peng_ fires up an email client | 23:00 | |
| lifeless | Peng_: except renaming is about to be disabled ;) | 23:01 |
| lifeless | jml: ^ :P | 23:01 |
| jml | lifeless: yes. | 23:01 |
| jml | it'd be nice if bzr had an option to ignore the default stacking policy | 23:02 |
| lifeless | thumper: btw, lp:pqm was already 1.6 branch and repo; stackable. | 23:02 |
| lifeless | thumper: its because trunk wasn't hosted. | 23:02 |
| thumper | lifeless: that shouldn't matter | 23:03 |
| lifeless | thumper: ok | 23:03 |
| lifeless | thumper: mirrored branches don't have a private copy though | 23:03 |
| thumper | lifeless: I know | 23:03 |
| lifeless | thumper: so bzr+ssh can't stack locally | 23:03 |
| thumper | lifeless: trust me on this, it is tested | 23:03 |
| thumper | lifeless: we have custom transports | 23:04 |
| lifeless | ok | 23:04 |
| lifeless | question; how can I change https://code.edge.launchpad.net/%7Elifeless/pqm/trunk/+edit to be hosted | 23:06 |
| thumper | you can't | 23:06 |
| lifeless | I deleted the (optional) Branch URL | 23:06 |
| jam | lifeless: delete it and push ? | 23:06 |
| lifeless | jam: that deletes all the active merge proposals | 23:06 |
| lifeless | and bug links | 23:07 |
| jam | lifeless: shiny | 23:07 |
| lifeless | the former is valuable, the latter would be nice but is less valuable | 23:07 |
| lifeless | jam: in fact, I'm not even sure one can delete it with active merge proposals | 23:07 |
| jam | So it sounds like it falls back to "you can't" | 23:07 |
| lifeless | thumper: please advise | 23:07 |
| jam | Since I don't think there is any way to promote a mirrored branch to a hosted branch without deleting it | 23:08 |
| * lifeless tries just pushing anyway | 23:08 | |
| jam | lifeless: you could rename it out of the way | 23:08 |
| jam | then everything ends up linked to the wrong thing | 23:08 |
| jam | but at least they are still there | 23:08 |
| lifeless | ah, readonly transport | 23:08 |
| james_w | Stacked on: lp:ubuntu/karmic/asio | 23:08 |
| james_w | jml: I'm sorry I ever doubted you :-) | 23:09 |
| * thumper on a call | 23:09 | |
| james_w | jml: https://code.edge.launchpad.net/~ubuntu-branches/ <- I'm going to kick of a big run tonight if that looks good to you | 23:10 |
| Peng_ | jam: BTW, I tried having a team +junk branch; it was rejected. | 23:10 |
| jam | jml: ^^ what happened with that? | 23:11 |
| jam | Only on the staging server? | 23:11 |
| Peng_ | That's entirely possible. | 23:11 |
| james_w | team's aren't allowed junk branches are they? | 23:11 |
| jml | they have been recently | 23:12 |
| james_w | ah | 23:12 |
| jam | Peng_, jml: http://code.mumak.net/2009/03/team-junk-branches.html | 23:12 |
| jml | but our branch creation policy code is in a few too many places. | 23:12 |
| Peng_ | Well, I ran into that wall on the branch description page where I renamed it. | 23:12 |
| jam | btw jml, I want my bubble domes | 23:12 |
| Peng_ | Bubble domes? | 23:13 |
| jml | Peng_: yeah, that makes a *lot* of sense. | 23:13 |
| jml | Peng_: the edit form had completely different set of logic. | 23:13 |
| jam | Peng_: read ^^, but it refers to a Simpson's episode, and talks about "not all designs are good ones" | 23:13 |
| jam | Such as "Separate Bubble Domes" on a vehicle | 23:13 |
| lifeless | oh yes | 23:14 |
| lifeless | it was hilarious episode | 23:14 |
| Peng_ | I see. | 23:15 |
| Peng_ | Not that there's anything wrong with it, but I've only seen a couple episodes of The Simpsons. | 23:15 |
| Peng_ | jml: The Wikipedia image link in that post is broken. | 23:17 |
| mwhudson | Peng_: when did you upgrade your bzr.mattnordhoff.com branches? | 23:41 |
| poolie | hello all | 23:41 |
| poolie | jam, still around? | 23:41 |
| Peng_ | mwhudson: Um. 20:55 -- ~1h45m ago. | 23:42 |
| Peng_ | mwhudson: (Which is a few minutes after I upgraded lp:loggerhead.) | 23:43 |
| mwhudson | Peng_: ok | 23:44 |
| mwhudson | Peng_: this is really odd | 23:45 |
| mwhudson | Peng_: some of your branches are ok | 23:45 |
| mwhudson | e.g. https://code.edge.launchpad.net/~mnordhoff/loggerhead/new-style-classes | 23:45 |
| Peng_ | mwhudson: Huh. You're right, that is bizarre. | 23:47 |
| Peng_ | It looks like that branch was last mirrored right after I made the change. | 23:48 |
| * Peng_ shrugs. | 23:48 | |
| Peng_ | Maybe things'll work out in a few hours? | 23:48 |
| Peng_ | mwhudson: Maybe some of my branches got caught in between the upgrade and lp:loggerhead getting renamed or something. | 23:49 |
| mwhudson | Peng_: yeah, that's my theory (hope!) | 23:49 |
| Peng_ | Heh, right. | 23:49 |
| mwhudson | jelmer: please stop registering huge mirrored branches on launchpad for the moment | 23:50 |
| gutworth | how can I change my working copy back to an old version? | 23:50 |
| mwhudson | jelmer: it won't work and causes us problems | 23:50 |
| mwhudson | jelmer: (i'll fix it soonish) | 23:50 |
| mwhudson | gutworth: bzr revert -r -3 | 23:51 |
| gutworth | ah | 23:51 |
| gutworth | I was messing around with checkout and switch | 23:52 |
| mwhudson | checkout and switch are to do with the relationship of working tree and branch | 23:52 |
| mwhudson | revert is a pure wt think | 23:52 |
| mwhudson | *thing | 23:52 |
| Peng_ | mwhudson: One branch was remirrored just now, and it went correctly. | 23:53 |
| mwhudson | Peng_: ah, that was the one i hit try again on | 23:53 |
| mwhudson | Peng_: phew! | 23:53 |
| Peng_ | Oh, heh. | 23:53 |
| mwhudson | i was really confused there | 23:53 |
| Peng_ | I guess you can give up the crying, then? :D | 23:54 |
| mwhudson | somewhat | 23:55 |
| Peng_ | Mind if I hit retry on the rest of the branches? | 23:55 |
| mwhudson | Peng_: go ahead | 23:55 |
| Peng_ | Oh, good, there were only 3 left. | 23:56 |
| gutworth | is there a command line way to disable lazy import? | 23:56 |
| jelmer | mwhudson: ok | 23:57 |
| Peng_ | gutworth: I don't know of one. | 23:57 |
| mwhudson | jelmer: thanks | 23:57 |
| mwhudson | gutworth: no | 23:57 |
| jelmer | mwhudson: feel free to remove whatever mirrored branches are there now from me if you have some automated way of doing so | 23:57 |
| Peng_ | beuno: So, is the t-shirt thing still on? :D | 23:58 |
| beuno | Peng_, of course! | 23:58 |
| beuno | send me your address! | 23:58 |
| jelmer | mwhudson: (I have a plugin that automatically registers stuff if I push it to samba.org, have disabled that now) | 23:58 |
| mwhudson | jelmer: nah, they'll get disabled after a few tries | 23:58 |
| mwhudson | jelmer: thanks | 23:59 |
| mwhudson | jelmer: i'll let you know when it's safe again :) | 23:59 |
| Peng_ | beuno: Are they shipped from somewhere in the U.S.? | 23:59 |
| beuno | Peng_, or the UK, not sure | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!