| poolie | together or separately? | 00:00 |
|---|---|---|
| lifeless | about the 1.3 regression | 00:00 |
| lifeless | https://bugs.edge.launchpad.net/ubuntu/hardy/+source/bzr/+bug/208418/ | 00:00 |
| ubotu | Launchpad bug 208418 in bzr "ValueError when trying to pull/merge from a remote repository" [Critical,Confirmed] | 00:00 |
| poolie | yes me too | 00:01 |
| poolie | call the meeting room then | 00:01 |
| * spiv dials in | 00:01 | |
| beuno | vila, uploaded a few changes, hope they're fine with you :) | 00:01 |
| lifeless | x`whats the page again | 00:02 |
| lifeless | got it | 00:03 |
| spiv | lifeless, poolie: http://people.ubuntu.com/~andrew/bzr-dbus-knit.tar.gz | 00:12 |
| spiv | "bzr pull bzr+ssh://bazaar.launchpad.net/%7Ebzr/bzr-dbus/trunk/" in that | 00:13 |
| jelmer | woot, finally got bzr to authenticate over ftp using Kerberos \o/ | 00:13 |
| spiv | "13.743 incompatible format signature inserting to KnitVersionedFile(file:///home/andrew/code/bzr-dbus.knit-1/.bzr/repository/knits/b7/test_hook.py-20070206032 | 00:15 |
| spiv | 729-2b5teqiwctqrfgei-8)" | 00:15 |
| spiv | that looks suspicious | 00:15 |
| spiv | From the -Dhpss output, there's only two chunks been read. | 00:17 |
| spiv | So it's seeing an incompatible format chunk, and translating that, then falling over. | 00:17 |
| spiv | And it happens on the first knit record. (The first chunk read is an overall format header, IIRC). | 00:17 |
| beuno | jelmer, around? | 00:19 |
| beuno | jelmer, it seems to use Branch.get_config(), I need to pass a branch to it, so I have to check each time if there is branch or not. Won't that be a bit of a performance git? | 00:21 |
| beuno | s/git/hit | 00:22 |
| lifeless | spiv: so, my bet is spot on ;) | 00:23 |
| jelmer | beuno: I think it's pretty quick if bzrlib is already loaded | 00:26 |
| jelmer | beuno: To be sure it may be useful to bypass that stuff if GlobalConfig() has nautilus integration disabled | 00:27 |
| spiv | lifeless: what do you make of http://rafb.net/p/b2vAx192.html | 00:28 |
| spiv | lifeless: it looks like maybe fulltext records are missing the int,int,int header? | 00:28 |
| poolie | jelmer: nice | 00:28 |
| poolie | re kerberos | 00:29 |
| beuno | jelmer, let me give it a try... | 00:29 |
| poolie | spiv: well, itym the deltas? | 00:29 |
| poolie | the deltas look like fulltexts? | 00:29 |
| spiv | poolie: each component should be (component_id, record, record_details, digest) | 00:31 |
| spiv | Hmm, well. | 00:32 |
| spiv | the first component has ('line-delta', False), but also has the int,int,int header line. | 00:32 |
| spiv | The final component has ('fulltext', False), | 00:32 |
| spiv | It seems to be iterating the components in reverse order. And the second last one has 'line-delta', but is a fulltext. | 00:33 |
| spiv | So I guess that's why it's blowing up. | 00:33 |
| poolie | spiv: what routine did this come from? | 00:33 |
| spiv | It builds that components list using KnitVersionedFile._get_record_map | 00:34 |
| spiv | bzrlib.knit:KnitVersionedFile._get_content_maps | 00:34 |
| poolie | it looks to me like the secondone is also a delta but does not have int,int,int headers? | 00:36 |
| spiv | Right, but it hasn't got that far. | 00:37 |
| spiv | Because it's already blown up :) | 00:37 |
| lifeless | spiv: the '88,89,1\n', | 00:37 |
| lifeless | spiv: is the delta length header | 00:37 |
| lifeless | spiv: fulltexts are not meand to have one | 00:37 |
| poolie | lifeless: so the first delta looks ok, but the others are not | 00:37 |
| poolie | spiv: what method is iterating the components in reverse order? | 00:37 |
| poolie | oh | 00:38 |
| * poolie reads the backtrace | 00:38 | |
| spiv | poolie: KnitVersionedFile._get_content_maps is | 00:38 |
| poolie | riht | 00:39 |
| === hexmode` is now known as hexmode | ||
| lifeless | so lower_fulltext doesn't have a int int int prefix | 00:40 |
| lifeless | spiv: line 123 is the bug | 00:41 |
| lifeless | spiv: it claims 'line-delta' but it has a fulltext | 00:41 |
| lifeless | spiv: as you say above :> | 00:42 |
| poolie | of which file? | 00:42 |
| lifeless | spiv: so you need to look at what created the content maps | 00:42 |
| poolie | or of the pastebin | 00:42 |
| lifeless | poolie: of the pastebin | 00:42 |
| poolie | right | 00:42 |
| poolie | i was really impressed for a second there :) | 00:42 |
| spiv | lifeless: right, and ditto line 239 | 00:43 |
| spiv | self._index.get_build_details(['robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d']) claims line-delta | 00:44 |
| spiv | (ditto for the other fulltext record) | 00:44 |
| poolie | spiv: could you pastebin the -Dhpss output if you have it? | 00:47 |
| spiv | Which asks the backing index for the _StreamIndex | 00:47 |
| spiv | poolie: coming up | 00:47 |
| lifeless | spiv: what is self._index? | 00:48 |
| spiv | poolie: http://rafb.net/p/vLuSj352.html | 00:48 |
| schierbeck | jelmer: ping | 00:48 |
| spiv | lifeless: <bzrlib.knit._StreamIndex object at 0x88db2ec> | 00:49 |
| spiv | lifeless: with a .backing_index of _KnitIndex(b7/test_hook.py-20070206032729-2b5teqiwctqrfgei-8.kndx) | 00:49 |
| lifeless | k | 00:49 |
| lifeless | the backing index is in the target repository is it not? | 00:49 |
| spiv | Which has 'line-delta' in its self._cache | 00:49 |
| * poolie looks at diff from 1.2 to 1.3 in knit.py | 00:50 | |
| spiv | lifeless: the one I'm pulling into, yes | 00:50 |
| spiv | lifeless: the remote branch is in pack format | 00:50 |
| lifeless | spiv: is 'robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d' in the local knitindex? | 00:50 |
| spiv | lifeless: yes: http://rafb.net/p/nfa8B131.html | 00:52 |
| spiv | lifeless: and, curiously, it's a line-delta in the test_hook .kndx file. | 00:53 |
| lifeless | spiv: well 'robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d' in self._index.backing_index.versions() is easier :) | 00:53 |
| spiv | So, the kndx says line-delta. | 00:54 |
| spiv | But the component the code was dealing with in _get_content_maps looked like a fulltext. | 00:55 |
| lifeless | so, how did the component get there :P | 00:57 |
| spiv | Gar, pdb bugs. | 01:03 |
| spiv | --Call-- | 01:03 |
| spiv | /usr/lib/python2.5/bdb.py:318: RuntimeWarning: tp_compare didn't return -1 or -2 for exception | 01:03 |
| spiv | i = max(0, len(stack) - 1) | 01:03 |
| spiv | LEAVING RECURSIVE DEBUGGER | 01:03 |
| spiv | Oh, right, because I tried to step into a generator. | 01:04 |
| spiv | I've seen that pdb bug before. | 01:05 |
| * spiv puts a breakpoint somewhere else | 01:05 | |
| poolie | i'm going to try just getting the data stream for this file across hpss | 01:06 |
| spiv | Ok, I think I see part of the problem: | 01:16 |
| spiv | (Pdb) pp self._access.backing_knit.get_lines('robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d')[0] | 01:16 |
| spiv | '# bzr-dbus: dbus support for bzr/bzrlib.\n' | 01:16 |
| spiv | (Pdb) pp self._access.backing_knit._index.get_options('robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d') | 01:16 |
| spiv | ['line-delta'] | 01:16 |
| spiv | (Pdb) pp self | 01:17 |
| spiv | <bzrlib.knit._KnitData object at 0x88dc36c> | 01:17 |
| spiv | I think that may be causing _StreamAccess.get_raw_records to return a fulltext with a 'line-delta' flag. | 01:17 |
| * spiv rereads | 01:17 | |
| jelmer | schierbeck: pong | 01:17 |
| poolie | get_lines is meant to return a fulltext though... | 01:17 |
| schierbeck | could i get you to review the seahorse patches? | 01:18 |
| spiv | Hmm, maybe not. | 01:18 |
| schierbeck | including the gannotate crasher fix? | 01:18 |
| schierbeck | it can wait until tomorrow if you like | 01:18 |
| poolie | so we're working on file id 'test_hook.py-20070206032729-2b5teqiwctqrfgei-8' right? | 01:19 |
| poolie | afaics the only new version of that is 'jelmer@samba.org-20080319144357-o10479ukm9486mjc' | 01:19 |
| beuno | jelmer, almost there :) | 01:20 |
| spiv | poolie: that matches what I've seen. | 01:21 |
| poolie | so i have a reference to the remote knit, and to the composite knit used in pulling | 01:22 |
| poolie | am going to try to read the raw records from both.. | 01:22 |
| poolie | ok, so, obviously, calling get_lines on the result of _knit_from_datastream fails | 01:23 |
| poolie | whereas calling that on the vf obtained direct from the remote repository works | 01:24 |
| jelmer | schierbeck: I don't like the fix, I think we should rather pass in a branch and a repository | 01:24 |
| jelmer | schierbeck: since gannotate does have a repository and a repository is sufficient for retrieving the signatures | 01:24 |
| schierbeck | okay | 01:24 |
| poolie | i wonder if the problem relates to sharing the local index... | 01:24 |
| spiv | Ugh, pdb gets really confused by generators. | 01:26 |
| poolie | they have the same index except obviously a different index_memo | 01:27 |
| lifeless | poolie: get lines returns an output | 01:27 |
| poolie | what do you mean? | 01:28 |
| lifeless | meh, sorry | 01:29 |
| lifeless | bad api - similar method names different levels | 01:29 |
| poolie | :) i think i said something to that effect last week | 01:29 |
| poolie | so i'm going to try to use the index memo to get the raw record in both ways | 01:29 |
| poolie | and see if they are plausible | 01:30 |
| spiv | Interestingly, I'm seeing duplicated reads of knit records. | 01:30 |
| spiv | Huh! | 01:31 |
| spiv | I'm seeing different bytes for subsequent reads of one of the affected records... | 01:31 |
| poolie | ipython yay | 01:31 |
| spiv | Ah, different index_memos. | 01:32 |
| spiv | (None, 3160, 743) vs. (True, 'robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d', None, None) | 01:32 |
| poolie | interesting | 01:32 |
| poolie | ok, so In [73]: rcptknit._data.read_records([(missing_version, rcpt_index_memo)]) | 01:32 |
| poolie | Out[73]: | 01:32 |
| poolie | {'jelmer@samba.org-20080319144357-o10479ukm9486mjc': (['88,89,1\n', | 01:32 |
| poolie | " hook.on_server_start(['source'], 'target')\n", | 01:32 |
| poolie | '109,110,1\n', | 01:32 |
| poolie | " hook.on_server_stop(['source'], 'target')\n"], | 01:32 |
| poolie | 'aeb329edcf769738daaf07c22e921310551ff520')} | 01:32 |
| poolie | in other words, the composite knit for receiving the data stream _does_ seem to have the right delta at one level | 01:32 |
| poolie | it must be losing it later on | 01:32 |
| spiv | Well, that particular version_id has had the rigth data all the way through, I think. | 01:33 |
| spiv | We seems to be seeing the mismatch on a record that's already present locally, I think? | 01:33 |
| poolie | oh fuck | 01:34 |
| poolie | gnome terminal crashed losing all my state | 01:34 |
| spiv | poolie: *suck* | 01:35 |
| lifeless | xterm | 01:35 |
| lifeless | + screen | 01:35 |
| poolie | yeah | 01:35 |
| poolie | it had just sucked me into trusting it in hardy | 01:35 |
| lifeless | spiv: what did you think of my impotr hook | 01:38 |
| spiv | lifeless: it looks interesting, but I haven't done much more than glance at it | 01:39 |
| poolie | spiv, so we think the bad version is eg 'robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d'? | 01:39 |
| spiv | poolie: yes | 01:41 |
| spiv | poolie: (and 'robertc@robertcollins.net-20070427001748-ctalelbr21ggxkuh', but it's choking on the other one first) | 01:41 |
| lifeless | its not me I promise | 01:43 |
| spiv | lifeless: :) | 01:44 |
| spiv | So fundamentally, I think the mismatch is read_records_iter is returning a fulltext, where _get_components_positions says it should be a line-delta | 01:44 |
| poolie | ok, so calling remote_vf.get_data_stream gives back a gzipped record that does have delta markers within it | 01:45 |
| spiv | The interesting thing is that read_records_iter is recursing: the top-level one has a _StreamAccess, which calling get_raw_records on causes an underlying _KnitData.read_records_iter to be called. | 01:46 |
| poolie | but at some later point they seem to be lost | 01:46 |
| poolie | one change in this since 1.3 is that we try to share structure among copies of the text | 01:46 |
| poolie | to avoid constructing new ones | 01:46 |
| lifeless | 'oops' | 01:46 |
| poolie | i can't really see how it would happen, but maybe this is causing something that should have line deltas to have them edited out | 01:46 |
| spiv | The bottom-most read_records_iter does give back a line-delta record, but by the time it goes through the intervening layers it's a fulltext. So I'm suspecting _get_components_positions isn't taking that into account? | 01:46 |
| beuno | jelmer, sent the patch | 01:47 |
| poolie | i think it's somewhere there too | 01:51 |
| schierbeck | jelmer: i've sent in a new iteration of the gannotate fix | 01:54 |
| poolie | spiv: well, at some point it must be actually getting transformed into a fulltext | 01:56 |
| poolie | oh | 01:57 |
| poolie | here's an idea | 01:57 |
| poolie | i have been assuming it's being passed back as the fulltext of that version | 01:57 |
| poolie | but we haven't checked that's true | 01:57 |
| poolie | or i haven't | 01:57 |
| poolie | anyhow | 01:57 |
| spiv | Hmm! | 01:59 |
| spiv | I think I have a fix. | 01:59 |
| spiv | I'm not sure it's the right fix... | 01:59 |
| spiv | poolie: lifeless: http://rafb.net/p/FvWu4u73.html | 02:01 |
| poolie | i had been wondering about get_build_details | 02:02 |
| poolie | (why won't irssi do tab-completion on symbols? :) | 02:02 |
| spiv | Hmm, I think I maybe got the comment backwards. | 02:03 |
| poolie | what is index_memo[0] in this case? | 02:04 |
| spiv | 'thunk_flag' | 02:04 |
| spiv | poolie: see the docstring on _StreamIndex.get_position | 02:04 |
| poolie | in what sense is it thunking? | 02:05 |
| spiv | Basically, if that's set, then _StreamAccess.get_raw_records will unconditionally return a fulltext. | 02:05 |
| lifeless | spiv: IIRC getting the stack is kindof slow ? | 02:06 |
| spiv | lifeless: yeah | 02:06 |
| poolie | maybe we can rename it? | 02:07 |
| spiv | _StreamAccess.get_raw_records has a comment in the implementation that sort of explains the thunking. | 02:07 |
| lifeless | spiv: for debugging, it would be nice to give the call frame for the lock acquisition that hasn't been released. | 02:07 |
| abentley | lifeless: Is http://people.ubuntu.com/%7Erobertc/baz2.0/shallow-branch/ revno 3247 the most recent version? | 02:08 |
| spiv | lifeless: yeah, that would be nice | 02:08 |
| lifeless | abentley: probably | 02:08 |
| lifeless | spiv: but we do lots of locking | 02:08 |
| lifeless | spiv: so the test suite would likely be visibly slower. any thoughts? | 02:08 |
| spiv | Yeah. | 02:08 |
| spiv | Debug flag, I think :( | 02:08 |
| spiv | I don't think we want this on all the time. | 02:09 |
| poolie | because of holding the call stacks? | 02:09 |
| lifeless | spiv: planning a debug flag already | 02:09 |
| lifeless | thanks | 02:09 |
| spiv | Happily, with my -Dselftest_debug flag, you can set debug flags that won't be cleared by the test suite... | 02:09 |
| poolie | lifeless: why slower? | 02:09 |
| spiv | So that's probably good enough. | 02:09 |
| abentley | lifeless: I have done some prototyping of the remote stacking default discussed in my email here: http://code.aaronbentley.com/bzr/bzrrepo/stacking-policy2/stacking-policy | 02:10 |
| spiv | poolie: just acquiring the current stack trace is relatively slow. | 02:10 |
| lifeless | spiv: how does that work ? | 02:10 |
| spiv | lifeless: if -Dselftest_debug is set, then the "clear the debug flags" part of the test setup is disabled. | 02:11 |
| spiv | lifeless: so I can do e.g. -Dselftest_debug -Dhpss and get nice hpss debug logs in test failures. | 02:11 |
| spiv | I strongly suspect it will confuse any tests for debug.debug_flags itself, but as a tool for debugging individual tests rather than the whole suite, it's helpful. | 02:12 |
| spiv | (plus turning on debug flags that emit log output might confuse tests that are particular about the log output they expect) | 02:13 |
| spiv | Well, tests pass with my patch. | 02:14 |
| poolie | lifeless: of course the lock statement that is not cleaned up may not be the one that actually acquired the lock in the first place | 02:14 |
| spiv | lifeless: any comments on my candidate fix? | 02:14 |
| poolie | so perhaps you should leave this for now | 02:14 |
| poolie | wow | 02:15 |
| poolie | that is a bit messy | 02:15 |
| lifeless | poolie: huh? | 02:16 |
| poolie | spiv: http://rafb.net/p/n0SGoV75.html | 02:16 |
| lifeless | poolie: knowing who physically aquired the lock should be enough to debug things | 02:16 |
| poolie | i think that should be 'if from_backing_knit' | 02:16 |
| lifeless | poolie: I am leaning towards leaving the warnings in place | 02:16 |
| poolie | lifeless: surely in a test the filename of the lock will make it fairly easy to tell? | 02:16 |
| spiv | poolie: yeah, that would be clearer. I don't recall why it tests that rather than the thunk_flag. | 02:17 |
| lifeless | poolie: smart server threads? | 02:17 |
| poolie | otoh, for the gc warning, then knowing the allocating stack _will_ make it far more useful | 02:17 |
| poolie | since right now the gc message is pretty hard to match up to a bug | 02:17 |
| poolie | otoh if it's slow you would not want it on by default | 02:17 |
| lifeless | right | 02:17 |
| lifeless | how about I finish the code :P | 02:18 |
| poolie | spiv: how about http://rafb.net/p/dte0qf23.html | 02:20 |
| poolie | i'm a big fan of making the bug obvious before you fix it | 02:20 |
| spiv | poolie: +1 | 02:20 |
| poolie | (not actually tested, just in addition to your change) | 02:21 |
| spiv | It looks correct to my eyes. | 02:21 |
| spiv | I'm fairly sure this is the bug. | 02:21 |
| poolie | yes it looks right to me to | 02:21 |
| poolie | too | 02:21 |
| spiv | I'm not sure why 1.2 didn't have this bug, I guess get_build_details has changed since then. | 02:21 |
| poolie | um, i wonder if the code at the bottom of get_raw_records, circa l2270 is right | 02:21 |
| === mw is now known as mw|out | ||
| poolie | what is it doing with orig_options? | 02:22 |
| poolie | and why? :) | 02:22 |
| spiv | It's making sure orig_options has the right value ;) | 02:23 |
| spiv | And then ignoring it :) | 02:23 |
| poolie | can it do anything more useful? | 02:23 |
| poolie | i think not because it's the higher level index that says what the options will be, in here we can't really check it | 02:24 |
| spiv | Yeah, I think so too. | 02:24 |
| poolie | i actually think the orig options are none of our business.. | 02:25 |
| spiv | This method smells a bit. I guess it's meant to be somewhat temporary. | 02:25 |
| poolie | if the backing_knit returned a text that's good enough? | 02:25 |
| spiv | Yeah, I think so. | 02:25 |
| poolie | lifeless: this is your code i think | 02:26 |
| poolie | the handling just above that of final newline looks suspicious to me too | 02:27 |
| poolie | shouldn't that be handled inside get_lines? | 02:27 |
| lifeless | poolie: sorry, I'm not tracking the conversation | 02:29 |
| lifeless | whats up? | 02:29 |
| poolie | do you have a sec? | 02:29 |
| poolie | wondering about the handling of orig_options in about line 2270 | 02:29 |
| poolie | and the addition of a final newline above that | 02:30 |
| lifeless | which file, what source code tree | 02:30 |
| lifeless | I mean, what branch | 02:30 |
| poolie | knit.py 1.3 | 02:30 |
| poolie | probably unchanged in trunk | 02:30 |
| lifeless | let me branch 1.3 | 02:30 |
| poolie | if that's easier | 02:30 |
| lifeless | I've spent the last three weeks changing this in trunk | 02:31 |
| lifeless | :P | 02:31 |
| spiv | poolie: I'm going to break for lunch now | 02:31 |
| poolie | :) | 02:31 |
| lifeless | if its anything to do with StreamAccess, andrew wrote the code | 02:31 |
| poolie | http://rafb.net/p/GRinMk31.html <--- 2nd hunk of this | 02:32 |
| lifeless | and john did some large scale restructuring | 02:32 |
| poolie | ok, so | 02:32 |
| poolie | do you think that patch is reasonable? | 02:32 |
| lifeless | hmm from_back_knit seems wastage | 02:33 |
| lifeless | that should have just replaced the index object with a index that represents the backing object | 02:33 |
| lifeless | anyhow | 02:33 |
| lifeless | poolie: you're commenting out some adaption logic ? | 02:34 |
| * spiv is not quite at lunch yet... | 02:34 | |
| lifeless | index_memo has to stay opaque please | 02:34 |
| poolie | yes, i think it's dead code but it's attributed to you | 02:34 |
| lifeless | don't call it a tuple of things, or ti stops being opaque | 02:34 |
| poolie | within this class it has that form | 02:35 |
| poolie | will add a note to that effect | 02:35 |
| lifeless | yes, but the docstring is for the public interface | 02:35 |
| lifeless | an Index and an Access class are paired | 02:35 |
| poolie | sure | 02:36 |
| poolie | so, why does that code add a newline? | 02:36 |
| spiv | I dimly recall there being some deficiency in the get_lines interface that made that necessary. | 02:37 |
| spiv | Something to do with the noeol flag, maybe? | 02:38 |
| poolie | sure | 02:38 |
| poolie | but it seems to me that, hm, that should be handled by the backing knit | 02:38 |
| lifeless | so I think its attributed to me because of a move | 02:39 |
| kgoetz | is anyone aware of a bzr script/tool that opens up a diff in one pane (of emacs/vim) and your log edit window in the other when doin a commit? | 02:39 |
| lifeless | kgoetz: well, 'bzr commit --show-diff' will give you the diff in the editor | 02:40 |
| lifeless | you could split the pane | 02:40 |
| spiv | Hmm, I definitely need some food. | 02:41 |
| * spiv -> really lunch | 02:41 | |
| poolie | lifeless: ok i will kill it and see if it still passes | 02:41 |
| lifeless | poolie: final eol issues | 02:41 |
| kgoetz | lifeless: thanks, i'll try it out | 02:41 |
| poolie | we should really work out how to test for it | 02:41 |
| lifeless | poolie: so, the low level storage does not have enough info to reconstruct a full text correctly, ever, without the index metadata | 02:42 |
| poolie | right :/ | 02:42 |
| kgoetz | wow. ancient bzr doesnt have the switch :| *goes to find a newer version* | 02:43 |
| lifeless | kgoetz: improvements come over time; news at 11 :) | 02:43 |
| jml | lifeless: how do I uncombine threads? | 02:43 |
| kgoetz | lifeless: hehe :) | 02:44 |
| lifeless | jml: make a new thread, set appropriate last revisions | 02:44 |
| poolie | lifeless: oh i remember: the problem with the gc warnings and tests (or one additional problem) is that now we just use short random nomes for the test directories it is very unclear even which test caused the problem | 02:47 |
| kgoetz | are backports build of bzr for feisty? | 02:48 |
| poolie | yes, in the ppa | 02:48 |
| kgoetz | thanks, i'll keep looking. :) | 02:49 |
| poolie | launchpad.net/~bzr/+archive i think | 02:49 |
| poolie | is it not? | 02:49 |
| poolie | lifeless: so anyhow regarding EOLs | 02:49 |
| poolie | shouldn't self.backing_knit.get_lines(version_id) | 02:49 |
| poolie | return lines that either have an eol or not as appropriate? | 02:49 |
| lifeless | poolie: interestingly; LockDir does not clear the nonce when it unlocks | 02:50 |
| lifeless | poolie: backing_knit.get_lines() should yes | 02:51 |
| lifeless | poolie: but if we're returning whats meant to look like a serialised record | 02:51 |
| lifeless | poolie: then it has to have a trailing newline regardless | 02:51 |
| lifeless | poolie: frankly, I think you're altering the wrong bit in this patch | 02:51 |
| lifeless | because its returning valid texts, with a single incorrect bit set AFAICT | 02:52 |
| poolie | that's the point of + if index_memo[0]: | 02:53 |
| poolie | + # texts retrieved from the backing knit are always full texts | 02:53 |
| poolie | + method = 'fulltext' | 02:53 |
| lifeless | except somehow we're returning line-delta for one of those | 02:54 |
| poolie | right | 02:55 |
| poolie | andrew's reasoning aiui is this | 02:55 |
| poolie | whenever we get something from the backing knit | 02:55 |
| poolie | we always get a full text | 02:55 |
| poolie | therefore our index should always say that it will be returned as a full text | 02:56 |
| poolie | the separate issue i'm concerned with is whether it correctly passes through the noeol flag on lines retrieved from the backing knit | 02:57 |
| lifeless | well, if the eol flag is wrong the md5 sum check will error | 02:58 |
| lifeless | the noeol *flag* must be preserved unaltered | 02:58 |
| lifeless | the last line of the lines returned must always end in \n except for an empty content | 02:59 |
| lifeless | because thats the serialised form | 02:59 |
| poolie | ok | 03:00 |
| poolie | so, we add this so that the serialized form is correct | 03:00 |
| poolie | and the noeol option will be seen because the _StreamIndex.get_options passes through the option from the backing file | 03:00 |
| poolie | i might get lunch too and wait for andrew | 03:01 |
| poolie | biab | 03:01 |
| lifeless | right | 03:05 |
| lifeless | thats how I read the code | 03:05 |
| beuno | jelmer, I forgot to update news. Should I send a bundle to the list or just merge? | 03:18 |
| lifeless | poolie: did you land the warning disabling patch ? | 03:26 |
| jelmer | beuno: just merging is fine I think | 03:27 |
| poolie | lifeless: i don't think so; at any rate i did not send it today | 03:31 |
| poolie | spiv: back? | 03:31 |
| beuno | jelmer, done. Ping me if you need anything else on my end to get 0.94 out the door | 03:35 |
| poolie | lifeless: can i bother you about this some more, or at least yammer in your direction | 03:38 |
| lifeless | sure | 03:38 |
| poolie | so get_raw_records to get it from thebacking knit | 03:38 |
| lifeless | do you want voice? | 03:38 |
| poolie | is getting the lines, joining them, then converting that to a data blcok | 03:39 |
| poolie | hm | 03:39 |
| poolie | it seems like this is sometimes double handling but i guess making it faster is not the point here, just making it work | 03:41 |
| poolie | for this bug | 03:41 |
| poolie | oh i see | 03:41 |
| poolie | nm | 03:41 |
| kgoetz | lifeless: thanks for your tip earlier. its exatly what i'm after. | 03:42 |
| poolie | spiv, lifeless: so it seems to me that _StreamIndex.get_options is also wrong: | 03:46 |
| poolie | if we're going to return a record from the backing knit, i.e. by generating a fulltext record, then we must change the options to indicate that it will be a fulltext record - agree? | 03:47 |
| moquist | I'm new to bzr, and I would like to use it to help me manage my .bash* and .vim* files on several systems. I can't figure out how to pull/checkout/branch without getting my bzr-ed dotfiles in a subdirectory of my home directory. "bzr: ERROR: Target directory "./" already exists" is a message I'm not sure how to avoid. | 03:54 |
| poolie | moquist: i think you, on the destination machine | 03:55 |
| poolie | | cd ~ | 03:55 |
| poolie | | bzr init | 03:55 |
| poolie | | bzr pull --remember URL | 03:55 |
| poolie | welcome to bzr btw | 03:55 |
| moquist | poolie: hi. We spoke in an elevator at UDS-Montreal about you teaching me bzr someday. :) | 03:56 |
| * mneptok waves from said city | 03:56 | |
| moquist | poolie: and thx. | 03:56 |
| * moquist tries it out | 03:56 | |
| mneptok | moquist: personally, i would create ~/scratchdir and put your content in there. init bzr there. practice, get comfy, then init in your ~/ for actual usage. | 03:57 |
| poolie | oh, right | 03:57 |
| poolie | hi matt | 03:57 |
| poolie | ^^ wise man :) | 03:57 |
| mneptok | moquist: but then, i'm shy on first dates ;) | 03:57 |
| poolie | so actually, i keep my dotfiles in .bzrconfig and symlink them into my homedir | 03:57 |
| * mneptok swoons | 03:57 | |
| poolie | i'm not sure it's really needed | 03:57 |
| mneptok | *that's* the kinda talk i like, poolie :) | 03:57 |
| poolie | on the second date he brings his toybox though | 03:58 |
| poolie | or so i hear | 03:58 |
| moquist | mneptok: Well, I just learned today how to use bzr for managing source for a real project, and I'm more-or-less comfortable with merges, conflict resolution, etc. But I'm happy to work on a project in a subdir, so this was a confusion I didn't have to figure out for that. :) | 03:58 |
| lifeless | poolie: that sounds plausible | 03:59 |
| poolie | about mneptok, yeah | 03:59 |
| mneptok | moquist: just a suggestion. i've been burned so many times i always play it safe. you know your needs and abilities far better than do i. do what suits your comfort level and needs. :) | 03:59 |
| poolie | or my patch? | 03:59 |
| lifeless | heh; what time did you start this morning :P | 04:00 |
| lifeless | both I guess | 04:00 |
| moquist | mneptok: Oh, I appreciate the advice, and I'm thinking about it. And I'm thinking through my backups, and whether or not they're current, etc. ;) | 04:00 |
| mneptok | poolie: only you get the toybox, big fella :) | 04:00 |
| poolie | about 9 when steve called and said mdz was bitten by this bug | 04:00 |
| poolie | but i started early and finished late | 04:01 |
| poolie | yesterday | 04:01 |
| poolie | so will have an early friday and take you up on that virtual ale | 04:01 |
| mneptok | do bugs in bzr reflect the Ausiie nature of most of the dev team? like, are the bugs highly toxic, venomous, and capable of supersonic flight? | 04:01 |
| === Verterok is now known as guillo | ||
| poolie | heh | 04:02 |
| poolie | did you read the crocodile hunter's company is being charged with tax evasion? | 04:02 |
| mneptok | *that's* goota sting, Ray. | 04:02 |
| mneptok | *gotta | 04:02 |
| poolie | we should rename KnitCorrupt, it usually means "your data is fine but we have a bug..." | 04:03 |
| === guillo is now known as Verterok | ||
| mneptok | maybe they'll change the daughter's name to Bindy Suit | 04:03 |
| AfC | Gah. I wish I could supress the whole branch nickname thing. | 04:04 |
| === beuno is now known as beuno_ | ||
| AfC | It always ends up being about three branches out of date after we've switched a few times. | 04:05 |
| === beuno_ is now known as beuno | ||
| lifeless | it doesn't change when you switch ? | 04:05 |
| poolie | it may be a tree nickname instead? which would be a bug | 04:06 |
| lifeless | don't think trees have nicks | 04:06 |
| poolie | just a guess, if it is not working properly with switch | 04:06 |
| poolie | but i think i remember seeing it really in the branch | 04:07 |
| jml | mneptok: the Bazaar User Guide recommends shaking out your boots before using bzr.dev. | 04:08 |
| jml | just in case. | 04:08 |
| poolie | lol | 04:09 |
| spiv | poolie: yes, back. | 04:09 |
| AfC | lifeless: no. I can't say that I blame anyone for what I thought, but I did sorta think it would switch to the last component of the branch URL I was switching to. [This is with bzr 1.3] | 04:09 |
| AfC | jml: :) | 04:09 |
| mneptok | jml: and all this time i thought that was to make sure lifeless wasn't hiding in there, optimizing your lacing routines | 04:10 |
| mwhudson | but lifeless is from kiwi-land -- surely his software should spew lava and pyroclastic flows all over everything? | 04:10 |
| poolie | spiv: see my scrollback about get_options? | 04:11 |
| mneptok | mwhudson: you should see the haka it makes when it segfaults | 04:11 |
| spiv | poolie: catching up atm | 04:11 |
| poolie | this is my current overall diff | 04:11 |
| poolie | we should think about writing a test for this | 04:12 |
| spiv | poolie: what you say about get_options makes sense to me. | 04:15 |
| rockstar_ | I'm trying to use svn2bzr.py, and I'm getting an error on from bzrlib.clone import copy_branch because there's no module named clone | 04:18 |
| poolie | rockstar_: i would guess the version of svn2bzr is too old for your bzrlib or vice versa | 04:19 |
| rockstar_ | poolie, I pulled the svn2bzr from lp, and I've got bzr 1.1.0.candidate.1 installed | 04:21 |
| poolie | i meant to say, this is my current diff: http://rafb.net/p/bonbwZ20.html | 04:21 |
| rockstar_ | Is there a branch outside the lp 'main' branch I should be pulling from? | 04:22 |
| lifeless | you should only use the main branch there if you want a development version | 04:24 |
| lifeless | and its development versions work with bzr's development versions | 04:24 |
| poolie | i think we removed bzrlib.clone some time ago, do you recall? | 04:24 |
| rockstar_ | Well, I couldn't find a released version of the script. | 04:25 |
| rockstar_ | At least, not on the lp site | 04:25 |
| poolie | rockstar_: the site says "svn2bzr is a tool to convert Subversion repositories into Bazaar 2.0 repositories. It does not currently have an active maintainer. You might be interested in bzr-svn instead." | 04:26 |
| poolie | bzr-svn does seem to be what most people use | 04:26 |
| rockstar_ | That appeared like a bridge between a working svn and a working bzr branch though. | 04:27 |
| poolie | yes, it is | 04:27 |
| poolie | you don't have a working svn server (anymore)? | 04:27 |
| rockstar_ | Well, I do, but I don't want to use it. Just want to convert the entire repo from svn to bzr and move forward on bzr | 04:28 |
| poolie | ok | 04:29 |
| poolie | so svn2bzr may need a small update for the new api | 04:29 |
| poolie | can i suggest you please file a bug at https://bugs.edge.launchpad.net/svn2bzr/trunk/ | 04:29 |
| poolie | with the full traceback | 04:29 |
| poolie | um | 04:29 |
| poolie | you may have more success if you use an older version of bzr corresponding to that svn2bzr release | 04:30 |
| spiv | poolie: s/memors/memos/. I agree with lifeless earlier comment that get_build_details docstring shouldn't say more than "opaque structure". | 04:30 |
| rockstar_ | poolie, where's the current svn2bzr trunk? I'd like to take a whack at fixing the bug. | 04:30 |
| poolie | then (if necessary) upgrade | 04:30 |
| poolie | great! | 04:30 |
| poolie | spiv: agree too, was just changing that | 04:30 |
| === BasicMac is now known as BasicOSX | ||
| spiv | poolie: I'm not certain if the change to get_method is 100% safe -- shouldn't it raise an error if the backing knit doesn't have that version? | 04:30 |
| spiv | (I can imagine it not mattering in practice, but we should be conservative with changes we're backporting) | 04:31 |
| poolie | spiv: good point, maybe i should change it to call my get_options and use that? | 04:31 |
| spiv | Yeah, that sounds like a good idea. | 04:31 |
| spiv | Otherwise, that patch looks good to me. | 04:32 |
| poolie | rockstar_: https://code.edge.launchpad.net/~niemeyer/svn2bzr/trunk | 04:32 |
| spiv | We just have to figure out what test(s) to write... | 04:32 |
| lifeless | yay | 04:34 |
| lifeless | ERROR: test_lockdir.TestLockDir.test_20_lock_peek | 04:34 |
| lifeless | Different number of acquired and released locks. ([<bzrlib.lock.LockResult object at 0x311ee10>], []) | 04:34 |
| lifeless | if I may | 04:36 |
| lifeless | I'd rather you guys didn't make too many changes here; just the minimum to fix the bug | 04:36 |
| lifeless | I'm in the business of overhauling this entire structure anwyay | 04:36 |
| lifeless | but I'd be happy to take a list of 'we think X should be done' and I'll fold that into my loom | 04:39 |
| poolie | well | 04:44 |
| poolie | i'll try to keep it focussed but i think a strictly minimal one line fix leaves trouble in the code- | 04:44 |
| lifeless | and indeed | 04:46 |
| lifeless | test_20_lock_peek was leaving a physical lock in place | 04:46 |
| poolie | yay | 04:46 |
| lifeless | so a couple of commits and I'll send in this loom for review | 04:47 |
| lifeless | it may not be perfect; but its a good step I feel | 04:47 |
| poolie | great | 04:47 |
| poolie | so you are going to actually fix them? | 04:47 |
| poolie | or some of them? | 04:47 |
| poolie | spiv: so http://rafb.net/p/hPuGm457.html is my final patch, i think | 04:48 |
| poolie | with your fix for get_method and better commentsn | 04:48 |
| poolie | needs tests still obivously | 04:48 |
| spiv | poolie: still has the "memors" typo in a docstring | 04:48 |
| poolie | hopefully there are already some for the stream classes | 04:48 |
| poolie | thanks | 04:48 |
| spiv | and slightly odd wrapping in the same docstring | 04:48 |
| lifeless | poolie: no, I shall leave that for lesser beings | 04:50 |
| spiv | poolie: I think that patch looks good. | 04:50 |
| lifeless | it will now print out: | 04:50 |
| lifeless | Broken test test_20_lock_peek (bzrlib.tests.test_lockdir.TestLockDir): Different number of acquired and released locks. ([<bzrlib.lock.LockResult object at 0x33f9d10>], []) | 04:50 |
| lifeless | on left behind physical locks | 04:50 |
| lifeless | I think this is a significant improvement even if not 100% accurate. | 04:51 |
| lifeless | it may not be 100% congruent with the current stipple | 04:51 |
| lifeless | because I think its lockable files or something that does the current warnings | 04:51 |
| poolie | if we had selftest --strict it would be nice for it to trap these | 04:53 |
| poolie | like for tests to say "actually i kinda failed but i'll live" | 04:53 |
| spiv | selftest --test-harder? ;) | 04:53 |
| poolie | elite mode | 04:54 |
| poolie | the developer guide does i think say we want --strict | 04:54 |
| poolie | --fierce :) | 04:54 |
| lifeless | hmm | 04:55 |
| lifeless | what I've *done* is have -Dlock trap them | 04:55 |
| lifeless | and in future -Dlock should also get full backtraces of the acquirer | 04:55 |
| lifeless | anyhow, its a sonnet in two parts; reviews FTW | 04:56 |
| spiv | So, to test this fix... we can either try poking at KnitVersionedFile.insert_data_stream directly, or write a higher-level test that pack->knit pulling via streams works. | 04:56 |
| spiv | The key properties seem to be that the knit needs a line-delta record, and the format of the stream needs to be incompatible with the knit versioned file, triggering this code path. | 04:58 |
| rockstar_ | poolie, it looks like the error I'm getting in svn2bzr.py has to do with the dump file I'm using. It's trying to split on a line that throws a ValueError | 04:58 |
| rockstar_ | 'Node-path: ' can't split on ': ' It's not catching an empty value | 05:00 |
| poolie | rockstar_: i thought you were getting an import error? | 05:03 |
| poolie | spiv: ok, are there any tests for such pulling already? | 05:03 |
| lifeless | rockstar_: bzr-svn has an import mode | 05:03 |
| lifeless | rockstar_: I think you will likely have better results with it | 05:03 |
| rockstar_ | lifeless, yea, that was suggested too. I just figured I could fix a bug while I was in here. | 05:05 |
| spiv | poolie: test_knit.BasicKnitTests has some test_insert_data_stream* methods. | 05:05 |
| lifeless | rockstar_: up to you :P. | 05:06 |
| spiv | poolie: I don't know of any similar tests at a higher level. | 05:07 |
| lifeless | this is strange | 05:07 |
| lifeless | :!bzr annotate bzrlib/knit.py | 05:07 |
| lifeless | bzr: ERROR: exceptions.TypeError: sequence item 0: expected string, tuple found | 05:07 |
| lifeless | :/ | 05:07 |
| poolie | i meant an error from an import statement | 05:07 |
| poolie | above | 05:07 |
| poolie | just going to branch and commit what i have | 05:08 |
| poolie | i find this creation of new singleton classes for each group of locks a bit gross | 05:09 |
| lifeless | singletons ? | 05:10 |
| poolie | +hooks = PhysicalLockHooks() | 05:10 |
| lifeless | oh group of hooks ? | 05:10 |
| poolie | yes | 05:10 |
| lifeless | well, its less text than putting staticmethod decorators on everything | 05:10 |
| poolie | why not just have them all on Hooks()? | 05:11 |
| lifeless | I actually like it, its very convenient, useful for testing and creating isolated state | 05:11 |
| lifeless | namespaces are good, we should do more of them | 05:11 |
| lifeless | but look, if you want to collapse them all into one, create a patch. *I* think it will be ugly, less modular, harder to extend and reuse. | 05:12 |
| poolie | hm | 05:12 |
| poolie | ok | 05:12 |
| poolie | i think the problem is they are fragmented namespaces | 05:12 |
| poolie | afaik there is no way to find out about all the hooks that are active in bzrlib | 05:13 |
| poolie | sight | 05:13 |
| fullermd | So, is it known that bzr.dev eats itself in some cases talking to bzr://, while 1.3 works peachy? | 05:13 |
| lifeless | re: introspection - you are correct that there isn't a single call you can make to find out about all the hooks | 05:14 |
| poolie | to the same version? | 05:14 |
| fullermd | File "/home/fullermd/src/bzr/bzr.dev/bzrlib/remote.py", line 883, in _get_parent_map | 05:14 |
| fullermd | assert type(key) is str | 05:14 |
| fullermd | AssertionError | 05:14 |
| poolie | having a namespace like "lock.acquired" is of course fine | 05:14 |
| fullermd | Same with bzr.dev and 1.3 acting as the server. 'bzr log bzr://localhost/...' works with the 1.3 client, and dies with a trace ending as above with bzr.dev. | 05:14 |
| spiv | fullermd: that one is new to me | 05:15 |
| lifeless | thats a line I added | 05:15 |
| lifeless | to ensure correct api usage with a changed api | 05:15 |
| lifeless | well, to catch incorrect api usage | 05:15 |
| lifeless | fullermd: can you file a bug with how to reproduce? | 05:15 |
| poolie | lifeless: the other specific thing that bothers me is that reset_hooks() needs to know what specific class to create a new instance of | 05:16 |
| lifeless | fullermd: assign to me, I'll fix on monday or before | 05:16 |
| poolie | it's not very unreasonable for a test to do so | 05:16 |
| poolie | it just seems odd | 05:16 |
| lifeless | I don't see that a single class changes that | 05:17 |
| lifeless | it will still know the class to create :P | 05:17 |
| lifeless | did you watch the paradox of choice? | 05:17 |
| poolie | no, there was a critical bug, you might have noticed :P | 05:17 |
| poolie | may do it when this was done | 05:17 |
| poolie | more generally, | 05:19 |
| poolie | if you have an object api, where the general api is that you're meant to operate on the object rather than rebinding the variable | 05:19 |
| poolie | then needing to do so for this case seems unclean | 05:20 |
| lifeless | how so - the object is the saved state | 05:20 |
| fullermd | lifeless: bug 211661, filed and assigned | 05:20 |
| ubotu | Launchpad bug 211661 in bzr "bzr.dev smart client fails on log" [Undecided,Triaged] https://launchpad.net/bugs/211661 | 05:20 |
| lifeless | think of it as a register window rather than stack frame | 05:21 |
| lifeless | rather than copying everything to the stack frame, we just move the window | 05:21 |
| lifeless | and its all there waiting for us when we return | 05:21 |
| poolie | so the problem is: there's no standard way to save a group of hooks, clear them, and restore it | 05:24 |
| poolie | there is almost a standard pattern, but it requires creating a new class for each one | 05:25 |
| poolie | instance of a different class rather | 05:25 |
| poolie | but it's ok, it's consistent with what we have | 05:25 |
| poolie | can be cleaned up later | 05:25 |
| lifeless | so if I wanted to do it generically, I think I would do saved_hooks = hooks; hooks = hooks.__class__() | 05:26 |
| poolie | right | 05:26 |
| lifeless | I think that it is fine to mandate a parameterless constructor | 05:26 |
| poolie | or you could have in the base class, hooks.make_empty() | 05:26 |
| lifeless | I don't know that that would be cleaner | 05:27 |
| poolie | maybe not | 05:27 |
| lifeless | I want 'bzr p ull' to work. that is all. | 05:29 |
| poolie | if we hooked into zsh correction sufficiently well it might | 05:30 |
| poolie | though i don't know if it ever suggests joining words like that | 05:30 |
| lifeless | bash <- | 05:30 |
| lifeless | spiv: http://bundlebuggy.aaronbentley.com/request/<20080228144229.GF3192@steerpike.home.puzzling.org> <- has that landed? | 05:31 |
| ubotu | New bug: #211661 in bzr "bzr.dev smart client fails on log" [Undecided,Triaged] https://launchpad.net/bugs/211661 | 05:31 |
| spiv | lifeless: IIRC yes, let me check | 05:32 |
| lifeless | bb thinks it hath not | 05:32 |
| spiv | Huh, interesting. | 05:33 |
| spiv | Some of it has :) | 05:33 |
| lifeless | poolie: btw, you said I had broken ReST in my plugin api patch, but rest doesn't think so. Why did you think I did? | 05:34 |
| poolie | i don't remember, where was the patch? | 05:36 |
| lifeless | http://bundlebuggy.aaronbentley.com/request/<1204283630.28682.40.camel@lifeless-64> | 05:36 |
| lifeless | btw, the status heading I intend to keep because its consistent with other documents | 05:36 |
| abentley | poolie: I've solved that merge bug. | 05:38 |
| poolie | way to go | 05:38 |
| poolie | spiv: my patch is in https://code.edge.launchpad.net/~mbp/bzr/208418-knit-parsing (not mirrored yet) | 05:38 |
| spiv | poolie: thanks! | 05:38 |
| poolie | abentley: I got a bb 500 error, just so you know | 05:40 |
| poolie | will try again... | 05:40 |
| abentley | Please do. | 05:40 |
| poolie | it was "database is locked" | 05:41 |
| poolie | lifeless: i thought there were column separators missing from your table | 05:42 |
| poolie | you're welcome to keep a heading called "Status", I just want you to put some actual status information under it | 05:43 |
| poolie | like adding "this api is implemented in 1.2 and is stable" | 05:43 |
| abentley | poolie: Well, that one might have been due to all the mail going through it. | 05:44 |
| abentley | At least, it's working, and I don't have any mail from the nanny-script. | 05:44 |
| poolie | ok | 05:44 |
| poolie | is it just that only one process can use sqlite at a time? | 05:44 |
| abentley | Many can read, only one can write. | 05:45 |
| abentley | Viewing the home page writes to some caches. | 05:46 |
| abentley | (line number count, for example) | 05:46 |
| poolie | right | 05:46 |
| poolie | so switching to pgsql should help this | 05:46 |
| abentley | Finer-grained locking? | 05:47 |
| poolie | iirc it should allow multiple fronts to (apparently) write at once | 05:47 |
| abentley | lifeless: hbb? | 05:48 |
| lifeless | hypothetical bundle buggy | 05:50 |
| lifeless | k, thats 8 hours | 05:52 |
| lifeless | to keep robert sane, work shall cease | 05:52 |
| bob2 | ETOOLATE | 05:54 |
| abentley | bob2: lol | 05:55 |
| abentley | poolie: Could you do that "Bzr Developers" stuff? | 05:57 |
| poolie | oops, wrong channel | 05:58 |
| poolie | 15:51 <poolie> spiv, so you're working on tests? | 05:58 |
| poolie | 15:52 <poolie> spiv, lifeless: I'm wondering about starting to make a new release | 05:58 |
| poolie | 1.3.1 with just that change, before the tests are done | 05:58 |
| poolie | 15:52 <poolie> with a view to getting it out at a reasonable time today | 05:58 |
| poolie | abentley: what stuff? | 05:59 |
| abentley | I created a team called "Bzr Developers" so that it can own bzr, and I can join it instead of Bazaar Developers. | 05:59 |
| abentley | That way, I don't get mail about subprojects I'm not interested in. | 05:59 |
| poolie | ok | 06:00 |
| abentley | I made you the owner of Bzr Developers after I'd set up the profile. | 06:00 |
| spiv | poolie: I am | 06:00 |
| poolie | do you think i shouldmerge this now? | 06:01 |
| poolie | and release it? | 06:01 |
| poolie | i guess i could at least call it 1.3.1rc1 | 06:01 |
| poolie | abentley: but isn't that what ~bzr is for? | 06:02 |
| abentley | ~bzr is Bazaar Developers. | 06:03 |
| poolie | i see | 06:03 |
| poolie | a bit poorly named then | 06:03 |
| poolie | Launchpad loves creating teams | 06:03 |
| abentley | Yeah, it's a bit ugly at times. | 06:04 |
| abentley | I don't know how else to handle scads of people, though. | 06:04 |
| jamesh | poolie: would it really be any better if we called them ACLs? | 06:05 |
| poolie | :) | 06:05 |
| poolie | indeed | 06:05 |
| poolie | well, it would have two differences | 06:09 |
| poolie | one is that they would not then have such visible names | 06:09 |
| poolie | that might make it more confusing to be dealing with these anonymous objects | 06:09 |
| poolie | certainly harder to give the same acl to different objects | 06:09 |
| poolie | but otoh it would not cause lasting problems when people use the name ~bzr for what should actually be ~bazaar-devs | 06:10 |
| poolie | secondly, it would raise the question of whether we want different ACEs | 06:10 |
| jamesh | poolie: I think providing a project-level namespace for branch aliases that is controlled by the project owner might be the answer here | 06:10 |
| poolie | like read/write/control access, or negative ACEs | 06:11 |
| poolie | ! | 06:11 |
| jamesh | effectively an extension of the current lp:$PROJECT names | 06:11 |
| poolie | well i agree with you, but i was talking more generally than just that | 06:11 |
| spiv | poolie: I don't see any harm in making a 1.3.1rc1 out of what you already have | 06:13 |
| abentley | poolie: Could you also make ~/bzr-developers the owner of /bzr please? | 06:14 |
| spiv | poolie: if the only difference between the rc and final is adding some tests, then I think that's fine. | 06:14 |
| poolie | ar | 06:16 |
| poolie | yes | 06:16 |
| poolie | getting tired | 06:16 |
| poolie | jamesh: that might do | 06:17 |
| poolie | wouldn't those important branches normally be series? | 06:17 |
| poolie | maybe not, they might be important feature branches | 06:17 |
| poolie | so should that right be restricted to project admins? | 06:17 |
| poolie | oh, owners | 06:18 |
| jamesh | poolie: would the old bzr.hpss branch have been a series? | 06:18 |
| poolie | so typically a team | 06:18 |
| jamesh | or would you consider it not special enough to put in the project namespace? | 06:18 |
| poolie | jamesh: 1s | 06:19 |
| poolie | abentley: uh how do i do that? | 06:19 |
| poolie | oh | 06:19 |
| poolie | 'change maintainer' | 06:19 |
| poolie | there are too many similar names: owner/maintainer/author/registrant | 06:20 |
| poolie | some have distic | 06:20 |
| poolie | some have meaning and some don't | 06:20 |
| abentley | I think owner/maintainer/registrant are the same here! | 06:20 |
| poolie | "change maintainer" takes you to a page headed "change owner" :) | 06:21 |
| abentley | "Change maintainer" link goes to "Change owner" and button says "Change registrant"! | 06:21 |
| poolie | that's really funny | 06:21 |
| spiv | abentley: bingo! :) | 06:21 |
| poolie | bug 202135 | 06:22 |
| ubotu | Launchpad bug 202135 in launchpad "Change project maintainer page also uses owner and registrant" [Undecided,New] https://launchpad.net/bugs/202135 | 06:22 |
| abentley | Well, at least people are noticing. | 06:22 |
| abentley | Okay, looks like I can change the owner. | 06:25 |
| poolie | hm | 06:25 |
| poolie | abentley: might it not have been better to keep ~bzr as the owner of bzr, and make the new team for everything else? | 06:25 |
| poolie | and wasn't vila trynig to do something similar? | 06:25 |
| poolie | did you talk to him? | 06:26 |
| abentley | No, I wasn't aware of vila's efforts. | 06:26 |
| abentley | I'm not sure whether we can change the shortname of Bzr Developers easily. | 06:26 |
| jamesh | the team owner should be able to change its nickname | 06:27 |
| jamesh | (I think) | 06:27 |
| abentley | Yeah, looks like we can. | 06:27 |
| abentley | Shall I? | 06:27 |
| abentley | Oh, I can't change the shortname for Bazaar developers, which would have to happen first. | 06:28 |
| abentley | Anyhow, Bazaar Developers, which everyone's subscribed to, should retain its memberships in other teams. | 06:29 |
| poolie | spiv: did your patch actually allow you to pull from 'bzr+ssh://bazaar.launchpad.net/%7Ebzr/bzr-dbus/trunk/' | 06:29 |
| poolie | it is not working for me | 06:30 |
| abentley | So we can just swap the shortnames. | 06:30 |
| poolie | my larger patch may have broken it | 06:30 |
| poolie | abentley: i'm concerned that will cause the ppa to move | 06:30 |
| abentley | Aren't PPAs associated with teams? | 06:31 |
| AfC | Anyone know off hand what we need to do to get Ohloh to support Bazaar? [no, not that it matters, but you know, its one of those things that can enhance visibility] | 06:31 |
| poolie | AfC: mail them and ask? | 06:32 |
| abentley | I think right now the PPA hasn't moved, but if we swap the shortnames, it will. | 06:32 |
| poolie | abentley: yes that's what i meant | 06:32 |
| cprov | abentley: they get affected by renaming person/team | 06:32 |
| spiv | poolie: it gave me the same "branches have diverged" error as sftp:// did | 06:32 |
| spiv | poolie: whereas without it gave a traceback | 06:32 |
| AfC | poolie: I guess so. http://www.ohloh.net/about/faq#sourcecontrol | 06:33 |
| chandlerc | anyone familiar with bzr-svn? | 06:33 |
| poolie | spiv: with my branch I get | 06:34 |
| poolie | KnitCorrupt: Knit <bzrlib.knit.AnnotatedKnitContent object at 0xb75222ec> corrupt: line in annotated knit missing annotation information: need more than 1 value to unpack | 06:34 |
| abentley | poolie: I believe we can copy stuff from one PPA to another, so we can do that if/when we change the shortnames. | 06:34 |
| spiv | poolie: hmm! | 06:34 |
| spiv | poolie: no, I didn't get that. | 06:34 |
| abentley | poolie: Anyhow, thanks! | 06:34 |
| poolie | abentley: really my question is: why not remove ~bzr from everything but ownership of bzr? | 06:34 |
| poolie | won't that give what you want? | 06:34 |
| abentley | Yes. I assume other people want to stay members of other things, though. | 06:35 |
| cprov | abentley: or just request a sysadmin to rename the archive disk directory ;) you can have such privileges. | 06:35 |
| chandlerc | well, if anyone has any ideas, i'm getting a SubversionException Unrecognized URL scheme ... 170000 | 06:35 |
| abentley | If they do, then we'd have to switch the team associations from ~bzr to ~bazaar | 06:36 |
| abentley | And move a bunch of people there, too. | 06:36 |
| chandlerc | however svn co on the exact same URL, so I'm fairly certain my Subversion is built with SSL Support | 06:36 |
| AfC | chandlerc: you are using the latest bzr and bzr-svn? | 06:36 |
| chandlerc | bzr 1.3, bzr-svn 0.4.9 | 06:36 |
| abentley | But for me personally, that solution would be fine. | 06:36 |
| spiv | poolie: just to confirm, my simple patch works with a pristine copy of the knit repo for running "bzr pull --overwrite", where without the patch that fails. | 06:36 |
| chandlerc | svn is a weird 1.6 build | 06:36 |
| chandlerc | trying to be a 1.5 branch build of subversion now | 06:37 |
| spiv | poolie: I'm rereading your diff now to see if I can spot the culprit | 06:37 |
| poolie | spiv: that's odd, i don't even get the divergence error | 06:37 |
| poolie | and i'm using the tarball and url you cited earlier | 06:37 |
| spiv | poolie: odd! I'm working with bzr.dev rather than 1.3, but that ought not make a difference... | 06:38 |
| * spiv tries with poolie's branch | 06:38 | |
| poolie | spiv: well a lot of stuff changed in knit.py since 1.3 | 06:39 |
| spiv | poolie: I can reproduce your error with your branch (after fixing a trivial bug in get_options) | 06:41 |
| spiv | poolie: merging bzr.dev into your branch makes no difference | 06:42 |
| lifeless | well | 06:43 |
| lifeless | looking up | 06:43 |
| lifeless | i think we should rename ~bzr to ~bazaar | 06:43 |
| lifeless | and ~bazaar-devs to ~bzr | 06:43 |
| lifeless | then transfer objects, ppa etc across | 06:44 |
| lifeless | *or* | 06:44 |
| lifeless | rename 'bazaar developers' to 'bzr develoeprs' to match its original intent and make the new group the project-wide group | 06:44 |
| poolie | i agree with lifeless | 06:46 |
| poolie | and i prefer the second option, i think | 06:46 |
| chandlerc | AfC: I don't guess that helped much? | 06:47 |
| poolie | spiv: so maybe i should apply your minimal patch to 1.3 and see what happens | 06:47 |
| poolie | and we can triangulate | 06:47 |
| poolie | or rectangulate | 06:47 |
| spiv | poolie: it's your changes to get_method/get_option, it seems | 06:47 |
| spiv | poolie: If I back those out, it works | 06:47 |
| poolie | chandlerc: jelmer may be on in a few hours | 06:47 |
| poolie | or you can file a bug at launchpad.net/bzr-svn | 06:47 |
| spiv | poolie: specifically, get_options | 06:48 |
| poolie | if you do not ultimately get a good solution | 06:48 |
| poolie | spiv: thanks! | 06:48 |
| poolie | oh | 06:48 |
| poolie | aside from anything else i should not be mutating that lisnt | 06:48 |
| poolie | (whatever my next project is it will be in a pure language :) | 06:49 |
| AfC | chandlerc: Sounds like you've got a stack trace to hand, so I'd suggest filing a bug. It might be something silly, of course, but it might just as likely be something real. | 06:49 |
| abentley | poolie: Okay, I'll create a doppelganger Bazaar Developers with the name /~bazaar | 06:50 |
| AfC | that "170000" sounded a bit weird, but depending on what you're doing [vs what you _should_ be doing] it could mean anything | 06:50 |
| spiv | poolie: ah-hah | 06:50 |
| spiv | poolie: that was the bug, well spotted | 06:50 |
| chandlerc | AfC: k, i'm gonna try and roll back to svn 1.5 to be a little less bleeding edge, and if it happens then, i'll file a bug | 06:51 |
| AfC | as for Subversion, I've certainly never heard of 1.6; we're all still waiting impatiently for them to get off their asses and ship 1.5 | 06:51 |
| poolie | apache libraries like using large decimal numbers for errors iirc | 06:51 |
| AfC | chandlerc: good luck | 06:51 |
| chandlerc | AfC: It's just a select revision of the trunk | 06:51 |
| poolie | woo | 06:51 |
| chandlerc | not a real release.. i dunno why the hell its even packaged, but it was easier to get that 1.5 | 06:51 |
| poolie | spiv: that worked then | 06:51 |
| poolie | packaged in what system? ubuntu? | 06:52 |
| chandlerc | gentoo | 06:52 |
| spiv | poolie: yep, wrapping a list(...) around self.backing_index.get_options(version_id) fixed it | 06:52 |
| chandlerc | having to scrounge for ebuilds... i need svn+https authentication, which seems to require at least 1.5 | 06:52 |
| chandlerc | not even a patched 1.4.6 | 06:52 |
| abentley | poolie: The problem with that theory is that there's already a ~bazaar in Launchpad. | 06:53 |
| abentley | Though it looks like a dead account. | 06:54 |
| poolie | we could be a bit more explicit like ~bazaar-overall | 06:54 |
| AfC | chandlerc: I wouldn't recommend overlays under normal circumstances, but if you take the subversion ebuild from the bzr-gentoo-overlay thing lurking on Launchpad somewhere it will get you the necessary patches to svn for bzr-svn to work. | 06:56 |
| chandlerc | AfC: that works, but doesn't allow full use of https subversion repo's i thought | 06:58 |
| AfC | ah | 06:58 |
| abentley | poolie: I called it bazaar-devs, but I'm happy to rename it. | 07:04 |
| poolie | ok with me | 07:06 |
| poolie | spiv: | 07:06 |
| poolie | spiv: * Fix a bug causing a ValueError crash when fetching revisions from a knit | 07:06 |
| poolie | to pack repository or vice versa. | 07:06 |
| poolie | (#208418, Andrew Bennetts, Martin Pool, Robert Collins) | 07:06 |
| poolie | accurate? | 07:06 |
| spiv | poolie: accurate, but maybe also mention that it happens with the smart server | 07:07 |
| spiv | poolie: I don't think that code path is hit by other transports | 07:08 |
| spiv | poolie: depends on how much detail you want to cram into a single bullet point I guess :) | 07:08 |
| poolie | anything else? | 07:08 |
| poolie | no i doubt it | 07:08 |
| poolie | thought it is general code | 07:08 |
| poolie | spiv: can i say you will be helping me get the review queue down next week? | 07:16 |
| spiv | Yep | 07:17 |
| johnny | is there a way to run loggerhead via fastcgi ? it's hard to tell with those start and stop scripts | 07:20 |
| poolie | johnny: seems like it should be possible, mail the list or ask mwh for details | 07:25 |
| chandlerc | AfC: I filed it here: https://bugs.launchpad.net/bzr-svn/+bug/211683 thanks for the help. | 07:27 |
| ubotu | Launchpad bug 211683 in bzr-svn "bzr-svn crashes on branch with exception 170000" [Undecided,New] | 07:27 |
| ubotu | New bug: #211683 in bzr-svn "bzr-svn crashes on branch with exception 170000" [Undecided,New] https://launchpad.net/bugs/211683 | 07:35 |
| poolie | 1.3.1rc1 is out | 07:37 |
| poolie | i'm going to sign off | 07:37 |
| poolie | thanks for your efforts, spiv and lifeless and everyone | 07:37 |
| spiv | poolie: great! | 07:37 |
| spiv | poolie: I'm learning more about the precise conditions thanks to trying to write a test case :) | 07:38 |
| poolie | ok | 07:40 |
| poolie | that sounds useful | 07:41 |
| poolie | call if you want to talk about it | 07:41 |
| spiv | the conditions appear to be that the stream is delivering a line-delta record, whose parent is in the target, and also stored as a line-delta. (And of course that the source and target have different format signatures, i.e. one is annotated and the other isn't). | 07:42 |
| spiv | But it's bit frustrating trying to reproduce that in test_knit, as you don't get much control over whether something is stored as a knit. | 07:44 |
| spiv | er, stored as a delta. | 07:44 |
| spiv | Ah-hah, I have a failing test. | 07:46 |
| spiv | And it passes with the fix. | 07:47 |
| spiv | poolie: ok, I should have this sent to the list in a couple of minutes | 07:47 |
| spiv | poolie: have a great weekend | 07:47 |
| spiv | And that's me done for the day. | 08:09 |
| === doko_ is now known as doko | ||
| === mrevell is now known as mrevel-afk | ||
| === pmezard_ is now known as pmezard | ||
| === mrevel-afk is now known as mrevell | ||
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| ubotu | New bug: #131008 in bzr-svn "bzr-svn stores sqlite db in ~/.bazaar => REALLY SLOW on NFS" [Low,Triaged] https://launchpad.net/bugs/131008 | 13:16 |
| jelmer | pushing to svn+ssh is now slightly faster than pushing over bzr+ssh | 13:51 |
| === BjornT_ is now known as BjornT | ||
| === mrevell_ is now known as mrevell | ||
| === mw|out is now known as mw | ||
| === kiko is now known as kiko-phone | ||
| aantn | hello | 15:46 |
| aantn | I seem to have gotten locked out of launchpad | 15:46 |
| aantn | http://rafb.net/p/amQNZj18.html | 15:46 |
| james_w | aantn: run bzr break-lock sftp://branch a few times | 15:49 |
| === thekorn_ is now known as thekorn | ||
| === hexmode` is now known as hexmode | ||
| aantn | james_w: thanks | 15:53 |
| aantn | that did it | 15:53 |
| cody-somerville | Is it possible to have branches within branches? | 16:00 |
| james_w | cody-somerville: so that the outer ones know about the inner ones? | 16:02 |
| james_w | or are you just asking if bzr will fall over if you make a branch in a subdirectory? | 16:02 |
| cody-somerville | james_w, the outter ones known in the inner ones. | 16:11 |
| james_w | they are called nested trees, or subtrees. bzr can do them, but you will probably find some very surprising bugs at this point. | 16:13 |
| cody-somerville | Okay | 16:13 |
| * cody-somerville is convincing his company to use bazaar over svn. | 16:13 | |
| * cody-somerville hopes he isn't shooting himself in the foot. | 16:13 | |
| LeoNerd | ?? | 16:14 |
| LeoNerd | Are you just asking if you can branch a branch? | 16:14 |
| LeoNerd | If so.. sure... branches don't really have topology | 16:14 |
| LarstiQ | LeoNerd: no, if branches can contain branches. | 16:14 |
| LeoNerd | A branch is a container of a sequence of revisions | 16:15 |
| cody-somerville | ... | 16:18 |
| LarstiQ | LeoNerd: yes, but that isn't helpful in this discussion :P | 16:18 |
| LeoNerd | Well, I was still trying to understand the question | 16:18 |
| LarstiQ | cody-somerville: you can certainly have branches within other branches, you require propagation as well I gather? | 16:19 |
| LarstiQ | cody-somerville: are you using svn:externals (heavily)? | 16:19 |
| LarstiQ | cody-somerville: or formulated differently, what prompts you to ask about this feature? | 16:20 |
| cody-somerville | We don't currently use svn | 16:20 |
| cody-somerville | but we'd like to be able to pull sub-components of the system as well as the entire system | 16:21 |
| LarstiQ | cody-somerville: right | 16:24 |
| LarstiQ | cody-somerville: ah, you're evaluating both bzr and svn, but are using something else atm? | 16:24 |
| cody-somerville | LarstiQ, I just got hired and they aren't using anything :/ | 16:27 |
| LarstiQ | cody-somerville: well, from the positive side, no need to worry about legacy! | 16:28 |
| cody-somerville | :) | 16:29 |
| NfNitLoop | cody-somerville: Ouch. | 16:34 |
| ubotu | New bug: #211852 in bzr "bzr log should accepts multiple files" [Undecided,New] https://launchpad.net/bugs/211852 | 17:16 |
| xif | hello | 17:41 |
| xif | can I commit to an SVN repo with bzr? | 17:41 |
| xif | ah, there's bzr-svn in the repositories | 17:45 |
| * xif <3 Ubuntu | 17:45 | |
| seb_kuzminsky | hi folks, i've got merging problems... or maybe my workflow is just wrong for bzr | 18:04 |
| seb_kuzminsky | i think the root of my problem is lack of cherrypicking | 18:05 |
| seb_kuzminsky | i'm working on a project where the upstream repo is in cvs (boo, hiss) | 18:06 |
| seb_kuzminsky | i've checked out their tree and checked it into a local bzr branch called "upstream" in a shared repo | 18:06 |
| seb_kuzminsky | then i branched my upstream to "local", | 18:07 |
| seb_kuzminsky | and i'm doing all my development in my local branch | 18:07 |
| seb_kuzminsky | when i have something ready to send back to them, i first merge it to my "upstream" bzr branch | 18:07 |
| seb_kuzminsky | then cvs commit the merged result | 18:07 |
| seb_kuzminsky | i dont always merge all of local into my upstream, instead picking one or a few particular "local" commits to merge to "upstream" and commit to their cvs | 18:08 |
| seb_kuzminsky | that's cherrypicking, right? | 18:08 |
| seb_kuzminsky | then next time i try to do a similar thing to the next lump of patches, the merge gets all confused... | 18:09 |
| seb_kuzminsky | anyone here? maybe i should take this question to the mailing list? | 18:09 |
| james_w | seb_kuzminsky: that's cherry-picking yes. | 18:19 |
| james_w | seb_kuzminsky: you may be better off on the list. | 18:19 |
| seb_kuzminsky | ok thanks james i'll try that | 18:21 |
| === kiko-phone is now known as kiko | ||
| awilkins | seb_kuzminsky: Have you considered using seperate feature branches? | 19:09 |
| Stavros | hello | 19:11 |
| Stavros | i am trying to checkout a repo using bzr+ssh but i'm getting "unknown command: serve" | 19:11 |
| Stavros | any ideas why that might be? | 19:11 |
| beuno | Stavros, does the remote location have bzr installed? | 19:12 |
| beuno | (and, if it does, what version?) | 19:12 |
| Stavros | beuno: 0.8.2 :/ | 19:13 |
| Stavros | could that be it? | 19:13 |
| beuno | Stavros, that doesn't sound like a bzr version | 19:13 |
| luks | that's ancient... | 19:14 |
| Stavros | stavros@menhir$ bzr version | 19:14 |
| Stavros | bzr (bazaar-ng) 0.8.2 | 19:14 |
| luks | bzr didn't have a smart server back then | 19:14 |
| Stavros | ah :/ | 19:14 |
| Stavros | i'll ask for an upgrade | 19:14 |
| rockstar_ | Using bzr-svn, I checked out an svn repository as a bzr branch, effectively converting the repo. Is there a similar tool for CVS? | 19:22 |
| seb_kuzminsky | awilkins: that would probably help... but i'd still have the same problem unless i could convert my workflow to only use "merge -r" with increasing revno's, right? | 19:49 |
| === phanatic_ is now known as phanatic | ||
| rockstar_ | I'm trying to move a project from sourceforge's CVS to Launchpad. Is there a tool readily available that would preserve history and such? | 20:32 |
| kgoetz | perhaps the #launchpad ffolks if they have migration tools | 20:32 |
| axes | does the windows installer for bazaar install the necessary libraries for uploading to an SSH server? The connection starts correctly, getting up to the rsa fingerprint, but then drops with "EOF during negotiation". | 20:34 |
| kgoetz | axes: sounds like a key missmatch | 20:35 |
| james_w | rockstar_: there are a couple of cvs importers, I don't know which is best, I think cvsps-import is meant to be pretty good. | 20:36 |
| axes | kgoetz: It notifies me that the key isn't cached, but doesn't give me an option to override - is there a flag I can add to force it without the key? | 20:36 |
| james_w | but as kgoetz says #launchpad may be able to give you a pointer as they spend a lot of time trying to import from cvs | 20:37 |
| james_w | axes: you can select what will provide the ssh somehow, I think an environment variable. | 20:37 |
| james_w | kgoetz: aren't you supposed to be playing games? :-) | 20:37 |
| kgoetz | james_w: i'm multitasking :) | 20:38 |
| axes | james_w: I'm not on a personal computer, so I'd prefer to use the built in libraries - the windows installer packages this functionality, doesn't it? | 20:38 |
| abentley | james_w, axes: Well, Launchpad uses cscvs, which is pretty stable, but not very friendly. | 20:38 |
| james_w | ah, thanks abentley | 20:39 |
| james_w | axes: are you using pageant? | 20:39 |
| abentley | lifeless originally wrote it to import into Gnu Arch. | 20:39 |
| axes | james_w: I'm not sure what I'm using, I haven't done any additional confiuration beyond installing. | 20:40 |
| james_w | axes: I'm not familiar with the windows version, sorry, but I know that paramiko is used, so you are able to use different ssh client libraries. | 20:41 |
| james_w | I don't know how it goes about finding and picking them on windows though | 20:41 |
| james_w | axes: http://bazaar-vcs.org/Bzr_and_SSH might help you | 20:41 |
| axes | james_w: I'm going to try and manually install the paramiko and pyCrypto packages now (I'd think they came with the installer, but maybe not). Also, it seems odd that it gets as far as it does in the connection and then fails, if the problem is a lack of an SSH library | 20:42 |
| james_w | oh, I don't think it's lack of a client. | 20:42 |
| james_w | do you need a key to access the server? | 20:42 |
| axes | james_w: The server should accept any key, I'm hoping it'll ask for a password | 20:46 |
| === BasicMac is now known as BasicOSX | ||
| axes | james_w: Now I'm getting an error saying that a procedure entry point was not found in cygcrypto-0.9.8.dll... | 20:51 |
| james_w | ouch | 20:52 |
| xma | hi #bzr | 21:23 |
| blueyed | jelmer: I'm looking at improving bzr support in etckeeper (which has been added in Debian) and especially the pre-commit hook. Do you have something new about this? I've thought about shipping a bzr plugin with etckeeper, but that seems bulky.. | 21:23 |
| beuno | is there anyway to ask bzr log for "all commits after X revid"? | 21:37 |
| frsk | Is bzr log -r x.. doing what you want? | 21:39 |
| beuno | frsk, ah, it's bzr log revid:X... | 21:39 |
| beuno | (not quite, but made me think, thanks) | 21:39 |
| frsk | D'oh, forgot he revid-part | 21:40 |
| frsk | the* | 21:40 |
| NfNitLoop | Does anyone know if there is work being done on a Netbeans bzr plugin? | 22:25 |
| NfNitLoop | I've seen some online sources that say "Well, Mercurial did it, so it shouldn't be too hard..." | 22:25 |
| NfNitLoop | but nothing beyond that. | 22:25 |
| beuno | NfNitLoop, not at the moment, no | 22:27 |
| beuno | Verterok was looking into it, but I believe he doesn't currently have the time | 22:27 |
| ubotu | New bug: #211967 in bzr "bzr smart server should support hooks" [Undecided,New] https://launchpad.net/bugs/211967 | 22:27 |
| NfNitLoop | I've been using Eclipse, but a project at work uses Netbeans and I miss bzr integration sorely. :) | 22:28 |
| beuno | NfNitLoop, well, maybe if you ping Verterok, he might regain interest in it :) | 22:28 |
| NfNitLoop | Verterok: *ping* ;) | 22:29 |
| NfNitLoop | I dunno, maybe I'll get interested in it. : ) | 22:29 |
| * beuno hides | 22:29 | |
| beuno | NfNitLoop, well, if you do, Verterok can be very much of help to you, since he already went through the whole eclipse pain | 22:29 |
| NfNitLoop | I could have the time, but as much as I'd like to be the steward of some cool OSS, I alway seem to end up doing something else. :p | 22:30 |
| NfNitLoop | beuno: aah, he wrote the Eclipse one? I use it. It's nice. :) | 22:30 |
| beuno | NfNitLoop, yeap, that's why he would be _the_ person to help you out with it | 22:30 |
| NfNitLoop | I imagine I might take the same approach, use bzr-xml to read any data that gets returned, and just call the bzr command. | 22:31 |
| tro | i dunno if there are any devs around, but BZR ROCKS. and THANKS! it works as i expect it to, which is rare | 22:32 |
| beuno | tro, it would be great if you could send a mail to the list with a few reasons why | 22:32 |
| NfNitLoop | tro: isn't it? "Hey, it's featureful AND makes sense!" | 22:32 |
| tro | i love how i just moved the entire repo with a single bzr push | 22:33 |
| NfNitLoop | tro: tar works too. ;) | 22:33 |
| NfNitLoop | (and mv, while we're at it!) :) | 22:34 |
| tro | neat. i think the best part of it that i can unbind at any time and then rebind. i've got my repo on this really sucky slow server, so whenever it gets too slow, i just unbind, commit and bunch of revisions and bind/update/commit the next day | 22:34 |
| NfNitLoop | tro: I pretty much stick to unbound dev, then push changes when I'm done. | 22:35 |
| NfNitLoop | that way it's easy to keep my laptop, server & workstation all in sync. | 22:35 |
| NfNitLoop | but checkouts are nice too. : ) | 22:35 |
| abentley | tro: Glad you like it. | 22:35 |
| tro | NfNitLoop: i'm afraid of losing my changes, though, so i like to sync at least once a day | 22:35 |
| tro | anyway. thanks, guys! *back to coding* | 22:36 |
| db-keen | I've been using bzr branch and bzr push to work with svn repositories, I just noticed svn-import. Should I be using that instead of branch? | 22:55 |
| bob2 | only if you want to import the entire sn repository | 22:58 |
| NfNitLoop | I assume if you branch from another svn-branch into a shared repo, it will share history (as much as svn allows?) | 23:00 |
| NfNitLoop | (even if you didn't svn-import?) | 23:00 |
| NfNitLoop | or, at least, I hope. Since I've been working under that assumption. ;) | 23:04 |
| spiv | NfNitLoop: that's right | 23:43 |
| blueyed | jelmer: around? (re: etckeeper) | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!