| lifeless | mtaylor: its the older form of shelve | 00:02 |
|---|---|---|
| lifeless | mtaylor: for folk with old shelves they need to get ack | 00:03 |
| Peng_ | Or for people on Windows, right? | 00:09 |
| garyvdm | Hi - I'm getting an error trying to commit which is quite weird. | 00:21 |
| garyvdm | http://paste.ubuntu.com/202463/ | 00:21 |
| garyvdm | Could not acquire lock "/home/garyvdm/qbzr/wd/qbzr/.bzr/checkout/dirstate": (11, 'Resource temporarily unavailable') | 00:21 |
| garyvdm | There is nothing that I am aware of that could be holding a lock. | 00:22 |
| garyvdm | Nothing running that is. | 00:22 |
| garyvdm | Ah - never mind - I had a bzr runinng in my ide that was stoped in pdb that was holding the lock. | 00:24 |
| poolie | hello | 00:27 |
| poolie | jam, thanks for the analysis of 390745 | 00:31 |
| poolie | jml/thumper/mwh: I'm thinking about doing "reconfigure --stacked-on" or --unstacked soon | 00:38 |
| poolie | robert questions whether this is a good use of time or not | 00:39 |
| poolie | any opinions? | 00:39 |
| mwhudson | poolie: YES PLEASE | 00:39 |
| poolie | k | 00:42 |
| thumper | poolie: how would that interact with LP? | 00:42 |
| igc | morning | 00:43 |
| poolie | hello igc | 00:43 |
| poolie | thumper: um | 00:43 |
| igc | hi poolie, thumper | 00:44 |
| thumper | poolie: as in, reconfiguring a stacked LP branch | 00:44 |
| thumper | hi igc | 00:44 |
| poolie | it would work over hpss to let you configure branches to be either stacked or unstacked | 00:44 |
| poolie | not sure what you're asking | 00:44 |
| thumper | poolie:would it pull the necessary revisions from the stacked branch? | 00:44 |
| thumper | poolie: how about the ability to override the suggested stacking branch? | 00:44 |
| poolie | yes, it would potentially copy a lot of data when making the branch standalone | 00:45 |
| thumper | poolie: is incremental reconcile very hard? | 00:45 |
| poolie | lifeless estimates several days | 00:46 |
| lifeless | thumper: its tricky; gotta copy some data exclude others while simultaneously altering it | 00:47 |
| thumper | I'd say that is more important than playing with stacking right now | 00:48 |
| thumper | IMHO | 00:48 |
| thumper | or | 00:48 |
| thumper | some optimisations for reconcile on 2a formats | 00:49 |
| thumper | we're wanting to move more internal teams to the 2a format | 00:49 |
| thumper | and james_w's ubuntu branches | 00:49 |
| poolie | ok, that's useful feedback | 00:49 |
| poolie | though it's not necessarily either/or | 00:50 |
| thumper | heh | 00:50 |
| thumper | no | 00:50 |
| thumper | we want everything, and a pony | 00:50 |
| poolie | in that i'd need to page in a lot of robert's state to do renconcile | 00:50 |
| jml | delicious ponies. | 00:50 |
| poolie | but i can do the stacking thing fairly quickly | 00:50 |
| thumper | reduced swapping is always a win | 00:51 |
| thumper | I'd still like the ability to tell the bzr client not to stack no matter what LP suggests | 00:51 |
| thumper | which we can't do right now | 00:51 |
| lifeless | the streaming fetch bug is highest IMO | 00:52 |
| lifeless | reconcile is a pain, can't merge for lp developers is a blocker | 00:52 |
| lifeless | other teams have /way/ fewer devs per branch, which makes transition much easier. Also smaller history. | 00:52 |
| thumper | yeah | 00:53 |
| thumper | +1 on streaming fetch | 00:53 |
| spiv | lifeless: as in inventory deltas, or do you mean something else? | 00:54 |
| mwhudson | i was assuming reconfigure --unstacked/--stacked-on wouldn't be especially hard | 00:54 |
| poolie | me either | 00:54 |
| lifeless | spiv: https://bugs.edge.launchpad.net/bzr/+bug/390563 | 00:54 |
| ubottu | Ubuntu bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged] | 00:54 |
| poolie | so easy a manager could do it | 00:54 |
| thumper | poolie: :) | 00:54 |
| thumper | poolie: also a definitive "don't stack" flag should be easy too right? | 00:54 |
| lifeless | mwhudson: the library call to change already takes care of fetch; more problematic is making a new repo when making a shared repo branch into a stacked branch | 00:55 |
| lifeless | thumper: don't stack may require smart server verb changes. FWIW | 00:55 |
| lifeless | thumper: but is a don't stack flag needed ? | 00:55 |
| thumper | lifeless: I thought we decided a while ago that stacking was determined entirely client side | 00:55 |
| poolie | so, seriously | 00:55 |
| poolie | i have to make some calls today | 00:55 |
| lifeless | thumper: I know the lp-code team have occasion to use it for testing, but outside that group? | 00:56 |
| poolie | i was hoping i could do one or the other of them in the time i do have today | 00:56 |
| thumper | lifeless: for unrelated branches, it is useful | 00:56 |
| thumper | although, perhaps limited use | 00:56 |
| thumper | poolie: pick one an do it! | 00:56 |
| thumper | :) | 00:56 |
| lifeless | thumper: /may/ require verb changes ;) | 00:56 |
| lifeless | thumper: we have more verbs doing more things, now. | 00:56 |
| thumper | lifeless: is one "JFDI" ? | 00:57 |
| lifeless | for a small hack, I'd most like to see network activity not overwriting stuff when there is no progress bar. Or something like that. Its a very visible ugliness | 00:57 |
| poolie | lifeless: it's high on my list too | 00:58 |
| lifeless | mwhudson: the bzr log from codehosting | 00:59 |
| lifeless | mwhudson: is it safe to attach to the bug, or do you think there are things we'll want kept secret in them ? | 01:00 |
| mwhudson | lifeless: i think it's pretty unlikely there's anything sensitive in there | 01:00 |
| igc | poolie: ready for a call soon? | 01:04 |
| Peng_ | Yep, pushing 2a -> 1.9rr over hpss isn't very fun. 22 seconds, while 2a -> 2a is 6. | 01:04 |
| Peng_ | (For 11 revisions of loggerhead.) | 01:05 |
| poolie | igc, yes, let me get a couple of things closed here | 01:05 |
| poolie | will call you in 5? | 01:05 |
| Peng_ | Still usable, of course, but it doesn't make dogfooding very fun. | 01:05 |
| igc | sure | 01:07 |
| lifeless | Peng_: indeed | 01:07 |
| Peng_ | Well, I could upgrade lp:loggerhead to 2a when nobody's looking, and it would take them a while to figure it out... :D | 01:09 |
| lifeless | I wouldn't | 01:09 |
| lifeless | not till we fix the current set of critical bugs | 01:09 |
| Peng_ | What is the current set of critical bugs? | 01:10 |
| Peng_ | Absent factory, IDS being used for push, ? | 01:10 |
| lifeless | lp knows :P | 01:12 |
| Peng_ | Yeah, that's mostly it, aside from some rich-root upgrade issues. | 01:22 |
| Peng_ | The other one is cross-format inventory delta streaming. | 01:25 |
| lifeless | thats needed for cross format pushing to be pleasant | 01:26 |
| poolie | igc https://edge.launchpad.net/bzr/+milestone/2.0 | 01:49 |
| poolie | Peng_: that url for you too | 01:49 |
| lifeless | spiv: what are you up to today? Could I request https://bugs.edge.launchpad.net/bzr/+bug/338561 ? | 01:49 |
| ubottu | Ubuntu bug 338561 in bzr "calling an unknown method logs noise (do_end, and a backtrace)" [High,Confirmed] | 01:49 |
| poolie | lifeless, spiv, can you tell me about bug 390563 too? | 01:49 |
| ubottu | Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged] https://launchpad.net/bugs/390563 | 01:49 |
| lifeless | poolie: I'm investigating it at the moment | 01:51 |
| lifeless | poolie: all I know for sure is in the bug | 01:51 |
| lifeless | I think | 01:51 |
| Peng_ | poolie: Oh, thanks. | 01:51 |
| spiv | lifeless: hmm, I could have sworn I fixed that a couple of months back. Sure, I'll look at that. | 01:57 |
| lifeless | spiv: lots of them in ~/.bzr.log on lp codehosting ;) | 01:58 |
| SamB | spiv: could be that someone unfixed them | 02:00 |
| SamB | or that the fix somehow got lost before being merged... | 02:00 |
| lifeless | SamB: thats what we have tests for; and lp/bb both track merge status by revids | 02:01 |
| lifeless | SamB: e.g. 'no' ;) | 02:01 |
| lifeless | poolie: is there more you want to know about 390563? | 02:02 |
| SamB | lifeless: depending on how forgetful you are | 02:02 |
| SamB | and/or whether you actually manage to write said tests | 02:02 |
| spiv | SamB: it's possible that I actually just fixed something similar but not quite the same, too :) | 02:03 |
| spiv | SamB: my memory of things I did a few months ago tends to be pretty hazy. | 02:03 |
| SamB | spiv: yeah, there's also that | 02:03 |
| lifeless | spiv: a few months ago, at my place, we looked at it and said 'lets file a bug and keep going on streaming' | 02:03 |
| spiv | lifeless: ah | 02:06 |
| spiv | Also, I think before that I fixed a similar issue to do with streaming bodies, perhaps. | 02:07 |
| lifeless | yes, that rings a bell | 02:07 |
| mwhudson | er | 02:21 |
| mwhudson | pqm seems to be getting absentcontentfactory errors with two non-stacked branches | 02:21 |
| lifeless | mwhudson: details? | 02:23 |
| lifeless | mwhudson: push or pull | 02:23 |
| lifeless | could be bug 365615 | 02:24 |
| ubottu | Launchpad bug 365615 in bzr "Random 'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository" [Critical,Fix released] https://launchpad.net/bugs/365615 | 02:24 |
| mwhudson | lifeless: merge, i expect, i don't really know details | 02:24 |
| lifeless | mwhudson: who does | 02:24 |
| mwhudson | dunno | 02:24 |
| mwhudson | lifeless: all i'm going in is failure mails to the launchpad list | 02:24 |
| mwhudson | it could be 365615 i guess | 02:25 |
| mwhudson | a traceback would be nice... | 02:25 |
| fullermd | igc: Nice timing results... | 02:35 |
| igc | fullermd: indeed. jam rocks! | 02:36 |
| fullermd | 's almost enough to make me wanna see how long importing ports would take... | 02:36 |
| fullermd | Though I don't think I'd want my system murdering me in my sleep for doing so. | 02:37 |
| igc | (I'm guessing his chk-map tweaks made a huge difference, together with his faster-commit stuff) | 02:37 |
| igc | fullermd: for *really* huge imports, there's still plenty of tuning to do I think | 02:37 |
| igc | fullermd: but probably in fast-import itself, more than the core | 02:38 |
| igc | fullermd: and I'm unlikely to get to tuning fast-import till after 2.0 reaches RC | 02:38 |
| fullermd | Yeah. It'd be pretty huge. Say around 200k revisions of 200k files. | 02:38 |
| fullermd | (well, files and dirs) | 02:39 |
| lifeless | fullermd: doit | 02:42 |
| lifeless | fullermd: generate a stream and save to disk ; then you can import incrementally or some such | 02:43 |
| fullermd | Yeah, the first step would be seeing if I have enough disk space to hold the fast-import stream... | 02:44 |
| fullermd | Certainly no time for it this weekend though; it's Field Day. | 02:44 |
| fullermd | (and the following few days will be "desperately catch up on sleep", as usual ;) | 02:45 |
| lifeless | whats a field day? | 02:45 |
| fullermd | http://www.arrl.org/contests/announcements/fd/ | 02:46 |
| thumper | lifeless: does the nightly ppa contain the autopack fix yet? | 02:47 |
| fullermd | (For some of us, hanging around an IRC channel about a version control tool just ain't nerdy enough, see...) | 02:47 |
| lifeless | thumper: I don't know | 02:49 |
| thumper | ok | 02:50 |
| thumper | lifeless: a pack of an already mostly packed 2a repo is taking quite a while | 02:50 |
| thumper | is that expected | 02:50 |
| thumper | ? | 02:50 |
| thumper | like 10 minutes | 02:50 |
| lifeless | thumper: do you have the C extensions? | 02:52 |
| thumper | lifeless: it is from the PPA so I think so | 02:53 |
| lifeless | thumper: and 'pack' has to recompress all history, so its a slow command to run (which is why you shouldn't ever run it unless you have specific reasons to do so) | 02:53 |
| lifeless | thumper: so why were you packing? | 03:02 |
| thumper | testing mainly, making my repo smaller, considering how to handle this on a large scale for LP | 03:03 |
| lifeless | thumper: bzr will pack as needed | 03:06 |
| lifeless | manual packing is generally a bad idea | 03:06 |
| Peng_ | mwhudson or beuno: ping | 03:12 |
| jfroy_ | jelmer: I just tried to diff two local branches which are both branches of remote svn branches | 03:21 |
| jfroy_ | And bzr died with a missing revision / no such revision error | 03:22 |
| jfroy_ | Is there any way to figure out, perhaps, where that revision is? | 03:22 |
| jfroy_ | if anywhere | 03:22 |
| jfroy_ | this is kind of an open question too, I suppose | 03:22 |
| jfroy_ | wondering if there's a way to search a repository or a branch for a specific revision ID | 03:23 |
| lifeless | log -r revid:REVID | 03:24 |
| jam | igc: did you change fast-import to use _add_text instead of add_lines at least? | 03:24 |
| jfroy_ | lifeless: ok I think I am screwed :/ | 03:27 |
| jfroy_ | well maybe | 03:28 |
| jfroy_ | it's odd | 03:28 |
| lifeless | or cat-revision | 03:28 |
| jfroy_ | that revision shows up in a branch in another repository | 03:28 |
| jfroy_ | but does not show up in the same branch in another reposityr | 03:28 |
| jfroy_ | *repository | 03:29 |
| jfroy_ | it's clearly a bzr-svn bug | 03:29 |
| jfroy_ | :( | 03:29 |
| jfroy_ | actually, it looks like that revision was in a local branch I did not push to subversion | 03:30 |
| jfroy_ | and have since deleted in the local repository | 03:30 |
| === timchen119 is now known as nasloc__ | ||
| Peng_ | mwhudson & beuno: unping. :) | 03:41 |
| mwhudson | Peng_: not-hi | 03:42 |
| Peng_ | mwhudson: Heh, nice timing. | 03:44 |
| igc | jam: not yet - my figures are still with code calling add_lines() | 03:45 |
| lifeless | jam: hi | 03:47 |
| lifeless | jam: did you get anywhere with the stacking bug overnight? | 03:47 |
| jam | lifeless: I did not, other than to not be able to reproduce it locally, but to have the lp branch fail :( | 03:48 |
| lifeless | jam: lftp seems to be working again with lpp | 03:49 |
| Peng_ | mwhudson: FWIW, I unpinged you because I decided to send a merge request. | 03:49 |
| lifeless | lp's sftp server, so you can just mirror down the branch | 03:49 |
| lifeless | you don't need all of lp | 03:49 |
| mwhudson | Peng_: oh ok | 03:50 |
| mwhudson | Peng_: ah, cool in principle at least, haven't read the diff yet :) | 03:54 |
| Peng_ | mwhudson: The diff is the part I'm worried about. :P | 03:54 |
| jelmer_ | jfroy_: hi | 03:59 |
| jelmer_ | jfroy_: there's been another report of that as well | 03:59 |
| jelmer_ | jfroy_: I suspect there's a regression since one of the 0.6 releases | 03:59 |
| jfroy_ | is there anything at al to be done to salvage that revision? | 03:59 |
| jfroy_ | I suspect push_merged_revision will help | 04:00 |
| jfroy_ | since it will push merged revisions, even those of otherwise purely local branches I would not otherwise push myself | 04:00 |
| jfroy_ | (which I do a lot, scratch branch, private feature branch, merge branches) | 04:00 |
| jelmer_ | jfroy_: until we've figured out what the bug is about, no idea if push merged revisions will help | 04:01 |
| jfroy_ | I think it will | 04:03 |
| jfroy_ | the branch nick on that missing revision if from a branch that was purely local | 04:03 |
| jfroy_ | I suspect that specific revision never got pushed to svn | 04:03 |
| jfroy_ | so other people, starting from scratch, will have that revision as a ghost | 04:03 |
| jfroy_ | push merged revision should avoid that situation | 04:04 |
| jfroy_ | (purely local and since then deleted) | 04:04 |
| jelmer_ | if you can confirm that is the case, please let me know | 04:06 |
| jelmer_ | are you using "bzr branch" or "bzr svn-import" to fetch? | 04:06 |
| jfroy_ | branch | 04:08 |
| RenatoSilva | Is there any documented problems with Novell filesystems? | 04:08 |
| lifeless | no | 04:08 |
| jelmer_ | jfroy_: I need to get some sleep, again, if you find more info please let me know | 04:08 |
| jfroy_ | will do | 04:09 |
| jelmer_ | jfroy_: I hope to put some time into bzr-svn again at the end of the week | 04:09 |
| jfroy_ | np | 04:09 |
| jfroy_ | it's not a show stopper | 04:09 |
| RenatoSilva | I get an error about .bzr/branch/lock/[...].tmp/lock, something like that. I think it may be related to big dir names or so. Stupid Novell anyway. | 04:12 |
| mtaylor | lifeless: | 04:15 |
| mtaylor | >>> import cpuinfo | 04:15 |
| mtaylor | >>> cpuinfo.cpuinfo_processor_count(True) | 04:15 |
| mtaylor | 2 | 04:15 |
| lifeless | mtaylor: cpuinfo.processor_count(True) would be nicer | 04:25 |
| lifeless | mtaylor: and for nonstrict mode (which scripts will want, | 04:25 |
| lifeless | cpuinfo.processor_count() | 04:25 |
| mtaylor | lifeless: indeed | 04:25 |
| lifeless | if you can :) | 04:26 |
| mtaylor | lifeless: totally | 04:26 |
| lifeless | mtaylor: don't you need perl first ? | 04:26 |
| mtaylor | lifeless: ew | 04:26 |
| lifeless | mtaylor: to be able to use this, I mean? | 04:26 |
| lifeless | isn't your test thingy that checks cpu counts perl? | 04:26 |
| mtaylor | lifeless: so - do you have any philosophical or other arguments about various ways to build python extension modules in the context of a larger autotools-run project | 04:27 |
| mtaylor | lifeless: yeah. I'll add perl in just a sec | 04:27 |
| lifeless | mtaylor: personally, I hate setup.py being mixed in with autotools | 04:27 |
| thumper | spiv: ping | 04:27 |
| lifeless | no point taking one half assed build system and mixing *another* half assed one in with it | 04:27 |
| spiv | thumper: pong | 04:28 |
| lifeless | mtaylor: but, working >> purity | 04:28 |
| thumper | spiv: I have a local lightweight checkout of a 2a branch | 04:28 |
| mtaylor | lifeless: k. I go back and forth on that... because I hate mixing the two - but I also hate telling automake all about python :) | 04:28 |
| mtaylor | lifeless: working bitshift purity? | 04:28 |
| thumper | spiv: bzr info -v tells me it is Branch format 7 | 04:28 |
| * mtaylor is confused | 04:28 | |
| lifeless | mtaylor: working is more important than purity | 04:28 |
| thumper | spiv: pushing to LP says: Source branch format does not support stacking, using format: | 04:29 |
| thumper | Branch format 7 | 04:29 |
| mtaylor | lifeless: yes yes. trolling | 04:29 |
| thumper | spiv: what can I do to help diagnose | 04:29 |
| spiv | thumper: known bug, lemme get you the number | 04:29 |
| spiv | thumper: https://bugs.edge.launchpad.net/bzr/+bug/388908 | 04:29 |
| lifeless | thumper: its filed as a bug already | 04:29 |
| ubottu | Ubuntu bug 388908 in bzr "unnecessary stacking upgrade warning with bzr.dev" [High,Triaged] | 04:29 |
| thumper | ok, thanks | 04:30 |
| abentley | jam: branch push is complete. | 04:30 |
| thumper | spiv: I was wondering if it had something to do with the format 6 remote branch format problems | 04:30 |
| lifeless | thumper: what format 6 remote branch problems? | 04:31 |
| spiv | thumper: no | 04:31 |
| * igc lunch (and afk for a few hours) | 04:35 | |
| mtaylor | lifeless: it would be great if ruby and perl had something like AM_PATH_PYTHON... | 04:50 |
| lifeless | wouldn't it just | 04:57 |
| jfroy_ | hey, this may be a stupid question, but is there a difference between bzr shelve and looms? | 05:00 |
| lifeless | huge | 05:03 |
| Peng_ | mwhudson: loggerhead/main.py should lose the exec bit, right? | 05:04 |
| mwhudson | Peng_: i thought i did that, so yes | 05:05 |
| Peng_ | mwhudson: Mind if I do it? | 05:06 |
| Peng_ | mwhudson: Err, yeah, you did do it. I misread the diff. Sorry! | 05:06 |
| mwhudson | Peng_: i just did | 05:06 |
| mwhudson | gar, didn't mean to commit that :( | 05:07 |
| * mwhudson uncommits | 05:07 | |
| Peng_ | Oh yay, one of my 2a branches just committed suicide. | 05:07 |
| Peng_ | Oh, it was just bzr-search. | 05:09 |
| Peng_ | ...Which doesn't really make a difference, because I usually bug lifeless about these sorts of things anyway. :P | 05:10 |
| Peng_ | mwhudson: Hey hey, your revision makes bzr-search explode on 2a. :) | 05:15 |
| mwhudson | Peng_: hooray | 05:21 |
| mtaylor | lifeless: python. ruby. done. | 05:23 |
| mtaylor | lifeless: perl next | 05:23 |
| Peng_ | Buggy bug filed, FYI -- https://bugs.edge.launchpad.net/bzr-search/+bug/391459 | 05:27 |
| ubottu | Ubuntu bug 391459 in bzr-search "KeyError in _terms_for_file_terms lambda indexing 2a copy of Loggerhead" [Undecided,New] | 05:27 |
| Peng_ | "Ubuntu bug"? | 05:28 |
| Peng_ | mwhudson: I like 'hi', 'ho', 'ha'. :) Today I used 'Hello' but it felt kind of silly and verbose. | 05:37 |
| lifeless | Peng_: thanks for the bug; will check later | 05:44 |
| Peng_ | lifeless: :) | 05:46 |
| === abentley1 is now known as abentley | ||
| poolie | spiv, around? want a quick call in a bit? | 06:30 |
| bignose | bzr-loom crashes, no matter what I do (Debian bug #532947). | 06:48 |
| ubottu | Debian bug 532947 in bzr-loom "bzr-loom: =?utf-8?Q?=E2=80=98loomify?=" [Important,Open] http://bugs.debian.org/532947 | 06:48 |
| bignose | how can I un-loomify a branch so I can keep working on it? | 06:48 |
| poolie | bignose: can you branch individual threads out into separate branches? | 06:49 |
| bignose | poolie: using what command? whatever I do it crashes with the message as recorded in that bug report. | 06:49 |
| lifeless | bignose: I think its all fixed upstream | 06:50 |
| lifeless | bignose: I'm not sure the branch is corrupted; is it possible that you simply have a broken combination of loom + bzr? | 06:50 |
| bignose | anything's possible. | 06:51 |
| bignose | so how can I get back to a working state for that branch? | 06:53 |
| bignose | or, more relevant to today: a branch that has already been working fine with a loom, but is now unreadable as per that bug report? | 06:54 |
| lifeless | if it *is* a damaged loom, you might be able to get the thread tip ids out using hexdump on .bzr/branch/current-loom, and use the python api to fetch content from the repo | 06:55 |
| bignose | urk. | 06:55 |
| wgrant | I'd just try upgrading bzr-loom first, though... | 06:55 |
| lifeless | if, as I suspect, you just have an incompatible loom, get your loom version matching your bzr version, and it should be fine | 06:55 |
| bignose | I'll wait for the Debian package to update, then. | 06:55 |
| lifeless | jelmer was asking for help on it | 06:56 |
| bignose | the "Debian Bazaar maintainers" (listed as the maintainer) have yet to give any response to that bug report, though :-( | 06:56 |
| poolie | igc, could you post your "IDE Integration..." message on the project blog? | 06:57 |
| bignose | is this related to the discussion on the Bazaar mailing list, about the systemic problem of plug-ins that *need* to be at the same version, but never *say* that in the corresponding OS packages? | 06:57 |
| lifeless | bignose: loom tries very hard not to be tied to specific versions | 06:58 |
| lifeless | but there have been a few API skews that affected it recently. | 06:58 |
| vila | hi all | 07:29 |
| lifeless | hai | 07:29 |
| igc | hi vila | 07:37 |
| vila | hi Ian ! | 07:46 |
| === afk is now known as mthaddon | ||
| === maxb_ is now known as maxb | ||
| Peng_ | Does bug #390563 waste disk space in non-stacked branches or just bandwidth? | 09:23 |
| ubottu | Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged] https://launchpad.net/bugs/390563 | 09:23 |
| Peng_ | ...S'pose I could check it myself. | 09:23 |
| vila | Peng: and tell us if you can reproduce it and how | 09:23 |
| Peng_ | Oh, right, I forgot that that bug only affects certain branches. | 09:24 |
| Peng_ | effects? eh | 09:28 |
| fullermd | Affects. | 09:28 |
| fullermd | Well, the bug may effect certain branches too, but that would be a really weird bug :p | 09:28 |
| Peng_ | Someday, I should learn the difference between those two words. | 09:29 |
| Peng_ | Then I should verify "then" and "than". :P | 09:29 |
| fullermd | Generally, affect is a verb and effect is a noun. | 09:30 |
| Peng_ | (OK, I just said that one for the punny thing.) | 09:30 |
| * Peng_ is obviously a linguistic master. :P | 09:30 | |
| fullermd | Oh, you can sort them out. Their knot that hard. | 09:31 |
| mwhudson | fullermd: you're a bad man | 09:34 |
| Peng_ | mwhudson: Shouldn't that be "your a bad man"? | 09:36 |
| fullermd | Hey, the proof is in the pudding, just take a different tact. | 09:37 |
| Lo-lan-do | Hi all | 09:54 |
| Lo-lan-do | What's the status of the HistoryHorizon feature currently? | 09:54 |
| Lo-lan-do | (The use case I'm looking for is the "Old huge project" mentioned on http://bazaar-vcs.org/HistoryHorizon) | 09:55 |
| Lo-lan-do | Is it fulfilled by stacked branches? | 09:56 |
| Peng_ | Lo-lan-do: They're not the same thing, but stacked branches let you store the repository on the server, similar to a lightweight checkout, only you've got a real branch. | 09:59 |
| lifeless | Lo-lan-do: we have decent performance and excellent compression even for huge old projects, in the 2a format. | 10:07 |
| Peng_ | Users will just move the goalposts by making even huger projects. :P | 10:17 |
| Lo-lan-do | lifeless: Huge as in? | 10:18 |
| Lo-lan-do | I'm talking about a 16G CVS repo here. | 10:18 |
| Peng_ | lifeless: Do you sleep? | 10:19 |
| Lo-lan-do | We need to do some cleanup in there, and it'll be smaller with bzr, but still, if the main repo could be limited in history that would certainly help. | 10:19 |
| Lo-lan-do | Could the main repo be stacked on a historical one, thus making day-to-day operations fast while keeping history? | 10:21 |
| Peng_ | Lo-lan-do: What do you mean? Like, have a stacked branch pointing to another one on the same machine? | 10:22 |
| Lo-lan-do | I'm very glad to hear about 2a, too. Do you think it'll be stable before the end of the year? | 10:22 |
| Lo-lan-do | Peng_: Yes. So daily commits only add to the smaller "current" repo. | 10:23 |
| Lo-lan-do | But maybe 2a entirely removes the benefits of such an approach, in which case I'll happily recommend that. | 10:23 |
| asabil | hi all | 10:24 |
| asabil | is there a way to setup a configuration (bugtracker settings) that will be propagated during a bzr branch to all users ? | 10:24 |
| Peng_ | Lo-lan-do: Having a larger repo isn't a problem. Stacking that would be pointless. | 10:26 |
| lifeless | Peng_: theory has that I do | 10:27 |
| Lo-lan-do | Having to replicate a large repo with file transfers could cause problems. | 10:27 |
| lifeless | Lo-lan-do: that could be massively smaller - perhaps even 1GB total, in 2a | 10:27 |
| Peng_ | Lo-lan-do: Actually...a smaller repo would probably save a few ms here and there, but stacking would also cost a few ms here and there. :D | 10:27 |
| Peng_ | Lo-lan-do: If the users do "bzr branch --stacked", they won't have to replace the entire thing. | 10:27 |
| Lo-lan-do | I fear that smart repo formats wouldn't be very good at rsyncing (but maybe I'm completely wrong) | 10:27 |
| lifeless | Peng_: but its only EOD, not time-to-sleep now | 10:27 |
| Peng_ | Err, replicate* | 10:27 |
| Peng_ | lifeless: Ah. | 10:28 |
| lifeless | Lo-lan-do: all our formats since pack-0.92 rsync very well | 10:28 |
| Peng_ | lifeless: Except when they get packed... | 10:28 |
| lifeless | Lo-lan-do: old data is rarely moved on disk, so it rarely shows up | 10:28 |
| lifeless | Lo-lan-do: as long as noone runs 'bzr pack', which they shouldn't. | 10:28 |
| Lo-lan-do | Good to know. | 10:28 |
| Lo-lan-do | I guess bzr pack could be run monthly or so, if it's useful at all. | 10:29 |
| lifeless | I wouldn't even do that | 10:29 |
| lifeless | bzr incrementally packs as commits and pushes occur. | 10:29 |
| Lo-lan-do | More and more excellent. | 10:29 |
| lifeless | every power of 10 commits it does a full pack automatically | 10:30 |
| lifeless | so if you have 1M commits today, you'd need another 9 million to need another full pack ;) | 10:30 |
| Peng_ | Running "bzr pack" occasionally *would* buy you a teensy bit of performance, but it's not enough to matter. Autopacking keeps things from getting out of hand. | 10:31 |
| lifeless | Peng_: actually, full packing when its not needed, with pack ordering, can decrease performance :) | 10:32 |
| lifeless | Peng_: (for a central repo thats only push/pulled with) | 10:32 |
| Peng_ | lifeless: Oh? Why? I don't get it. | 10:32 |
| Peng_ | Also, Firefox crashed. Arrgh. | 10:32 |
| Lo-lan-do | How do the new repo formats cope with thousands of branches? | 10:32 |
| lifeless | Peng_: by creating a single large btree that has to be read rather than a smaller one with the most recent data and a larger one that isn't read at all | 10:32 |
| Peng_ | lifeless: Ahh. | 10:33 |
| lifeless | you'd need fairly extreme repos for this to show up | 10:33 |
| lifeless | as we get a 200:1 fanout in our indices today | 10:33 |
| lifeless | Lo-lan-do: should be fine; there isn't a single file listing all the branches or anything, so its much of a muchness | 10:34 |
| Lo-lan-do | Good. | 10:34 |
| Lo-lan-do | Last two questions: timeframe for format 2a being officially stable? And possibility for repo-side hooks? | 10:35 |
| Peng_ | Repositories don't really know about branches. They're just big bags of revisions. | 10:35 |
| Lo-lan-do | (The hooks can be done without, they use incron for now) | 10:35 |
| Lo-lan-do | (they=my current client) | 10:36 |
| Peng_ | Well, I guess it could matter if you had a complicated history and bzr was bad at choosing compression parents, but it's not. | 10:36 |
| lifeless | Lo-lan-do: 2a is supported now; however you need https://bugs.edge.launchpad.net/bzr/1.16/+bug/365615 - we're still polishing the code around the format. | 10:36 |
| ubottu | Ubuntu bug 365615 in bzr/1.16 "'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository on write operations" [Critical,Fix committed] | 10:36 |
| lifeless | Lo-lan-do: we'll be doing a 1.16.1 with that hotfix and possibly a couple of others (to do with stacking on 2a formats) | 10:37 |
| Lo-lan-do | I'm not in much of a hurry, they'll need time to think about it anyway. | 10:37 |
| Lo-lan-do | My current job is to find quickfixes to make the CVS repo a bit more usable than it currently is. | 10:38 |
| Lo-lan-do | ...and to provide recommendations for the longer term. | 10:38 |
| Lo-lan-do | I'm pretty sure bzr will be in that part :-) | 10:38 |
| lifeless | awesome | 10:39 |
| Peng_ | Stupid question: how large is MySQL's repo? | 10:40 |
| Lo-lan-do | A bzr branch uses 600 MB (with working-tree) | 10:40 |
| mwhudson | Peng_: ~600 megs or so | 10:40 |
| Lo-lan-do | The .bzr is 467MB here | 10:41 |
| lifeless | Lo-lan-do: of mysql? | 10:41 |
| lifeless | Lo-lan-do: it shrinks by about 2/3rds going to 2a | 10:41 |
| Lo-lan-do | (Branched from lp:mysql-server sometime this week) | 10:41 |
| Lo-lan-do | format: unnamed, bzr 1.11 | 10:42 |
| lifeless | info -v will show you the actual repo format | 10:42 |
| Peng_ | In 1.11, it'll probably also spend a long time churning through the history, but you can Ctrl+C it. | 10:42 |
| Lo-lan-do | packs 6 | 10:42 |
| Lo-lan-do | This 2/3 number is awesomely impressive. | 10:43 |
| Lo-lan-do | Sorry, crashed. You were saying? | 10:48 |
| lifeless | nothing ;) | 10:48 |
| lifeless | 19:42 < Lo-lan-do> packs 6 | 10:48 |
| lifeless | 19:43 < Lo-lan-do> This 2/3 number is awesomely impressive. | 10:48 |
| lifeless | 19:46 -!- Lo-lan-do [n=roland@193.252.149.222] has quit [Read error: 104 (Connection reset by peer)] | 10:48 |
| lifeless | 19:48 -!- Lo-lan-do [n=roland@193.252.149.222] has joined #bzr | 10:48 |
| Lo-lan-do | Cool. | 10:48 |
| Lo-lan-do | Anyway, will you be available for a beer at Debconf? :-) | 10:49 |
| Lo-lan-do | I think I owe a couple to jelmer too. | 10:49 |
| lifeless | I won't be at debconf | 10:52 |
| lifeless | sorry :( | 10:52 |
| Kinnison | You won't? Boo hiss :-( | 10:52 |
| Lo-lan-do | RMLL in Nantes maybe? | 10:52 |
| lifeless | Kinnison: where is it this year ? | 10:53 |
| Lo-lan-do | Western Spain | 10:53 |
| Kinnison | Cacéres, Spain | 10:53 |
| lifeless | yah. Wrong side of the world | 10:53 |
| Kinnison | About four hours west of Madrid | 10:53 |
| lifeless | when things line up, its awesome to get to such things | 10:53 |
| lifeless | but as it stands, its awfully hard to get there, and I've used all my conference leave this year already. | 10:53 |
| Kinnison | fair enough | 10:54 |
| Lo-lan-do | My plan is to develop the bzr plugin for fusionforge during debcamp/debconf | 10:54 |
| Kinnison | Lo-lan-do: coo. sounds amusing. | 10:54 |
| Lo-lan-do | (And git, and hg, and whatever VCS out there if there's a guru around to tell me what needs to be done for his preferred one) | 10:55 |
| Lo-lan-do | I'll probably implement a cpold plugin too, if only as a proof of concept after my refactoring. | 10:55 |
| Kinnison | lifeless: any plans for a UDS in the UK any time soon? | 10:55 |
| Peng_ | cpold? | 10:56 |
| lifeless | next is US I think; beyond that no idea | 10:56 |
| Lo-lan-do | Peng: The oldest VCS of them all. | 10:56 |
| Lo-lan-do | Peng: "cp foo.c foo.c.old" | 10:56 |
| Peng_ | Lo-lan-do: Oh. I use that one a lot! | 10:57 |
| Lo-lan-do | There you are :-) | 10:57 |
| Lo-lan-do | I'm wondering if I'll have the nerve to actually upload a gforge-plugin-scmcpold to Debian :-) | 10:58 |
| Lo-lan-do | Anyway, food calls. Thanks for your answers! | 10:58 |
| Peng_ | Lo-lan-do: See you later! :) | 10:59 |
| Peng_ | Hmm, food. Good idea. | 10:59 |
| awilkins_ | Is bzr 2 getting copy of files in inventories? | 12:01 |
| === awilkins_ is now known as awilkins | ||
| gioele | hello | 12:02 |
| lifeless | awilkins: no | 12:02 |
| awilkins | I suppose it would be yet another awkward format hump to drive over | 12:03 |
| awilkins | It's nice to see that not-rich-root is deprecated for 2a | 12:03 |
| gioele | do stacked branches require the master branch to support the staking in some way? Or this feature can be used with any published branch, regardless of its format? | 12:06 |
| lifeless | the formats must match | 12:20 |
| lifeless | and bzr won't honour default-stacking requests with very old branches because that would potentially leave the trunk unable to merge from feature branches | 12:20 |
| gioele | lifeless: anyway, is it possible to use stacking with lp:bzr? | 12:23 |
| lifeless | yes, and bzr should do that by default | 12:24 |
| gioele | lifeless: that = stacking? if I do a bzr clone lp:bzr I end up with a stacked branch? | 12:25 |
| lifeless | no | 12:25 |
| lifeless | and doing that isn't very useful or sensible anyway | 12:25 |
| lifeless | (stacking your local copy on the network version | 12:25 |
| lifeless | ) | 12:25 |
| lifeless | if you do a bzr push lp:~gioele/bzr/foo, it will stack on lp;bzr automatically | 12:26 |
| gioele | lifeless: but then the remote branch is stacked, not the branch on my PC, if I understood that correctly | 12:27 |
| lifeless | right, but its not useful to stack branches on your pc | 12:31 |
| lifeless | a stacked branch doesn't have enough data in it to even create a working tree | 12:31 |
| gioele | I see | 12:32 |
| gioele | thank you for the explaination | 12:35 |
| === mrevell is now known as mrevell-lunch | ||
| ddaa | Hello. | 13:39 |
| ddaa | I have a collaborator, who is using Windows to write to some files in a linux-based bzr tree over the network (presumably SMB) | 13:40 |
| ddaa | This appears to cause the executable bit to turn on on every file he edits from the network. Which is kind of annoying to me. | 13:40 |
| ddaa | Is there a way to edit files in a linux bzr tree from windows over SMB that will not cause those files to be recorded as executable when committing from linux. | 13:41 |
| ddaa | Note that I do not really care about whether the becomes executable on the linux filesystem. I just do not want bzr to record a permission change. | 13:42 |
| matkor | Hi ! what is easiest way to apply changes (uncommited) from given branch to current one ? | 13:48 |
| Lo-lan-do | bzr merge --uncommitted $given | 13:49 |
| ddaa | bialix: Can I make my collaborator use the bzr-x-bit plugin on linux to solve this problem? | 13:49 |
| bialix | ddaa: no | 13:49 |
| matkor | Lo-lan-do: Looks great, thank you very much ! | 13:49 |
| Lo-lan-do | matkor: Then you'll probably do "cd $given ; bzr revert" or so | 13:50 |
| bialix | x-bit plugin does reverse thing | 13:50 |
| Lo-lan-do | (Be sure to only do that afterwards) | 13:50 |
| ddaa | bialix: doh, any idea? | 13:50 |
| bialix | SMB settings maybe? I'm not Linux expert | 13:51 |
| ddaa | I know, but you're the expert of all things windowish around. | 13:51 |
| bialix | IIUC this is always problem: try to open USB flash disk on Linux and all files have x-bit set | 13:51 |
| bialix | ddaa: IIUC your situation: your collaborator working directly with files over the network? | 13:52 |
| bialix | so why he does not have separate tree on his local disk? | 13:52 |
| bialix | e.g. lightweight checkout | 13:52 |
| ddaa | Yup. As I said, I do not care much what the filesystem says, I just do not want this nonsense to contaminate my carefuly tended bzr branch. | 13:52 |
| bialix | lightweight checkout will help you | 13:52 |
| ddaa | bialix: out of convenience, he's editing, over SMB, files that are used by a live web server on linux. | 13:53 |
| * bialix out of ideas | 13:53 | |
| bialix | I'm usually working via ssh in those cases | 13:54 |
| ddaa | I do not want to worry about running the web server on windows, but I would like him to be able to retain the convenience of editing files on his big-screen windows system while he's testing IE compatibility. | 13:54 |
| * ddaa contemplates how all evil in computing those days can be ultimately traced to Internet Explorer. | 13:54 | |
| bialix | and Bill G. of course! | 13:55 |
| ddaa | I do not like to take things personally. It's fine to hate pieces of technologies, but not people. | 13:56 |
| matkor | Lo-lan-do: Sure, I will even commit first on current :) | 13:56 |
| bialix | as you wish, I've tried to make joke | 13:56 |
| ddaa | bialix: sorry :) I'm just annoyed about how it became fashionable to hate B. Gates and Microsoft over the past few years. | 13:57 |
| ddaa | I mean, they actually invented a few good things. | 13:57 |
| ddaa | Like the scroll wheel. | 13:57 |
| ddaa | Thinking of it... Microsoft is actually pretty good at making mice, keyboards and joysticks... | 13:58 |
| LeoNerd | MS mice are quite nice, yeah.. | 13:58 |
| LeoNerd | Probably because Logitec make them? | 13:58 |
| garyvdm | When Bug 1 gets fixed people will be replace those with Mark S. and Canonical :-P | 13:59 |
| ddaa | LeoNerd: that might have something to do with it :) | 13:59 |
| * garyvdm ducks and runs | 13:59 | |
| ddaa | garyvdm: a few people already have. | 13:59 |
| garyvdm | Is ubottu asleep/ | 13:59 |
| garyvdm | bug 00001 | 13:59 |
| ubottu | https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout) | 13:59 |
| ddaa | Not ubottu, but most of the time this page times out. | 14:00 |
| ddaa | something to do with insanely large amount of comments, dups, subscribers and so on and so forth. | 14:00 |
| fbond | Hi. In the old bzr shelve, I could `bzr shelf show FOO`, I think, to see a diff representing that particular change on the shelf. Can I do that with the new shelve/unshelve commands? | 14:00 |
| fbond | `bzr unshelve --dry-run` shows me a stat-like representation of the change, but not a diff. | 14:01 |
| garyvdm | bug 391471 | 14:01 |
| garyvdm | bug #391471 | 14:01 |
| ubottu | Launchpad bug 391471 in tortoisebzr "Inconsistent Diff behavior" [Undecided,New] https://launchpad.net/bugs/391471 | 14:01 |
| garyvdm | https://bugs.launchpad.net/ubuntu/+bug/1 | 14:02 |
| ubottu | Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/1/+text) | 14:02 |
| fbond | garyvdm: That bug has a lot of comments. | 14:02 |
| garyvdm | lol | 14:02 |
| garyvdm | oops - I've now cause to to try 3 times... | 14:03 |
| garyvdm | *caused it | 14:03 |
| === mrevell-lunch is now known as mrevell | ||
| ddaa | Okay it turns out there should be two ways of fixing it. | 14:11 |
| ddaa | 1. setting the "create mask" in smb.conf to something like "644", so files are not create executable | 14:11 |
| ddaa | 2. configuring the windows-side editor to save files in place (instead of doing the copy-rename thing). | 14:12 |
| asabil | jelmer: ping ? | 15:07 |
| jelmer | asabil: pong | 15:18 |
| asabil | jelmer: did you receive my filter-branch merge request for bzr-rebase ? | 15:18 |
| jelmer | asabil: no, I didn't see anything | 15:32 |
| asabil | jelmer: I did send it a while ago, maybe I should resend it ? | 15:32 |
| jelmer | asabil: please do | 15:33 |
| Lo-lan-do | Are pack files often modified? | 15:33 |
| Lo-lan-do | Or are they only generated once by a commit or a repack and not changed afterwards? | 15:34 |
| Lo-lan-do | I'm pondering about risks of filesystem fragmentation. | 15:34 |
| jelmer | Lo-lan-do: pack files are not modified themselves, but new pack files will be created regularly | 15:42 |
| jelmer | (e.g. by commit, repack, push/pull etc) | 15:42 |
| Lo-lan-do | Okay, so little risk for fragmentation increasing over time. Good, good. | 15:50 |
| mxpxpod | jelmer: ping? | 15:53 |
| jelmer | mxpxpod: pong | 15:56 |
| mxpxpod | jelmer: I'm trying to mirror dojotoolkit.org's svn repository using bzr-svn's svn-import, but we have a strange branching and tagging method | 16:00 |
| mxpxpod | basically, each project (dojo, dijit, dojox) has it's own sub-repository (src/dojox/{branches,tags,trunk}) | 16:01 |
| mxpxpod | but then when we release, we create a structure in src/branches/{release_version} that copies current trunk of each project into that directory | 16:01 |
| mxpxpod | same with tagging with the tags directory | 16:01 |
| mxpxpod | jelmer: if you want to take a look, it's at http://svn.dojotoolkit.org/src | 16:03 |
| abentley | jam: In case you missed it earlier, the push to /home/abentley/branches is complete | 16:04 |
| mxpxpod | jelmer: src/trunk is our old code-base | 16:05 |
| mxpxpod | jelmer: the problem is that when I did the svn-import, I specified branches=branches/*;*/branches/*;*/trunk and tags=tags/*;*/tags/*, but no tags showed up | 16:07 |
| mxpxpod | jelmer: am I going to have to tag things manually? | 16:07 |
| jelmer | mxpxpod: sorry, phone, back in a few minutes | 16:11 |
| === Kissaki^0ff is now known as Kissaki | ||
| asabil | jelmer: just sent it, you should receive it on your samba mailbox | 16:16 |
| jam | abentley: thanks | 16:18 |
| jam | robert says you can lftp the broken branch | 16:18 |
| jam | which works well, too | 16:18 |
| abentley | jam: was the lftp message for me? | 16:21 |
| jam | yes | 16:22 |
| jam | not that *you* need to | 16:22 |
| jam | just that it is another branch I can use | 16:22 |
| abentley | jam: I don't understand. by "broken branch", you mean db-devel? | 16:23 |
| jam | cinnamon-and-spice, IIRC | 16:23 |
| jam | abentley: sorry, crimson-and-clover | 16:23 |
| abentley | jam: Oh, you'd like a copy of lp:~sinzui/launchpad/crimson-and-clover ? | 16:24 |
| === vxnick is now known as vxnick_afk | ||
| abentley | jam: I've mirrored crimson-and-clover for you at /home/abentley/crimson-and-clover | 16:32 |
| mxpxpod | is there a way to register a directory service and have it create a shared repo for multiple branches for certain urls? | 16:34 |
| asabil | jelmer: did you get it this time ? | 16:37 |
| jelmer | asabil: yep, thanks | 16:37 |
| asabil | cool | 16:38 |
| jelmer | mxpxpod: re | 16:41 |
| jelmer | mxpxpod: that should've worked | 16:42 |
| jelmer | mxpxpod: did svn-import say anything about the layout being used? | 16:42 |
| mxpxpod | jelmer: Using repository layout: WildcardLayout(['branches/*', '*/branches/*', '*/trunk'],['tags/*', '*/tags/*']) | 16:43 |
| * awilkins thinks bzr-svn should have a layout option for "total freakin' mess" | 16:43 | |
| mxpxpod | awilkins: :) | 16:43 |
| mxpxpod | jelmer: I think the problem is that we have src/tags/release-1.3.1/dojo | 16:44 |
| kirkland | jelmer: hi there | 16:44 |
| mxpxpod | and dojo resides in src/dojo/{trunk,branches} | 16:44 |
| kirkland | jelmer: i'm still getting a vcs import update failure for qemu's git | 16:44 |
| kirkland | jelmer: i was under the impression that LP's rollout this morning had your latest fixes? | 16:44 |
| kirkland | jelmer: http://launchpadlibrarian.net/28287607/qemu-git-log.txt | 16:45 |
| kirkland | jelmer: https://code.edge.launchpad.net/~vcs-imports/qemu/git | 16:45 |
| === abentley1 is now known as abentley | ||
| jelmer | kirkland: I'm not sure what version of bzr-git launchpad is using | 16:47 |
| kirkland | jelmer: is there any way that I can run this script/process locally, on my hardware | 16:48 |
| kirkland | jelmer: and push to a bzr branch in LP? | 16:48 |
| kirkland | jelmer: i'm happy to cut vcs-imports out of the loop, until they get that fixed | 16:49 |
| kirkland | jelmer: i need a bzr/git mirror up ASAP | 16:49 |
| jelmer | kirkland: yeah, just install bzr-git and run something like this from a cronjob: | 16:50 |
| kirkland | jelmer: what's bzr-git? a bzr pluggin? | 16:51 |
| Jc2k | yes | 16:51 |
| jelmer | kirkland: "bzr svn-import git://git.savannah.nongnu.org/qemu.git qemu; bzr push -d qemu lp:~kirkland/qemu/git-import" | 16:51 |
| jelmer | sorry, git-import rather than svn-import obviously | 16:52 |
| kirkland | jelmer: s/svn-import/git-import/ | 16:52 |
| kirkland | k | 16:52 |
| kirkland | jelmer: thanks | 16:52 |
| jelmer | kirkland: alternatively if you just need the main branch you can just use "bzr branch" / "bzr pull" with git URLs | 16:53 |
| mxpxpod | jelmer: I'm figuring for this strange layout that we have that I'll have to do some sort of custom import for this repo | 16:54 |
| kirkland | jelmer: and getting git-import .... | 16:54 |
| kirkland | jelmer: cd .bazaar/plugins; bzr branch lp:bzr-git ? | 16:55 |
| jelmer | kirkland: yep | 16:55 |
| jelmer | kirkland: you'll also need dulwich, which is a dependency of bzr-git | 16:55 |
| jelmer | mxpxpod: there don't seem to be any actual tags for dojo that bzr-svn could import | 16:55 |
| jelmer | mxpxpod: http://svn.dojotoolkit.org/src/dojo/tags/ is empty | 16:56 |
| kirkland | Unable to load plugin 'git'. It requested API version (1, 17, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 13, 0), and the maximum is (1, 13, 1) | 16:56 |
| mxpxpod | jelmer: yeah, we tag dojo, dijit, dojox, and util at src/tags/{release_name}/{project_name} | 16:56 |
| jelmer | kirkland: the version of bzr you have locally is too old, you need at least 1.14 for bzr-git | 16:57 |
| kirkland | jelmer: best way of getting a newer bzr onto a jaunty machine? a ppa, perhaps? | 16:59 |
| jelmer | kirkland: yeah, there's a bzr ppa (~bzr on lp) | 16:59 |
| kirkland | jelmer: cheers, thanks for your help, dude | 16:59 |
| mxpxpod | kirkland: https://launchpad.net/~bzr/+archive/ppa | 16:59 |
| jelmer | mxpxpod: so in that case it seems your tags setting is incomplete | 16:59 |
| mxpxpod | jelmer: right, but how do I tell svn-import that the tag is at tags/release-1.3.1/dojo rather than dojo/tags/release-1.3.1 ? | 17:00 |
| mxpxpod | and then how do I get it to translate the former to the latter for the conversion? | 17:01 |
| jelmer | mxpxpod: try tags/*/dojo | 17:02 |
| mxpxpod | jelmer: what if I'm importing the whole repo at one time? | 17:02 |
| === abentley1 is now known as abentley | ||
| jelmer | mxpxpod: shouldn't be any different | 17:05 |
| mxpxpod | jelmer: so, just put tags/*/{project_name} for each project? | 17:06 |
| jelmer | mxpxpod: yeah, that's how it's intended to work at least | 17:06 |
| mxpxpod | jelmer: same with branches? | 17:07 |
| jelmer | mxpxpod: yeah | 17:07 |
| mxpxpod | jelmer: welp, here goes nothing ;) | 17:09 |
| === abentley1 is now known as abentley | ||
| === vxnick_afk is now known as vxnick | ||
| marianom | hi guys, can anyone tell me why I'm hitting this error? bzr: ERROR: Reserved revision-id {null:} | 17:55 |
| marianom | First time I see it | 17:55 |
| mxpxpod | jelmer: that didn't work :( | 18:02 |
| mxpxpod | jelmer: I did this: bzr init-repo --1.14-rich-root test; cd test; bzr svn-import http://svn.dojotoolkit.org/src . | 18:05 |
| kirkland | jelmer: http://pastebin.ubuntu.com/203025/ | 18:20 |
| kirkland | jelmer: dulwich is installed | 18:20 |
| kirkland | never mind | 18:24 |
| kirkland | bzr: ERROR: exceptions.ImportError: bzr-git: Dulwich is too old; at least 0.3.1 is required | 18:28 |
| kirkland | i installed dulwich from the ppa | 18:28 |
| jelmer | kirkland: I don't think there's a current dulwich packaged in the ppa | 18:38 |
| kirkland | jelmer: okay, thanks. | 18:38 |
| jh | hi, I'm trying to get to the newest revsion of a branch on launchpad. I had already a local copy of the repository and changed some things (and committed it locally). how can I change to the current remote revision? ignoring all my local changes | 18:40 |
| dash | you want to remove your local changes? | 18:41 |
| dash | or merge the remote ones into your local branch | 18:41 |
| jh | I want to ignore my local changes | 18:41 |
| dash | bzr pull --overwrite <remote url> | 18:42 |
| dash | if by 'ignore' you mean 'remove' | 18:42 |
| jh | y | 18:42 |
| jh | thx! | 18:42 |
| ddaa | There's something annoying about shelve storing a pack in the shelf instead of a diff. | 18:44 |
| dash | yes | 18:44 |
| ddaa | Previously, I could go into the shelf, and modify the shelved diff. | 18:44 |
| dash | also the shelve plugin has more features than the builtin | 18:44 |
| ddaa | In this instance, I want to split a diff hunk. | 18:45 |
| dash | me too | 18:45 |
| * ddaa shakes dash's hand | 18:45 | |
| ddaa | dash: so what is it you do you to satisfy you obsessive-compulsive need for clean commits? | 18:45 |
| dash | (I am trying to split up a very large diff into multiple unrelated ones via loom+shelve) | 18:45 |
| dash | ddaa: Nothing easy. | 18:46 |
| ddaa | that kind of sucks | 18:46 |
| dash | yes | 18:46 |
| dash | i think i am going to switch back to shelve1 | 18:46 |
| ddaa | you mentioned a different between a plugin and a builtin | 18:46 |
| dash | yes, the 'shelve' in bzrtools is different | 18:47 |
| ddaa | I did not realize shelve was now a builtin | 18:47 |
| dash | so yeah, try 'bzr shelve1' | 18:47 |
| ddaa | Yay, happiness. | 18:48 |
| ddaa | bzr shelve1, manual diff editing, bzr unshelve1 | 18:48 |
| ddaa | dash: thanks pal | 18:49 |
| dash | <3 | 18:49 |
| === vxnick is now known as vxnick_afk | ||
| === mthaddon is now known as afk | ||
| mwhudson | jelmer_: hello, https://code.edge.launchpad.net/~vcs-imports/mnemosyne-proj/maemosyne still seems to be failing with bzr 0.4.0, i can't remember if i asked you about this one already :) | 20:26 |
| mwhudson | bzr-git, obv | 20:26 |
| === afk is now known as mthaddon | ||
| === cprov is now known as cprov-afk | ||
| poolie | hello | 21:37 |
| * beuno waves at poolie | 21:37 | |
| poolie | good morning beuno | 21:37 |
| beuno | how are you poolie? | 21:38 |
| poolie | good thanks | 21:40 |
| poolie | woke up a bit too early though | 21:40 |
| poolie | how are you? | 21:40 |
| beuno | pretty good | 21:41 |
| beuno | slow day for me today | 21:41 |
| poolie | how is 2a dogfooding going for you? | 21:42 |
| poolie | i realize bug 390563 is a big deal | 21:42 |
| ubottu | Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged] https://launchpad.net/bugs/390563 | 21:42 |
| beuno | poolie, that's really making things chaotic | 21:53 |
| beuno | but, apart from that, things seem much faster | 21:53 |
| beuno | I've upgraded about 30 branches at the office to 2a | 21:54 |
| beuno | and it's gone well | 21:54 |
| beuno | no problemas at all | 21:54 |
| beuno | something to note is that at least half the branches didn't go down in size from 1.9 | 21:54 |
| poolie | ok, interestig | 21:56 |
| poolie | how about if you repack them? | 21:56 |
| beuno | I do, all of them | 21:56 |
| beuno | initially the branches are larger | 21:56 |
| beuno | and then they go down to about the same size after a pack | 21:56 |
| beuno | they are branches with heavy binary usage | 21:57 |
| === Kissaki is now known as Kissaki^0ff | ||
| lifeless | oh wow | 22:32 |
| lifeless | did all codeimports die overnight? | 22:32 |
| lifeless | mwhudson: ^ | 22:32 |
| mwhudson | lifeless: no | 22:32 |
| thumper | lifeless: no, we've just now automatically failing imports that have failed lots | 22:32 |
| mwhudson | oh yes, that's a lot of spam in my codeimport folder... | 22:33 |
| lifeless | vila: still around? | 22:35 |
| poolie | hello mwhudson, lifeless | 22:38 |
| mwhudson | hi poolie | 22:38 |
| lifeless | mwhudson: you're going to cherrypick bug 365615 today, yes? | 22:49 |
| ubottu | Launchpad bug 365615 in bzr/1.16 "'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository on write operations" [Critical,Fix committed] https://launchpad.net/bugs/365615 | 22:49 |
| mwhudson | yeah, we should | 22:50 |
| mwhudson | lifeless: it won't hit prod until uk versions of 'today' of course | 22:50 |
| mwhudson | lifeless: is there any sense in waiting for a fix to the other absentcontentfactory bug to maybe appear? | 22:51 |
| mwhudson | lifeless: also, is the fix for that bug in the 1.16 branch? | 22:51 |
| mwhudson | seems no | 22:52 |
| mwhudson | i guess i should talk to the 1.16 release manager | 22:52 |
| mwhudson | who should be waking up around about now... | 22:53 |
| lifeless | mwhudson: its not in the 1.16 branch yet | 22:56 |
| lifeless | mwhudson: just cherry pick | 22:56 |
| lifeless | and no, no sense waiting | 22:56 |
| poolie | lifeless: did you talk to jam today (au time)? | 22:59 |
| poolie | i was just going to call him and say hello | 22:59 |
| lifeless | poolie: no; I'd like to to pickup the state on the bug | 23:00 |
| lifeless | he commented about 7 hours ago on the bug, but hasn't mailed a status note, nor has vila | 23:00 |
| lifeless | so AFAICT it hasn't advanced any | 23:00 |
| lifeless | which may just mean that a lot of work hasn't ruled anything out nor proven anything | 23:01 |
| lifeless | poolie: I'll be on m mobile; just grabbing a hot brekkie | 23:03 |
| poolie | lifeless: john's sending an update now | 23:12 |
| FibeRichio | Hi, I wanted to exclude a directory called 'webstats' from the revision, so I did 'bzr ignore ./webstats'. It told me that there already existed a directory in the revision and that I should use the remove command, but after I did 'bzr remove webstats', the entire directory dissappeared from my filesystem? | 23:17 |
| lifeless | back | 23:20 |
| lifeless | poolie: thanks | 23:20 |
| lifeless | FibeRichio: right, it did that because it was versioned | 23:21 |
| lifeless | FibeRichio: do this: | 23:21 |
| lifeless | bzr revert webstats | 23:21 |
| lifeless | bzr remove --keep webstats | 23:21 |
| FibeRichio | thanks, that looks bettter :) | 23:21 |
| lifeless | np | 23:25 |
| rocky | jelmer_: hey, does deleting tags not work with bzr-svn ? | 23:28 |
| poolie | jam, lifeless, i filed bug 391851 | 23:47 |
| ubottu | Launchpad bug 391851 in bzr "groupcompress holds a compressed full text for each file in each group" [Medium,Confirmed] https://launchpad.net/bugs/391851 | 23:47 |
| poolie | jml that's what you mentioned last night | 23:47 |
| lifeless | oh that reminds me | 23:47 |
| poolie | i don't think there was a bug for it previously | 23:47 |
| lifeless | I'll file one on skinny networkin | 23:47 |
| lifeless | g | 23:47 |
| poolie | ok, refer back to this one | 23:47 |
| poolie | i mean put in a see also | 23:47 |
| lifeless | Actually | 23:48 |
| lifeless | I think yours really should just be turned into 'skinny on the network please' | 23:48 |
| lifeless | as the other aspects were all considered and balanced during design. | 23:48 |
| lifeless | single commit having a full text isn't a drawback, as it makes commit fast; and group size is dynamically tuned based on file size | 23:49 |
| lifeless | poolie: ok if I repurpose it? or should I close it and file a targeted one for networking? | 23:49 |
| poolie | either is ok | 23:51 |
| poolie | i'd like the other one perhaps open at least at low priority | 23:52 |
| poolie | so it has a handle | 23:52 |
| lifeless | poolie: I'm not clear what it is meant to be though - I don't see anything in 391851 as a bug or defect, other than networking not being skinny | 23:53 |
| lifeless | poolie: quick call? | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!