| jelmer | KombuchaKip: I think that would have to be a part of it | 00:15 |
|---|---|---|
| KombuchaKip | jelmer: So basically poor poolie's got his work cut out for him. | 00:16 |
| jelmer | KombuchaKip: heh | 00:18 |
| jelmer | KombuchaKip: weren't you volunteering to do the work ? ;-) | 00:18 |
| KombuchaKip | jelmer: Hey man, happy to test it when he's got it written ;) | 00:19 |
| jelmer | KombuchaKip: :) | 00:43 |
| jelmer | spiv: I do actually wonder if a bzr background daemon would be a good idea | 00:44 |
| spiv | jelmer: it's a really nice idea in principle | 00:45 |
| jelmer | apart from automatically updating the dirstate on inotify changes it could take e.g. care of caching some of the data for nautilus-bzr and providing that | 00:45 |
| spiv | jelmer: in practice I think it'll be a bit tricky because I doubt the way the OS observes and reports filesystem changes is trivial to map cleanly to what the user thinks they're doing | 00:46 |
| jelmer | spiv: right, you wouldn't want to actually track the nasty stuff word does to its files.. | 00:46 |
| fullermd | With a shotgun, maybe ;p | 00:47 |
| spiv | jelmer: e.g. you'd want to deal nicely with apps that do "save" as "write to tmp dot file, atomic rename over new file", vs. "open existing file for write, write new contents (and maybe truncate?)", and goodness knows what other variationss | 00:47 |
| spiv | jelmer: I think it's probably tractable, at least for the majority of important cases | 00:48 |
| jelmer | spiv: thfair enough | 00:48 |
| spiv | So long as you don't want to try to do something like "auto-commit on every write", anyway | 00:48 |
| spiv | Which really wants to be an app-level hook, not OS level, for this sort of reason. | 00:49 |
| spiv | But for tracking renames, deletes, and *maybe* some kinds of adds, it seems like it could work. | 00:49 |
| spiv | (And potentially for tracking "hey this file has changed, you can assume it's dirstate info is stale now" for optimisation purposes, not sure that's really worth it though) | 00:50 |
| jelmer | spiv: yeah, thatÅÅ's the bit I was wondering about. it might have a significant impact in big trees | 00:58 |
| mwhudson | autocommit on every write would be shotgun inspiring | 01:01 |
| jelmer | IIRC the webdav support in mod_dav_svn can do that for you | 01:02 |
| mwhudson | yes | 01:04 |
| mwhudson | it was fairly shotgun inspiring, iirc :) | 01:04 |
| mwhudson | well, under some circs anyway | 01:05 |
| spiv | mwhudson: ISTR at least one emacs user on the list saying they have it hooked up to do that | 01:09 |
| spiv | mwhudson: and then they like to rebase -i or some other lossy operation to turn that into a pretty history later. | 01:10 |
| mwhudson | spiv: gosh | 01:10 |
| spiv | I can sort of see the appeal, even if I wouldn't do that myself :) | 01:10 |
| spiv | It's certainly an intriguing way to think about revision control | 01:11 |
| spiv | Why shouldn't the scope of your revision control tool include your individual saves, or even individual edits? | 01:11 |
| spiv | (And if it does, what should the UI look like?) | 01:12 |
| spiv | It certainly makes the difference between "record what I did" and "publish intelligible changes" a bit more important to describe | 01:13 |
| spiv | I think to an extent the fact it's currently easy to assume that "what I did" is so close to "what I want to share with others" does encourage the mindset that a little bit of rebasing to go from the former to the latter is the obvious thing to do. | 01:16 |
| === r0bby is now known as robbyoconnor | ||
| slangasek | vila: bug #884270> well, I don't currently have any branches needing merging :) | 02:39 |
| ubot5 | Launchpad bug 884270 in Ubuntu Distributed Development "bzr should do smarter merging of .po files" [High,In progress] https://launchpad.net/bugs/884270 | 02:39 |
| poolie | hey slangasek | 02:39 |
| poolie | he'll be asleep | 02:39 |
| poolie | he oughta anyhow | 02:39 |
| fullermd | Well, he says that about _me_ all the time... | 02:40 |
| slangasek | yes, he pinged me when I was asleep, so :) | 02:41 |
| poolie | spiv could you look over https://code.launchpad.net/~mbp/loggerhead/240580-tarball/+merge/83364 ? | 02:49 |
| spiv | poolie: seems ok at a glance, I'd be concerned about memory consumption but I see that's already a known issue | 03:02 |
| poolie | yeah | 03:09 |
| poolie | it makes some efforts to only stream things and not hold the whole tarball in memory | 03:09 |
| poolie | i think streaming individual files is out of scope for this | 03:09 |
| poolie | and indeed something i plan to go back to right after landing it- | 03:09 |
| spm | if we have a lightweight checkout; is the proper method of resyncing that back to it's master (basically we only have a readonly copy); simply to delete and re-check? | 04:53 |
| fullermd | Why do you need to resync? | 04:55 |
| spm | this is part of an automated rollout/update script; so ensuring it's up to date | 04:57 |
| fullermd | Sounds more like a call for update then. | 04:57 |
| spm | gnngh. I thought i tried that and it barfed on me. | 04:58 |
| spm | no, I did a bzr pull. | 04:58 |
| spm | that failed. | 04:58 |
| fullermd | Yeah, that would very probably not be what you want ;p | 04:59 |
| spm | do what i mean, not what I ask | 04:59 |
| spm | :-) | 04:59 |
| fullermd | I think darcs can do that. It takes a few months though. | 04:59 |
| spm | right, that works much cleaner. ta fullermd | 05:01 |
| fullermd | Oxygen consumption for the day: justified! | 05:01 |
| spm | heh | 05:01 |
| poolie | two screenfulls of active reviews! | 06:29 |
| poolie | hi vila? | 08:29 |
| vila | poolie: hey ! (sry, forgot to say hi) | 08:29 |
| poolie | np :) | 08:30 |
| poolie | hi jam? | 09:07 |
| jam | hi poolie | 09:07 |
| poolie | vila, would you mind trying to help https://answers.launchpad.net/bzr/+question/179594 | 09:45 |
| mgz | morning all. | 09:46 |
| poolie | hi mgz | 09:47 |
| vila | poolie: meh, I don't understand what the question is there ;) | 09:48 |
| vila | mgz: _o/ | 09:49 |
| poolie | well, that's why i'm finding it hard to deaol with it at 9pm friday | 09:49 |
| poolie | :) | 09:49 |
| vila | deaol == deal + eod, a sure sign you need to go enjoy your week-end ! ;-D | 09:54 |
| vila | (that was a gracious tip from a tyop expert ;) | 09:55 |
| poolie | jelmer, hi, it would be nice to do a followup that removes some copypaste from the hpss code | 10:38 |
| jelmer | hi poolie | 10:39 |
| jelmer | poolie: which copypaste specifically, just the catching of UnknownSmartMethod, followed by _ensure_real call, etc ? | 10:39 |
| poolie | yes, that sort of thing | 10:40 |
| poolie | not necessarily all of them at once | 10:40 |
| poolie | it just does seem pretty duplicative | 10:40 |
| mgz | was going to bug jelmer a bit about that in our review blitz today, | 10:40 |
| mgz | you've already done a good job on the queue overnight though poolie :) | 10:41 |
| poolie | thanks | 10:41 |
| poolie | i thought i ought to | 10:41 |
| jelmer | poolie: yes, thanks very much for the reviews | 10:41 |
| poolie | also, the unconscionably long delayed download tarball patch from xaav is going to be live soon | 10:41 |
| jelmer | poolie: I'll see if I can add a decorator | 10:41 |
| poolie | something like thta | 10:41 |
| mgz | the other thing I wonder about with the hpss changes if we want to start wrapping everything useful, rather than aiming at a curated subset, doesn't that take it all the way to a general RPC interface? | 10:45 |
| mgz | not that I'm sure the reduced surface area is very helpful currently, it's pretty trivial to dos a smart server | 10:45 |
| spiv | In the ideal world, I think we'd have relatively few RPCs, but ones that are powerful enough to efficiently satisfy all the needs | 10:46 |
| mgz | but it seems like the boilerplate isn't of much benefit right now. | 10:46 |
| mgz | spiv: that's my general feeling as well, but we don't seem very near that. | 10:46 |
| spiv | e.g. rather than get_revisions, it would be nice if that were somehow expressed as get_stream | 10:46 |
| spiv | (Or get_record_stream, whatever it is called) | 10:47 |
| poolie | ok, that's enough for today | 10:48 |
| spiv | Which is in one sense not really any different (what's the real difference between one more RPC and more kind of value for get_stream's argument?) | 10:48 |
| poolie | good night all | 10:48 |
| mgz | night poolie! | 10:48 |
| spiv | Good night! | 10:48 |
| spiv | But it feels a bit better to me, somehow | 10:48 |
| spiv | Especially as there's the potential to e.g. have iter_inventories reuse the same stuff | 10:49 |
| spiv | One thing that would help would be to make bzrlib's own internal APIs for the basic objects (Repository, Branch, perhaps a few others) narrower, or at least built on a narrow subset | 10:50 |
| spiv | Another instance was the bug about maybe adding RPCs to accelerate CommitBuilder. Again I think in a perfect world that would be built on this hypothetical subset | 10:52 |
| spiv | (But that's a case I haven't looked at closely at all, so that's just an intuition rather than a carefully considered opinion.) | 10:53 |
| mgz | narrow and clearly defined interfaces conflicts with the recent history of feature additions, though | 10:54 |
| spiv | Well, in the case of repository (a relatively easy case), what does it really need apart from locking, get_parent_map (and maybe a few other rev graph primitives?) and get_record_stream (with a sufficiently flexible way to describe which stream you need)? | 10:56 |
| spiv | And initialize and maybe config, I guess. | 10:57 |
| spiv | Oh, and insert_record_stream, of course :) | 10:57 |
| spiv | Branch I suppose adds config (including nick), tags, its intrinsic state (last revision info) | 10:59 |
| spiv | You need some way to either ask Branch to look up revids/revnos w.r.t. to its ancestry, or to ask a Repo to do that w.r.t. to that particular Branch's ancestry. | 10:59 |
| spiv | (e.g. to resolve a dotted revno to revid and vice versa) | 11:00 |
| mgz | hm, so get_signature_text and set_signature_text would instead use stream with params to say which repo bits they wanted? | 11:00 |
| spiv | mgz: right! | 11:00 |
| spiv | And there's possibly some special cases to reduce round trips | 11:00 |
| spiv | (e.g. ideally we could initialize a branch+repo+bzrdir, and have it all write-locked ready for insert_record_stream etc, in one RPC) | 11:01 |
| spiv | mgz: in fact, set_signature_text almost certainly could and should use insert_record_stream today | 11:01 |
| * spiv -> afk | 11:02 | |
| mgz | on the future feature front, a git-annex-y interface to repo would be neat | 11:04 |
| jelmer | spiv: sorry, was off getting some groceries | 11:07 |
| jelmer | spiv: thanks for your thoughts :) | 11:07 |
| jelmer | mgz: what do you mean with a git-annex-y interface exactly? | 11:08 |
| mgz | jelmer: a way for people to keep big files that can't be usefully versioned along with their repos | 11:12 |
| mgz | however slimlined bzr makes storing uncompressable, unmergable blobs, you'll never want the entire history of a video render copied around with the rest of the branch | 11:16 |
| mgz | without a certain amount of manual what lives where control like git-annex has, there's no way to satisfy the opposing needs | 11:18 |
| === yofel_ is now known as yofel | ||
| jelmer | mgz: still up for some peer-reviewing today? | 11:28 |
| jelmer | I'm not sure if there is actually much left | 11:28 |
| jelmer | ah, John's client-reconnect work | 11:28 |
| mgz | yeah, there are a few bits, and I especially got a headset thingy yesterday too, | 11:30 |
| mgz | so that needs testing out :) | 11:30 |
| jelmer | heh | 11:30 |
| * jelmer stumbles onto mumble | 11:30 | |
| jelmer | bzr: ERROR: Permission denied: "/root/foo/.bzr/branch-format": [Errno 13] Keine Berechtigung: u'/root/foo/.bzr/branch-format' | 11:40 |
| mgz | that's a german error without any non-ascii charas | 11:44 |
| jelmer | bzr: ERROR: Permission denied: "/root/ë/.bzr/branch-format": [Errno 13] Keine Berechtigung: u'/root/\xeb/.bzr/branch-format' | 11:45 |
| mgz | I think german is less non-ascii-ish than many other languages | 11:46 |
| mgz | 'Keine Berechtigung' needs a sharp-s or something to tickle it | 11:46 |
| mgz | ...did you type A-tilde, left arrows or is that a decode bug as well? | 11:47 |
| jelmer | No, I typed an e-umlaut | 11:47 |
| jelmer | mgz: http://pad.lv/894442 | 14:08 |
| ubot5 | Launchpad bug 894442 in Launchpad itself "Dynamic bug listings are too sparse" [High,Triaged] | 14:08 |
| mgz | right, I'm going to grab some food | 14:43 |
| jelmer | food, now there's an idea | 14:44 |
| mgz | I realised I was actually really hungry, and it's nearly 3 :) | 14:45 |
| jelmer | yeah, it's nearly 4 here and I haven't had lunch.. | 14:50 |
| mgz | all fooded up. | 15:48 |
| jelmer | \o/ | 15:49 |
| mterry | Hey bzr+Ubuntu folks! You need to file a MIR for subunit in Ubuntu. Your latest uploads are blocking on building until python-subunit enters main | 16:34 |
| mterry | I'll review after you file. Just ping me | 16:35 |
| vila | mterry: huh ? When did python-subunit *left* main ? | 16:38 |
| mterry | vila, I don't believe it's ever been in it | 16:38 |
| vila | mterry: I'm not the one doing the uploads but I remember the MIR have been filed releases ago | 16:38 |
| mterry | https://launchpad.net/ubuntu/+source/subunit | 16:38 |
| vila | python-subunit and subunit are different iiuc | 16:39 |
| mterry | vila, subunit is the source package | 16:39 |
| mterry | vila, but I see what you are talking about: https://bugs.launchpad.net/ubuntu/+source/subunit/+bug/780767 | 16:39 |
| ubot5 | Ubuntu bug 780767 in subunit (Ubuntu) "[MIR] subunit" [Undecided,Fix released] | 16:39 |
| vila | jelmer: ^ ? | 16:39 |
| vila | ha, jelmer knows already then | 16:40 |
| jelmer | vila: hi | 16:40 |
| jelmer | mterry: hi | 16:40 |
| mterry | yup, left comment and changed bug status | 16:40 |
| mterry | vila, thanks | 16:41 |
| vila | mterry: thanks for raising the issue | 16:41 |
| jelmer | mterry: somebody in #ubuntu-devel mentioned that the promotion to main wouldn't actually happen until somebody in main (or seed) depended on it | 16:41 |
| mterry | jelmer, well that's the case now :) | 16:42 |
| mterry | jelmer, or are you saying that it has been promoted but won't "show up" until it's seeded? | 16:42 |
| mterry | whatever, it'll sort itself out now one way or the other | 16:43 |
| jelmer | mterry: that's my understanding (and why I uploaded with this dependency, despite the fact that subunit wasn't in main yet) | 16:43 |
| jelmer | mterry: that's great, thanks :-) | 16:43 |
| mgz | vila: do you want to look at jam's client reconnection branch again, or are you okay with us trying to land it now? | 17:38 |
| vila | mgz: I'm ok with you ;-) | 17:38 |
| mgz | ...there are various fun conflicts to resolve first, but jelmer is having a conflict day already | 17:45 |
| lamalex | lifeless, is there any sort of glib runner for testtools? | 17:48 |
| lamalex | i started working on one but vaguely remember thumper mentioning one existed in some form | 17:48 |
| lamalex | jml, ^^^ | 17:53 |
| jml | lamalex: there's tribunal | 17:53 |
| jml | lamalex: testtools is runner-agnostic though, you can use whatever works with standard unittest | 17:54 |
| cr3 | hi folks, I'm trying to import bzrlib.plugins.loom.branch on lucid and I get: ImportError: No module named loom.branch. | 17:59 |
| cr3 | I'm using the bzr ppa and I should have the latest updates: http://pastebin.ubuntu.com/749515/ | 17:59 |
| mgz | cr3: from outside the context of bzrlib? | 18:03 |
| mgz | you'd need to call bzrlib.plugin.load_plugins() first to get the import paths right. | 18:04 |
| cr3 | mgz: thanks, that worked swimingly | 18:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!