| Peng_ | beuno: FWIW, my branch is at http://bzr.mattnordhoff.com/loggerhead/loggerhead/358322-sql-dirs/ . LP hasn't mirrored the latest revisions yet. | 00:00 |
|---|---|---|
| beuno | Peng_, cool. Looking good | 00:02 |
| Peng_ | I'll send a merge proposal in 40 minutes after LP mirrors it again. :\ | 00:03 |
| blfgomes | lifeless: I have to go, but I'll keep searching tomorrow. From what I can see, the code is getting my credentials but it's getting lost somewhere. | 00:03 |
| blfgomes | Thanks for the help. | 00:04 |
| lifeless | blfgomes: ok; please do file a bug | 00:05 |
| lifeless | as vila may know the answer | 00:05 |
| blfgomes | I will | 00:05 |
| blfgomes | see ya | 00:05 |
| igc | morning all | 01:22 |
| Peng_ | G'morning! | 01:22 |
| jml | lifeless: you may have already got a bug/todo about this | 01:30 |
| jml | lifeless: but it would be really great if there could be something like a commit message associated with each thread of a loom. | 01:30 |
| lifeless | jml: there should be a bug | 01:32 |
| lifeless | jml: as I want that | 01:32 |
| jml | arse. | 01:37 |
| jml | I can't upgrade a loomified branch6 format branch. | 01:37 |
| jml | lifeless: how do you get a log of the commits in a thead? | 01:44 |
| jml | thread | 01:44 |
| lifeless | bzr log -r thread:..-1 | 01:45 |
| lifeless | not quite what you want | 01:45 |
| lifeless | file a bug | 01:46 |
| lifeless | loom needs someone to just spend a couple of weeks on it | 01:46 |
| jml | I'd say more than a couple. | 01:52 |
| jml | but maybe not a lot more :) | 01:52 |
| jml | bzr: ERROR: Start revision not found in left-hand history of end revision. | 01:54 |
| jml | nice | 01:54 |
| lifeless | da fuck | 01:56 |
| lifeless | is that from thread:..-1? | 01:56 |
| lifeless | oh, you'll want to set -n0 or whatever it is probably | 01:57 |
| lifeless | I suspect the log work done hasn't taken looms into consideration | 01:57 |
| lifeless | in a loom the left-hand-history is the work done on the thread | 01:57 |
| lifeless | and up-thread does merges into the thread | 01:57 |
| lifeless | file a bug | 01:58 |
| jml | on bzr? | 02:00 |
| lifeless | yes | 02:02 |
| lifeless | task on both, if like | 02:02 |
| * jml discovers another bug :) | 02:08 | |
| jml | lifeless: https://bugs.edge.launchpad.net/bzr/+bug/362667 | 02:14 |
| ubottu | Ubuntu bug 362667 in bzr-loom "Pushing a rich-root loom as a stacked branch is very, very slow" [Undecided,New] | 02:14 |
| lifeless | jml: yes | 02:14 |
| jml | lifeless: know of a work around? | 02:23 |
| lifeless | jml: try sftp:// | 02:23 |
| lifeless | jml: also have a look at your hpss activity | 02:24 |
| jml | lifeless: still the same as on the bug report. | 02:24 |
| lifeless | jml: its asking for one rev at a time | 02:30 |
| jml | lifeless: handy. | 02:30 |
| jml | lifeless: the sftp push took ~260s | 02:30 |
| lifeless | yup | 02:30 |
| lifeless | we have optimisations for regular branches loom is probably unintentionally disabling | 02:31 |
| * Peng_ makes random trivial changes to lp:loggerhead. | 02:53 | |
| Peng_ | It was never a good idea to give me access to it. I do stuff like this all the time. :D | 02:53 |
| poolie | is it just me or is the "userdoc driven design" thread getting too much in to particular cases too early? | 02:55 |
| lifeless | poolie: thats what that design pattern does IME | 02:55 |
| poolie | the pattern of writing user documentation first? | 02:55 |
| poolie | i would have attributed it more to having an open email thread | 02:56 |
| lifeless | yes | 02:56 |
| lifeless | documentation isn't goal level, it makes assumptions about constraints, internals, ffacilities etc | 02:56 |
| jelmer | evening | 03:08 |
| Peng_ | Hi. :) | 03:11 |
| grettke | Hi folks. Can anyone verify that symlinks work with bzr on cygwin? I find that they don't work with Windows and bzr. | 03:53 |
| * igc lunch | 04:37 | |
| jkakar | poolie: Heya, I heard we're possibly working on very similar projects. | 06:40 |
| jkakar | poolie: I've been basically copying the APIs from bzrlib.options and bzrlib.commands and making a tool that can be used to create applications with a bzr-like command-oriented interface. | 06:40 |
| jkakar | poolie: jml mentioned you were working on something similar; the bits I have so far are at launchpad.net/commandant. | 06:40 |
| lifeless | jkakar: I've been making bzr libs command internals more modular | 06:42 |
| lifeless | jkakar: such that i have a branch which allows completely replacing the ui | 06:43 |
| jkakar | lifeless: Nice. I started by trying to use the bits from bzrlib.commands and friends. | 06:43 |
| jkakar | lifeless: It took me several hours to build a working prototype of my application (much of that involved learning about bzrlib) and included some heinous monkey patches. | 06:43 |
| jkakar | lifeless: Once I had the basic prototype using bzrlib working I decided it would be too terrible to continue, and, at the time, I wasn't interested in spending the time it would take to "fix" bzrlib. | 06:44 |
| lifeless | heh | 06:44 |
| jkakar | lifeless: So I reimplemented the basic prototype from scratch using TDD. It took me exactly 16 minutes. I've been building on that base. :) | 06:44 |
| lifeless | well :) | 06:44 |
| lifeless | we're somewhat phobic about external dependencies | 06:44 |
| jkakar | I can understand why. | 06:45 |
| lifeless | but I'm happy to get bzrlib to the point you can use it reliably | 06:45 |
| lifeless | ideally: | 06:45 |
| lifeless | import bzrlib.commands | 06:45 |
| jml | o/` I get by with a little help from your deps o/` | 06:45 |
| lifeless | bzrlib.commands.Command.hooks['find_commands'].clear() | 06:45 |
| jkakar | That'd be cool. I've basically been implementing almost exactly the same APIs as bzrlib.commands and bzrlib.options, so that the possibility of merging our bits stays, well, a possibility. :) | 06:45 |
| jkakar | That and I like the command APIs in bzr, so why reinvent the wheel? | 06:46 |
| jml | lazr.command | 06:46 |
| jml | do it. | 06:46 |
| lifeless | bzrlib.commands.Command.hooks.install_named_hook('find_commands', command_loader(__name__)) | 06:46 |
| jkakar | Nice. | 06:46 |
| lifeless | its approximately that in my pending Commands.as_hooks branch | 06:47 |
| lifeless | I have some decisions and cleanups to make | 06:47 |
| vila | hi all | 07:10 |
| vila | poolie: ping | 07:39 |
| poolie | vila, hi! | 07:39 |
| lifeless | spiv: wow, how long did that analysis take ?:) | 08:03 |
| spiv | lifeless: longer than I thought! | 08:14 |
| spiv | lifeless: I just concocted a shorter example that exhibits the behaviour. | 08:15 |
| lifeless | surely just a long list of non-interned strings is enough | 08:16 |
| spiv | lifeless: it has to be a long list of objects that refer to each other, such that the C stack grows with each object dealloc | 08:17 |
| spiv | lifeless: e.g. a linked list | 08:17 |
| lifeless | right | 08:17 |
| spiv | lifeless: and guess what data structure jam was stress-testing? ;) | 08:17 |
| lifeless | an actual list :) | 08:17 |
| lifeless | not a vector | 08:17 |
| spiv | Right. "list", not "list". ;) | 08:18 |
| lifeless | but also reduce(range(8192), lambda x:[x]) | 08:19 |
| spiv | lifeless: probably, but it's hard to observe the behaviour without using __del__ or weakrefs to observe when dealloc happens. | 08:22 |
| spiv | lifeless: http://rafb.net/p/C3wWeG57.html | 08:23 |
| quicksilver | is there an option to bzr push to choose an older tree format? | 10:01 |
| quicksilver | say I want to push to a server which only has bzr 0.11 | 10:01 |
| jonnydee | abentley: Can you just tell me when the Nested Trees feature is expected to be released? I mean can you give me an estimation about the targeted bazaar version? | 10:10 |
| spiv | quicksilver: you can "bzr init --knit URL" (or --weave? It's been a while...) first, then push to that. You may not be able to use bzr+ssh with a server that old (but SFTP should be nearly as good compared to bzr+ssh with a 0.11 server...). | 11:02 |
| quicksilver | or I could bzr init on the remote server and then push to it? | 11:03 |
| spiv | Right. | 11:04 |
| spiv | bzr push will preserve the format of an existing branch. | 11:04 |
| * quicksilver nods | 11:08 | |
| quicksilver | I hadn't thought of initing an empty branch, for some reason | 11:08 |
| quicksilver | I only thought of initing a populated branch | 11:08 |
| quicksilver | and didn't want ot lose history :) | 11:08 |
| === ivan is now known as Guest21648 | ||
| === Guest21648 is now known as ivan | ||
| MvG | I've just tried to push a branch (of bzr.dev) with two small commits to lp. Noticed that it claimed to use a default stacking dir, but was transferring huge amounts of data, like what seemed to be the whole repo. Progress stayed at "Transferring:Walking content. 24366/24366", only data and speed got adjusted. I canceled, tried again, same thing. Is there something wrong with stacking? | 12:54 |
| james_w | MvG: can you pastebin "bzr info -v" of your local branch please? | 13:14 |
| === mario__ is now known as pygi | ||
| MvG | james_w: http://rafb.net/p/hxYeuO24.html | 13:15 |
| james_w | Branch format 6 | 13:15 |
| MvG | So the format doesn't support stacked repos, and the upstream repo was created using the same format? | 13:16 |
| james_w | bug 356699 I expect | 13:17 |
| ubottu | Launchpad bug 356699 in bzr "not stacking when pushing to launchpad" [Undecided,New] https://launchpad.net/bugs/356699 | 13:17 |
| MvG | Looks like my guy, yes. | 13:19 |
| MvG | How can I remove a remote repo, to re-create it in a stacked format? | 13:20 |
| james_w | you can delete it from the launchpad web UI | 13:20 |
| james_w | go to branch page and click on the little dustbin next to the branch title | 13:21 |
| james_w | however, that may not be enough, you may need to upload your local branch to have it work | 13:21 |
| MvG | What formats do support stacking? 1.9? | 13:22 |
| james_w | 1.6 and later | 13:23 |
| MvG | Doesn't look good. :-( | 13:25 |
| adamt | Hi! | 14:07 |
| adamt | Is there really no netbeans-plugin in devopment? :) | 14:07 |
| kinkie | Hi all, a question: is there a way to reparent a branch? That is: I've branched off http://foo/branch/trunk, which is also accessible as bzr+ssh://foo/bzr/branch/trunk. Is there a way to change the parent location without needing to also rebranch all children? Thanks! | 14:09 |
| bob2 | bzr pull --remember newurl | 14:09 |
| jelmer | hi kinkie | 14:09 |
| kinkie | ok. Thanks! | 14:09 |
| bob2 | or hack .bzr/branch/branch.conf | 14:09 |
| jelmer | MvG: just noticed your patch | 14:09 |
| kinkie | Hi jelmer :D | 14:09 |
| * kinkie would prefer not to hack if possible :D | 14:09 | |
| jelmer | MvG: it seems like it would be useful to have a common helper function that can take a BzrDir and return an instance of the default format compatible with that BzrDir | 14:10 |
| jelmer | MvG: "bzr upgrade" already does this by itself at the moment | 14:11 |
| yelly | hey, I'm trying to install bazaar on OS X. I've just installed python 2.6.2, but it's still asking me to update to 2.5, what up with that? | 14:22 |
| * SamB wishes bzr would say how the branches have diverged | 14:27 | |
| jelmer | SamB: bzr missing ? | 14:37 |
| SamB | jelmer: hmm. | 14:37 |
| SamB | maybe if "bzr pull" would suggest that? | 14:37 |
| SamB | would there be a reason not to have it do that? | 14:38 |
| jelmer | SamB: no, that seems like a good suggestion | 14:38 |
| jelmer | SamB: perhaps it can also say how many revisions have diverged on each side | 14:38 |
| SamB | hmm. | 14:38 |
| SamB | well, I'll just make the patch to suggest "bzr missing" | 14:38 |
| abentley | jonnydee: I can't give anything precise. I'm expecting it to land in weeks or a few months. | 14:40 |
| SamB | _fmt = ("These branches have diverged." | 14:42 |
| SamB | + " Use the missing command to see how." | 14:42 |
| SamB | " Use the merge command to reconcile them.") | 14:42 |
| SamB | how does that look? | 14:42 |
| jonnydee | abently: thanx for your answer :) "few months" to wait for such a great feature is no problem for me. best regards, jonnydee :D | 14:42 |
| === sabdfl1 is now known as sabdfl | ||
| SamB | jelmer: is that a good way to say it, do you think? | 14:43 |
| jelmer | SamB: I think so | 14:46 |
| lifeless | jam: ping | 14:47 |
| lifeless | jam: I have an idea | 14:47 |
| SamB | hmm, is there a simple way to say "only run the self tests for bzr (and it's included plugins)" ? | 14:48 |
| lifeless | jam: for BTreeIndexBuilder, I suggest we create a bloom when inserting keys into it. We can choose a pretty big bloom size. | 14:48 |
| lifeless | jam: and when we spill, we only probe fallback indices for keys if the big bloom says the key might be preesent in the index at all | 14:48 |
| lifeless | SamB: BZR_PLUGIN_PATH=/dev/null bzr --selftest | 14:49 |
| lifeless | I think | 14:49 |
| SamB | or that, + tests for a given plugin? | 14:49 |
| SamB | oh ... but without skipping the loading of plugins | 14:49 |
| lifeless | yelly: it probably means that you have multipl copies of plugins | 14:50 |
| lifeless | yelly: it probably means that you have multipl copies of **python** | 14:50 |
| yelly | lifeless: how would I find out? | 14:50 |
| lifeless | yelly: are you using the dmg installer? | 14:51 |
| SamB | (you may want to see whether the plugins you have installed break the plain bzr tests without actually running their own tests, no?) | 14:51 |
| jam | lifeless: so you are thinking to create an in-memory only bloom? | 14:51 |
| yelly | yeah | 14:51 |
| jam | you need ~1 byte per object to have a decent bloom hit rate | 14:51 |
| jam | so for 100k keys, that is 100-200kB in memory | 14:51 |
| lifeless | yelly: I'm not sure; I don't have a macos X box | 14:51 |
| jam | not too bad | 14:51 |
| lifeless | jam: right, way <<< 20bytes or 200 | 14:52 |
| jam | for 500k keys (launchpad currently) that is about 1MB | 14:52 |
| jam | still "decent" | 14:52 |
| yelly | although, come to think of it, i prob should be logging out before i start worrying ;) | 14:52 |
| yelly | sometimes your so tired you forget the basics | 14:52 |
| yelly | I'll get back if it doesn't work out | 14:53 |
| yelly | thanks all | 14:53 |
| lifeless | yelly: file a bug in the bug tracker or something if you don't get an answer once you are awake :) | 14:53 |
| jam | lifeless: I'll also note that in my testing, resizing a bloom "works", but is inefficient, so you sort of want to pre-allocate a large size | 14:53 |
| lifeless | jam: its a concept; if you want to play with it and see if it flies | 14:53 |
| lifeless | right, I was thinking to start by testing with just a 10MB fixed size thing | 14:53 |
| lifeless | or even 1MB | 14:54 |
| lifeless | if you avoid probing until you have most of the keys in, the remainder shouldn't be able to thrash the cache or whatever it is that they are doing | 14:54 |
| lifeless | [I'm separately analysing that issue, I have a lsprof generating data now... its quite a large dataset | 14:54 |
| lifeless | the index build has been running since about 10am | 14:55 |
| lifeless | its now midnight | 14:55 |
| lifeless | jam: I wouldn't resize; I'd cascade | 14:56 |
| lifeless | jam: start with size N; if it gets too dirty, create a Y-scaled up bloom; when thats dirty, YYN, etc | 14:58 |
| jam | lifeless: are you saying insert all the keys from scratch? | 14:58 |
| lifeless | jam: no | 14:58 |
| lifeless | jam: insert into the new bloom new keys | 14:59 |
| lifeless | when being asked for a key, check all the blooms | 14:59 |
| === abentley1 is now known as abentley | ||
| lifeless | jam: anyhooo, way past bedtime | 15:14 |
| lifeless | jam: just felt it was a fairly useful insight into our needs here that we could test easil | 15:14 |
| lifeless | y | 15:14 |
| lifeless | hope it helps | 15:14 |
| SamB | what do I do with a merge directive to get it into bzr.dev (hopefully)? | 15:17 |
| SamB | is there a pyrex-less "buildbot" (or whatever you use to do automated tests)? | 15:20 |
| spiv | SamB: post it to the list in an attachment, in a subject starting with [MERGE] | 15:23 |
| spiv | SamB: HACKING.txt in the source tree should describe the process in detail | 15:23 |
| spiv | SamB: we don't use buildbot, but we do have a PQM instance that runs the full test suite (including pyrex extensions) before allowing a commit to the trunk. | 15:24 |
| spiv | jam: that was a wacky gc problem | 15:24 |
| spiv | jam: I'm about to go to bed, but I'm inclined to think it's a bug in Python | 15:25 |
| SamB | spiv: maybe you should also test *without* pyrex installed ? | 15:25 |
| SamB | (if you're going to let people install that way, anyway) | 15:25 |
| jam | SamB: all of our dual implementations are meant to have thorough implementation tests | 15:25 |
| jam | which are run whether pyrex has been run or not | 15:25 |
| SamB | hmm. | 15:26 |
| jam | If we are missing a test, then we are missing a test | 15:26 |
| jam | but you shouldn't have to run everything as a bzr command to test an interface | 15:26 |
| spiv | SamB: we write the unit tests in such a way that the pure python implementations are always tested with the exact same tests that are applied to the pyrex implementations. | 15:26 |
| * SamB got a lot of output from the test suite though | 15:26 | |
| spiv | SamB: it's always possible there are gaps in the coverage :) | 15:26 |
| SamB | does that include running the blackbox tests with the pyrex variants not being loaded? | 15:27 |
| spiv | SamB: but I don't think we've had much trouble with bugs like "X only works with pyrex bits built" | 15:27 |
| spiv | SamB: no | 15:27 |
| SamB | well, see, that's the sort of thing I mean | 15:27 |
| SamB | run ALL tests with NO pyrex bits, too | 15:27 |
| spiv | SamB: the point of running the same unit test suite for the two implementations is so that we can confidently then run other tests like blackbox with just one implementation, because they are the same. | 15:28 |
| spiv | SamB: *proven* to be the same, thanks to the tests... | 15:28 |
| SamB | well, if the tests proved that, that would be fine ;-) | 15:28 |
| spiv | SamB: the potential gap is if the automatic "use pyrex, else use plain python" logic fails. | 15:28 |
| SamB | but I happen to know some mathematics | 15:28 |
| spiv | (Or just a vanilla gap in the unit tests) | 15:28 |
| SamB | and I don't think that's how proofs work ;-) | 15:28 |
| spiv | Ok, "proven" is too strong a word. | 15:29 |
| SamB | well, yes, that would be a "vanilla gap" | 15:29 |
| spiv | But "very high confidence" | 15:29 |
| SamB | the unit tests can't prove that everything uses the tested interface ;-) | 15:29 |
| SamB | the problems I'm thinking you might miss are perhaps more likely to be in the other tests than anywhere else ;-) | 15:30 |
| spiv | So far, this strategy has worked very well; it hasn't let much (any?) bugs of the sort you are worried about slip through, and it doesn't require running large fractions of our test suite twice just to exercise a tiny fraction of the code. | 15:30 |
| SamB | I'm seeing stuff like: | 15:30 |
| jam | SamB: any time you have multiple implementations, there is a temptation to run higher level tests against all implementations. | 15:30 |
| jam | However, we have 10 repository formats, 5 branch formats, 5 transports, etc | 15:31 |
| jam | so you get into running the tests 10*5*5*xxx times | 15:31 |
| jam | so we rely on having good interface tests | 15:31 |
| spiv | I think this is because the unit tests are pretty good, and because the "use pyrex if available, otherwise use plain python fallback" logic is pretty simple, so the risks of it failing are pretty small... and if it does, then it fails in a very straighforward way. | 15:31 |
| SamB | well, yes, I'm not worried about that logic | 15:31 |
| SamB | if it fails, I'll know | 15:31 |
| jam | SamB: Also, in at least some of the permutations of pyrex I test, I also test that the abstraction function is correct | 15:32 |
| jam | Specifically, I do stuff like: | 15:32 |
| jam | if pyrex_is_available: self.assertIs(function, pyrex_function) | 15:32 |
| jam | To now that the logic that is permuting is at least getting the right one on this test run | 15:32 |
| jam | admitedly that doesn't test both halves of the possibility during test time | 15:33 |
| * SamB woners why he gets this: | 15:33 | |
| SamB | ERROR: blackbox.test_branch.TestRemoteBranch.test_branch_local_remote | 15:33 |
| SamB | 'str' object has no attribute 'get' | 15:33 |
| spiv | jam: I suppose we could temporarily muck with sys.modules if we really wanted too... | 15:33 |
| jam | spiv: yeah, but then you have to re-import everything/ run bzr in a subprocess, etc. | 15:33 |
| spiv | jam: you don't *have* to | 15:33 |
| jam | SamB: if you could pastebin a full traceback, it makes it easier | 15:33 |
| jam | !paste | 15:33 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 15:34 |
| SamB | jam: how do I get selftest to give full tracebacks ? | 15:34 |
| spiv | jam: but it's a bit fiddly, yeah. | 15:34 |
| jam | SamB: when it finishes, it does | 15:34 |
| spiv | SamB: it reports them when the run finishes | 15:34 |
| jam | spiv: I guess you could nuke the module under test, right? | 15:34 |
| SamB | oh. that could take a while! | 15:34 |
| spiv | SamB: You can run just one test by doing "bzr selftest TEST_NAME" | 15:34 |
| jam | SamB: that specific error looks like something is getting a string when we are expecting a dict | 15:34 |
| spiv | SamB: (you can even use a regex, plus other fancy stuff) | 15:35 |
| spiv | SamB: you can even do that while another bzr selftest is running, we isolate our tests properly :) | 15:35 |
| jam | SamB: btw, when I run that exact test here, it succeeds with or without the extensions built... | 15:36 |
| SamB | http://paste.ubuntu.com/152835/ | 15:37 |
| SamB | hmm | 15:37 |
| SamB | jam: what plugins do you have ? | 15:38 |
| SamB | wait, that doesn't seem to be it | 15:39 |
| jam | SamB: that directly points to a bug in the bzr-svn plugin | 15:39 |
| SamB | oh it does ? | 15:39 |
| jam | /home/naesten/.bazaar/plugins/svn/transport.py | 15:40 |
| jam | line 78 | 15:40 |
| SamB | oh, yeah, now I see it | 15:40 |
| jam | jelmer: ^^ didn't the credential handling change a bit recently? | 15:40 |
| SamB | maybe I'm using the wrong branch | 15:40 |
| === abentley1 is now known as abentley | ||
| SamB | hmm. this message doesn't wrap nicely. | 15:44 |
| exarkun | SamB: that's because it's so short | 15:46 |
| exarkun | SamB: it doesn't need to wrap | 15:46 |
| exarkun | len("hmm. this message doesn't wrap nicely.") == 38; who has a terminal that narrow? | 15:46 |
| === nevans1 is now known as nevans | ||
| SamB | exarkun: not THAT one | 15:52 |
| exarkun | SamB: Oh. | 15:52 |
| SamB | the branches-have-diverged one, with my additions | 15:52 |
| SamB | where should I add a \n ... | 15:53 |
| ehazlett | is there a way to dump a bzr repo to svn? | 15:57 |
| === lamont` is now known as lamont | ||
| igc1 | night all | 16:02 |
| vila | igc1: good night ! | 16:10 |
| ronny | lifeless: i decided not to put any further efford into subunit, hope you find someone that cares enough to enhance the nose plugin | 16:29 |
| ehazlett | is there a way to dump a bzr repo to svn? | 16:38 |
| jelmer | SamB: please update your instance of bzr-svn | 16:40 |
| jelmer | SamB: You should at least get a different error these days | 16:40 |
| jelmer | ehazlett: bzr push | 16:40 |
| ehazlett | jelmer: thx | 16:42 |
| ehazlett | jelmer: do i have to specify any arguments; it just created a new branch | 16:43 |
| ehazlett | jelmer: nvmd... :) | 16:43 |
| ehazlett | what i'm trying to do is import the bzr branch into hg -- the only way i can see to do it is to dump to svn... anyone have any other ideas? | 16:45 |
| hsn_ | !cvs import | 16:49 |
| ubottu | Sorry, I don't know anything about cvs import | 16:49 |
| hsn_ | !cvs migration | 16:50 |
| ubottu | Sorry, I don't know anything about cvs migration | 16:50 |
| jelmer | ehazlett: have you tried tailor? | 16:56 |
| === rockstar` is now known as rockstar | ||
| jelmer | ehazlett: also, the mercurial folks might have better ideas about this | 16:57 |
| ehazlett | jelmer: no i will try it -- yeah, i can't seem to get an answer... | 16:57 |
| jelmer | SamB: ? | 17:16 |
| Seablade | Quick question if I can. Can bzr maintain hard links between the source and repo? Is this possible without the bazaar server running(IE. push/pull/merge with another individual, or to an FTP server?) I am looking for a solution to maintain audio sessions where the session files are plain text, but the audio files I only want to commit once due to time constraints and the software would hard link to those files as it uses them. | 17:20 |
| vila | jam: ping, quick feedback about conversion to dev6, | 17:25 |
| vila | even with xml8 patched same time, same memory consumption.... | 17:26 |
| vila | ...argh, of course since I ran with the same *unpatched* bzr >-/ time for some vacations really :-( | 17:27 |
| quicksilver | I'm being stupid today | 17:34 |
| quicksilver | what's the bzr command to see the diff between two branches? | 17:34 |
| quicksilver | bzr diff foo-a foo-b # gives ERROR: Files are in different branches | 17:34 |
| quicksilver | do I have to run the merge speculatively and examine the diff? | 17:35 |
| vila | quicksilver: bzr diff --old <old-branch> --new <new-branch> | 17:36 |
| vila | both are optional | 17:37 |
| vila | quicksilver: or you can use 'bzr merge --preview' | 17:37 |
| quicksilver | vila++ | 17:37 |
| vila | quicksilver: of course redirecting 'bzr merge --preview' in an emacs buffer and issuing M-x diff-mode there.... | 17:38 |
| vila | ...is a pretty good cherry-picker :) | 17:38 |
| quicksilver | yes of course | 17:38 |
| quicksilver | you didn't think I was considering doing this outside emacs, I hope? | 17:39 |
| quicksilver | what kind of man do you take me for? | 17:39 |
| vila | no of course :-) | 17:39 |
| blfgomes | lifeless: I've filed a bug report regarding that authentication issue | 18:39 |
| maco | is it possible to use bzr with Python 2.3.4? | 20:24 |
| LarstiQ | I don't think so. | 20:25 |
| maco | bleh. ok. i need to figure out svn or something then. | 20:28 |
| maco | thanks | 20:28 |
| nekohayo | LarstiQ: any news for the etiquette guide on http://bazaar-vcs.org/Scenarios ? | 20:46 |
| nekohayo | (just checking randomly) | 20:46 |
| LarstiQ | nekohayo: no sorry, no progress | 20:46 |
| nekohayo | ok | 20:46 |
| LarstiQ | item 45 on my todo list fwiw | 20:46 |
| nekohayo | oh you have an ordered todo list | 20:47 |
| nekohayo | is that a particular app? | 20:48 |
| LarstiQ | nekohayo: I use yagtd | 20:49 |
| LpSolit | is it possible to get a single file with bzr (I'm only interested in a specific file, and I don't want to do a whole checkout of a branch)? | 21:15 |
| fullermd | Yes, with export. | 21:17 |
| LarstiQ | or cat | 21:19 |
| LpSolit | export? what would be the command? | 21:19 |
| fullermd | Oh yeah. I was probably thinking of cat... | 21:20 |
| fullermd | Though a glance at the help suggests it won't actually work... | 21:20 |
| LpSolit | can the file be on a remote server? | 21:21 |
| fullermd | No way to tell it to use some branch other than one you're in. Export should be able to do it though. | 21:21 |
| fullermd | Though I don't know how the output will look for a single file... | 21:21 |
| fullermd | I would guess it will end up looking like the tree with everything but that file (and its containing dirs) deleted, but... | 21:22 |
| LarstiQ | fullermd: I remember fixing remote cat bugs | 21:23 |
| LarstiQ | (just lp: that doesn't take it) | 21:23 |
| fullermd | Oh, I guess it does. The help is very unclear on that though. You'd never know other than by trying. | 21:25 |
| LarstiQ | yeah, bzr cat sftp://host/path/to/branch/path/to/file worked | 21:27 |
| LpSolit | bzr cat bzr://bzr.bugzilla.org/selenium/3.4/t/test_sudo_session.tbzr: ERROR: u'bzr://bzr.bugzilla.org/selenium/3.4/t/test_sudo_session.t' is not present in revision lpsolit@gmail.com-20090415114310-63op6fa1unrk58xf | 21:28 |
| LpSolit | what does it mean? :) | 21:28 |
| LpSolit | oh, typo | 21:29 |
| LpSolit | pfff | 21:29 |
| fullermd | ls can help you catch that: | 21:29 |
| fullermd | % bzr ls bzr://bzr.bugzilla.org/selenium/3.4/ | grep test_sudo_session | 21:29 |
| fullermd | bzr://bzr.bugzilla.org/selenium/3.4/t/test_sudo_sessions.t | 21:29 |
| LpSolit | yes, I forgot the final s | 21:29 |
| LpSolit | is there a way to redirect it to a file rather than my screen? | 21:30 |
| LpSolit | cat --file or something? | 21:30 |
| LarstiQ | cat > file? | 21:30 |
| fullermd | Well, generally with the shell... | 21:30 |
| fullermd | Though I guess it probably should grow a -o. | 21:30 |
| LpSolit | yes, I had > file in mind, but I wondered if there was an argument for cat ;) | 21:30 |
| LpSolit | anyway, this is working great, thanks a lot :) | 21:32 |
| LpSolit | last question: can I download 2 files at once using cat? | 21:33 |
| LpSolit | or should I loop over each file I want? | 21:33 |
| Peng_ | LpSolit: Try it and see. :D | 21:33 |
| LpSolit | haha | 21:33 |
| Peng_ | LpSolit: It should be possible; it shouldn't need a write lock or anything. | 21:33 |
| LpSolit | when someone knows, it's so much faster ;) | 21:33 |
| LpSolit | ok, I think I have all the information I need. Thanks again! Very helpful! :) | 21:34 |
| * LarstiQ thought trying was faster than asking | 21:36 | |
| Peng_ | Well, if someone answers immediately, that's probably faster. | 21:37 |
| LarstiQ | hmja, if you're already in your irc client and don't have /exec | 21:38 |
| fullermd | Well, y'never know. He might be an emacs user, and so unable to fit anything else on the machine unless he exits it... | 21:39 |
| LarstiQ | tsk :P | 21:39 |
| === bob2 is now known as Guest10433 | ||
| lifeless | ronny: fair enough, thanks | 22:53 |
| ronny | lifeless: i'll either go for py.test extensions or wire something up that can be feed directly into a shell | 22:54 |
| lifeless | ronny: sure | 22:56 |
| lifeless | jam: around? | 22:56 |
| === luke-jr_ is now known as luke-jr | ||
| Peng_ | jelmer: ping | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!