| jam | vila: btw, I've been using your --startingwith a lot lately, thanks for doing it | 00:00 |
|---|---|---|
| jam | It actually jumps out at me when I'm using an older branch which doesn't have it | 00:00 |
| james_w | Is there a pleasant way of deciding whether something is remote? | 00:02 |
| james_w | I take BRANCH as an argument on the command line, if it is local then I want to "cd" there, if it isn't I want to change some values of something | 00:04 |
| james_w | it doesn't have to be perfect in checking whether something is local, and I don't mind about the case that someone gives an sftp:// URI that resolves to their current working directory. | 00:04 |
| james_w | would just checking for local paths and file:// URIs with string comparison be ok? | 00:05 |
| james_w | local = urlparse.urlsplit(location)[0] in ('', 'file') | 00:07 |
| james_w | that would seem to do it | 00:07 |
| beuno | mwhudson, you've got mail. Let me know if that addresses your comments | 00:11 |
| poolie | lifeless: can you please set up a pqm 1.6 branch some time soon | 00:12 |
| poolie | actually nm | 00:12 |
| poolie | we'll wait to branch til next week | 00:12 |
| mwhudson | beuno: ok | 00:13 |
| beuno | cool, ipython uses bzr and LP! http://ipython.scipy.org/moin/ | 00:13 |
| igc | morning | 00:13 |
| mkanat | jam: Where is cvsps-import storing the map history? | 00:23 |
| jam | mkanat: look at your output there should be a directory where it is storing something.map | 00:24 |
| jam | I don't remember off-hand | 00:24 |
| jam | but it should be fairly obvious | 00:24 |
| mkanat | jam: Okay. | 00:24 |
| mkanat | Ah, yeah. | 00:24 |
| mkanat | jam: If I do a manual checkin on one of the branches, will it break fmap? | 00:25 |
| jam | mkanat: you aren't supposed to be modifying these branches outside of cvsps, I'm not sure what will happen if you do | 00:26 |
| mkanat | Hm. | 00:26 |
| mkanat | jam: I'm trying to figure out a workaround for the situation I'm in, any ideas? | 00:26 |
| Pieter | Hmm.. I downloaded the bzr emacs repository from http://bzr.notengoamigos.org/emacs.tar.gz, but I get a fatal error when trying to check out revision 50255 | 00:26 |
| jam | mkanat: well, you can fix cvsps or rebase.... | 00:26 |
| jam | sorry I don't have a better answer | 00:26 |
| mkanat | jam: It looks like rebase won't work, as far as I can see... | 00:27 |
| jam | mkanat: sorry you can fix (cvsps or rebase) | 00:28 |
| mkanat | Ahh. | 00:28 |
| jam | not (fix cvsps) or (rebase) | 00:28 |
| mkanat | jam: What would happen if I surgically remove those revisions from revision-history? | 00:31 |
| mkanat | Ha, okay, that's bad. | 00:33 |
| === abentle1 is now known as abentley | ||
| Pieter | jearl`: you there? | 00:50 |
| spiv | Ah, I'm back online. | 01:13 |
| lifeless | mkanat: uncommit should be fine, I would expect converters to just re-add them tho :P | 01:16 |
| lifeless | mkanat: also, you may find that there are fixes for the cvsps program itself 'out there', I've seen various folk talk about patches for it | 01:17 |
| mkanat | lifeless: Yeah, but this one isn't so much a bug as a missing feature. | 01:24 |
| mkanat | lifeless: Also, there are commits after the "bad ones". | 01:24 |
| lifeless | mkanat: sorry, I didn't track the very start of the conversation; whats the root bad behaviour of cvsps? | 01:24 |
| mkanat | lifeless: It doesn't track what patchset a branch starts at from its parent. | 01:25 |
| lifeless | so how do we create new branches at all? | 01:25 |
| lifeless | does cvsps-import infer that itself? | 01:26 |
| lifeless | jam: ^ ? | 01:26 |
| mkanat | lifeless: I think so. I think the first time it sees a branch name it branches it from its ancestor at that point in time. | 01:31 |
| mkanat | lifeless: I'm guessing there's no way to uncommit a series of revisions that aren't actually the most modern set. | 01:31 |
| jam | lifeless: The stream of cvsps tells you "create a new branch, originating from this branch" | 01:34 |
| jam | It doesn't indicate at what point in time along the other branch to split, it was just inferred by order | 01:34 |
| lifeless | jam: ok | 01:34 |
| lifeless | jam: so could we not just run cvsps in toto again, checking it for consistency against the last output | 01:34 |
| james_w | lifeless: hi, do you have a minute, I'd like to confirm something? | 01:35 |
| lifeless | james_w: shoot | 01:35 |
| james_w | lifeless: is your idea that a revision should only appear in the left hand ancestory of a branch if it was uploaded to that distribution? | 01:35 |
| jam | lifeless: I think cvsps deterministically gives the same results each time | 01:35 |
| lifeless | james_w: from the branch point yes | 01:36 |
| jam | lifeless: if it didn't, then I couldn't support resume without more work | 01:36 |
| james_w | lifeless: e.g. if Debian was to upload two versions quickly, and the first wasn't synced then it should not be a revision in the Ubuntu branch. | 01:36 |
| lifeless | jam: surely then new branches appear in the entire output correctly? | 01:36 |
| jam | lifeless: apparently not | 01:36 |
| jam | It seems that if you tag a branch | 01:37 |
| jam | and then do a couple of commits on the source branch | 01:37 |
| jam | and *then* commit to the new branch | 01:37 |
| jam | it shows the same thing | 01:37 |
| jam | except it doesn't realize that the tag was on an earlier commit | 01:37 |
| lifeless | oh, date sorted output | 01:37 |
| jam | something like that | 01:37 |
| jam | it claims to do topological sorting, etc | 01:38 |
| jam | but we are seeing date sorted here | 01:38 |
| james_w | lifeless: what about packages that predate Ubuntu, should they adopt the history of the Debian branch? | 01:38 |
| lifeless | james_w: I'm not sure what you mean | 01:40 |
| james_w | lifeless: this is stage 2 really, but I want to get it clear in my head, the first version of package foo didn't appear in Ubuntu as it predates it, so if the above statement is true it should not be in the left-hand ancestory. However, this would mean that the branches for Debian and Ubuntu are divergent, even if foo has only ever been synced from Debian. | 01:42 |
| james_w | is that the desired behaviour? | 01:43 |
| lifeless | ah | 01:43 |
| lifeless | so perhaps rephrasing | 01:43 |
| lifeless | 'every upload we import from ubuntu should be in the left hand ancestry' | 01:44 |
| james_w | sure | 01:45 |
| lifeless | does that help ? | 01:46 |
| james_w | and in the first case, where debian uploads two packages quickly and only the second is synced, should that cause divergence, or would it be ok to include the first upload in the left hand ancestry? | 01:46 |
| lifeless | I think that is fine | 01:47 |
| lifeless | given you're tagging to identify distro versions orthogonally to revision ids | 01:47 |
| lifeless | I don't think I ever suggested that commit should imply upload, only that upload -> left hand commit | 01:48 |
| lifeless | (If I did, sorry for confusion, I didn't intend to) | 01:48 |
| lifeless | abentley: I have a test case | 01:48 |
| james_w | ah, no, you didn't imply either way, I don't think. I was just unsure, so I wanted to confirm before getting too far down one path. | 01:49 |
| james_w | thanks for your time. | 01:49 |
| lifeless | abentley: http://pastebin.com/d54e0a61e | 01:49 |
| lifeless | abentley: if you could just eyeball that and see if it makes sense to you | 01:50 |
| james_w | back to bed :-) | 01:50 |
| lifeless | fun, it breaks everything | 01:51 |
| lifeless | actually, http://pastebin.com/d3ba9db64 is the working version | 01:52 |
| abentley | lifeless: on line 21, is that "line\2line..."? | 01:54 |
| lifeless | abentley: oh, nice catch :) | 01:54 |
| lifeless | should be \n indeed | 01:55 |
| lifeless | now it only breaks annotated weaves as expected | 01:55 |
| abentley | Is the first vf only being used to generate a sha1? | 01:56 |
| lifeless | yes, I am shrinking it further now | 01:56 |
| lifeless | if it appears to make sense to you that is | 01:57 |
| abentley | I forget what the parameters to ParentText are... | 01:58 |
| lifeless | parent number | 01:58 |
| lifeless | | __init__(self, parent, parent_pos, child_pos, num_lines) | 01:58 |
| lifeless | I got those numbers by printing the bzr generated mpdiff with the optimiser disabled | 01:59 |
| lifeless | but I wanted a test that was independent of that other discussion | 01:59 |
| abentley | Yeah, assuming that \2 is \n, it looks reasonable. | 02:00 |
| lifeless | thanks | 02:00 |
| * fullermd hates the launchpad bug mailings... | 02:02 | |
| fullermd | Every time I THINK I've captured every way they can get to me, some whole new set of headers arrives... | 02:03 |
| lifeless | ok, it has to be on top of a delta to trigger the error | 02:04 |
| lifeless | http://pastebin.com/d3b2ceea5 | 02:05 |
| * igc running some errands - bbl | 02:21 | |
| lifeless | yay finally triggered this without mpdiff involvement | 02:31 |
| poolie | lifeless: no test for 234748 yet, will do it soon | 02:50 |
| lifeless | poolie: I'm dealing with a very similar bug | 02:51 |
| lifeless | nearly finished | 02:51 |
| lifeless | if you have a fix for 234748, perhaps you could try my test case against it ? | 02:51 |
| poolie | happy to | 02:52 |
| lifeless | http://pastebin.com/d6b23fcca | 02:52 |
| jml | feature request: | 02:54 |
| lifeless | a request for a feature | 02:54 |
| jml | bzr foo --hlep should show the help for foo | 02:55 |
| poolie | it does | 02:55 |
| jml | If I can't type 'help' then I probably need it. | 02:55 |
| poolie | unless you meant literally hlep | 02:55 |
| spiv | Hmm. We have quite a few tests that rely on indirect ways to force snapshotting in knits. Which is fine (we don't want a public API for that), but maybe it deserves some explicit test infrastructure so that if the snapshotting heuristic changes we don't have to change/audit lots and lots of tests. | 02:55 |
| poolie | oic :) | 02:55 |
| lifeless | spiv: indeed. I'd already written: | 02:56 |
| lifeless | meh | 02:56 |
| lifeless | I'll finish, commit and you can review instead ;) | 02:56 |
| spiv | lifeless: ok :) | 02:56 |
| LaserJock | is there anybody specifically looking at git-bzr bridging? | 02:57 |
| lifeless | igc | 02:58 |
| LaserJock | I just had a possibly nasty idea of CVS -> git -> bzr | 02:59 |
| lifeless | why? | 02:59 |
| lifeless | cvs->git recommends cvs2svn fastexport nowadays | 02:59 |
| lifeless | and bzr-fastimport can read that directly | 02:59 |
| LaserJock | because CVS -> bzr isn't quite working and cvs->git is working for me | 02:59 |
| LaserJock | hmm, maybe I should try bzr-fastimport then | 03:01 |
| LaserJock | wait a sec though | 03:02 |
| LaserJock | why doesn't LP use bzr-fastimport then | 03:03 |
| poolie | LaserJock: i think fastimport is probably the way to go | 03:03 |
| poolie | but it would be good to just fix the bugs in reading from cvs2svn | 03:03 |
| poolie | jelmer was looking at doing git foreign branch support though | 03:04 |
| lifeless | poolie: did your fix fix my test case? I would expect not .. | 03:12 |
| poolie | sorry have not tried it yet, will now | 03:14 |
| poolie | !! | 03:15 |
| poolie | yes it did | 03:15 |
| lifeless | thought it might | 03:15 |
| poolie | i am a bit surprised; i thought this only affected the multiple extraction case | 03:15 |
| poolie | interesting | 03:15 |
| lifeless | no | 03:15 |
| lifeless | we've an awkward abstraction | 03:15 |
| poolie | it doesn't strictly do so | 03:15 |
| lifeless | the Content objects | 03:15 |
| poolie | yes | 03:15 |
| poolie | also, the higher-level check code is still really thinking in terms of knits or weaves | 03:16 |
| lifeless | ok, I'm going to commit what I have | 03:16 |
| lifeless | because I think they are useful changes to review | 03:16 |
| lifeless | and send in and move on | 03:16 |
| mwhudson | LaserJock: because fastimport is pretty new, and launchpad has been doing cvs imports since 2004? | 03:16 |
| LaserJock | mwhudson: makes sense | 03:17 |
| lifeless | also | 03:17 |
| mwhudson | not sure how well suited the fastimport is for syncs | 03:17 |
| lifeless | I haven't seen anything as strict or capable as cscvs is at at handling *ongoing* fuckage of cvs | 03:17 |
| LaserJock | ah | 03:17 |
| lifeless | there are amazingly stupid things people can do to a live cvs repository | 03:18 |
| mwhudson | yeah, if we can fix the file-created-by-merge bug cscvs starts to look quite good again for what it dos | 03:18 |
| mwhudson | (and i think this bug is created by cvs changing since cscvs was written, believe it or not) | 03:18 |
| fullermd | That's a side effect of there being amazingly stupid things people _have_ to do to a live cvs repository :) | 03:18 |
| lifeless | given it consists entirely of analysing breakage people *do* | 03:18 |
| mwhudson | !cvs bashing | 03:18 |
| ubottu | Factoid cvs bashing not found | 03:18 |
| mwhudson | :) | 03:19 |
| lifeless | fullermd: not true; choose to yes, have to - no | 03:19 |
| poolie | lifeless: so this looks like a good test for 234748; do you think i should add another closer to the case where this arose? | 03:19 |
| lifeless | poolie: uhm, my test happens to show up the bug. its a bit of a bug we don't have good tests of the behaviour on these things, neither fish nor fowl :( | 03:20 |
| poolie | well, it's pretty close to what i had in mind, except i didn't think it'd show up through that api | 03:20 |
| lifeless | poolie: I've committed and sent to the list my state | 03:25 |
| lifeless | poolie: that bug actually can lead to knit corruption on knit repositories | 03:25 |
| lifeless | (not packs though) | 03:25 |
| lifeless | jml: if you use your patched loom | 03:27 |
| lifeless | jml: and do 'bzr st --short' what happens? | 03:27 |
| jml | lifeless: traceback. I guess I do need those args after all. | 03:28 |
| lifeless | :) | 03:28 |
| jml | and maybe a test to catch that. | 03:28 |
| lifeless | mmm | 03:28 |
| lifeless | no need for the test I think | 03:29 |
| lifeless | bzr blackbox tests will exercise options | 03:29 |
| lifeless | (bzr selftest status) with loom installed should break | 03:29 |
| jml | hmm. | 03:29 |
| lifeless | oh | 03:29 |
| jml | if that's the strategy, why did I need to add a test for non-loom support? | 03:29 |
| lifeless | also you should upddate the bzr_commands in setup.py | 03:30 |
| lifeless | I'd like to someday have 'bzr selftest loom' use that metadata to also run blackbox tests that match those patterns from bzrlib core | 03:30 |
| lifeless | jml: because non-loom support is an explicit case we will not cause a fragile test on | 03:31 |
| lifeless | jml: as opposed to options from bzr itself which could change at any time | 03:31 |
| jml | lifeless: (just clarifying) even though it's covered you think it's better to have something explicit? I'm cool with that. | 03:33 |
| jml | lifeless: I've done all that now. | 03:39 |
| fullermd | OK, I'm having a hard time figuring out what -Dhpss is saying, but I get two of the "does not understand protocol 3" messages when doing a pull over the smart server when I specify a URL. | 03:42 |
| beuno | fullermd, I've been getting those for a while not with bzr.dev | 03:45 |
| fullermd | It's not the getting them; it's the getting TWO of them. | 03:46 |
| beuno | ah | 03:46 |
| fullermd | (actually, I get it with a number of other commands too, but pull's the easy one to point at) | 03:48 |
| beuno | fullermd, I get two also | 03:49 |
| beuno | (I just checked with pull) | 03:49 |
| beuno | I don't with push though | 03:49 |
| beuno | from the log, it looks like one for get, and one for open | 03:51 |
| lifeless | yay with that fix versionedfiles tests pass | 04:02 |
| fullermd | beuno: You want to file it? | 04:03 |
| beuno | what would be the best way to get a diff for a file between 2 revisions? | 04:03 |
| lifeless | 'bzr diff -r x..y' | 04:03 |
| beuno | fullermd, I don't want to take the credit :p | 04:03 |
| beuno | lifeless, right, I meant with bzrlib :) | 04:04 |
| fullermd | Well, I can't make heads or tails of -Dhpss :| | 04:04 |
| spiv | fullermd: that sounds like a bug in pull, we should avoid opening multiple connections when one will do. | 04:04 |
| fullermd | merge at least did it too. | 04:04 |
| lifeless | beuno: so do I - look at the code :P | 04:04 |
| spiv | fullermd: feel free to pastebin the ~/.bzr.log + console output, or mail it to me. | 04:04 |
| fullermd | I noticed on an attempt to merge --uncommitted over bzr+ssh. Double sin-points for 2 protocol downgrades, before telling me it wouldn't work remotely anyway :p | 04:05 |
| spiv | fullermd: or a way to reproduce | 04:05 |
| beuno | lifeless, lol, well, yes. I was hoping for some magical answer which would save me from half an hour of browsing through bzrlib, but I guess it's the only way to learn :) | 04:05 |
| fullermd | spiv: bzr init /tmp/foo ; cd /tmp/foo ; env BZR_REMOTE_PATH=bzr-1.4 bzr.dev pull bzr+ssh://localhost/tmp/foo/ | 04:06 |
| fullermd | Or 1.5, or whatever is old enough to force the downgrade. | 04:06 |
| beuno | or just pulling from LP with bzr.dev :) | 04:07 |
| spiv | fullermd: ta | 04:08 |
| spiv | fullermd: I see it, thanks! | 04:08 |
| spiv | Ooh, three connections in fact. | 04:08 |
| fullermd | Well, it was only one connection 'till *I* looked at it. That moved it to 2. Then you looked at it, and it became 3. | 04:09 |
| fullermd | Nobody else look at it! | 04:09 |
| lifeless | 37 errors left | 04:17 |
| jml | lifeless: woot. | 04:18 |
| * beuno curses loggerhead | 04:24 | |
| beuno | mwhudson, I may be wrong, but there is absolutely no easy way to get a diff for one file, with the current loggerhead code, right? I gets *all* the files changed | 04:25 |
| mwhudson | beuno: at some point, we should drink a very large amount of beer together | 04:26 |
| mwhudson | beuno: that sounds entirely plausible | 04:26 |
| rockstar | If I upgrade a parent bzr branch, is that going to break merges with the branch's children? | 04:26 |
| mwhudson | you'll need to bend the history.History interface a bit | 04:26 |
| mwhudson | rockstar: "depends" | 04:26 |
| mwhudson | i think | 04:26 |
| beuno | mwhudson, heh, I will owe you quite a few when a month in, so I'll make an effort to make that happen | 04:26 |
| beuno | mwhudson, I'm going to add that then, I need that if I'm going to do any of the things I have in mind (I've been going in circled cursing for the past 4 hours) | 04:27 |
| mwhudson | ok | 04:28 |
| mwhudson | i haven't been loggerhead-ing much today | 04:28 |
| beuno | 30 minutes to get the ajax part sorted out, 4 hours jumping around loggerhead code and looking at many # This is a bad API, remove this eventually | 04:28 |
| mwhudson | heh heh heh | 04:33 |
| lifeless | aaargh backscatter time | 04:33 |
| lifeless | rockstar: no except for the case of rich-roots | 04:33 |
| rockstar | lifeless, pack-0.92-subtree It's in great need of upgrading. | 04:36 |
| lifeless | abentley: I've come around to your way of thinking w.r.t. keyspaces; the compelling argument for me is 'making pack indices regeneratable' - but the changes are all deeper than the surface stuff | 04:38 |
| lifeless | abentley: we need to alter the knit records and up | 04:39 |
| lifeless | rockstar: there is no more rececnt format than that | 04:39 |
| rockstar | lifeless, more recent than pack-0.92-subtree ? Really? | 04:40 |
| lifeless | rockstar: there are three flavours of formats - plain, rich-root, and subtree | 04:40 |
| lifeless | pack-0.92 is the most recent subtree format | 04:40 |
| rockstar | lifeless, so no need to upgrade? | 04:40 |
| abentley | I'm glad that you agree. I'm curious about how it makes pack indices regeneratable, but I don't understand what you said afterward. | 04:40 |
| * rockstar wonders who told him to upgrade | 04:40 | |
| lifeless | rockstar: no need | 04:40 |
| lifeless | abentley: every record written to a pack file should have enough data to parse it and figure out what index to put it in etc | 04:41 |
| abentley | rockstar: I recommend downgrading to rich-root-pack. | 04:41 |
| abentley | Unless you are actually using the subtree functionality. | 04:42 |
| abentley | lifeless: Right. | 04:42 |
| abentley | Why do we need to alter the knit records? | 04:42 |
| abentley | You want to store additional data in them? | 04:42 |
| rockstar | abentley, will that break branches that need to merge back in? | 04:42 |
| lifeless | abentley: and currently they don't :(. Anyhow, short term I think I've taken a huge step towards consistent access, but deadlines | 04:42 |
| lifeless | abentley: yes, the knit records should store the full key | 04:43 |
| abentley | rockstar: Not unless they're using the subtree features. | 04:43 |
| abentley | Those features are experimental, and no one should be using them. | 04:44 |
| abentley | lifeless: Alternatively, we could store supplemental data elsewhere. Anyhow, I agree about deadlines. | 04:45 |
| rockstar | abentley, alright, so I just bzr upgrade --rich-root-pack PATH_TO_REPO ? | 04:46 |
| lifeless | abentley: storing it elsewhere makes verification harder amongst other things | 04:47 |
| abentley | rockstar: No. Because you're doing a downgrade that was supposed to be disallowed, you need to create a new branch and pull into it. | 04:47 |
| rockstar | And then push that new branch with --overwrite ? | 04:48 |
| lifeless | upgrade --rich-root-pack may well work, because it will trigger the clone-and-copy upgrade path | 04:48 |
| abentley | No, overwrite doesn't change format. | 04:48 |
| lifeless | but take a backup first :P | 04:48 |
| rockstar | lifeless, that's a given :) | 04:49 |
| spiv | fullermd: I've found the reconnection bug. It's pretty trivial, I'll send a fix in a moment. | 04:51 |
| lifeless | abentley: question for you on bundle installs - you check for presence of texts before installing... | 04:51 |
| lifeless | abentley: it would be simpler to just add them I think, trusting to the underlying store to turn duplicates into a sha check | 04:52 |
| abentley | lifeless: I don't think any of our current APIs allow this. | 04:54 |
| abentley | In many contexts, an early check could avoid plenty of I/O. But for this purpose, it would be fine. | 04:54 |
| lifeless | abentley: thanks. in point of fact add_lines explicitly allows exact match duplicates IIRC | 04:56 |
| abentley | Ah. I guess I just assumed the API would match the store characteristics. | 04:57 |
| lifeless | oh, add_lines raises RevisionAlreadyPresent | 04:58 |
| lifeless | I'll check that that is not the cast any more | 04:58 |
| lifeless | 19 | 05:16 |
| lifeless | (this is without reconcile tests being run :P) | 05:17 |
| ToyKeeper | Hmm, is bzr supposed to require x11? | 05:24 |
| lifeless | no | 05:25 |
| ToyKeeper | It looks like bzr recommends bzrtools, which recommends graphviz. apt-get follows those. | 05:25 |
| lifeless | does graphviz require x? | 05:25 |
| ToyKeeper | Yup. | 05:25 |
| lifeless | I thought it was just a rendering library | 05:25 |
| lifeless | anyhow, override apt :P | 05:25 |
| ToyKeeper | Yeah, just inconvenient. I figure I should check if it was intentional before filing a bug. :) | 05:28 |
| fullermd | graphviz can be built without requiring X, but I expect standard packages won't trim the options enough to do so. | 05:28 |
| lifeless | ToyKeeper: its a weakness in dpkg | 05:29 |
| lifeless | ToyKeeper: (I suspect) | 05:29 |
| ToyKeeper | Of the two optional dependency types, apt treats one as a requirement and ignores the other. I'd consider it a bug in apt, unless there's a hidden feature I'm missing. | 05:31 |
| lifeless | ToyKeeper: its bizarre - graphviz package says that it contains the command line tools | 05:34 |
| lifeless | ToyKeeper: and there doesn't seem to be a graphviz-nox package | 05:34 |
| RAOF | ToyKeeper: That's a deliberate design decision - Recommends is there for packages which aren't hard dependencies, but which almost all sane people will want to use. Thus, installing recommends-by-default is the new default. | 05:35 |
| RAOF | ToyKeeper: "aptitude install bzr graphviz-" will, however, install bzr without graphviz (and hence x11). | 05:35 |
| ToyKeeper | ish | 05:38 |
| ToyKeeper | It pulls in graphviz plus all deps, then removes graphviz from the list. So, 79 new packages instead of 80. :) | 05:38 |
| lifeless | ToyKeeper: thats a definite bug | 05:39 |
| lifeless | ToyKeeper: (on aptitude) | 05:39 |
| ToyKeeper | Oh, sorry. That's what apt-get does. aptitude works correctly. | 05:40 |
| RAOF | Aptitude has had recommends-by-default for longer ;) | 05:40 |
| poolie | spiv, are you away on friday the 13th? :) | 05:44 |
| spiv | poolie: <insert ominous music here> | 05:45 |
| ToyKeeper | I don't suppose there's a way to do an anonymous "bzr branch lp:foo", is there? :) | 05:49 |
| lifeless | ToyKeeper: exactly that will do it | 05:49 |
| ToyKeeper | Oh, hmm. I tried it and got a warning about logging in, then a traceback. | 05:50 |
| lifeless | the whinging is quite annoying | 05:51 |
| * ToyKeeper -> away | 05:52 | |
| poolie | there probably should be a way to turn it off... | 06:01 |
| poolie | spiv: is that a yes? please don't make me go back into canonicaladmin :) | 06:01 |
| ToyKeeper | FWIW, it was caused by a broken python2.5 package; difflib was not importable. | 06:03 |
| poolie | oh ok | 06:03 |
| poolie | so just local to your machine? | 06:03 |
| TFKyle | mm, it'd be nice if launchpad people could register lp.net and have it like sourceforge has sf.net | 06:07 |
| poolie | true | 06:08 |
| fullermd | If only they'd thought of it 11 years ago... :p | 06:09 |
| spiv | poolie: yes :) | 06:11 |
| lifeless | what the frell is it with concrete drills and epping | 06:32 |
| lifeless | !!!!!!!! | 06:33 |
| beuno | mwhudson, I'm off to bed. I've got most of the basics down for the diff-on-request branch, but I wasted a ton of time trying to figure out some of loggerhead (and bzr) inner workings. Hope to be able to upload the branch tomorrow (which will probably be your saturday, so I won't expect feedback) | 06:35 |
| mwhudson | beuno: time spent learning about innards is hardly wasted | 06:36 |
| mwhudson | beuno: i am on holiday my monday, btw | 06:36 |
| mwhudson | though i guess that's your sunday | 06:36 |
| beuno | mwhudson, yes, but it frustrates me when 7 hours go by, and I don't have much code to show for it :/ | 06:37 |
| mwhudson | feel free to send me email about anything you like :) | 06:37 |
| beuno | ah, well, that will give me more time to polish | 06:37 |
| bimberi | lifeless: Is the railway line (to Chatswood iirc) finished? | 06:37 |
| beuno | mwhudson, very cool, thanks. Enjoy your weekend+holiday@ | 06:37 |
| poolie | lifeless: your test doesn't actually fail in trunk afaics | 06:38 |
| poolie | is it meant to? | 06:38 |
| lifeless | poolie: the bundle I mailed? contains its own fix | 06:39 |
| lifeless | bimberi: its not the source of the noise, buut no | 06:39 |
| poolie | i applied just the test into a branch from trunk and it does not fail | 06:39 |
| lifeless | poolie: *blink* let me check | 06:39 |
| lifeless | poolie: bah I must have fucked it while shrinking it | 06:40 |
| poolie | i was trying to write something based on it that would check get_lines and wondered what i was doing wrong :) | 06:41 |
| lifeless | checking why now | 06:43 |
| lifeless | here is why: | 06:44 |
| lifeless | (Pdb) merge_content.text() | 06:44 |
| lifeless | ['prelude \n', 'line'] | 06:44 |
| lifeless | (Pdb) content.text() | 06:44 |
| lifeless | ['line\n'] | 06:44 |
| lifeless | (Pdb) | 06:44 |
| lifeless | so I was wrong - you have to pass in left_matching_blocks to add_lines() to trigger the bug via the top level api | 06:45 |
| lifeless | and the only thing that does that is bundles | 06:45 |
| poolie | hm | 06:45 |
| poolie | this sounds like a kinda different bug then | 06:45 |
| lifeless | mwhudson: btw, is all the code import spam needed? | 06:45 |
| lifeless | poolie: the one I pastebinned earlier definitely failed | 06:46 |
| lifeless | I will reinstate that test | 06:46 |
| mwhudson | lifeless: unclear, i guess | 06:47 |
| mwhudson | it's probably not necessary for _you_ to get it :) | 06:48 |
| lifeless | mwhudson: well, if you think about queue management, if the queue is centralised and gui managed, telling all the operators of the queue on any change is, well, overkill | 06:49 |
| lifeless | 'queue died' is interesting | 06:49 |
| mwhudson | lifeless: it should be a feed i guess | 06:49 |
| lifeless | uhm, I guess I mean 'what happend to reporting exceptions' :) | 06:49 |
| mwhudson | lifeless: thumper did all the email stuff, blame him | 06:50 |
| mwhudson | :-p | 06:50 |
| lifeless | thumper: this is me blaming you | 06:50 |
| lifeless | poolie: ok, have a verified test now | 06:58 |
| lifeless | and mailed | 07:01 |
| lifeless | hmm, it probably wants a couple of lines trimmed, but thats minor | 07:02 |
| lifeless | (cause I just realised I don't use the sha1) | 07:02 |
| * spiv ducks out to the shops | 07:29 | |
| poolie | lifeless: http://pastebin.ubuntu.com/15732/ | 07:33 |
| luks | which I worked on in the pre-coding time into Picard itself. | 07:36 |
| luks | er, sorry :) | 07:37 |
| lifeless | poolie: http://pastebin.com/d47e68554 enjoy | 08:11 |
| thumper | lifeless: feel free to filter it :) | 08:25 |
| lifeless | thumper: I will but it makes seeing the wheat harder | 08:48 |
| lifeless | night all | 08:48 |
| slangasek | supposing that I have a pair of CVS repositories (one for upstream, one for Debian packaging) and I'd like to migrate them to bzr. Are there any tricks available that might let me do a one-time import and merge? | 09:02 |
| poolie | slangasek: would suggest importing them separately then merging i guess | 09:03 |
| slangasek | poolie: if my Debian CVS repo happens to be a full-source repo rather than a debian-only repo, am I SOL on that count? :) | 09:04 |
| poolie | are there any connections, like common tags between them? | 09:06 |
| poolie | or are they just totally unrelated (but similar) histories? | 09:06 |
| slangasek | I could reconcile the tags between them if that would help | 09:07 |
| slangasek | poolie: so would that help? :) | 09:15 |
| poolie | sorry, i don't have any good suggestions for how to merge them | 09:18 |
| slangasek | so you were just teasing me? :) | 09:23 |
| slangasek | well, I think I could probably get away with just ignoring the upstream repo altogether, if worst comes to worst | 09:24 |
| slangasek | since upstream is dead :P | 09:24 |
| enquest | my project wont update due some errors... I got two files with "RM or RN" What do these mean? | 09:31 |
| Pilky | enquest: I'd guess remove and rename | 09:31 |
| spiv | enquest: see "bzr help status-flags" | 09:32 |
| === thekorn__ is now known as thekorn | ||
| enquest | I already did that "RN www/media/admin/js/tiny_mce => www/media/admin/js/tiny_mce.OTHER@" | 09:34 |
| enquest | no tiny_mce.OTHER@ is there nor tiny_mce | 09:34 |
| enquest | as I removed them | 09:34 |
| poolie | night all | 09:35 |
| enquest | now I get Path conflict: www/media/admin/js/tiny_mce.OTHER / www/media/admin/js/tiny_mce.OTHER | 09:36 |
| igc | night all - have a good weekend | 09:37 |
| dragffy | hi all | 11:05 |
| dragffy | trying to push a branch on to launchpad but it keeps failing with an error, can anyone help please? | 11:06 |
| dragffy | $ bzr push lp:~dragffy/grope/dev | 11:06 |
| dragffy | bzr: ERROR: Target directory lp:~dragffy/grope/dev already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway. | 11:06 |
| thumper | where are the archives of the bzr mailing list? | 11:07 |
| spiv | dragffy: have you tried "bzr push --use-existing-dir lp:~dragffy/grope/dev"? | 11:07 |
| thumper | nm, found it | 11:09 |
| dragffy | hi spiv i tried that, but when I looked in launchpad it still said that the branch hadn't been pushed to | 11:21 |
| dragffy | i'm creating a new hosted branch | 11:21 |
| thumper | dragffy: had you interrupted it before? | 11:24 |
| thumper | I've forgotten how to run the bzr tests :( | 11:24 |
| LarstiQ | thumper: ./bzr selftest pattern? | 11:25 |
| thumper | LarstiQ: thanks | 11:25 |
| thumper | dragffy: have you done a "bzr lp-login" ? | 11:27 |
| jimcooncat | I'm having a hell of a time trying to figure this out. Is there a really easy way to get started? A mature plugin for nautilus or gedit? | 11:28 |
| dragffy | thumper: i didn't interrupt it | 11:28 |
| dragffy | thumper i didn't do bzr lp -login | 11:29 |
| dragffy | thumper: but i did do: bzr launchpad-login | 11:29 |
| dragffy | is that ok? | 11:29 |
| thumper | dragffy: yeah | 11:29 |
| dragffy | i just did that the one time | 11:29 |
| dragffy | so it seems it found me on launchpade and found my ssh key | 11:29 |
| thumper | hmm.. | 11:30 |
| thumper | that is very strange | 11:30 |
| dragffy | not really, i'm always unlucky! | 11:30 |
| thumper | dragffy: how about calling bzr with -Dhpss and looking in your .bzr.log file | 11:30 |
| dragffy | i've tried deleting the branch several times to begin again | 11:30 |
| dragffy | thumper: i'll try | 11:30 |
| dragffy | seems like it worked this time | 11:33 |
| dragffy | perhaps bzr liked it if i waited | 11:34 |
| dragffy | i mean launchpad | 11:35 |
| jimcooncat | I have bzr-gtk installed, but no apparent nautilus integration. How to? | 11:35 |
| dragffy | olive | 11:35 |
| thumper | jimcooncat: sorry, I use KDE | 11:35 |
| leroux | Was wondering if anyone can help me - I develop on my local box that doesn't have a live ip, then I use bzr rspush to push my changes to a dev server on the net somewhere. Now I made some minor changes there, committed them and merged it in to my local repository using bzr merge. But now if I try and use bzr rspush from my local box it tells me that the local branch is not a newer version of the remote branch. How can I get back to the point wh | 11:36 |
| dragffy | thumper: kde4? | 11:36 |
| jimcooncat | dragffy: I have olive up, but there's no help. website provides no guidance I can find | 11:36 |
| thumper | dragffy: sometimes | 11:36 |
| dragffy | mm yeah it's pretty new | 11:36 |
| thumper | rspush? | 11:36 |
| dragffy | jimcooncat: i don't know of anyway to integrate it with nautilus | 11:37 |
| dragffy | jimcooncat: but the command line is fairly simple | 11:37 |
| thumper | leroux: does your other machine have bzr on it? | 11:38 |
| leroux | thumper: yes. I used it to commit my changes ;) | 11:38 |
| thumper | leroux: did you commit the merge? | 11:38 |
| leroux | thumper: yes.. | 11:38 |
| leroux | thumper: I've also committed afterwards locally | 11:39 |
| leroux | thumper: see.. I want to get the changes I've made after successfully merging back onto the other machine, but can't push there now because bazaar says this version isn't newer | 11:40 |
| thumper | leroux: I'm not familiar with rspush, is there a particular reason you are using it rather than push? | 11:40 |
| james_w | jimcooncat: the nautilus integration is separate from bzr-gtk. The last I looked the nautilus stuff had bitrotted though. | 11:41 |
| leroux | thumper: yes - it is much much faster and it automatically creates/updates/whatever the working copy on the remote box | 11:41 |
| jimcooncat | james_w thanks. I have an idea for a project but no files yet, and I want to use version control. Should I write my first file first, then bzr-add? | 11:42 |
| thumper | leroux: sorry not sure, perhaps james_w may know | 11:42 |
| leroux | thumper: it is from bzrtools | 11:42 |
| leroux | thumper: ok, thanks | 11:42 |
| james_w | jimcooncat: yup, you can start with "bzr init foo" to create a branch "foo" to work in, then when you are ready to commit some work "bzr add && bzr commit" | 11:43 |
| james_w | leroux: did you "bzr commit" locally after the "bzr merge"? | 11:44 |
| leroux | james_w: yes. and then I made some minor changes and then I committed again | 11:44 |
| james_w | leroux: also "bzr missing" will tell you what revisions are different on each side. | 11:44 |
| dragffy | thumper: thanks for your help | 11:45 |
| james_w | leroux: "bzr missing --theirs-only" needs to be empty to push. | 11:45 |
| leroux | james_w: it says theirs is empty, mine has 4 new commits (a change I made here before merging, the merge and two minor test commits I made afterwards in an effort to get bzr to realise that yes - this is the newer one. | 11:47 |
| james_w | leroux: strange, does "bzr push" work, or does it refuse in the same way as rspush? | 11:48 |
| leroux | james_w: I'll check now.. | 11:48 |
| leroux | james_w: btw, could it be a time and timezone thign? | 11:48 |
| james_w | don't think so. | 11:48 |
| james_w | it doesn't use timestamps to figure out what's newer | 11:48 |
| Pieter | How should I send in fixes to the bzr-fastimport thing? bugtracker, register a branch, send patches somewhere? | 11:49 |
| james_w | Pieter: whatever is easiest for you, you can email bazaar@lists.canonical.com with [fastimport:MERGE] in the subject, or do it through launchpad. | 11:50 |
| leroux | james_w: odd. bzr push worked. must be a bug in rspush | 11:52 |
| leroux | james_w: how do I update the working tree manually again? | 11:52 |
| james_w | leroux: ssh to the machine and run "bzr update" in the branch | 11:52 |
| jimcooncat | ok, so I've got two versions of my simple hello.sh committed, "bzr log" looks good, but "bzr diff hello.sh" shows no output. | 11:53 |
| leroux | james_w: thanks. that sorted it. hopefully after this rspush won't be confused any more. | 11:53 |
| james_w | jimcooncat: "bzr diff" will show you differences between what you just committed and what is currently in the file, which is nothing if you haven't changed it since committing | 11:53 |
| james_w | if you want to see the changes between the first and second version use "bzr diff -r 1..2" | 11:54 |
| jimcooncat | james_w thanks. I might figure this out yet. | 11:54 |
| jimcooncat | ok, now stuff is showing up in olive. thanks for the help | 11:56 |
| james_w | no problem | 11:57 |
| jimcooncat | one more please, to rename my file, do I just mv it, or do I have to use a bzr command? | 11:58 |
| Pieter | How do I edit the log message of an earlier commit? | 11:58 |
| Kinnison | IMO you don't | 11:59 |
| Kinnison | but there may be a way | 11:59 |
| james_w | jimcooncat: "bzr mv" | 12:00 |
| james_w | it will move the file as well | 12:00 |
| jimcooncat | good. olive rename feature doesn't seem to work | 12:00 |
| james_w | if you have already moved it then doing the "bzr mv" should work it out anyway (there is an --after flag if it doesn't) | 12:00 |
| james_w | Pieter: that's not possible. | 12:01 |
| james_w | Pieter: if it was the last revision and you haven't pushed it yet then uncommitting and committing again will allow you to do it, but if you the revision is already public it is a bad idea. | 12:02 |
| === yacc__ is now known as yacc | ||
| emgent | someone remember how to set profile on bzr? | 12:24 |
| luks | 'profile'? | 12:25 |
| emgent | luks: yeah, "name surname email" | 12:25 |
| luks | bzr whoami | 12:25 |
| emgent | cool true. | 12:25 |
| emgent | thanks | 12:25 |
| Pieter | james_w: yes, I know, I just want to clear up the logs before pushing them | 12:35 |
| Pieter | Can I then export some revisions as plaintext and apply them one at a time? | 12:53 |
| vadi2 | Is it possible to get olive on windows? | 14:05 |
| jelmer | vadi2, yes, see the wiki page for bzr-gtk | 14:06 |
| jelmer | there's a installer linked from there | 14:06 |
| vadi2 | Found it, thank you | 14:07 |
| vadi2 | Odd question, but I don't suppose you know how to install a decent gtk theme on windows? | 14:08 |
| jelmer | no, sorry | 14:15 |
| Pieter | Just did my first launchpad merge proposal \o/ | 14:43 |
| james_w | Pieter: cool, thanks. How is the revision you refer to broken? | 14:51 |
| Pieter | james_w: it crashes with bzr: ERROR: not well-formed (invalid token): line 16, column 56 | 14:52 |
| Pieter | there's a more verbose message if you try to get the revision tree | 14:53 |
| pickscrape | Is the launchpad merge stuff really bundle buggy in disguise? | 14:55 |
| james_w | pickscrape: not really | 14:56 |
| james_w | though the do fulfil a similar need | 14:56 |
| Pieter | james_w: http://bzr.pastebin.com/mea883cc | 15:00 |
| nedosa | hi, have a question about bzr-svn | 15:02 |
| jelmer | nedosa, hi | 15:03 |
| nedosa | are merge-commit logs supposed to appear in the svn repo | 15:03 |
| james_w | Pieter: I've not seen that error before, it may be a bug in the converter that was used to create the branch I guess. | 15:03 |
| nedosa | jelmer, hi | 15:03 |
| jelmer | nedosa: no, they're not supposed to appear unless you're viewing the repo with bzr itself | 15:04 |
| nedosa | aaah, excellent | 15:04 |
| jelmer | nedosa: svn can't represent merge commits | 15:04 |
| nedosa | jelmer, so, bzr log svn://... should give me merge-commit logs | 15:06 |
| jelmer | yes, but "svn log svn://" won't | 15:06 |
| nedosa | jelmer, trying to atm, but can't see merge logs, is that maybe an svn 1.5 feature ? | 15:08 |
| jelmer | nedosa: What are you trying specifically? | 15:10 |
| nedosa | jelmer: so, i've used bzr svn-import to set up a bzr repo, then created a trunk branch off that | 15:11 |
| nedosa | jelmer:, did a dummy commit, merged the two, then pushed the merge into the svn repo | 15:11 |
| nedosa | now, both bzr and svn repo are in revno 607 | 15:12 |
| nedosa | but only the bzr repo display the merge-commit log message | 15:12 |
| jelmer | nedosa: The svn repo doesn't contain the merged revision itself, only a pointer to it | 15:13 |
| jelmer | try viewing the svn branch in "bzr viz" | 15:13 |
| nedosa | whether i use svn or bzr for the svn repo I only get 1 commit message for that revision | 15:13 |
| nedosa | jelmer: trying... | 15:13 |
| nedosa | bzr vis --limit=1 svn+ssh:// ... crashes... :( | 15:15 |
| jelmer | does it work ok on the bzr repo? | 15:16 |
| nedosa | jelmer: yeah, viz works great on the bzr repo | 15:18 |
| jelmer | nedosa, please file a bug | 15:19 |
| jam | jelmer: doing 'log' on the svn repo won't try to access the local bzr repo | 15:19 |
| jam | so all it has is a dangling pointer | 15:19 |
| jam | I wonder if "viz" is confused by the ghost reference | 15:19 |
| jelmer | jam: Yeah, I know - I was just expecting bzr log to indicate ghosts | 15:19 |
| jelmer | jam: viz does show ghosts | 15:19 |
| nedosa | jelmer: will do | 15:19 |
| jam | jelmer: I believe it gives a parent reference, but doesn't show a node for it | 15:19 |
| jam | so if you have --show-ids, you'll see the parent referenced | 15:20 |
| jam | but otherwise it hides ghosts, IIRC | 15:20 |
| jelmer | jam: ah, ok | 15:21 |
| nedosa | k, for reference, i sue bzr 1.5 in hardy, with bzr-svn 0.4.10 | 15:22 |
| nedosa | will file a bug | 15:22 |
| jelmer | thanks :-) | 15:24 |
| nedosa | jelmer: this behaviour is pretty important to us, so is this something that should be supported and is a bug, or something difficult to implement by bzr-svn ? | 15:26 |
| jelmer | nedosa: what specific behaviour are you looking for? | 15:27 |
| jelmer | nedosa: bzr-svn does do merge tracking | 15:27 |
| jelmer | nedosa, but it won't push right hand side revisions into svn, just pointers to those revisions | 15:28 |
| nedosa | jelmer: yeah, i meant merge tracking | 15:28 |
| nedosa | jelmer: as long as a log appears, it should be sufficient | 15:29 |
| jelmer | nedosa: to see the log for those right hand side revisions you need to fetch them from some bzr branch first | 15:30 |
| jelmer | since they're not pushed into svn - only a pointer to them | 15:31 |
| jelmer | e.g. you can do "bzr branch svn://repo-you-pushed-to-earlier/" on some other machine | 15:34 |
| jelmer | and then "bzr pull url-to-your-bzr-repo" and it will fill in those right hand side revisions | 15:35 |
| nedosa | jelmer: if I try and pull, it says there are no revisions | 16:12 |
| nedosa | which is to be expected, since both svn and bzr repos are in sync | 16:12 |
| vadi2 | Does anyone know why would a "Authentication type (password) not permitted." be given on windows? From this log: http://pastebin.com/m1224f4de | 16:14 |
| fullermd | Well, pretty much what it says... | 16:15 |
| fullermd | bazaar.launchpad.net Bad authentication type (allowed_types=['publickey']) | 16:15 |
| fullermd | LP only allows publickey auth. | 16:15 |
| vadi2 | ? | 16:15 |
| vadi2 | The ssh key was generated from the putty thing as the instructions say | 16:15 |
| fullermd | Is it uploaded to launchpad? | 16:15 |
| vadi2 | Yes, it's set in his profile (https://launchpad.net/~dazedxjoker) | 16:16 |
| jam | vadi2: I think you have to manually add the ssh-key to pageant | 16:17 |
| jam | and then everything should work | 16:17 |
| vadi2 | What's that, and how? | 16:17 |
| jam | There should be an icon in your sys tray, right click, add key, find the key you generated | 16:17 |
| jam | and type in the password (if you gave it one) | 16:17 |
| jam | You may need to "Start/Putty/Pageant" if it isn't already running | 16:18 |
| jam | (I have it set to start on windows startup on my machine) | 16:18 |
| vadi2 | Ok, we got it. Thank you very much | 16:19 |
| jam | did that work? | 16:19 |
| vadi2 | yep | 16:19 |
| matkor | Hi ! If I want revert given commit I do: bzr merge -r <rev>..<rev_pre> ./ | 16:26 |
| matkor | What if I want revert only chnages made in one file ? | 16:26 |
| Pilky | matkor: bzr revert <file> -r <rev> | 16:34 |
| james_w | matkor: does it work to pass the filename to the merge command? | 16:34 |
| james_w | otherwise you could do the merge and then "bzr revert" all the other files, but I realise that is not the easiest thing to do. | 16:35 |
| matkor | james_w: No bzr merge refuses to get filenames as parameteres ... | 16:37 |
| matkor | Pilky: I will have file at version <rev> ... bu I want only exclude changes made _between_ <pre_rev> and <rev> ... | 16:38 |
| Pilky | and your current version is greater than <rev> I assume | 16:39 |
| matkor | james_w: Not bad idea when changes are in few files ... I was thinking about bzr diff -r b..a -p1 | patch -p1 | 16:39 |
| james_w | that would work | 16:40 |
| james_w | it's pretty much what bzr is effectively doing. | 16:40 |
| matkor | Pilky: correct .. I am tring to remove sb mistake ... | 16:40 |
| matkor | OK. bzr diff | patch seems to work for me- only you have to be in topmost directory in working tree :) Thanks a lot for your help | 16:43 |
| dato | matkor: | patch -d `bzr root` ;) | 16:44 |
| matkor | dato: ha ! I will test it next time :) Thanks to tou , too :) | 16:44 |
| matkor | c'ya l&gs | 16:56 |
| === kiko is now known as kiko-fud | ||
| jelmer | Nephyrin, Ah, I think you need "bzr fetch" these days | 18:03 |
| jelmer | nedosa, Ah, I think you need "bzr fetch" these days | 18:03 |
| lamont | from the "not sure which manpage to look at" department: if I want a command to run every commit, how do I do that? | 19:19 |
| beuno | lamont, post-commit-hook? | 19:27 |
| lamont | sounds right. | 19:27 |
| lamont | and that's documented where? | 19:27 |
| * beuno looks | 19:27 | |
| beuno | lamont, http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#hooks | 19:28 |
| lamont | tjamls | 19:29 |
| lamont | thanks, even | 19:29 |
| beuno | welcome :) | 19:29 |
| lamont | and if I want to set the hook for the branch, rather than the user, is there a plugins directory in the branch? or just back in ~/.bazaar/plugins? | 19:32 |
| beuno | I don't think you can set a hook for a specific branch. I may be wrong though, I haven't played with them very much. | 19:34 |
| beuno | (no plugins per branch, that's for sure) | 19:34 |
| dato | well | 19:34 |
| dato | bzr-cia is per-branch | 19:34 |
| dato | but I guess | 19:34 |
| dato | it runs for every branch, and only acts if it's configured | 19:34 |
| beuno | right, it's a plugin-config rather then a bzr one | 19:35 |
| beuno | you may be able to write a plugin that runs hooks on the specified branches :p | 19:37 |
| === kiko-fud is now known as kiko | ||
| fdv | Hi. I was trying to 'co' a repository from an svn repo using 'bzr co svnrepo bzrrepo', when, after a long time, bzr failed with 'bzr: ERROR: exceptions.KeyError' on a plain filename with only [a-zA-Z./]. Does anybody know why this happens (and if there is a way to work around it)? | 20:20 |
| beuno | fdv, can you pastebin the full traceback? | 20:20 |
| fdv | beuno: most of it, I guess :) | 20:21 |
| fdv | http://rafb.net/p/MZ74fW96.html | 20:22 |
| beuno | looks like a bzr-svn error | 20:23 |
| beuno | jelmer, around? | 20:23 |
| === mw is now known as mw|food | ||
| Jc2k | fdv: what version of bzr-svn are you using, also what version of bzr | 20:25 |
| Jc2k | does it happen if you bzr branch svnrepo bzrrepo? | 20:26 |
| Jc2k | also, is there a public copy of this repo so we can recreate it? | 20:26 |
| jelmer | Yeah, I suspect this is a bug that was fixed in 0.4.10 | 20:26 |
| fdv | bzr-svn is 0.4.9-1, and bzr is 1.3.1-1 | 20:26 |
| fdv | ah | 20:26 |
| fdv | Jc2k: unfortunately, this is a closed repo | 20:27 |
| fdv | it's rather big, if that matters | 20:27 |
| fdv | 1.5G | 20:27 |
| fdv | took me about 1-1.5 hours to get to this point | 20:27 |
| Jc2k | fdv: i converted a 2gb repo the other day ;D | 20:27 |
| fdv | nice | 20:27 |
| fdv | good to know it works | 20:27 |
| Jc2k | http://bzr-mirror.gnome.org | 20:28 |
| fdv | what's the difference between co and branch in this case? | 20:28 |
| Jc2k | it was a guess, but jelmer is the expert | 20:28 |
| jelmer | Jc2k: Nice, I wasn't aware of that :-) | 20:28 |
| jelmer | Jc2k: (bzr-mirror.gnome.org) | 20:28 |
| Jc2k | jelmer: my pet project :) its switched off right now, but i have a bot the issues a bzr pull in response to the svn-commits mailing list :) | 20:29 |
| Jc2k | jelmer: (thats why i was interested in a speedy svn-import command :)) | 20:29 |
| fdv | beuno, Jc2k, jelmer: thanks for your help, I'll try with a newer bzr-svn | 20:30 |
| jelmer | Jc2k: (-: | 20:31 |
| Jc2k | jelmer: speaking of which i have a log... | 20:32 |
| jelmer | Jc2k: What sort of log? | 20:34 |
| fullermd | It's big, it's heavy, it's wood. | 20:34 |
| Jc2k | jelmer: we were talking about bzr svn-import taking a long time to "top up" and existing clone of an svn repo | 20:34 |
| Jc2k | jelmer: you asked for -Dtransport | 20:34 |
| jelmer | Jc2k, ah, right | 20:35 |
| jelmer | Jc2k, can you mail it to me? I'm heading out in a few minutes | 20:35 |
| Jc2k | sure | 20:35 |
| beuno | fullermd, Canonical should hire you just to stick around and comment, this is (odd, I know) the channel that makes me laugh the most | 20:37 |
| fullermd | If you actually find my randomness funny, that should seriously worry you about your mental state ;) | 20:39 |
| fdv | jelmer: I still get the keyerror using 4.10 :p | 20:40 |
| fdv | do I need to delete the cache or something? | 20:40 |
| Jc2k | fdv: try bumping your bzr version as well | 20:41 |
| fdv | Jc2k: I did, had to :) | 20:41 |
| fdv | bzr-svn required >= 1.4 | 20:41 |
| fdv | I'm running 1.5 now | 20:41 |
| Jc2k | ah, nm then ;D | 20:41 |
| fdv | :) | 20:42 |
| beuno | fullermd, well, I'd rather not go into details and enjoy it :p | 20:42 |
| nekohayo | hey there, I have some silly questions for you folks :) | 20:43 |
| nekohayo | 1) is merging at the same time as other changes a bad idea? | 20:44 |
| nekohayo | 2) what about merging and changing some of the lines that came from the merge? | 20:44 |
| nekohayo | will these kind of actions break/corrupt history, or create a spatiotemporal void that will suck in anything in a radius of 30 km? | 20:45 |
| pickscrape | Make sure you don't commit any anticode. | 20:45 |
| statik | nekohayo, changing lines after the merge and before committing is fine. it's a great time to run tests and fix any code that did not merge correctly | 20:47 |
| statik | nekohayo, i think it's better to commit or shelve any local changes that you have before merging in new stuff though | 20:47 |
| nekohayo | statik: what do you mean by shelve? | 20:51 |
| statik | nekohayo, the bzrtools plugin has a shelve command which allows you to set aside uncommitted changes | 20:52 |
| nekohayo | statik: and won't changing lines right after merging (but before committing the merge) corrupt the thing, spurring conflicts all the time when you merge in other directions? | 20:52 |
| beuno | nekohayo, not at all, I do that all the time. In fact, it's a requisite to solve conflicts | 20:53 |
| fullermd | Now that said, I generally restrict myself to doing the minimum necessary to clean up conflicts right after merges. Most of the times I've done more, I've wished later I did them in another rev. | 20:54 |
| beuno | right, that's a better practice | 20:57 |
| beuno | but doing so won't raise hell, if that's what you where aiming at | 20:57 |
| === mw|food is now known as mw | ||
| fdv | hm. now it seems the co from svn comes further (with bzr 1.5 and bzr-svn 0.4.10), but there seems to be a bug somewhere as memory is just consumed, very quickly, until it's depleted the box' resources | 21:03 |
| fdv | I'd think 2G memory and 3G swap should be enough :p | 21:05 |
| Jc2k | fdv: there is a leak in the subversion python bindings | 21:05 |
| Jc2k | fdv: what distro you running? | 21:05 |
| Jc2k | (i have a deb for etch i could throw you) | 21:05 |
| fdv | Jc2k: hardy heron | 21:06 |
| Jc2k | really, wow... | 21:07 |
| fdv | ? | 21:07 |
| fdv | how's that wow? :) | 21:07 |
| Jc2k | fdv: hardy has the fix.. that might even have been were i robbed the diff from when making my custom etch deb | 21:07 |
| fdv | I guess it's the most mainstream distro around these days ;) | 21:07 |
| Jc2k | fdv: so the wow was oh god, whats leaking now ;D | 21:07 |
| fdv | aw | 21:08 |
| fdv | hm.. | 21:08 |
| jelmer | I haven't backported all memory leak fixes from svn 1.5 into the hardy package | 21:10 |
| fdv | I guess running this under valgrind would bring my box to a grinding halt... | 21:12 |
| Jc2k | :) you really need to try subversion 1.5 if you want this right now.. | 21:12 |
| fdv | :p | 21:12 |
| Jc2k | i wonder if it will play nice under jhbuild.. | 21:12 |
| fdv | is it unproblematic to run a 1.5 client against a 1.4 repo? | 21:13 |
| fdv | guess so | 21:13 |
| Jc2k | actually no, its build to allow that | 21:14 |
| Jc2k | *built | 21:14 |
| fdv | I hust remember having some issues in an early version with a local copy worked with with a newer version, after which the previous wouldn't work | 21:15 |
| fdv | but that's of course locally | 21:16 |
| * Jc2k tries to find a subversion 1.5 download to set up a jhbuild cage | 21:18 | |
| === brilliantnut is now known as brilliantout | ||
| fdv | I still get the keyerror exception.. :p | 22:14 |
| fdv | even after removing svn-cache | 22:14 |
| fdv | jelmer: any ideas? | 22:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!