| Raim | I understand the first two about the protocol version, but the third sounds like server and client can't communicate | 00:00 |
|---|---|---|
| Peng_ | If the server doesn't support protocol v2, it is far older than 1.5. | 00:01 |
| Raim | oh wait | 00:02 |
| Raim | gah, the network I am connecting to is not homogenous, this is actually an older Debian box with 0.11.0 | 00:03 |
| Peng_ | Wow, that's *ancient*. | 00:04 |
| Peng_ | Raim: You'd have to use sftp; modern clients dropped support for smart servers that old. | 00:05 |
| Peng_ | 0.11? What disk format would that use? I didn't even use bzr back then... | 00:05 |
| Raim | Peng_: nah, I just have to use another server which also has access to the NFS share where the repo lives | 00:06 |
| Raim | Peng_: works fine now. I just made a bad assumption and did not check the versions properly | 00:06 |
| Peng_ | OK, that works too. | 00:07 |
| igc | morning | 00:16 |
| Peng_ | Good morning. | 00:19 |
| igc | hi Peng_ | 00:23 |
| lifeless | hi igc | 00:23 |
| igc | hi lifeless | 00:23 |
| abentley | lifeless: Thanks for the review. | 00:26 |
| lifeless | abentley: no probs | 00:28 |
| lifeless | abentley: you registered it with the new hooks registry; all was good in the world | 00:28 |
| * igc out for a few hours - chemo day - bbl | 00:36 | |
| poolie | hello all | 00:36 |
| poolie | good luck igc | 00:36 |
| igc | thanks poolie | 00:36 |
| abentley | poolie: hi there. | 00:42 |
| abentley | igc: good luck. | 00:42 |
| poolie | hi abentley | 00:42 |
| poolie | abentley: i heard you made me the reviewer for the nested trees doc | 00:43 |
| poolie | i'll do something on it today | 00:43 |
| abentley | poolie: Maybe we could have a quick chat? | 00:43 |
| poolie | abentley: sure, can you wait 5m? | 00:44 |
| abentley | poolie: sure. | 00:44 |
| lifeless | jelmer: so did you upload subunit? or should I | 01:26 |
| jelmer | lifeless: I did some work on it (fixing lintian warnings and the like) | 01:26 |
| lifeless | oh noes | 01:27 |
| jelmer | s/warnings/issues pointed out by lintian/ | 01:27 |
| jelmer | I also sent in a merge request for a shell bug | 01:27 |
| jelmer | did you see that one? | 01:27 |
| lifeless | no | 01:27 |
| jelmer | lp:~jelmer/subunit/merge | 01:28 |
| lifeless | nice, https://code.edge.launchpad.net/~subunit/ shows package branches now | 01:28 |
| jml | lifeless: it's shown package branches forever :) | 01:28 |
| lifeless | jml: oh cool | 01:28 |
| jml | lifeless: drop the tilde and they'll disappear | 01:29 |
| lifeless | jelmer: I can see the reviews, but I didn't et mail | 01:29 |
| jml | lifeless: they are also very badly sorted. | 01:29 |
| lifeless | jml: how can I debug this | 01:29 |
| lifeless | jml: I don't get notification on merge proposals to subunit trunk | 01:29 |
| lifeless | I'm subscribed | 01:29 |
| thumper | lifeless: how did ~subunit get 1 registered branch? | 01:30 |
| lifeless | I checked my subscription and it says all code review stuff | 01:30 |
| thumper | nm | 01:30 |
| jml | lifeless: https://code.edge.launchpad.net/~subunit/subunit/trunk says you aren't subscribed. | 01:30 |
| thumper | it is old | 01:30 |
| jml | oh subunit developers | 01:30 |
| jml | wait no | 01:30 |
| lifeless | I can't tell whats going on | 01:31 |
| lifeless | jelmer: land it | 01:33 |
| jelmer | lifeless: ack | 01:34 |
| lifeless | thumper: what do you mean by 'it is old'? | 01:36 |
| lifeless | jml: so even though subunit-developers is the default review team, they are not notified? | 01:36 |
| thumper | lifeless: before we had a registrant for branches | 01:36 |
| lifeless | thumper: I would like a clear thing saying whether I will get notified about a given branch | 01:37 |
| lifeless | thumper: at the moment I can't tell | 01:37 |
| * lifeless files a few bugs | 01:38 | |
| thumper | if you are not subscribed, you don't get anything | 01:38 |
| thumper | lifeless: assign to beuno :) | 01:38 |
| lifeless | thumper: I'll let you decide | 01:40 |
| BasicOSX | lifeless: tracking down the 1.13.2 == 1.14.xx, I introduced the issue into the 1.13 branch when I merged ~spiv/bzr/stacking-inventory into 1.1.13 branch as part of the fix to Bug 354036 | 01:41 |
| ubottu | Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] https://launchpad.net/bugs/354036 | 01:41 |
| BasicOSX | There was a bug task for 1.13, assigned to me. I need help understanding what I should have done, since a flatout merge of spiv's branch was not the right thing to do | 01:42 |
| BasicOSX | revno: 4112.1.1 [merge] is the offending revno | 01:43 |
| BasicOSX | I can post to the ML if that is better | 01:43 |
| lifeless | BasicOSX: you should done a cherrypick into your local branch | 01:43 |
| lifeless | BasicOSX: the easiest way to make this happen is to: | 01:44 |
| lifeless | - get the branch you want merged to trunk if it isn't already | 01:44 |
| lifeless | - bzr merge -c <trunkrevno> bzr.dev in your release branch | 01:44 |
| lifeless | - bzr commit | 01:44 |
| lifeless | - submit to pqm for that release branch | 01:44 |
| BasicOSX | making notes | 01:45 |
| lifeless | 'bzr merge' should never be used from a feature branch to a release branch, unless the feature branch is intended specifically for that release | 01:46 |
| BasicOSX | I see that now. In the past someone has done the cherrypicking for me (not an excuse) | 01:47 |
| BasicOSX | To fix the mess, do I issue bzr uncommits? | 01:48 |
| lifeless | mail the list re the mess | 01:49 |
| BasicOSX | ok | 01:49 |
| lifeless | we need to consider who may have 1.13.14 | 01:49 |
| poolie | abentley: i reviewed the docs and posted a comment | 01:52 |
| poolie | looking at the other threads now | 01:52 |
| abentley | poolie: thanks. | 01:57 |
| kvanderw | Running 'bzr' on my /home/me directory. Also, /home/me/fw02/root. When in /home/me/fw02/root it is referencing the .bazaar/bazaar.conf file in /home/me and not the one in /home/me/fw02/root. Is that the way it should be? | 02:27 |
| kvanderw | solo mode if it makes any difference. | 02:28 |
| spiv | kvanderw: the .bazaar/bazaar.conf file has user-wide configuration, so bzr always looks it up in your home directory. | 02:29 |
| spiv | kvanderw: so yes, that's expected behaviour. | 02:29 |
| spiv | kvanderw: perhaps you are getting confused with the .bzr directory that is part of branches, repositories and working trees? | 02:30 |
| kvanderw | spiv: Thanks... just making me wonder... The subdir is an rsync copy of a firewall. I had forgotten that I had installed bzr over my home directory. | 02:31 |
| kvanderw | Just bad management from a noob :) | 02:31 |
| kvanderw | spiv: though, it sounds like, even if I put it outside that dir structure, it still always looks to my 'home' dir for the conf. No prob... Just trying to learn the ropes. | 02:32 |
| kvanderw | spiv: Thanks! | 02:32 |
| spiv | kvanderw: right | 02:33 |
| lifeless | spiv: is this a TODO? | 02:33 |
| lifeless | + # Also, perf tests: | 02:33 |
| lifeless | + # - if all invs present, then no texts are checked | 02:33 |
| spiv | lifeless: oops, yes. | 02:34 |
| spiv | lifeless: actually, I was intending to not bother as it seemed too much hassle for minimal benefit... | 02:35 |
| lifeless | have you done a user level perf test | 02:35 |
| lifeless | say to people? | 02:35 |
| spiv | Not explicitly, I have done a bit of branching locally to confirm that the final form of the fix really did fix the original issue and didn't notice any slowdown in branching all of bzr.dev locally. | 02:37 |
| lifeless | I'll let you make the call | 02:37 |
| spiv | I'll run another quick experiment. | 02:38 |
| lifeless | what do you think of my -Dhpss backtrace patch? | 02:38 |
| spiv | I don't think I've seen it... where is it? | 02:42 |
| spiv | Oh, something to do with getting backtraces from _ensure_real? | 02:43 |
| spiv | lifeless: I like the idea of making the remaining VFS causes easier to identify, but I'm fairly sure I haven't seen an actual patch for it. | 02:47 |
| lifeless | spiv: yes | 02:52 |
| lifeless | spiv: no idea where it went | 02:54 |
| lifeless | resending | 02:54 |
| lifeless | spiv: its hit the list | 03:04 |
| spiv | Cool, I'll take a look. | 03:04 |
| spiv | lifeless: thanks for the review, btw | 03:04 |
| jam | lifeless or spiv: PendingAncestryResult.get_keys() returns ghosts, is it supposed to? | 03:13 |
| jam | The StreamSource code then calls Graph.iter_topological_order(keys) | 03:14 |
| jam | which strips ghosts | 03:14 |
| jam | so StreamSource works | 03:14 |
| jam | but it is causing stacking w/ bbc to fail | 03:14 |
| jam | spiv: also, why in your new code did you create 1 set per key, rather than having a single set? | 03:17 |
| jam | I'm a bit concerned about having 100k sets in memory | 03:17 |
| jam | (unlikely to be intentional for something which is stacked, though) | 03:17 |
| spiv | jam: heh | 03:17 |
| jam | I just don't see what it gets you | 03:17 |
| jam | versus 1 big set | 03:17 |
| spiv | jam: I just sent mail on this :) | 03:17 |
| jam | since you only call stuff like 'get_referrers()' | 03:18 |
| spiv | jam: before I saw that you were on IRC | 03:18 |
| jam | spiv: :) I just got the email | 03:18 |
| jam | spiv: are there direct tests of PendingAncestryResult? | 03:19 |
| spiv | jam: there are some in test_graph | 03:19 |
| jam | yeah, I just found it | 03:20 |
| jam | no tests for ghosts | 03:20 |
| lifeless | jam: PAR returning ghosts is sarguably a bug | 03:20 |
| jam | I guess that leaves it open for me to interpret :) | 03:20 |
| lifeless | jam: I see no reason to keep that | 03:20 |
| jam | lifeless: agreed, just wanted to make sure everyone else thought so, too | 03:20 |
| lifeless | jam: IDS breaks streaming push cross-format :( | 03:21 |
| lifeless | which I knew | 03:21 |
| lifeless | but jelmer filed a bug saying 'it go sloweth' | 03:22 |
| jam | lifeless: does it go 'slowether' than doing it any other way? | 03:22 |
| lifeless | jam: much | 03:22 |
| jam | interesting, considering it goes *much* faster locally | 03:23 |
| lifeless | spiv: inventory deltas top of the pile now? | 03:23 |
| jam | it doesn't really query the target | 03:23 |
| lifeless | jam: latency | 03:23 |
| jam | I suppose this is a 'pull' issue? | 03:23 |
| jam | I would assume it is faster for 'push' | 03:23 |
| lifeless | jam: push | 03:23 |
| spiv | lifeless: theoretically yes, but I'm on leave from tomorrow till All Hands | 03:23 |
| lifeless | jam: no, every write is a round trip | 03:23 |
| lifeless | spiv: oh, I didn't know. | 03:23 |
| jam | lifeless: well, isn't that just NewPack.set_buffer_size() ? | 03:24 |
| lifeless | spiv: I will see if I can squeeze it in; please ensure you have it pushed and a mail to me with the url of the current state | 03:24 |
| jam | Considering we hold a write group for 100 revisions at a time | 03:24 |
| spiv | Crap, I haven't mailed the about that yet... I'll do that now. | 03:24 |
| jam | And we transfer texts 'in bulk' as well | 03:24 |
| lifeless | jam: even so, its still many round trips rather than streaming | 03:24 |
| lifeless | and each commit is about 10 round trips | 03:24 |
| lifeless | and then a re-read to refresh data | 03:24 |
| lifeless | jam: I can pretty much guarantee that disabling IDS over the network will be faster in all cases | 03:25 |
| lifeless | jam: particularly if we do what I propose and set the fetch order to gc-optimal | 03:25 |
| jam | well, other than the 4-5 things I listed, sure... | 03:26 |
| jam | IDS wasn't specifically tuned for remote ops | 03:26 |
| lifeless | I realise IDS is fast locally | 03:28 |
| lifeless | AFAICT there are two specific issues; long conversion times, and writing many small chk pages meaning we can't really do gc-optimal cross-format | 03:28 |
| lifeless | because we'll get optimal texts but not optimal chk pages | 03:28 |
| lifeless | I don't want to delete IDS until there is a better option; if thats even possible. However I also want network ops to be fast | 03:29 |
| lifeless | I'd like to see IDS split into a sink and stream pair and just hooked into the generic paths | 03:29 |
| jam | lifeless: so other than wanting to trigger commit_write_group on the target | 03:30 |
| jam | I'm pretty sure all the work is done in the source | 03:30 |
| jam | and there isn't specific chatter between both sides | 03:30 |
| lifeless | I suggest we add a stream flag saying 'the data from start to here is topologically consistent' | 03:32 |
| lifeless | we should design this next week/sprint week | 03:32 |
| jam | I guess it switches from texts => inventories => revisions | 03:32 |
| lifeless | I have a few things I want to include | 03:32 |
| jam | oh, and it wants 'add_inventory_by_delta' | 03:32 |
| jam | which requires 'streaming inventory deltas' | 03:33 |
| lifeless | jam: network deltas will cover that | 03:33 |
| jam | which you keep claiming exists somewhere :) | 03:33 |
| lifeless | yes, spivs laptop | 03:33 |
| spiv | The delta serialisation is already in bzr.dev | 03:35 |
| spiv | It just isn't hooked up to anything yet. | 03:35 |
| lifeless | spiv: oh you landed that? | 03:35 |
| spiv | lifeless: we did :P | 03:35 |
| lifeless | spiv: sweet, I hadn't noticed. | 03:35 |
| lifeless | spiv: there's no other outstading branch then is there | 03:35 |
| spiv | Yeah, I forgot too until I went over my old branches looking for half-done work :) | 03:36 |
| spiv | Right, no other outstanding branch. | 03:36 |
| lifeless | ok | 03:36 |
| lifeless | jam: ^ | 03:36 |
| jam | spiv: where is it? | 03:36 |
| lifeless | jam: small amount of glue left; get_delta(); serialise(); yield; | 03:36 |
| spiv | jam: bzrlib/inventory_delta.py | 03:38 |
| jam | spiv: .... PendingAncestryResult.get_recipe() does not return ghosts as 'exclude_keys' | 03:39 |
| jam | Which makes 'bzr branch from-stacked' search all the chk pages, and want to copy all texts that are referenced from the stacked branch... | 03:40 |
| spiv | jam: PendingAncestryResult doesn't have any exclude keys | 03:40 |
| lifeless | jam: par is a full-history grab | 03:41 |
| spiv | it's just "get me the ancestry for <heads>" | 03:41 |
| jam | lifeless: but on a Stacked location, *without* fallbacks set | 03:41 |
| jam | ... | 03:41 |
| jam | which is how the stacking code works | 03:41 |
| spiv | If you want "get me the keys from <heads> to <stop_keys>", that's SearchResult | 03:41 |
| lifeless | jam: so I think you still have a bug :) | 03:41 |
| lifeless | jam: here is how it is meant to work | 03:41 |
| lifeless | the server gets a par for the branch tip | 03:42 |
| lifeless | it then finds all the revisions it actually has | 03:42 |
| lifeless | it then calculates a delta for the new content in all those revisions and sends that | 03:42 |
| lifeless | it should have enough data in the inventories to do that, *because* we include the adjacent inventories | 03:42 |
| jam | spiv: so the idea was that if we have 'exclude_keys' *already* computed from the search result, why should I compute them *again* | 03:42 |
| jam | now, PAR may never have excluded_keys | 03:43 |
| lifeless | in this situation note that there are no exclude keys | 03:43 |
| lifeless | and cannot be, because we're always grabbing all the history if we have a par | 03:43 |
| jam | so... can I just never trust the recipe? | 03:43 |
| lifeless | its never used if we have a shared repo | 03:43 |
| jam | or should I trust it, unless it is empty? | 03:43 |
| lifeless | jam: the recipe is completely accurate | 03:43 |
| jam | note that PAR without stacking | 03:43 |
| jam | will have no exclude keys | 03:43 |
| jam | and require searching the *entier* graph to find that it is correct | 03:43 |
| lifeless | jam: I don't understand why you think you can't trust it | 03:44 |
| spiv | what do you mean "find that it is correct"? | 03:44 |
| jam | lifeless: I want to transmit all revisions from the stacked branch | 03:44 |
| lifeless | jam: yes, which the par will have found | 03:44 |
| jam | And all inventories for only those revisions, and no chk pages for previous revisions | 03:44 |
| jam | I was using the 'exclude_keys' to figure out what inventories *not* to transmit | 03:44 |
| jam | rather than doing another get_parent_map call | 03:44 |
| lifeless | exclude_keys is wrong wrong tool to use | 03:44 |
| jam | because it is redundant with SearchKey | 03:44 |
| jam | SearchResult | 03:45 |
| jam | sorry | 03:45 |
| jam | lifeless: except SearchResult has already done that sort of get_parent_map for me | 03:45 |
| jam | and avoids having to do double duty | 03:45 |
| jam | especially on a 'branch everything from a non stacked branch' case | 03:45 |
| lifeless | jam: you want to send search.get_keys() | 03:45 |
| jam | lifeless: and *not* send get_parent_map(search.get_keys()).itervalues().discard(search.get_keys()) | 03:46 |
| jam | yse | 03:46 |
| jam | yes | 03:46 |
| jam | I just didn't want to have to re-compute 'exclude_keys' for the case when SearchResult has already *done* that. | 03:46 |
| lifeless | so, feel free to improve PAR is perhaps the right answer | 03:46 |
| jam | well, I don't like doing: _, _, exclude_keys, _ = search.get_recipe() | 03:47 |
| lifeless | its sketchy, it was created to avoid the 'billion round trips to find graph' case | 03:47 |
| jam | so I would rather do it a different way | 03:47 |
| jam | like "search.get_tails()" (get_exclude_keys(), etc) | 03:48 |
| jam | and PAR could compute that when it computes get_keys() | 03:48 |
| lifeless | I don't think andrew or I are tightly attached to any of these internals | 03:48 |
| jam | though I notice that the Result objects often don't actually cache anything | 03:48 |
| jam | so it seems a bit off to assume that get_keys() is called before get_tails() | 03:48 |
| jam | lifeless: I'm trying to understand what you *do* like, so I can not make a mess | 03:49 |
| jam | In the short term, I can just do another get_parent_map() | 03:49 |
| jam | it just seemed redundant | 03:49 |
| jam | (not that we don't do that *all the time* already...) | 03:49 |
| lifeless | jam: Whats wrong with _, _, exclude_keys, _ = search.get_recipe() | 03:49 |
| lifeless | is it doing more work | 03:49 |
| lifeless | or is it ignore the variables you don't want that you don't like? | 03:49 |
| jam | lifeless: get_recipe() seems like it should really be opaque | 03:49 |
| spiv | jam: I think our graph search stuff is pretty primitive at the moment, so I'm definitely in favour of improving it. | 03:50 |
| lifeless | jam: unfortunately, and I sighed when I realised, we messed up PAR and its not as opaque as it could be | 03:50 |
| lifeless | jam: that said, if you want to add methods that you'll like that would be fine. | 03:50 |
| lifeless | jam: caching should be done with care, obviously. | 03:50 |
| jam | lifeless: well, you cache 'heads'... I suppose caching 'self.tails' if we have encountered them? | 03:51 |
| lifeless | jam: right | 03:51 |
| lifeless | jam: you actually want to cache ghosts in this case | 03:52 |
| jam | right | 03:52 |
| jam | and really only ghosts, since PAR is 'everything that you can reach' | 03:52 |
| spiv | Yeah, the step from generalising SearchResult to SearchResult+PendingAncestryResult wasn't perfect. | 03:52 |
| * igc back - chemo delayed for a week | 03:54 | |
| jam | hey igc, glad to hear you feel well today, sorry to hear it is because of delayed chemo | 03:56 |
| igc | hi jam! yeah - I feel fine fwiw | 03:56 |
| ziroday | Hi, when branching from https://code.launchpad.net/~breathe-dev/breathe-icon-set/trunk I got http://pastebin.com/m6ad04457 | 03:59 |
| ziroday | err http://pastebin.com/m64c5c70a sorry | 03:59 |
| lifeless | ziroday: I suspect a broken http proxy at your ISP | 04:04 |
| lifeless | ziroday: can you try using bzr+ssh please | 04:04 |
| ziroday | lifeless: doing so now | 04:04 |
| lifeless | ok | 04:05 |
| SamB | maybe something should be added to the smart protocol to help diagnose buggy http proxies ? | 04:10 |
| lifeless | SamB: patches considered helpful :) | 04:11 |
| lifeless | (in general its hard to tell 'bad proxy' from 'data attack' | 04:11 |
| SamB | some kind of handshake to be used after that kind of error to check for typical bugs, maybe? | 04:11 |
| SamB | lifeless: data attack? | 04:11 |
| lifeless | SamB: that error isnt from the smart protocol though | 04:11 |
| lifeless | SamB: a bad proxy gives bad bytes that it claims where what you asked for, but aren't. | 04:12 |
| SamB | oh, you mean it doesn't just get confused ? | 04:12 |
| SamB | or munge data ... or something like that? | 04:12 |
| lifeless | there are all sorts of things which may be causing it | 04:14 |
| lifeless | but we haven't detected an http protocol issue if we get the errror that ziroday saw | 04:14 |
| lifeless | but if it is (and ssh working says it is) the http proxy, then the proxy is effectively hostile | 04:14 |
| ziroday | well it appears to be working via bzr+ssh, I'll just advise the loco to use that | 04:15 |
| SamB | lifeless: yeah, what I'm saying is that if you get something like that, it might be a good time to check for such bugs in any proxy ;-) | 04:15 |
| spiv | SamB: yes, but exactly which bugs, and how? There are an infinite number of ways a proxy can screw up your data... | 04:16 |
| lifeless | ziroday: cool | 04:16 |
| ziroday | lifeless: spiv SamB: thanks for all the help, you've made my day :) | 04:17 |
| SamB | spiv: frequently seen bugs, I guess | 04:17 |
| lifeless | SamB: I agree with the sentiment, I'm not smart enough to see how to do it though | 04:17 |
| lifeless | SamB: because the symptoms are 'sometimes, when you ask for data you get different data' | 04:18 |
| SamB | yeah, me neither! | 04:18 |
| SamB | well, mostly because I don't know what any of those bugs are | 04:18 |
| lifeless | SamB: many of these intercepting proxies are proprietary | 04:18 |
| lifeless | so very few people will know exactly what the bug i | 04:19 |
| lifeless | s | 04:19 |
| SamB | well, I mean, what kind of corruptions they create | 04:19 |
| SamB | or at least what kind of data they are likely to corrupt | 04:19 |
| lifeless | who knows ;) | 04:19 |
| * mwhudson is pretty sure his isp uses good ol' squid | 04:22 | |
| SamB | if I knew that, I might be able to cook up an http smart-server handshake protocol that would allow the client to construct a desired HTTP response and see if it comes through unscathed ... | 04:22 |
| SamB | and some probe data to check for common bugs | 04:22 |
| lifeless | SamB: this isn' smart-server related | 04:23 |
| lifeless | SamB: this is simple plain HTTP GET's failing. | 04:23 |
| SamB | well, yes, I know ... but I figure you'd need cooperation from the remote that plain-old HTTP isn't going to give you | 04:23 |
| lifeless | I think it would be undesirable for bzr to issue arbitrary gets when something goes wrong on HTTP. In some organisations that would get a sysop coming around to your desk to 'talk' to you. | 04:24 |
| SamB | hmm. | 04:24 |
| SamB | a much simpler idea would be to simply point out that that type of exception is often caused by <foo>, where <foo> is derived from the access method in use ... | 04:25 |
| lifeless | thats possible. Which comes back to - corrupt data has a pretty good chance of causing a zlib decompression error | 04:26 |
| lifeless | you might like to file a bug about that approach | 04:26 |
| * SamB should file a bug against himself for being too lazy to file a bug ... | 04:27 | |
| Logomachist | You guys know if there are any books on Bazaar? | 04:33 |
| poolie | Logomachist: there's a book in progress, for now the best docs are the user guide on doc.bazaar-vcs.org | 04:54 |
| poolie | hello vila | 05:18 |
| Logomachist | Cool. Thanks Poolie | 05:25 |
| thumper | what is the difference between: 2645 ghost revisions | 05:44 |
| thumper | 2485 revisions missing parents in ancestry | 05:44 |
| thumper | in bzr check? | 05:44 |
| thumper | I get this after reconcile | 05:44 |
| lifeless | the former is ghosts, the latter is revisions that are present and should have been fixed up | 05:45 |
| lifeless | I think | 05:45 |
| thumper | lifeless: what, if anything, should or could I do about them? | 05:49 |
| lifeless | if reconcile left it like that, file a bug | 05:50 |
| lifeless | I'm currently overhauling check | 05:50 |
| lifeless | and will make sure its actually a relevant warning | 05:51 |
| thumper | ok | 05:51 |
| thumper | lifeless: what information would you like in the bug report? | 05:51 |
| thumper | it is the launchpad branch | 05:51 |
| thumper | I reconciled the 1.6 branch | 05:51 |
| thumper | then ran check | 05:51 |
| thumper | and that is what it said | 05:51 |
| lifeless | sure that would be fine. | 05:52 |
| thumper | however it did fix the 3547 inconsistent parents | 05:52 |
| lifeless | thumper: thats good and will help annotate give better answers | 06:05 |
| lifeless | sadness IllegalUseOfScopeReplacer: | 06:16 |
| lifeless | can't figure out why I'd get that in bzrlib.smart.medium | 06:17 |
| Peng_ | What *are* inconsistent parents? | 06:23 |
| lifeless | Peng_: when the cached index <> the revisions list of parents | 06:25 |
| lifeless | 65->61 seconds for check tests | 06:39 |
| lifeless | poolie: ping | 06:40 |
| lifeless | poolie: I need a pointer; whats the current idiom for doing 'I have three tasks, they may take varying time each' | 06:40 |
| poolie | one minute | 06:40 |
| lifeless | sure | 06:41 |
| lifeless | I'll just delete progress for now ;) | 06:41 |
| poolie | lifeless: and they hppen sequentially? | 06:42 |
| poolie | i guess you should still use phases | 06:42 |
| poolie | i don't think that's quite right | 06:42 |
| poolie | or maybe the api is right and the way they're used is not always optimal | 06:42 |
| poolie | at any rate i don't have a clear better answer | 06:43 |
| lifeless | well | 06:45 |
| lifeless | gnerators but yes there are some fairly discrete phases | 06:45 |
| poolie | did that answer your queston? you can call | 06:48 |
| lifeless | sufficiently | 06:48 |
| lifeless | I've spend the whole day on check so far | 06:48 |
| lifeless | it is faster | 06:48 |
| lifeless | but I'm not done | 06:48 |
| poolie | igc, i sent a response to your doc | 06:51 |
| poolie | about nested trees | 06:51 |
| poolie | it was good, but it opened up some questions for me | 06:52 |
| igc | poolie: thanks | 06:52 |
| igc | poolie: that's good - that was the point of writing it :-) | 06:52 |
| poolie | indeed :) | 06:53 |
| Peng_ | lifeless: OK, thanks. :) How's that fixed? Change the index? | 06:53 |
| * Peng_ goes to bed. I shouldn't ask questions right before leaving. :\ | 06:55 | |
| vila | hi all | 07:07 |
| lifeless | poolie: there appears to be significant overlap between the _render stuff in progress view, and progressbar | 07:15 |
| lifeless | poolie: I'd like to encourage you to delete a bunch of stuff | 07:15 |
| mwhudson | i owe poolie a patch in this area too | 07:21 |
| lifeless | hmmm | 07:36 |
| lifeless | bzr: ERROR: Server sent an unexpected error: ('error', "'pqm@pqm.ubuntu.com-20090505195559-0qmeyyua7e407sym'") | 07:36 |
| lifeless | not encouraging | 07:36 |
| lifeless | spiv: you seen that pushing to lp? | 07:36 |
| spiv | lifeless: no, I haven't. | 07:37 |
| spiv | That is worrisome. | 07:37 |
| lifeless | lp:~lifeless/bzr/check | 07:37 |
| spiv | lifeless: in reply to which verb? | 07:37 |
| lifeless | which is a tad ironic | 07:37 |
| spiv | Heh. | 07:38 |
| lifeless | oh, I see | 07:38 |
| lifeless | File "/home/robertc/.bazaar/plugins/branchfeed/branch_feed.py", line 41, in post_change_hook | 07:38 |
| lifeless | BranchFeed(change.branch).update() | 07:38 |
| lifeless | it doesn't handle ghosts yet. | 07:38 |
| lifeless | mea culpa. | 07:38 |
| lifeless | its odd that its getting a nonstacked repo or whatever is going on | 07:39 |
| spiv | branchfeed? Does that generate RSS or something? | 07:39 |
| lifeless | yes | 07:39 |
| lifeless | https://edge.launchpad.net/bzr-branchfeed | 07:39 |
| * jml wants 1.15dev on Launchpad | 08:01 | |
| jml | HPSS calls: 72 (23 vfs) | 08:03 |
| jml | hmm. | 08:03 |
| jml | 49 is still a lot. | 08:04 |
| lifeless | jml: doing what | 08:04 |
| lifeless | and is that against 1.15? | 08:04 |
| jml | lifeless: pushing up a new stacked branch. no, it's not against 1.15: from 1.15dev to 1.14 | 08:04 |
| lifeless | it'll drop more than just removing the vfs calls | 08:05 |
| lifeless | you're paying probes to find things that are in 1.15 etc too | 08:05 |
| jml | lifeless: *nod* I saw a few unrecognized method errors in the .bzr.log. | 08:06 |
| lifeless | and other things like ghost handling are more efficient, you won't see that in the log | 08:06 |
| mwhudson | jml: feel free to ec2test -b bzr=lp:bzr | 08:17 |
| jml | mwhudson: yeah. I might do that. | 08:17 |
| jml | I'm reminded that I should also upgrade twisted. | 08:17 |
| jml | I might go for a walk then write some talks instead. | 08:19 |
| Demosthenes | any pointers to how to make a precommit hook that can change the working tree? | 08:31 |
| lifeless | bzr help hooks | 08:31 |
| lifeless | there is a hook type documented there that can do that | 08:31 |
| Demosthenes | yep. saw that. it says write a python plugin. | 08:31 |
| Demosthenes | i wasn't planning on becoming a bzr dev. i wanted to run a shellscript to generate a report each time i commit. | 08:32 |
| lifeless | MutableTree.start_commit | 08:32 |
| lifeless | Demosthenes: nothing to do with being a bzr dev | 08:32 |
| Demosthenes | i did find a web page on pre_commit, with a helpful prewritten plugin that'd call $treeroot/precommit for you | 08:32 |
| lifeless | its just the language hooks run in; or you can install jelmer's shell-hooks plugin | 08:33 |
| Demosthenes | but as i understand it, precommits can't edit the tree | 08:33 |
| lifeless | right | 08:33 |
| lifeless | where is this page? | 08:33 |
| Demosthenes | http://schettino72.wordpress.com/2008/01/20/how-to-execute-tests-on-a-bazaar-pre-commit-hook/ | 08:33 |
| Demosthenes | but i think you gave me the answer, shell-hooks. | 08:33 |
| Demosthenes | oh heck. the shell-hooks doesn't support start_commit | 08:35 |
| Demosthenes | so back to step one. | 08:35 |
| lifeless | http://paste.ubuntu.com/170347/ | 08:39 |
| lifeless | enjoy | 08:39 |
| Demosthenes | hey cool, i'll give it a whirl | 08:40 |
| Demosthenes | you ought to post that somewhere so others can use it | 08:40 |
| lifeless | oh, the error will fail | 08:41 |
| lifeless | sec | 08:41 |
| lifeless | http://paste.ubuntu.com/170351/ updated | 08:41 |
| Demosthenes | look like it works great! | 08:45 |
| Demosthenes | i do appreciate it, i'm just stumped that something simple like that was difficult | 08:45 |
| lifeless | cool | 08:45 |
| poolie | lifeless: if you're still here: yes, i know, i really want to delete it too | 09:15 |
| lifeless | http://webpagetest.org/ is really quite nice | 09:16 |
| gcerquant | lifeless: nice (based on the screencast). But it couldn't connect to my website | 09:28 |
| gcerquant | now I am wondering if it's a problem with the test tool or with my server | 09:28 |
| lifeless | gcerquant: I've pointed it a few sites successfully | 09:28 |
| gcerquant | that is even more worrying :-/ | 09:29 |
| lifeless | e.g. http://pagetest.getrpo.com/result/NSB/ most recently | 09:29 |
| gcerquant | i am now trying an other test | 09:29 |
| * igc diiner | 09:32 | |
| gcerquant | looks like I have a DNS problem: testing from Dulles, VA, I get a DNS lookup failed. and from New Zealand, it works fine | 09:47 |
| gcerquant | lifeless: thanks a lot for this really neat tool (which also let me know about this problem) | 09:48 |
| lifeless | gcerquant: :) | 09:51 |
| lifeless | I only heard abou it today, myself | 09:51 |
| awilkins | gcerquant: Try setting your DNS to opendns | 10:23 |
| awilkins | gcerquant: The commonest reason I run into for DNS problems these days is a DNS daemon on the local wireless router crashing | 10:23 |
| awilkins | Usually fixable by router-reboot | 10:23 |
| gcerquant | It is (on my personal machine). But the requests are done with a machine I don't have control over... and it shows something is broken somewhere | 10:24 |
| awilkins | gcerquant: I hate infrastructure that breaks that other people have control over | 10:24 |
| gcerquant | I had similar problem with potential customers that had Verizon as their ISP. Don't know how widespread the problem is | 10:24 |
| gcerquant | me too | 10:25 |
| Lorem | Hi to all! | 10:34 |
| Lorem | i have a question | 10:34 |
| Lorem | i need to change my working directory to its parent, what is the best way? | 10:35 |
| vila | cd .. | 10:40 |
| GaryvdM | Lorem_: can you maybe explain in more detail? | 11:01 |
| awilkins | I think he means "I want to move my root to a subfolder of root and commit new content into root" | 11:02 |
| Lorem_ | awilkins, vice versa | 11:04 |
| Lorem_ | ah!!! no | 11:05 |
| Lorem_ | awilkins you are right | 11:05 |
| Lorem_ | is exactly what i want to do | 11:05 |
| awilkins | One aims to please ... | 11:06 |
| awilkins | :-) | 11:06 |
| === krisfree is now known as krisfremen | ||
| Mez | is there a way to enable a postcommit hook for ANY branch on a system? (an overarching bazaar.conf) | 11:26 |
| james_w | "[/]" in locations.conf? | 11:28 |
| Lorem_ | awilkins: i need to do that because i want to devide my project into 2 separete parts | 11:28 |
| Mez | james_w: It could be ran as different users though. | 11:28 |
| james_w | true | 11:29 |
| Mez | james_w: can you specify a post-commit hook from with the branch config ? (somewhere in .bzr?) | 11:30 |
| james_w | dunno | 11:30 |
| james_w | depends on the hook | 11:30 |
| Mez | james_w: basically I wanna setup the system so that it'll send a commit email whenever someone commits to any branch within /home/bzr (no matter who they login as - which is generally done through a bound branch) | 11:31 |
| andriijas | how do i check out a project from launchpad? | 11:36 |
| awilkins | andriijas: bzr branch lp:projectname | 11:37 |
| andriijas | ty | 11:37 |
| RaceCondition | are there any plans to make the bzr command a little bit faster? at least comparable to hg which it is currently not... | 11:41 |
| lifeless | RaceCondition: we're working on performance all the time | 11:41 |
| RaceCondition | but what's causing the current slowness of bzr? | 11:41 |
| lifeless | RaceCondition: doing what | 11:42 |
| RaceCondition | even bzr status | 11:42 |
| lifeless | how long is that taking for you? | 11:42 |
| RaceCondition | well not much, but still significantly longer than git status/hg status | 11:42 |
| lifeless | all three commands do different things | 11:43 |
| lifeless | so its hard to just compare them; however, bzr st for me is 0.3 seconds | 11:43 |
| lifeless | on my encrypted-disk slowish laptop | 11:43 |
| RaceCondition | 0.3 seconds is a lot | 11:43 |
| lifeless | it takes 0.24 seconds to load python and bzrlib | 11:44 |
| lifeless | we want to reduce that; its the major part of 'bzr status' these days. | 11:44 |
| RaceCondition | well it's obvious there's some constant overhead to all of the commands | 11:44 |
| RaceCondition | how come hg loads so fast? | 11:45 |
| RaceCondition | I mean I understand git, but hg is Python just like bzr... | 11:45 |
| lifeless | hg's code is very very lean, this has some advantages and some disadvantages | 11:45 |
| RaceCondition | what do you mean by lean? | 11:45 |
| RaceCondition | optimized? | 11:45 |
| lifeless | small | 11:45 |
| RaceCondition | oh | 11:45 |
| RaceCondition | so does the larger code size of bzr somehow result in more/better features? | 11:46 |
| Mez | lifeless: how would I setup a server so that any commit to /home/bzr (or sub branches) would generate a commit email? (these commits are generally though bound brnaches) | 11:46 |
| lifeless | yes, but its not all needed and that is one of the things we're changing | 11:46 |
| lifeless | I have to get back to the regional board emeting though,s orry | 11:46 |
| lifeless | Mez: install bzr-email, setup the config in locations.con | 11:46 |
| Mez | lifeless: I've tried that on the server. it doesnt work | 11:47 |
| lifeless | Mez: bzr versions? maybe file a bug on bzr-email with your config details and what you tried | 11:47 |
| Mez | 1.14 | 11:48 |
| Mez | ah, oops | 11:48 |
| Goundy | Guys I registred a branch on launchpad. | 11:49 |
| Mez | not the same user | 11:49 |
| Mez | damnit for different users :( | 11:49 |
| Goundy | Then I did: bzr branch mainline/ myWorkBranche/ | 11:49 |
| Goundy | Now I want to push myWorkBranch so I create a new branch on launchpad | 11:49 |
| Goundy | How to do this ? | 11:49 |
| RaceCondition | lifeless: just how long is it estimated that the feature cleanup will take? | 11:50 |
| Goundy | I tried a push but it says no new revision de push | 11:50 |
| Mez | but still didn't work :( | 11:50 |
| lifeless | Goundy: bzr push lp:~USERNAME/PROJECT/NEWBRANCHNAME | 11:59 |
| lifeless | Mez: file a bug please; bzr version for client and server and bzr-email version/revno | 11:59 |
| Goundy | lifeless yea Indeed it worked right now thank you very much dude ;) | 11:59 |
| lifeless | RaceCondition: no specific ETA; removing 0.24 seconds of constant overhead is less important than removing minutes of overhead on slow commands | 12:00 |
| lifeless | RaceCondition: on other machines it can be much lower too | 12:00 |
| RaceCondition | lifeless: I mean, will it be more like 2 months or more like 12 months? | 12:00 |
| lifeless | RaceCondition: I don't know | 12:01 |
| RaceCondition | and can I somehow track the progress you're making on this? | 12:01 |
| lifeless | sure, use bzr :) | 12:01 |
| lifeless | seriously though, the issues are tightly coupled to how python loads code, its not a simple thing to fix. | 12:02 |
| RaceCondition | lifeless: what about keeping a persistent process in memory somehow? | 12:19 |
| RaceCondition | so bzr status would just IPC that persistent process | 12:19 |
| luks | https://launchpad.net/bzr-service | 12:20 |
| RaceCondition | how do I use it? is it a replacement bzr command? | 12:21 |
| luks | I don't know actually, I just remembered seeing someting like that | 12:24 |
| lifeless | RaceCondition: there is a small C binary, bzr-client, that can talk to it | 12:32 |
| RaceCondition | lifeless: so will this change the way I use the bzr command? | 12:34 |
| lifeless | RaceCondition: I'd expect so; I don't know if it is a maintained plugin or not. | 12:34 |
| RaceCondition | well there's no point in better performance if it kills the usability... | 12:35 |
| spiv | RaceCondition: also, hg uses a more aggressive lazy-import module than bzr I think. | 12:39 |
| RaceCondition | spiv: and it's difficult to do the same in bzr? | 12:39 |
| spiv | RaceCondition: I'm pretty sure there's probably still some relatively low-hanging fruit in cleaning up our imports, though. | 12:40 |
| RaceCondition | yeah | 12:40 |
| RaceCondition | I have a feeling that performance is currently the main thing keeping bzr back, I myself at least am considering switching to hg because of this... | 12:40 |
| RaceCondition | but I'll wait if you say it'll be fixed more or less | 12:41 |
| spiv | At the moment it's quite common for all the repo formats to get loaded, for instance. And perhaps we should break up the bzrlib.errors module and put more of the exception definitions closer to the code that uses them. | 12:41 |
| lifeless | RaceCondition: performance as a whole is really important to us - just look at how much faster network push has gotten, or commit. | 12:41 |
| luks | bzrlib.builtins is pretty huge | 12:41 |
| spiv | Just the amount of time for Python to execute that many "class" statements is starting to be noticeable for us, and we always import bzrlib.errors for any command. | 12:41 |
| RaceCondition | spiv: still, what about integrating the bzr-service approach to bzr itself? | 12:41 |
| lifeless | luks: yes it is. I have some work in progress to radically shrink it. Needs details done. | 12:42 |
| RaceCondition | I mean this would mean you won't have to do any refactoring to lose the startup overhead | 12:42 |
| spiv | RaceCondition: I'm not very interested in that approach personally, but if someone wants to work on that I wouldn't discourage them. | 12:42 |
| spiv | If I ever get enough spare time I'd rather attack the problem at the source (things bzrlib could do better, things python itself could do better) | 12:42 |
| RaceCondition | well I'll be waiting :) | 12:43 |
| spiv | It's always a challenge finding the right trade-off with this sort of thing. For example, in general I've quite liked having lots of fairly fine-grained exceptions in bzrlib.errors, it's pretty convenient for maintainability of the code, but it's turned out to be a minor (and I do stress it's only minor) performance issue. | 12:45 |
| * awilkins is pretty happy with bzr performance ; no, it's not git, but it's rather faster than SVN and more compatible with win32 than git is | 12:59 | |
| awilkins | More performance is always welcomed though :-) | 13:00 |
| lifeless | awilkins: have you tried out 1.14 client and server yet? | 13:04 |
| awilkins | lifeless: 1.14 client is pretty nippy, I keep meaning to upgrade the server but it's not heavily used | 13:05 |
| awilkins | I suppose I use the server when I'm serving from my laptop to share it with my desktop | 13:06 |
| awilkins | I only ever try git to see if it got less scary on win32 though | 13:06 |
| awilkins | Although ATM most of my actual functioning work is being done on Jaunty because I got tired of the slothware that infests our corporate win32 installs | 13:08 |
| awilkins | It's actually faster to work on an external USB laptop drive than it is to use the internal drive with the win32 install | 13:08 |
| lifeless | nice | 13:09 |
| lifeless | you might like to test the 1.14 http server deployment carefully | 13:10 |
| awilkins | Why carefully? | 13:10 |
| lifeless | there is a bug open that the new jail for hpss servers may break http deployments | 13:10 |
| lifeless | I think its unrelated, but not 100% | 13:10 |
| lifeless | not 100% sure I mean. | 13:10 |
| awilkins | The last time I upgraded it the problem was that it defaulted to logging instead of not logging and the permissions errors were killing it | 13:10 |
| awilkins | Not your typical server install ; IIS 6 on win2k3 server running in PyISAPIe | 13:11 |
| lifeless | I know :) | 13:12 |
| awilkins | I have a very small incentive to upgrade it - most of the operations are being done to a file share and the server is only for external use avoiding the VPN | 13:12 |
| awilkins | Ah, yes | 13:12 |
| lifeless | we've made hpss operations _much_ better in 1.14 and 1.15;but if you're happy - great. | 13:13 |
| awilkins | Most of our external users are no longer working for us at the moment | 13:13 |
| lifeless | heh | 13:13 |
| awilkins | I'm really the person who uses it the most ; I can't stand fiddling about with VPN and file-share access sucks across it anyway | 13:14 |
| awilkins | And I only use it when a user has a problem in their branch they need examining | 13:14 |
| * awilkins feels motivated | 13:15 | |
| awilkins | It's running.... 1.9 | 13:16 |
| lifeless | heh | 13:19 |
| lifeless | iz stable | 13:20 |
| awilkins | Of course, our proxy server is so bad that you can't actually download 4.5 MB without it choking... | 13:26 |
| awilkins | lifeless: Yup, jail break: 'chroot-59278864:/// | 13:41 |
| awilkins | Nice. | 13:41 |
| lifeless | awilkins: damn | 13:43 |
| lifeless | awilkins: 1.12 for you then :( | 13:44 |
| lifeless | 1.13.2 happens to be == 1.14 | 13:44 |
| * lifeless hunts down the bug to confirm | 13:44 | |
| awilkins | https://bugs.launchpad.net/bzr/+bug/348308. | 13:44 |
| ubottu | Ubuntu bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] | 13:44 |
| lifeless | awilkins: if you could get a backtrace and perhaps put a few details in there that would be awesome | 13:44 |
| awilkins | It doesn't seem to emit a backtrace | 13:46 |
| * awilkins tries again | 13:46 | |
| awilkins | Or maybe I have logging off | 13:47 |
| lifeless | Peng_ has done so I just noticed | 13:47 |
| lifeless | don't worry, I'll follow up with his log info | 13:48 |
| awilkins | Aha | 13:48 |
| awilkins | Yes | 13:48 |
| * awilkins is tempted to just drop the resgistration of _pre_open_hook | 13:52 | |
| lifeless | you can do that too | 13:52 |
| awilkins | Commenting out _install_hook() on lin 75 of request.py is sufficient for the overly trusting | 13:55 |
| awilkins | It's running under user impersonation anyway and the users concerned only have rights for the repo folders | 13:56 |
| lifeless | the jail is to stop the server making http requests to the world ;) | 13:58 |
| lifeless | you need write access to make it do that, naturally. | 13:58 |
| lifeless | so its not a panic thing | 13:58 |
| awilkins | I have assessed the risks (ie - it was unjailed before anyway) and considered them to be manageable | 13:59 |
| lifeless | :) | 13:59 |
| lifeless | do let me know how it feels otherwise | 14:00 |
| lifeless | should be noticable snappier | 14:00 |
| awilkins | Well, quite snappy on a "no revisions to pull" from inside the network | 14:00 |
| lifeless | :) | 14:00 |
| awilkins | Has some issues with commands that write though | 14:14 |
| awilkins | I'm running a check on the repo | 14:14 |
| maxb_ | What is bzr's equivalent to "update -r NNN" in other VCSes? To temporarily set the working tree back to an earlier state | 14:27 |
| LeoNerd | revert ? | 14:28 |
| maxb_ | huh, ok. My intuition derived from other VCSes led me astray :-) | 14:34 |
| AmanicA | jelmer: do you know of a workaround for that "OperationalError: database is locked" bug? | 14:42 |
| AmanicA | my branch is locked and it does not seem to go away | 14:43 |
| AmanicA | sould I delete my cache? | 14:45 |
| jelmer | AmanicA: you mean the bzr-svn one? | 14:46 |
| AmanicA | yes | 14:46 |
| AmanicA | sorry | 14:46 |
| jelmer | AmanicA: I pushed a change to bzr-svn 0.6 the other day that allows it to use tdb rather than sqlite | 14:46 |
| AmanicA | I saw stuff like that yes | 14:47 |
| jelmer | AmanicA: tdb allows multiple writers (i.e. no more locking madness) | 14:47 |
| AmanicA | cool | 14:47 |
| AmanicA | how do I activate that? | 14:47 |
| jelmer | AmanicA: install python-tdb | 14:47 |
| AmanicA | ok thx | 14:47 |
| AmanicA | btw I found a workaround myself | 14:48 |
| AmanicA | lsof |grep svn |less | 14:48 |
| jelmer | AmanicA: ah :-) | 14:48 |
| AmanicA | and kill the nasty processes holding the lock | 14:48 |
| AmanicA | I'll stick that on the bug page | 14:48 |
| jonnydee | hi :) when I revert to an earlier revision, how can I ged rid of the marked changes reportet by "bzr st" ? | 14:57 |
| jonnydee | AFAIR I have to call another command after invoking "bzr revert -r <revspec>".... | 14:58 |
| igc | night all | 15:05 |
| james_w | jonnydee: plain "bzr revert" will remove any changes reported by "bzr st" | 15:09 |
| === vxnick_ is now known as vxnick | ||
| === vednis is now known as mars | ||
| jonnydee | james_W: but I thought a plain 'bzr revert' will revert to the last revision again...? | 15:21 |
| === guilhembi_ is now known as guilhembi | ||
| james_w | yes | 15:21 |
| jonnydee | But I just would like to "travel in time" and go to a specific revision by executing "bzr revert -r <revspec>". Now I want that 'bzr st' doesn't print anything... | 15:23 |
| jelmer | jonnydee: I think "bzr update -r" is supposed to do that, but I'm not sure if it's implemented yet | 15:23 |
| jonnydee | jelmer: OK, I see. That's what I need, thanks :) | 15:24 |
| maxb_ | LeoNerd: aha, my intuition wasn't so wrong after all (and bzr revert's help is really misleading) | 15:26 |
| jelmer | Yeah, I think we need to fix that.. | 15:27 |
| LeoNerd | maxb_: Oh.. I presumed you'd already tried 'bzr up -r' and failed.. :) | 15:27 |
| maxb_ | I did. Per above, it's not implemented | 15:28 |
| LeoNerd | Oh.. | 15:28 |
| maxb_ | jelmer: The bit which really confuses me is why "bzr revert" and "bzr revert ." behave differently | 15:28 |
| LeoNerd | Hm? It's it bzr merge . ? | 15:29 |
| * maxb_ has no idea what LeoNerd is talking about :-) | 15:29 | |
| LeoNerd | Hm.. thatsaid, I'm not sure I do either. perhaps I lost the plot... | 15:31 |
| jam | maxb_: 'bzr revert' revert everything in the tree, 'bzr revert .' revert everything underneath the current working directory | 15:31 |
| jam | bzr has a concept about the 'whole tree' which svn doesn't have | 15:31 |
| jam | jonnydee: you could 'bzr pull -r XXX . --overwrite' | 15:32 |
| jam | however, you won't have a way to go back to where you were | 15:32 |
| jam | without another branch | 15:32 |
| jam | I believe the sticking point for why 'bzr update -r XXX' failed to get implemented | 15:32 |
| jam | was where to look up 'XXX' in a heavy checkout situation | 15:32 |
| jam | since you could have a local branch and a remote branch, and XXX means different things in each | 15:32 |
| maxb_ | jam: Sorry, I should have been clearer: the bit which confuses me is what the rationale is for "bzr revert" and "bzr revert ." (in the tree root) behave differently - i.e. in respect to merge records | 15:32 |
| jam | maxb_: 'bzr revert .' is only reverting files/dirs, the meta-info isn't under '.' | 15:33 |
| jam | I could certainly agree with having a different flag for that | 15:33 |
| jelmer | +1 | 15:33 |
| LeoNerd | Ya.. revert is getting a little overloaded lately.. | 15:34 |
| LeoNerd | bzr revert should be roughly bzr diff | patch -R | 15:34 |
| maxb_ | jam: ok, that kind of makes sense. My naive assumption based on using other SCMs was that "resetting merge info" included "resetting the parent of the working tree" - which it actually doesn't, hence my confusion | 15:34 |
| maxb_ | Regarding the aforementioned lookup problem in heavy checkouts, surely the only sensible answer is "whatever revert -r XXX" does in that case? | 15:35 |
| jam | maxb_: 'update' things about the master branch, 'revert' never does (IIRC) | 15:37 |
| jam | s/things/thinks/ | 15:37 |
| jam | for example, 'bzr revert -r -1' does not do the same thing thing 'bzr update' would do. And I would consider "bzr update" ~= "bzr update -r -1" | 15:37 |
| maxb_ | oh. Um | 15:39 |
| maxb_ | bzr update is overloaded in the heavy checkout scenario, to mean both "change my local tree's parent" and "get changes from remote branch" | 15:39 |
| maxb_ | Ok, I understand the conundrum now | 15:39 |
| jam | maxb_: right | 15:44 |
| jam | and we sort of fell down a "we can't decide so we didn't do anything" pit | 15:44 |
| maxb_ | understandable, though regrettable | 15:45 |
| der| | hi, I would like to create a bzr server on my machine, can you please point me to the right direction on doing that ?, thanks.... | 15:57 |
| der| | ok never mind, reading the docs :) | 15:58 |
| SamB | der|: well, if you just want to provide read-only access, the simplest thing is to just put a repo up on your HTTP server | 15:59 |
| cornucopic | Hi all | 16:22 |
| cornucopic | bzr-email uses its 'own' smtp_connection.py. Whereas that is understood, why are certain methods not present there, as compared to the bzrlib/smtp_connection.py ? | 16:24 |
| cornucopic | like, for eg. the code in _authenticate() is different for the two | 16:25 |
| jelmer | cornucopic: I think that's mainly for historical reasons | 16:30 |
| cornucopic | jelmer, What about less/wrong functionality ? | 16:30 |
| cornucopic | jelmer, from the looks of it, the former won't look for a username in authentication.conf , if not specified in bazaar.conf. | 16:31 |
| cornucopic | that is one. | 16:31 |
| jelmer | cornucopic: I think one has just been patched while the other hasn't | 16:33 |
| jelmer | cornucopic: ideally they should be the same | 16:33 |
| cornucopic | jelmer, Yes. probably | 16:34 |
| ronny | jelmer: what are the plans wrt dulwich workdir support? | 16:40 |
| ronny | currently i have to deal with the fact that git wont tell me some data below at least 3 subprocess invocations | 16:41 |
| jelmer | ronny: it's there | 16:41 |
| jelmer | ronny: :-) | 16:41 |
| ronny | jelmer: did the repo url change at some point? | 16:41 |
| jelmer | ronny: well, work dir in the sense that we now have a index writer/reader and a function to commit trees | 16:41 |
| jelmer | ronny: http://people.samba.org/bzr/jelmer/dulwich/trunk | 16:42 |
| jelmer | ronny: or git://git.samba.org/jelmer/dulwich.git | 16:42 |
| ronny | jelmer: well, i kinda need something like git status + | 16:42 |
| ronny | ie all status information for all files in a workdir | 16:43 |
| jelmer | ronny: what exactly do you need? Something to tell you which files are out of date wrt the index? | 16:43 |
| ronny | jelmer: i need to know what the vcs thinks about all files in a workdir + what files are missing (and if the index know they are missing) | 16:44 |
| SamB | ronny: bzr status ? | 16:53 |
| jelmer | ronny: can you perhaps file a bug about what you're looking for (including a suggested API)? | 16:53 |
| SamB | oh, are you working in a git checkout ? | 16:53 |
| SamB | I mean, a native git checkout ? | 16:53 |
| SamB | with a .git directory, not a .bzr directory? | 16:54 |
| jelmer | ronny: API as in what it would return/yield, I guess the arguments would be a base path and an index object | 16:56 |
| jelmer | SamB: this is actually not related to bzr :-) | 16:56 |
| SamB | oh! how confusing. | 16:56 |
| SamB | jelmer: what is it about ? | 16:57 |
| SamB | oh, dulwich ... | 16:57 |
| jelmer | SamB: dulwich (http://samba.org/~jelmer/dulwich) | 16:57 |
| SamB | bzr-git's backend ? | 16:57 |
| jelmer | SamB: yep, but not tied to bzr in any way | 16:57 |
| SamB | I know | 16:57 |
| SamB | oh, that's such a pythonic way to name it :-) | 16:58 |
| SamB | jelmer: hmm ... I can't seem to clone your repository ... | 17:28 |
| SamB | git doesn't seem to like the nested ".git" directories | 17:28 |
| jelmer | SamB: yes, that's a git bug | 17:29 |
| SamB | jelmer: is it recognized as a bug by the maintainers? | 17:29 |
| jelmer | SamB: not sure, I haven't followed up on it | 17:29 |
| SamB | I have this feeling the behaviour is intentional ... | 17:30 |
| SamB | since it seems like those directories would be really confusing to work with | 17:31 |
| SamB | for both humans and tools alike | 17:31 |
| jelmer | SamB: I don't see what the problem is for humans | 17:32 |
| SamB | well, mostly what the tools would do if invoked from the subdirectory, I guess | 17:33 |
| jelmer | use the closest .git directory | 17:34 |
| SamB | well, yes, that could get confusing ;-) | 17:50 |
| CaMason | is it possible for me to have a 'reference' to an external svn project in my bzr project? I'm using some libs that are hosted on svn | 18:07 |
| CaMason | nvm I'll use checkout instead | 18:10 |
| pygi | CaMason: not yet | 18:14 |
| CaMason | pygi, ok no worries. It was a svn tag anyway :) | 18:15 |
| der| | hi, I've created a branch on my computer. A remote user downloaded my branch, he committed the changes, but when trying to push, it gives an error | 18:36 |
| beuno | der|, what error? | 18:36 |
| der| | bzr: ERROR: Cannot lock LockDir(sftp://host/var/bzr/bzr_test/.bzr/branch/lock): Permission denied: "/var/bzr/bzr_test/.bzr/branch/lock/5mc4cplu0h.tmp": [Errno 13] Permission denied | 18:37 |
| der| | I've used bzr with launchpad, haven't tried using my pc as a server though, where the main branch would be located | 18:37 |
| pzico | Hi, I have registered new launchpad project, but I'm a bit unsure how should I name branches. Should the name of the main branch be linux or ubuntu or dev.. or should I divide different parts in separate branches like python functionality in it's own and C in it's own. | 18:41 |
| SamB | pzico: generally, you put the whole code tree in one branch, and call it something like lp:~pzico/fooproject/trunk | 18:42 |
| pzico | Maybe I need some practical tutorial. Somehow those launchpad examples only mixed my head. | 18:42 |
| SamB | and then you make other branches for topics and stuff | 18:42 |
| pzico | does that mean that the trunk is also a folder on my home directory where I also made bzr init command? | 18:43 |
| SamB | not exactly | 18:43 |
| SamB | that's your local repository, where you work | 18:43 |
| SamB | you would push that to the lp url, though | 18:44 |
| SamB | oh, the ~pzico in the launchpad url just means that it's one of your branches | 18:45 |
| pzico | hmm, by taking couple of random examples of existing projects, why can't I see trunk used as a branch name? | 18:45 |
| SamB | the next bit, fooproject, should be the exact URL name of your launchpad project | 18:45 |
| SamB | pzico: well, often it gets abbreviated to just lp:fooproject | 18:45 |
| SamB | the third bit is whatever you like ... | 18:46 |
| pzico | so the trunk is a sensible name for the initial development branch? | 18:47 |
| SamB | yup | 18:47 |
| pzico | thanks, I just did my first push :D | 18:53 |
| pzico | Launchpad says: A development focus branch hasn't been specified, set it now. | 18:54 |
| pzico | Should I put here also that same? | 18:54 |
| pzico | I chose the same. I guess I got it all working. | 18:57 |
| pzico | Is it a good practice to have a separate branch for documentation or to include in trunk under specific folder name? | 19:05 |
| der| | I've created a bzr server on my machine, and I'm trying to commit the changes to the server, but it gives the following error: This transport does not update the working tree of: bzr://localhost/projects/bzr_test/trunk/. See 'bzr help working-trees' for more information. | 19:07 |
| der| | bzr: ERROR: Cannot lock LockDir(chroot-33399120:///projects/bzr_test/trunk/.bzr/branch/lock): Transport operation not possible: readonly transport | 19:07 |
| LarstiQ | pzico: normally, I'd keep everything pertaining to a project in one and the same branch | 19:07 |
| LarstiQ | der|: those are two different things | 19:08 |
| der| | LarstiQ, sorry, I'm a little bit confused here :) | 19:08 |
| LarstiQ | der|: the readonly mention seems to me like you didn't specify --allow-writes | 19:09 |
| der| | LarstiQ, uhm.... right.... | 19:09 |
| der| | LarstiQ, the --allow-writes should be passed when running bzr init right ? | 19:09 |
| LarstiQ | der|: to bzr serve | 19:09 |
| der| | LarstiQ, ah, good, let me try that | 19:09 |
| LarstiQ | der|: that is how you are running the server, right? | 19:09 |
| der| | LarstiQ, correct | 19:09 |
| LarstiQ | ok then | 19:10 |
| der| | what's the difference between the checkout and the branch commands ? | 19:10 |
| LarstiQ | der|: as to not upating the workingtree, a workingtree is usually not needed on a server hosting bzr branches | 19:10 |
| der| | LarstiQ, and why is that ? | 19:11 |
| LarstiQ | der|: checkouts bundle commit/publish and if you branch you decouple those. | 19:11 |
| LarstiQ | der|: all the required data for bzr to operate is stored in .bzr/ | 19:11 |
| der| | LarstiQ, yes | 19:11 |
| der| | LarstiQ, so, that means that if I'm going to have a server hosting bzr branches, I need working trees or normal trees ? | 19:13 |
| LarstiQ | der|: that means you only need branches | 19:15 |
| LarstiQ | der|: so on the server, go to /projects/bzr_test/trunk and do `bzr remove-tree` | 19:15 |
| der| | LarstiQ, ok | 19:15 |
| der| | LarstiQ, done | 19:15 |
| der| | LarstiQ, after I remove the working tree, I can push to that tree right ? | 19:17 |
| LarstiQ | der|: s/tree/branch/, yes :) | 19:17 |
| der| | LarstiQ, ah, I think I get it, correct me if I'm wrong..... so working trees are good with local branches | 19:17 |
| LarstiQ | der|: correct! | 19:18 |
| der| | LarstiQ, so let's say, /var/bzr/stuff | 19:18 |
| der| | LarstiQ, but, when I use a server, working trees are not needed, and we need branches | 19:18 |
| LarstiQ | for editing files, using them, etc. | 19:18 |
| LarstiQ | der|: basically. | 19:18 |
| der| | LarstiQ, and, by default, bzr creates working trees with bzr-init right ? | 19:18 |
| LarstiQ | der|: yes | 19:18 |
| der| | LarstiQ, ah ok | 19:18 |
| der| | LarstiQ, I'm a 3D artist, and I'm using bzr to keep track of the changes | 19:18 |
| LarstiQ | and bzr will not create working trees if you push to a remote server | 19:18 |
| LarstiQ | der|: cool :) | 19:19 |
| der| | along with qbzr, I created a small tool to make things faster | 19:19 |
| der| | let me show you | 19:19 |
| der| | LarstiQ, I'm doing this: http://ernestomendez.wordpress.com | 19:19 |
| LarstiQ | der|: so if you do `bzr init; bzr add; bz ci` locally, and then `bzr push to/server`, it will do the right thing | 19:19 |
| der| | LarstiQ, I'm using the qbzr plugin, along with a small gui I did for qbzr, to access stuff fast... Here's the screenshot: http://imagebin.org/48617 | 19:20 |
| LarstiQ | der|: so your tool is the list of actions on the right? | 19:21 |
| der| | yeah | 19:21 |
| LarstiQ | der|: how does it work, does it call the qcommands from the dir you started the tool from? | 19:21 |
| der| | LarstiQ, and I created a small .desktop file inside the project, with the variable Path= set as the working directory, where the project is located | 19:21 |
| LarstiQ | aah | 19:21 |
| der| | :D | 19:21 |
| der| | smart huh :P | 19:22 |
| LarstiQ | :) | 19:22 |
| der| | I had to read the .desktop file specification, was breaking my head | 19:22 |
| LarstiQ | der|: have you thought of contributing this to the qbzr plugin? | 19:23 |
| der| | LarstiQ, well, it would be my pleasure :D | 19:23 |
| der| | LarstiQ, I didn't know that would be of some use for you guys | 19:23 |
| der| | LarstiQ, and the cool thing, it doesn't use any .glade file, just pure code | 19:23 |
| LarstiQ | der|: you mention .glade, does that mean it uses gtk? | 19:24 |
| der| | LarstiQ, yeah, it's written in python/gtk (pygtk) | 19:24 |
| LarstiQ | ah ok | 19:24 |
| der| | but surely the guy can be implemented on qt | 19:24 |
| LarstiQ | der|: qbzr is written in pyqt | 19:24 |
| * LarstiQ nods | 19:24 | |
| LarstiQ | luks: would something like der|'s http://imagebin.org/48617 be useful to qbzr? | 19:25 |
| der| | LarstiQ, I mean, it's cool since you access all qbzr's commands easily, without having to use the command line | 19:25 |
| * LarstiQ nods | 19:26 | |
| LarstiQ | der|: I think there is a use for it, but I'm not a qbzr contributor. | 19:26 |
| der| | LarstiQ, ah, and the cool thing is, when you don't have a .bzr directory in it, the only button it has is 'Initialize Branch' which is bzr qinit | 19:26 |
| luks | hm, I'd rather add nautilus menu items | 19:26 |
| luks | so you don't have to launch any app | 19:27 |
| der| | yeah, nautilus-scripts would do the job too | 19:27 |
| LarstiQ | right, but you need to bring the menu up each and every time | 19:27 |
| der| | yeah | 19:27 |
| der| | on this case, you bring up the small app, then you just click, it won't close | 19:27 |
| der| | that way you can see the logs, then add the files,then commit etc | 19:27 |
| LarstiQ | qbrowse comes closeish | 19:28 |
| LarstiQ | qbrowse \o/ | 19:28 |
| LarstiQ | luks: thanks for that btw :) | 19:28 |
| luks | there is (unfinished and dead) bzr qbzr, which had this ambition | 19:29 |
| der| | luks, LarstiQ you can have the code here: http://dpaste.com/43453/ | 19:29 |
| LeoNerd | Ahah. I think I've found a bug... 'bzr revert' will save an old copy of a file to foo.~1~, unless it was modified by a merge. But now since 'bzr shelve' is implemented using a merge, it won't save one if you shelve/unshelve/revert | 19:53 |
| jnz_ | Hi, I'm having a problem supporting sftp into bzr, that is this: https://bugs.launchpad.net/ubuntu/+source/python-crypto/+bug/79519 . But I haven't understool how to resolve it. | 20:04 |
| ubottu | Launchpad bug 79519 in python-crypto "ImportError: No module named Crypto.Util.randpool" [High,Won't fix] | 20:04 |
| jnz_ | *understood | 20:04 |
| jnz_ | uh great :D | 20:04 |
| * LarstiQ looks at the bug | 20:05 | |
| jnz_ | I'm not using ubuntu | 20:05 |
| LarstiQ | jnz_: so the ubuntu bug doesn't apply to you :) Do you have pycrypto installed? | 20:05 |
| LarstiQ | without paramiko won't work, without which bzr can't support sftp/ssh | 20:06 |
| LarstiQ | LeoNerd: ah, good catch | 20:06 |
| jnz_ | uhm I have read that was needed only m2crypto, however I don't have it (no module named pycrypto) | 20:07 |
| LarstiQ | jnz_: python -c 'import Crypto' ? | 20:08 |
| jnz_ | no module named Crypto | 20:08 |
| LarstiQ | jnz_: then you don't have it installed | 20:09 |
| LarstiQ | jnz_: if your package management doesn't provide it, http://pypi.python.org/pypi/pycrypto | 20:10 |
| LarstiQ | hmm, maybe that is old | 20:10 |
| LarstiQ | but no, that is what I've got installed on Debian | 20:11 |
| jnz_ | I've installed it, but the problem remains, http://pastebin.com/m1721b456 (localhost is just for the test) | 20:13 |
| LarstiQ | jnz_: now it mentions you don't have paramiko installed | 20:14 |
| jnz_ | It's strange, if I open the python shell and try with `import paramiko' I get only warning message, but if I run the bzr command no module paramiko is found | 20:22 |
| LarstiQ | jnz_: does your bzr use the same python install as `python` from the commandline? | 20:23 |
| LarstiQ | jnz_: see `bzr --version` | 20:23 |
| === beuno_ is now known as beuno | ||
| chrismurf | Hi - I just performed a merge, and now 'bzr info' shows a 'submit branch' related to my repository. What is that, and how do I get rid of it? | 20:45 |
| jnz_ | ok resolved, thanks LarstiQ | 20:46 |
| chrismurf | now I have a "public branch" too. How do I just get rid of the 'related branches' -- they aren't valid locations. | 20:50 |
| LarstiQ | chrismurf: just like with pull --remember you can change those lcocations merge sets. | 21:21 |
| chrismurf | LarstiQ, I'm sorry; I don't understand? | 21:22 |
| LarstiQ | chrismurf: all the related branches get set by bzr commands if they're empty, or if you pass --remember to the relevant command | 21:22 |
| chrismurf | okay - so given that I now have the related branches, how do I get rid of them? | 21:23 |
| LarstiQ | chrismurf: is it your aim to have no related branhces at all, or different ones? | 21:23 |
| chrismurf | I didn't use '--remember' so, I'm not sure where they came from? | 21:23 |
| chrismurf | in this case, none | 21:24 |
| chrismurf | it's pointing at a temporary merge directory I created | 21:24 |
| chrismurf | which I doubt does harm, but that directory is going to go away | 21:24 |
| LarstiQ | chrismurf: the going away is fine | 21:24 |
| LarstiQ | chrismurf: they serve as defaults so you can do `bzr merge` without specifying an argument | 21:24 |
| LarstiQ | but anyway | 21:24 |
| LarstiQ | chrismurf: .bzr/branch/branch.conf | 21:25 |
| chrismurf | Ah! Thank you | 21:25 |
| chrismurf | and thank you for explaining their purpose | 21:25 |
| LarstiQ | and as useful shorthands | 21:25 |
| chrismurf | been using BZR mostly for client-server style interactions for a while now | 21:25 |
| LarstiQ | say, `bzr missing nosmart+:parent/../sibling` | 21:26 |
| chrismurf | but starting to use it more as a DVCS, and still learning | 21:26 |
| LarstiQ | chrismurf: righ | 21:26 |
| LarstiQ | chrismurf: main thing to remember, all branches are equal, none is technically special, it's just convenients for us humans :) | 21:26 |
| chrismurf | right :-) | 21:27 |
| chrismurf | so - hand editing branch.conf is a not-awful way to change such things? | 21:27 |
| chrismurf | since they're just convenience tags for me anyway? | 21:27 |
| LarstiQ | chrismurf: I think it's a bit of a ui wart, but yes, that's ok | 21:27 |
| LarstiQ | nothing in bzr will miss 'm | 21:28 |
| chrismurf | okay - and there's no "bzr get-rid-of-shortcuts" I should know :-) | 21:28 |
| LarstiQ | indeed | 21:28 |
| chrismurf | well, again, many thanks | 21:28 |
| LarstiQ | np | 21:29 |
| LarstiQ | chrismurf: feel free to ask more questions on your path to DVCS nirvana ;) | 21:31 |
| luke-jr_ | If I 'bzr commit', and 'bzr uncommit', will that commit be kept in the repository under its 'revid' in case I ever want to dig it out in the future? | 22:27 |
| lifeless | luke-jr_: yes until you garbage collect (there is a plugi to do this), or if you branch to a new repo it won't be copied across | 22:30 |
| lifeless | moin | 22:30 |
| luke-jr_ | I see. | 22:30 |
| luke-jr_ | so it wouldn't get sent with a push, either? | 22:30 |
| luke-jr_ | is there a good way to save scraps better? ;) | 22:31 |
| jam | morning lifeless | 22:47 |
| jam | luke-jr_: create a branch for them? | 22:47 |
| luke-jr_ | jam: by "scraps" I mean "broken and never worked or even compiled" ;) | 22:48 |
| jam | luke-jr_: if you have a commit that you want to save, I recommend creating a branch for them | 22:48 |
| jam | I personally have no qualms committing broken code | 22:48 |
| jam | I just don't merge it to 'trunk' | 22:48 |
| luke-jr_ | i c | 22:49 |
| jam | lifeless: I've been working on some slides, they are still pretty rough | 22:57 |
| jam | I was thinking to upload them somewhere if you wanted to then take over | 22:57 |
| jam | would you prefer a bzr branch? | 22:57 |
| jam | (I'm using .odp) | 22:57 |
| lifeless | jam: branch or mail is fine | 22:59 |
| lifeless | branch would be the canonical way :P | 22:59 |
| jam | lifeless: yeah, I just feel a little silly uploading a work-in progress to a +junk branch, but that was my original idea | 23:01 |
| lifeless | doit ;) | 23:07 |
| lifeless | we can't merge, so lets be careful about handing off | 23:07 |
| beuno | in bbc :) | 23:07 |
| lifeless | beuno: ? | 23:08 |
| beuno | in dev6-r-r format | 23:08 |
| beuno | dogfoooooood! | 23:08 |
| bob2 | congrats on becoming an adaptive vcs | 23:09 |
| lifeless | jam: drop me a mail when you've pushed; | 23:18 |
| jam | lifeless: lp:~jameinel/+junk/karmic_presentations | 23:19 |
| jam | I'm out for the night | 23:19 |
| AmanicA | dam its late if the americans goes to bed before you | 23:21 |
| jelmer | it's not a problem until you go to bed after the Californians ;-) | 23:22 |
| lifeless | AmanicA: the americans always go to bed before me | 23:33 |
| AmanicA | :) | 23:33 |
| AmanicA | like right after you get up | 23:34 |
| lifeless | :) | 23:34 |
| mwhudson | actually, not always | 23:45 |
| mwhudson | sometimes they are still around when i quit work, which is not really right :) | 23:45 |
| jelmer | lifeless: around? | 23:51 |
| lifeless | yes! | 23:51 |
| jelmer | lifeless: CHKMap, is that usable for a single file (like knits are), and could I use it to store arbitrary data? | 23:51 |
| jelmer | I'm using a knit for the file id map in bzr-svn atm, and from what I've seen a CHKMap would both be faster and more efficient | 23:52 |
| lifeless | jelmer: you need a pack repository style container | 23:52 |
| lifeless | same as bzr-search does | 23:53 |
| jelmer | lifeless: but it can store just arbitrary data (I need path string -> tuple of 3 strings) ? | 23:53 |
| lifeless | chkmap is str->str | 23:54 |
| lifeless | encode as you like on top | 23:54 |
| lifeless | actually I like | 23:54 |
| jelmer | neat, I'll go check that out | 23:54 |
| lifeless | its tuple->str | 23:54 |
| lifeless | s/like/lie | 23:54 |
| jelmer | mwhudson: looks like the linux kernel doesn't work with bzr-git yet | 23:56 |
| jelmer | mwhudson: they use unusual file modes that aren't mappable to bzr inventory entry properties | 23:56 |
| lifeless | oh? | 23:56 |
| jelmer | those file modes are forbidden in git these days, but they used to be allowed | 23:57 |
| jelmer | 644 and 755 are the only modes set by non-ancient versions of git | 23:57 |
| jelmer | and the linux kernel has e.g. 664 in some places | 23:57 |
| mwhudson | jelmer: weeeee! | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!