| briandealwis | I'm having strange locking problems on MacOS X where bzr is complaining about a lock being held — but it's the same process | 00:04 |
|---|---|---|
| briandealwis | This is with 2.3.0 | 00:04 |
| briandealwis | I have a branch bound to another branch, that is itself bound to another branch | 00:04 |
| briandealwis | It's complaining trying to acquire a lock to the third branch | 00:04 |
| spiv | That sounds like a familiar issue | 00:05 |
| spiv | I'll see if I can find a bug report about that | 00:05 |
| mgz | If there's something horribly wrong in my last post to the list, someone please correct me. | 00:07 |
| spiv | briandealwis: it might be related to https://bugs.launchpad.net/bzr/+bug/412223, but I think there's something specific to 2.3.0 because I think there's been a small spike in reports of it happening | 00:09 |
| ubot5 | Ubuntu bug 412223 in Bazaar "bzr up locks master branch" [High,Confirmed] | 00:09 |
| spiv | briandealwis: I can't find an obvious bug about it though, so I guess file a new report. Maybe we've regressed in how we handle a bound branch of a bound branch? | 00:10 |
| briandealwis | spiv: I don't think that's right. At least all my branches are local and fully-qualified | 00:10 |
| briandealwis | And I just unbound the second level, and it's still occurring. | 00:10 |
| briandealwis | Weirdness. | 00:10 |
| spiv | Indeed! | 00:10 |
| briandealwis | spiv: hmm, I'll have to dig into this tomorrow. It doesn't seems to only happen with a particular branch pair | 00:14 |
| spiv | briandealwis: ok. I think the contents of the .bzr/branch/branch.conf files would be particularly interesting | 00:15 |
| briandealwis | spiv: the only thing that's different is that I have some post-commit hooks to trigger a hudson build | 00:15 |
| spiv | Oh, and the traceback, of course :) | 00:16 |
| briandealwis | How do I force a branch back to a previous version? "bzr pull . -r −1" doesn't seem to do it… | 00:21 |
| lifeless | jelmer: when you are around | 00:22 |
| lifeless | https://bugs.launchpad.net/loggerhead/+bug/728691 | 00:22 |
| ubot5 | Ubuntu bug 728691 in loggerhead "loggerhead NoSuchRevision: KnitPackRepository exception" [Undecided,Incomplete] | 00:22 |
| briandealwis | ah, —overwrite it the key: "bzr pull . —overwrite -r −4" | 00:25 |
| spiv | mgz: replied :) | 00:27 |
| spiv | briandealwis: yep, --overwrite | 00:27 |
| jelmer | lifeless: hi | 00:28 |
| jelmer | lifeless: hmm | 00:28 |
| mgz | spiv: aha, there was a generic method, thanks. what's still not clear to me is what initialisation steps need/should really be done first. | 00:29 |
| jelmer | lifeless: Is there actually any reason for that method to use revision_trees() rather than get_revision_delta() ? | 00:29 |
| lifeless | jelmer: good question | 00:29 |
| lifeless | jelmer: that may be addressed by jams historydb work | 00:29 |
| spiv | mgz: just bzrlib.initialize(), IIRC | 00:30 |
| lifeless | with bzrlib.initialze(): do stuff | 00:31 |
| briandealwis | spiv: I put the branch.conf and .bzr.log at http://pastebin.com/cmv6ZWqv | 00:33 |
| briandealwis | spiv: I thought it might be related to a plugin, but doesn't seem to be | 00:33 |
| mgz | is that true even with hooks? you can't use run_bzr like that because it doesn't know about the commands, do any of the command objects themselves depend on hooks that aren't installed by default? | 00:34 |
| lifeless | mgz: there is an entry point for running commands that adds the bzr-internal command hooks | 00:35 |
| lifeless | mgz: its what the bzr script calls | 00:35 |
| mgz | but it's not part of initialize. | 00:36 |
| lifeless | right | 00:36 |
| lifeless | commands.install_bzr_command_hooks | 00:37 |
| lifeless | which is called by run_bzr_catch_errors | 00:37 |
| lifeless | and run_bzr-catch_user_errors | 00:37 |
| lifeless | which is called by main() | 00:38 |
| lifeless | mgz: start with bzrlib.commands.main() | 00:38 |
| mgz | one of the important bits there seems to be _register_builtin_commands which doesn't have a public alternative as far as I can see. | 00:39 |
| lifeless | nope | 00:39 |
| spiv | briandealwis: hmm, could you add -Dlock to the command line and paste the .bzr.log from that? That should tell us where the locking is happening. | 00:39 |
| lifeless | mgz: thats more plumbing :) | 00:39 |
| lifeless | mgz: if you want to use the inbuilt command dispatch, calling main() is the key | 00:40 |
| briandealwis | spiv: log at http://pastebin.com/68x4VM1n | 00:42 |
| briandealwis | spiv: oops, that didn't work | 00:42 |
| briandealwis | spiv: sorry, try this: http://pastebin.com/JptmhQUT | 00:43 |
| ovnicraft | hello, i found this plans http://doc.bazaar.canonical.com/developers/colocated-branches.html for 2.4 what is the state of this ? | 02:36 |
| spiv | ovnicraft: jelmer has the most up to date info I think | 02:47 |
| spiv | ovnicraft: IIRC, most if not all of the core infrastructure in the code now exists | 02:48 |
| spiv | ovnicraft: so what's left is mainly the UI | 02:48 |
| ovnicraft | we have problems with all modules in our repo each module/directory has dependencies each other i was thinking in a module to manage this and canc clone just the dep | 02:54 |
| ovnicraft | i need colocated for this ? | 02:54 |
| ovnicraft | can* | 02:54 |
| beuno | lifeless, ping | 02:57 |
| lifeless | beuno: hi | 02:58 |
| beuno | lifeless, hey! | 02:58 |
| beuno | so, I got into loggerhead hacking again | 02:58 |
| beuno | trying to get this tarball thing proposable | 02:58 |
| beuno | I've got it working | 02:58 |
| lifeless | have you looked at launchpad_loggerhead? thats the glue we use to run lh in lp | 02:58 |
| beuno | now, I'm trying to figure out what the best way to make it easy for LP to turn it off | 02:59 |
| beuno | I haven't in 2 years I think | 02:59 |
| spiv | ovnicraft: there are some existing plugins that may help you | 02:59 |
| lifeless | beuno: you should | 02:59 |
| beuno | lifeless, where can I grab that from? | 02:59 |
| ovnicraft | spiv, maybe a clue | 03:00 |
| lifeless | beuno: because we'd turn it off from there, whatever the mechanism - we'd be adding the hook or $whatever | 03:00 |
| lifeless | beuno: lib/launchpad_loggerhead | 03:00 |
| spiv | ovnicraft: bzr-colo, bzr-colocated, bzr-scmproj | 03:00 |
| beuno | lifeless, that assumes I have the LP tree :) | 03:00 |
| lifeless | beuno: yes, yes it does | 03:00 |
| beuno | lifeless, lets pretend I don't | 03:00 |
| lifeless | beuno: we have loggerhead running on lp | 03:01 |
| lifeless | bazaar.launchpad.net/~launchpad-pqm/launchpad/devel | 03:01 |
| lifeless | beuno: I hear you can browse via it | 03:01 |
| ovnicraft | spiv, yes i am checkin' bzr-colo so i need your opinion here to manage this if i am clear | 03:01 |
| beuno | sounds like en evil technology | 03:01 |
| ovnicraft | managing dependencies using colocated and write a plugin | 03:01 |
| lifeless | ovnicraft: easiest way to make it fast is to setup one, or perhaps several, shared repositories | 03:02 |
| lifeless | ovnicraft: then use bzr-scmproj - the repository will cache data locally for you | 03:03 |
| spiv | ovnicraft: I agree with lifeless; my guess is bzr-scmproj will either do what you want or be a good starting point for building what you want. | 03:04 |
| ovnicraft | sound ok i want to do something like bzr branch lp:project --myproj-modulename | 03:05 |
| ovnicraft | and maybe gets another modules | 03:06 |
| ovnicraft | like bzr pull --myproj-anothermodule | 03:06 |
| spiv | ovnicraft: I wouldn't think colocated branches would be a natural fit for managing a collection of different modules and their dependency relationships. It seems to me that colocated branches are better suited to tracking multiple versions of a single project (e.g. to have all of bzr 2.0, bzr 2.1, bzr 2.2, bzr 2.3 and bzr trunk branches). | 03:06 |
| ovnicraft | in that ways looks better so the problem is when cloning (if plugin exists) need just a copy from module and their deps | 03:08 |
| ovnicraft | and can pull more modules | 03:09 |
| beuno | lifeless, up for a loggerhead review? | 03:49 |
| beuno | anyway, sleep now | 03:52 |
| beuno | jam, if you happen to be around, https://code.launchpad.net/~beuno/loggerhead/export-tarball/+merge/52797 | 03:52 |
| beuno | oooops | 03:52 |
| beuno | this branch has things committed it shouldn't | 03:52 |
| beuno | gar... in the first revision | 03:53 |
| beuno | ok, really sleep now | 04:07 |
| * beuno waves | 04:08 | |
| spiv | vila: hmm, 16 package imports failing due to LockContention? That seems odd. | 04:30 |
| === Ursinha is now known as Ursinha-afk | ||
| vila | spiv: not fully there yet, but didn't bzr get upgraded on jubany ? | 06:43 |
| vila | spiv: there have been a few bugs around LockContention lately (one in particular has to do with connection reuse in builddeb ?) | 06:49 |
| vila | ok, I'm in, spiv ? | 07:22 |
| spiv | vila: there's an rt for upgrading bzr on jubany, but it hasn't been done yet IIRC | 07:39 |
| spiv | rt 44398 | 07:39 |
| vila | bzr version says 2.3b5 (which in itself is pretty weird, why b5 ???) | 07:40 |
| vila | ha right, so this points to bug #726854 which indeed mentions reusing transports (I didn't dig that though) | 07:43 |
| ubot5 | Launchpad bug 726854 in SABnzbd "Upgrading queue from 0.5.x to 0.6.0 can fail" [Critical,Fix released] https://launchpad.net/bugs/726854 | 07:43 |
| spiv | vila: specifically I saw LockContention on a local branch, though | 07:44 |
| spiv | vila: http://package-import.ubuntu.com/status/udev.html#2011-02-24%2020:39:43.444410 | 07:44 |
| vila | grr bug #726584 | 07:44 |
| ubot5 | Launchpad bug 726584 in Ubuntu Distributed Development "flash-kernel import fails apparently mismatching maverick and natty branches" [Undecided,New] https://launchpad.net/bugs/726584 | 07:44 |
| vila | *local* branch ? Urgh | 07:45 |
| maxb | vila: Hi. I think I'll rename bzr.webdav now, since there have been no objections | 07:50 |
| vila | maxb: please do ! Sorry I didn't find the time to do it myself :-/ | 07:50 |
| maxb | not a problem | 07:51 |
| * vila is still fighting to unbrick a natty vm... | 07:51 | |
| maxb | nothing too vital trapped inside it, I hope? | 07:51 |
| vila | no, it's ok | 07:51 |
| vila | what is a 'held package' ? | 07:51 |
| spiv | A virtual brick? | 07:51 |
| vila | update-manager is telling me: E:Error,pkgProblemResolver::Resolve generated breaks, this may be caused by help packages... | 07:53 |
| vila | spiv: :) | 07:53 |
| maxb | vila: A held package is one which has been placed on hold in aptitude or dpkg by the local sysadmin, to prevent automatic upgrades | 07:57 |
| vila | urgh, I can't remember doing that, how can I find it or them ? | 07:57 |
| maxb | dpkg -l | egrep ^h | 07:58 |
| vila | empty :-/ | 07:59 |
| spiv | I guess held packages aren't the problem then! | 07:59 |
| maxb | My general advice on encountering any sort of dependency chaos is that the interactive curses mode of aptitude is a wonderful tool :-) | 07:59 |
| vila | ha, let me try that | 08:00 |
| * vila restores last backup | 08:01 | |
| vila | the nice thing with vms is that they are easy to restore, just use the whole disk backup :) | 08:02 |
| vila | ok, that's 6GB, but still :D | 08:02 |
| jam | morning vila, evening spiv | 08:27 |
| vila | hi jam | 08:27 |
| mr-russ | out of curiosity, what tools to bzr developers use for development? vi, eclipse or something else? | 08:30 |
| lifeless | mr-russ: depends on the dev | 08:37 |
| lifeless | mr-russ: most are vim, at least one is emacs | 08:37 |
| jam | mr-russ: If I was using an idea, it would probably be Wing. Lots of good stuff there, but their VI-mode was lacking | 08:43 |
| jam | It might have gotten better since | 08:43 |
| jam | it was a year or two ago | 08:43 |
| jam | IDEs can be great, but VIM just rocks as a text editor | 08:43 |
| mr-russ | I've just never found a comfortable tools on linux that feels like I'm doing things fast. vi is pretty good, but my skills ain't brilliant, especially with shortcuts for going into functions and back, like ctags | 08:44 |
| jam | ^] | 08:45 |
| jam | or you're saying you know that but don't feel great with using it? | 08:45 |
| jam | Once you have vim muscle memory, it is pretty hard to use another editor, IME | 08:45 |
| soren | jam: I'd love to see you write code: wing - Galaga-like arcade game | 08:45 |
| jam | WingIDE | 08:46 |
| jam | http://wingide.com/ | 08:46 |
| soren | Aw, that's no fun at all. | 08:46 |
| jam | soren: but yes, that would be pretty awesome | 08:46 |
| jam | squashing bugs in real time, baby | 08:46 |
| vila | maxb: unbricked ! I had to reinstall the vbox additions which confused me for a bit though | 08:57 |
| vila | maxb: thanks for the aptitude trick ! | 08:57 |
| mok0 | "Branch to merge into, rather than the one containing the working directory." Does anyone understand that? I don't | 09:15 |
| mok0 | (from bzr merge --help) | 09:15 |
| vila | mok0: yes, almost everybody :) | 09:15 |
| vila | mok0: by default you merge in the directory you're working | 09:15 |
| mok0 | vila: ah, yes I see :-) | 09:16 |
| mok0 | vila: that help text could be better though :-) | 09:16 |
| vila | mok0: if, for whatever reason, you want to merge into *another* directory than the current one, you use -d | 09:16 |
| vila | mok0: certainly | 09:16 |
| mok0 | vila, I'd prefer (cd ../otherdir ; bzr merge ) | 09:16 |
| vila | mok0: so you don't need -d | 09:17 |
| mok0 | vila: right | 09:17 |
| vila | mok0: but if you have a good idea for a better phrasing, patch welcome ! | 09:17 |
| mok0 | vila: patch? That would take me an hour | 09:18 |
| mok0 | vila: I can submit a bug | 09:18 |
| vila | bzr branch lp:bzr ; hack hack, bzr commit ; bzr push lp:~<lp_login>/bzr/better-merge-help ; bzr lp-propose ; done | 09:19 |
| vila | mok0: sure, a bug is a good starting point | 09:19 |
| mok0 | vila: I could try. Never hacked on bzr before | 09:19 |
| mok0 | vila: heh lp is down | 09:27 |
| vila | mok0: ooohhhhhh, paaaaaaaaiiiiinnnn | 09:27 |
| mok0 | vila: actually, what I was looking for is a "dry-run" switch for merge | 09:28 |
| vila | mok0: db upgrade in progress, should be back in ~90 minutes at max :-/ | 09:28 |
| vila | mok0: --preview | 09:28 |
| vila | mok0: http://identi.ca/launchpadstatus for tracking lp status | 09:29 |
| mok0 | vila, oh, thanks. I got so puzzled at the -d switch I didn't discover that... | 09:30 |
| vila | mok0: :) | 09:30 |
| vila | mok0: almost all bzr commands accept a -d switch | 09:30 |
| mok0 | vila: I am slowly trying to become a more sophisticated bzr user. Not doing too well ;-.) | 09:30 |
| vila | mok0: take your time ;) | 09:31 |
| mok0 | vila: I guess the -h texts are not the best avenue for that endeavour | 09:31 |
| mok0 | vila, will --preview give me an indication of potential conflicts? | 09:32 |
| vila | mok0: well, they should. They are supposed to help... May be not the newcomers that may be better served by http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/index.html but still | 09:32 |
| mok0 | Because sometimes I'd like to put off a merge if there are conflicts | 09:32 |
| vila | yes, --preview will tell you about conflicts | 09:33 |
| mok0 | vila, I've read those docs many times | 09:33 |
| mok0 | vila: but my brain is old and fragile | 09:33 |
| vila | yeah, brains tend to become fragile when you get old, but they are also supposed to be more effective ;) | 09:34 |
| mok0 | vila: perhaps what I need is a reference-manual type document, with examples | 09:34 |
| mok0 | vila: effective? I guess... I am still going pretty ok at 10% capacity :-) | 09:34 |
| vila | wow, indeed, if you're able to discuss with *me* at 10% capacity, that's surely a good sign :D | 09:35 |
| mok0 | vila: the tutorials are fine for getting started, but they never give you the full story | 09:35 |
| vila | http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/index.html then ? | 09:35 |
| mok0 | vila, perfect! Bookmarked! | 09:36 |
| vila | http://doc.bazaar.canonical.com/bzr.dev/en/ is the starting point | 09:36 |
| mok0 | vila, one problem I meet in my daily workflow is this: | 09:37 |
| vila | or even http://doc.bazaar.canonical.com/en/ (except there is currently a bug there, 2.3 being the stable version, the links are valid, only the numbers are wrong) | 09:37 |
| mok0 | I have upstreams subversion branch mirrored on LP. I have a packaging branch off that | 09:38 |
| mok0 | upstreams branch contains a whole bunch of stuff that doesn't get into the distribution tarball ("make dist" tarball") | 09:38 |
| mok0 | to avoid getting a huge .diff.gz file, I have deleted everything from the packaging branch that does not go into the dist tarball | 09:39 |
| mok0 | that normally works fine, but when upstream has edited one of the "un-needed" files, I get conflicts | 09:40 |
| vila | :-/ | 09:40 |
| mok0 | I just need to resolve them, but it is a drag | 09:40 |
| mok0 | Most of the time, the merge goes smoothly, but I'd like to check if a merge would generate conflicts ahead of time. So perhaps --preview can help me there | 09:41 |
| vila | There are several works in progress to address that, including the ability to specify either globally or on a file-by-file basis that you don't care about modifications to deleted files | 09:41 |
| vila | --preview should help | 09:41 |
| mok0 | vila: ultimately, we shouldn't have to rely on tarballs for source packages, but... | 09:42 |
| vila | you should also be able to say 'bzr resolve --take-this <file>' to resolve the conflict where <file> is involved | 09:42 |
| vila | mok0: that's call UDD, see https://wiki.ubuntu.com/DistributedDevelopment | 09:43 |
| * mok0 goes off to bzr reference manual to see :-) | 09:43 | |
| mok0 | vila: yeah, I've been tracking that now and then, but much of it goes over my head. | 09:43 |
| vila | mok0: then this needs to be fixed | 09:44 |
| vila | not your head... | 09:44 |
| mok0 | vila: It is my religious belief that the packaging branch should be a child of upstream | 09:44 |
| mok0 | vila: and some of the current practices are not like that AFAIU | 09:44 |
| mok0 | vila: as like having debian/ in its own branch | 09:45 |
| vila | mok0: <cough> I'm (still) not a seasoned packager myself, but I'd like to get there and yes, the idea is that upstream should be a parent branch | 09:45 |
| vila | mok0: yup, we hope to get away from this practice as soon as it becomes *easier* to *not* use it | 09:45 |
| mok0 | vila: I also haven't grasped looms yet, which seems to be central in the whole patch thing | 09:46 |
| vila | mok0: looms are discussed indeed but needs some polish to be fully usable | 09:46 |
| mok0 | vila: ... unfortunately 3.0 (quilt) seems to have consolidated the way patches are treated | 09:46 |
| vila | mok0: think of looms as a stack of branches with upstream at the bottom | 09:47 |
| mok0 | vila: sort of like git? | 09:47 |
| mok0 | git branches? | 09:47 |
| vila | no, git branches are more like colocated branches where you switch from one branch to the other without any enforced relationship between them | 09:48 |
| mok0 | vila: I guess I should just try looms. I've put it off, because I've read (like you said) that looms "need some polish" | 09:49 |
| vila | colocated branches help using a single working tree when ... it matters. It can be because it's expensive to maintain (lots of compilations), it can be a convenience | 09:49 |
| vila | mok0: they need polish for the udd case, I use them daily myself | 09:49 |
| mok0 | I see | 09:49 |
| mok0 | Perhaps I should just try them. Doesn't it add another layer of complexity? | 09:50 |
| vila | mok0: you can think of them as an alternative to quilt (IIUC) where each patch is turned into a branch (and as such get an history) | 09:50 |
| vila | mok0: it depends on your workflow | 09:50 |
| mok0 | vila: hm, that sounds useful. I use quilt a lot | 09:50 |
| mok0 | vila: I am patching upstreams code quite a lot, and I keep all my changes in quilt patches | 09:51 |
| vila | I use looms when I want to work on a bug feature for a long time and create threads for pieces I can submit for inclusion in trunk | 09:51 |
| vila | s/bug/big/ | 09:51 |
| === Ursinha-afk is now known as Ursinha | ||
| mok0 | vila: threads? Uh-oh, another concept.. :-) | 09:51 |
| mok0 | vila: so, can I use looms in one branch and not another? | 09:52 |
| vila | mok0: a loom is composed by threads, a thread is just a funny name for a branch but with a name and a position in the loom | 09:52 |
| vila | mok0: yes, you can go from branches to looms | 09:52 |
| mok0 | vila: so looms replace branches? | 09:53 |
| vila | mok0: one part that need polish in looms is when you want to collaborate on looms, merging looms is... not implemented yet for example | 09:53 |
| mok0 | vila: ah, so they're for personal use | 09:53 |
| vila | well, technically they are a branch format | 09:54 |
| vila | mok0: in their actual state, they are safe to use for personal use, there are some rough edges when you try to share them | 09:54 |
| mok0 | vila, so I can make a child branch and turn that into a loom? | 09:54 |
| vila | mok0: pipelines are an alternative that some people prefer | 09:55 |
| vila | yes | 09:55 |
| vila | bzr loomify | 09:55 |
| vila | err | 09:55 |
| mok0 | vila: and what will LP say to that? | 09:55 |
| vila | For example, when I start a loom, I do: | 09:55 |
| vila | bzr branch lp:bzr new-stuff | 09:56 |
| vila | cd new-stuff; bzr nick bzr.dev # to track trunk | 09:56 |
| vila | bzr create-thread stuff | 09:56 |
| vila | from there I have two threads in the loom, I'll use the 'stuff' one to develop my new feature and commit there | 09:57 |
| vila | when I want to resync with trunk I do: bzr switch bzr.dev ; bzr up-thread | 09:57 |
| vila | err | 09:57 |
| vila | when I want to resync with trunk I do: bzr switch bzr.dev ; bzr pull -v ; bzr up-thread | 09:57 |
| mok0 | vila: "up-thread" ? | 09:58 |
| vila | the pull will update by base thread to the current version of trunk and 'up-thread' will merge my changes onto this new trunk | 09:58 |
| vila | it's a command provided by the loom plugin | 09:58 |
| vila | and lp knows about looms so you can push there like any other branch | 09:58 |
| mok0 | vila: it does sound a bit like a git-like workflow | 09:59 |
| mok0 | vila: beneath a bzr branch | 09:59 |
| vila | mok0: you mean rebase ? | 09:59 |
| mok0 | vila: no, I mean like having a stack of branches in a single directroy | 10:00 |
| vila | AFAIK with git you get a *set* of branches, not a stack | 10:00 |
| mok0 | vila: ah yes, that's true | 10:01 |
| mok0 | vila: so with threads, you can only merge "down" ? | 10:01 |
| vila | well, up :) | 10:01 |
| mok0 | :-D | 10:01 |
| mok0 | vila: and when you do that, the stack becomes lower? | 10:02 |
| vila | well, the pointer goes up | 10:02 |
| vila | each thread is fully included in the upper ones | 10:03 |
| mok0 | vila: but the bottom two threads will then be identical? | 10:03 |
| vila | if they are you use combine-threads to delete the upper one, it means you don't carry changes anymore in this thread | 10:03 |
| vila | it happens when the changes have landed on trunk | 10:03 |
| mok0 | vila: It's starting to dawn... | 10:04 |
| vila | it's a bit like maintaining a series of patches except you keep track of the history (roughly) | 10:04 |
| mok0 | vila: that sounds very useful | 10:05 |
| mok0 | vila: I should "just try it" | 10:05 |
| mok0 | vila: so I am maintaining my patches in quilt in the packaging branch. Where should I have the looms though? In "trunk" or in "ubuntu"? | 10:07 |
| vila | mok0: vast question :) | 10:08 |
| mok0 | vila: I was afraid so :-) | 10:08 |
| vila | mok0: the current theory is that you work in a loom with the following threads (starting from bottom): upstream, debian packaging, ubuntu packaging | 10:09 |
| vila | now, for the quilt patches, you can also add one thread by patch | 10:09 |
| vila | and that's where the discussion is roughly as there are various ways to handle the quilt patches with or without threads | 10:09 |
| mok0 | vila: but when you do "bzr builddeb" you need the debian/patches directory to be populated | 10:10 |
| vila | mok0: and I can't say much more on the topic as I don't know quilt :-/ | 10:10 |
| mok0 | vila: quilt just manages a stack of patches | 10:10 |
| vila | mok0: you'll need a better packager than me to answer this one ;D | 10:10 |
| mok0 | perhaps bzr builddeb know how to deal with looms | 10:11 |
| vila | mok0: the idea is that it's better to work with the patches applied than working with diffs of diffs | 10:11 |
| vila | mok0: not yet (AFAIK) | 10:11 |
| * maxb eeps at the size of scrollback.... what's the unanswered question, and can I help? :-) | 10:12 | |
| vila | mok0: but the plan is to teach builddeb to (hand waving) make it easier :D | 10:12 |
| mok0 | vila: I think just needs to try it | 10:12 |
| vila | mok0: maxb is a *far* better packager than me for one ;) | 10:12 |
| mok0 | vila: that would be cool. But of course packaging policies are decided in Debians dungeons | 10:13 |
| mok0 | maxb: we are discussing packaging using looms | 10:13 |
| mok0 | maxb: and I am asking more questions than 20 geniuses can answer :-) | 10:14 |
| maxb | Yes it's all a bit of an unresolved question | 10:14 |
| maxb | I think some people see a utopia where quilt series get mapped into looms, such that you keep history of the patch series too | 10:15 |
| mok0 | maxb: I described my branchs 25 minutes ago (10:38 my time) | 10:16 |
| maxb | *gah*, I am being summoned afk, sorry | 10:16 |
| mok0 | maxb: ah | 10:16 |
| mok0 | maxb, let me copy-paste a bit | 10:16 |
| mok0 | maxb, http://paste.ubuntu.com/578269/ | 10:18 |
| mok0 | maxb: I also asked vila on advice for maintaining my patches and we discussed looms | 10:20 |
| maxb | On the subject of the pastebin, that's a tricky one. | 10:29 |
| maxb | I think bzr core could use some way of being told that files are being deleted and you really don't care what upstream does with them from then on | 10:29 |
| maxb | However, you might be interested in using bzr-builddeb | 10:30 |
| maxb | If, instead of merging normally from the upstream import, you use its merge-upstream command, it will not only help you track what is in the tarballs, but will embed pristine-tar metadata in the packaging branch such that original tarballs can be rebuild from it | 10:31 |
| maxb | It goes like this: | 10:31 |
| maxb | bzr merge-upstream --version upstream-version path-or-url-to-upstream-tarball path-or-url-to-upstream-import-branch -r tag:the-tag | 10:32 |
| maxb | When you do this, bzr-builddeb will commit the contents of the tarball, associating it as a merge commit with the revision in the upstream import branch specified by the -r switch | 10:33 |
| mok0 | maxb: but I really think as a matter of philosophy that the packaging branch should be a child off upstreams branch | 10:34 |
| catphish | morning | 10:34 |
| maxb | As for the looms, I'd be tempted to loomify the packaging, and simply not bother with a quilt series at all | 10:35 |
| mok0 | maxb: ah, didn't read your last comment properly | 10:35 |
| maxb | I would use debian/source/options to put dpkg into single-debian-patch mode | 10:35 |
| mok0 | maxb: but I need a quilt series once the package is created? | 10:35 |
| maxb | mok0: ish. your series can contain a single monolithic patch | 10:36 |
| mok0 | maxb: single-patch mode? | 10:36 |
| mok0 | ah | 10:36 |
| mok0 | maxb: like the old diff.gz file | 10:36 |
| maxb | googling for reference, one moment | 10:36 |
| maxb | Point number 4 in http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/ | 10:37 |
| * mok0 looks | 10:37 | |
| mok0 | maxb: I've been avoiding 3.0 (quilt) ... I think it sux | 10:38 |
| catphish | i'm struggling to understand what initiates the execution of post_change_branch_tip hooks | 10:39 |
| maxb | This mostly makes it unsuck by making it behave like 1.0 :-) | 10:39 |
| catphish | i have configured one, and if i commit or push locally, it is executed, but if i push to the server remotely it is not | 10:40 |
| mok0 | maxb: I like the idea of debian/ in a tarball, but it is really unmanageable that unintentional changes to your source tree finds their way into debian/patches. That really sucks | 10:40 |
| mok0 | maxb: I usually do a quick lsdiff -z ...diff.gz to check that nothing but debian/ is added | 10:40 |
| maxb | catphish: Your hook is installed for the user that the server is executing as? | 10:41 |
| mok0 | maxb: with 3.0, I need to unpack the debian tarball and go look | 10:41 |
| catphish | yes | 10:41 |
| catphish | i am executing with -Dhooks | 10:47 |
| catphish | but that doesn't tell me that they're trying to be executed | 10:47 |
| catphish | http://paste.codebasehq.com/pastes/0177vm21a108 | 10:48 |
| catphish | it works if i push to the same repository locally, but not remotely over bzr serve --inet | 10:50 |
| vila | jelmer: before I forget: it would be nice if you could add an entry in the what's-new for 2.4 about the bunch of changes related to both the weave-as-plugin and the foreign plugins being better tested | 10:57 |
| vila | jelmer: may be more than one entry in fact;D | 10:58 |
| catphish | vila: any idea who i should talk to regarding hooks? | 11:18 |
| catphish | i'd read the code if i were just a little smarter | 11:19 |
| vila | catphish: lunch time right now, bbl (I'm freezing 2.3.1 though) | 11:20 |
| vila | catphish: but first things first, make sure you get the right code on the server when testing for hooks and remember that paths may be different (if you use them to parametrize your hooks) | 11:20 |
| catphish | ooo 2.3 1 :) | 11:21 |
| catphish | right code? | 11:21 |
| catphish | anyway enjoy lunch | 11:21 |
| catphish | i'd enjoy lunch more if i were in france i think | 11:22 |
| jelmer | vila: Sure | 11:25 |
| jelmer | vila: weave as a plugin hasn't really landed (yet) though | 11:26 |
| vila | jelmer: last I looked at the mp I understood you wanted to push some more changes or split it, should I look again ? | 11:33 |
| vila | catphish: hehe, back, very quick lunch, light, but prepared by my daughter which gave it this invaluable love touch ;) | 11:34 |
| catphish | :) | 11:34 |
| jelmer | vila: Yeah, that's still the case (unless you feel like reviewing a 4k-line branch :)) | 11:34 |
| vila | jelmer: not *that* much ;) | 11:35 |
| vila | catphish: ok, so given your pastebin it looks like the code is in the right place, to be extra sure, you can try 'bzr plugins -v' on the server to check which plugins are seen there | 11:43 |
| catphish | yeah it shows up in bzr plugins | 11:44 |
| vila | catphish: there may still be some env variations between your shell and your server but if the log comes from the server, you should be good | 11:44 |
| catphish | that log i pasted it generated when pushing through the web server | 11:44 |
| vila | ok, so I don't know the shellhooks plugin, how do you associate actions with branches there ? | 11:44 |
| catphish | http://paste.codebasehq.com/pastes/5ngeu2bx9wxb | 11:45 |
| vila | hmm, the author's name rings a bell <sarcasm> :D | 11:45 |
| catphish | lol | 11:45 |
| catphish | i rearranged it to be a little simpler for my needs | 11:45 |
| catphish | and if i push locally between 2 directories, the hook runs | 11:47 |
| vila | right, so the idea there is that the hook is always called and pass the basedir to the shell script ? | 11:47 |
| vila | locally == on the server | 11:47 |
| catphish | correct | 11:47 |
| catphish | the plugin isn't installed on the client machine | 11:48 |
| vila | hey ! if you push locally you don't involved the server code no ? | 11:48 |
| catphish | that's also correct | 11:48 |
| catphish | pushing locally between dirs on the server is 100% bzr code | 11:48 |
| catphish | ie. "bzr push /path/to/repo" | 11:49 |
| vila | hmm, so you probably don't use the right hook or the hook is not implemented correctly server-side | 11:49 |
| vila | ok, so the doc explicitly mention the server for post_change_branch_tip | 11:50 |
| spiv | Possible gotchas: 1) environment you're running 'bzr serve --inet' in might see different plugins? 2) paths the server sees might not be what you expect (chroot transports and such) | 11:50 |
| vila | spiv: the plugin doesn't filter the paths, it just pass them to the called shell command (AFAICS) | 11:51 |
| spiv | I'm about to go to bed, but hopefully that's enough clues for vila to work with :) | 11:51 |
| vila | hehe | 11:51 |
| spiv | vila: what happens if the transport.base is 'chroot+1234://...'? | 11:51 |
| vila | spiv: that the ones I started with but thanks for confirming :D | 11:51 |
| catphish | ooh... | 11:52 |
| vila | wow: return ! | 11:52 |
| catphish | that'll probably be it! | 11:52 |
| catphish | i assumed it would get file: | 11:52 |
| vila | catphish: here you are, the plugin doesn't suit your needs, the hidden assumption is that it's used only for the client for local paths | 11:53 |
| spiv | In the API it's not too hard to go from a chroot-decorated transport to the underlying file path | 11:53 |
| spiv | The shellhooks plugin probably ought to do that on behalf of the shell commands though. | 11:53 |
| catphish | i can easily rework the plugin now i know what the problem is | 11:53 |
| catphish | (assuming that's what the problem is :)) | 11:54 |
| vila | catphish: no, add a print, but as spiv said, you probably get {chroot|filtered}-12321:// | 11:54 |
| catphish | does that mean i'll never actually get the real path? | 11:54 |
| catphish | hopefully the API will let me extract it | 11:54 |
| spiv | Yes, the API will let you unwrap that. | 11:55 |
| spiv | I forget the exact details. | 11:55 |
| vila | catphish: you won't get the real path, probably a relative path from the base dir with some decorations in front of it | 11:55 |
| catphish | thanks both! | 11:55 |
| catphish | i'm happy to hack away at it now i know where to start | 11:55 |
| spiv | (Perhaps the API is not as convenient as it should be, but it's definitely possible) | 11:56 |
| vila | catphish: we did faster than yesterday ;) | 11:56 |
| spiv | Thinking of yesterday, I read the IRC logs about your bzr+https problem | 11:56 |
| vila | catphish: I should have listened harder when you first mentioned chunked encoding, sry about that | 11:56 |
| catphish | yes, thanks for being so helpful! | 11:56 |
| spiv | The TCP dumps were a bit mangled (non-ascii bytes replaced with '.'s) but there was nothing obviously wrong | 11:57 |
| catphish | that's yes to doing faster than yesterday, not yes you should have listened ;) | 11:57 |
| catphish | well thanks both, i don't think i'd have got there on my own! | 11:57 |
| spiv | I would in the first instance suspect your custom http->bzr server glue as having a bug, though. | 11:57 |
| spiv | But that's just a wild guess because there just isn't enough information to diagnose :( | 11:58 |
| vila | spiv: that was using a chunked encoding which our http stack is *not* ready to handle | 11:58 |
| spiv | I'm glad the Content-Length workaround helped. | 11:58 |
| spiv | vila: really?! | 11:58 |
| vila | seems so | 11:58 |
| spiv | vila: Which part/s? | 11:58 |
| spiv | I'm a bit sceptical of that, if that's true I would have expected problems before now. | 11:59 |
| catphish | chunked encoding combined with keepalive seemed to kill the http library after about 10 requests | 11:59 |
| vila | spiv: we *don't* use chunked encoding ourselves | 11:59 |
| spiv | I realise we mostly retrieve static files where the server can easily determine the content-length before it starts sending the body | 11:59 |
| catphish | which isn't a serious problem since it just opens a new connection and tries again, but if the request happens to have been a lock... | 11:59 |
| spiv | vila: the smart server has at some point, IIRC... | 12:00 |
| spiv | vila: (when conveyed over http) | 12:00 |
| vila | hmm | 12:00 |
| catphish | though in the future i'd prefer to be able to stream the response rather than buffering it to calculate the content-length | 12:00 |
| vila | Yesterday, I started with the assumption that we were supporting the chunked encoding and was proved wrong. | 12:01 |
| catphish | well chunked encoding works | 12:01 |
| spiv | vila: and to avoid buffering potentially the entire repo contents in memory it's basically necessary. | 12:01 |
| catphish | it just randomly fails | 12:01 |
| catphish | right now i have to buffer the whole response | 12:01 |
| vila | Since then, I seem to remember that for properly supporting 1.1 we have to clean up the socket when all the data is not consumed and to do so I'm pretty sure we rely on Content-Length | 12:02 |
| catphish | from what i could see, the closing 0\r\n is left in the read buffer sometimes | 12:02 |
| catphish | but since i'm not a python dev i'll stop talking now | 12:02 |
| spiv | catphish: do you have a trace of that somewhere we can see it? | 12:03 |
| catphish | yes | 12:03 |
| spiv | cool, file a bug with that attached. | 12:03 |
| * spiv -> bed | 12:03 | |
| vila | spiv: the other cause can be a smart client not consuming properly some server response | 12:03 |
| spiv | vila: not with v3 | 12:03 |
| vila | spiv: that was v3... | 12:04 |
| catphish | http://paste.codebasehq.com/pastes/eaoht6hslbts | 12:04 |
| catphish | that's the smallest representation of the problem | 12:04 |
| spiv | Two things spring to mind: a) v3's unit tests are very thorough about stuff like 'consumes whole response', b) even if it wasn't, the HTTP layer ought to be robust against that anyway. | 12:05 |
| catphish | sadly what happens is that the request gets sent twice | 12:05 |
| spiv | catphish: beautiful, thanks | 12:05 |
| vila | spiv: well, the robust part is to close, open a new connection, re-send the request | 12:06 |
| vila | spiv: that failed because the request was a lock and properly processed on the server :) | 12:06 |
| spiv | catphish: it probably doesn't reveal anything, but the previous request-response pair might be interesting to see too | 12:06 |
| spiv | vila: no | 12:07 |
| catphish | no? | 12:07 |
| spiv | vila: you can robustly consume and entire chunked http body | 12:07 |
| spiv | vila: at which point the channel is clear for the next message | 12:07 |
| spiv | s/and entire/an entire/ | 12:07 |
| vila | may be | 12:08 |
| spiv | (assuming the headers didn't specify Connection: close or whatever, of course) | 12:08 |
| vila | I'm not sure the layer get enough info to know that | 12:08 |
| catphish | spiv: http://paste.codebasehq.com/pastes/49osq8c9otx7 | 12:08 |
| vila | but in theory yes | 12:08 |
| spiv | vila: which layer? | 12:08 |
| catphish | if you really want to get your hands dirty | 12:08 |
| catphish | that's the tcp stream | 12:09 |
| vila | the http transport | 12:09 |
| catphish | sadly it's ascii and not coloured properly | 12:09 |
| catphish | but it shows what happened | 12:09 |
| vila | for get_bytes() and readv() we let the higher layer handle the socket content | 12:09 |
| catphish | the final request there is the one that failed (the write lock) | 12:09 |
| vila | get_file() not get_bytes() of course | 12:10 |
| spiv | vila: I think that's a tractable problem | 12:10 |
| vila | sure | 12:11 |
| spiv | (ITYM 'get' not 'get_file') | 12:11 |
| spiv | vila: HttpTransportBase.get already reads (and so buffers!) the entire reponse | 12:12 |
| vila | spiv: isn't there a FIXME there ? | 12:13 |
| vila | yes there is... | 12:14 |
| spiv | Sure that'd be nice to improve, but that's not *this* problem :) | 12:14 |
| spiv | readv is of course more complex, but basically the solution is the same: | 12:14 |
| spiv | If a caller issues a new request before you've finished reading the last response you only have a few options: | 12:15 |
| vila | indeed, see response.py | 12:15 |
| spiv | 1) raise an error (HPSS does this) | 12:15 |
| spiv | 2) assume no further consumption of the existing response will happen and just read and discard the contents (and cause errors if someone does keep trying to use that ReadVFile or whatever) | 12:17 |
| spiv | 3) read and buffer the remainder of the pending response so the existing call works before issuing the next request. | 12:17 |
| spiv | 4) assume pipelining | 12:18 |
| spiv | (and possibly risk deadlocks) | 12:18 |
| spiv | 5) make a new connection | 12:18 |
| spiv | Of all those, for bzrlib I'd be most tempted by 2 or 3. | 12:19 |
| spiv | Anyway, really bedtime now. | 12:19 |
| vila | yeah, sweet dreams :) | 12:19 |
| catphish | night :) | 12:19 |
| mok0 | vila, maxb, thanks for your help! | 13:14 |
| vila | :D | 13:14 |
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3.1 is frozen, installer build time ! (RM: vila) | ||
| vila | jelmer: *now* you can make a bzr-svn release ;-) | 13:40 |
| vila | jelmer: preferably one compatible with 2.3 ;-D | 13:41 |
| jelmer | vila: I'm on it :) | 13:46 |
| vila | \o/ | 13:46 |
| jelmer | I also just submitted three MPs for the weave plugin | 13:46 |
| vila | ha ha | 13:46 |
| vila | ok, I'll switch to that RSN :) | 13:47 |
| bialix | hey all | 14:17 |
| bialix | hi vila | 14:18 |
| vila | _o/ | 14:18 |
| bialix | I thought the spring is coming, but you're freezing releases, heh! | 14:18 |
| vila | time-based ! And this one was delayed because I was in vacations ;) | 14:19 |
| bialix | cool | 14:19 |
| bialix | vacation! | 14:19 |
| bialix | I've tried to make joke with spring and freeze, but I'm bad in English jokes | 14:20 |
| vila | oh my, I missed it :) | 14:20 |
| bialix | there is very cold these days ;-) | 14:20 |
| bialix | nm | 14:20 |
| bialix | just wanna ask strange question | 14:21 |
| bialix | I've just realized that bzr info shows location is quite strange order: push first, parent second. why so? | 14:21 |
| bialix | *blink* | 14:21 |
| bialix | very strange | 14:22 |
| bialix | vila: re windows installer: Gary is really very busy with his work. I'm not sure he'll be able to do one | 14:23 |
| vila | ok | 14:23 |
| bialix | and I've lost my installa-fu some time ago :-( | 14:24 |
| bialix | vila: can you ask jam to do the installer? | 14:24 |
| vila | bialix: jam moved from US to EU, he's in out TZ now :) | 14:25 |
| bialix | \o/ | 14:25 |
| vila | bialix: I think you wake him up from his nap by making his laptop ring :-D | 14:25 |
| bialix | jam have a ring now? | 14:25 |
| vila | bialix: as such, he may be too grumpy to jump on the offer ;) | 14:26 |
| bialix | :-D | 14:26 |
| vila | bialix: no idea, I'm making silly jokes | 14:26 |
| jam | I'm awake now, but I've got a pretty big stack on my plate | 14:26 |
| jam | we tried to rollout a new system on launchpad and 2 of my patches "failed" | 14:26 |
| bialix | morning jam | 14:26 |
| vila | jam: you're jinxed :-/ | 14:26 |
| jam | Empathy doesn't seem to ring like Pidgin did, but it does pop up a little Notifier for me. | 14:26 |
| jam | or maybe my music is too loud :) | 14:27 |
| rvba | Hi, I started hacking on lp:devel where I really should have on lp:db-devel ... I created a branch from lp:db-devel now but I need to pull my changes from my old branch (based on lp:devel). | 14:27 |
| vila | SAY WHAT ? | 14:27 |
| rvba | Should I export a patch and apply it manually or is there a more clever way to do this with bzr? | 14:27 |
| jam | rvba: I'm pretty sure you can just merge across | 14:27 |
| jam | db-devel is supposed to be a superset of devel, aiui | 14:27 |
| jam | cd db-devel-based-branch | 14:28 |
| rvba | jam: ok, I'll try this then, thx | 14:28 |
| awilkins | rebase, cherry pick | 14:28 |
| jam | bzr merge devel-based-branch | 14:28 |
| awilkins | or merge | 14:28 |
| jam | rvba: you may want to look at the diff, (bzr diff) and make sure you aren't bringing tons of unrelated devel stuff in | 14:28 |
| jam | but I think you'll be ok | 14:28 |
| jam | rvba: note, I had lots of trouble with devel vs db-devel as well | 14:28 |
| bialix | awilkins: or replay, that's one you haven't mentioned ;-) | 14:29 |
| jam | so don't feel too bad. double-mainlines is hard to keep straight for new contributors | 14:29 |
| awilkins | bialix, That's a new one on me | 14:29 |
| rvba | jam: ok, thanks I'll see how it goes | 14:29 |
| bialix | awilkins: why? ah, yes, jelmer said it's hidden | 14:29 |
| awilkins | Was it written to support the replay semantics that SVN supports? | 14:30 |
| bialix | awilkins: honestly, I have no idea what svn does. replay just replays commits, it's part of rebase (rewrite) plugin | 14:32 |
| jelmer | replay needs more polishing before it's exposed | 14:33 |
| jelmer | awilkins: what replay semantics does svn support that e.g. bzr merge doesn't? | 14:34 |
| awilkins | I think it just names the thing it uses for svnsync "replay" in some way | 14:34 |
| jelmer | the replay in svnsync is just an optimized implementation of regular "svn up" | 14:51 |
| maxb | vila: bzr-fatimport, eh? | 15:06 |
| vila | maxb: hehe, fixed in my branch, I saw the typo after sending the email :D I was wondering if/when someone will notice :) | 15:07 |
| vila | for once, the tyop *is* the joke ;D | 15:07 |
| fullermd | I figured it was like a signature, so we'd know it was from you :p | 15:10 |
| vila | ha ha, no, for those cases I just add 'crocodile' somewhere to catch true readers ;) | 15:11 |
| fullermd | 'minds me of years back in school, where some friends and I had a running thing where, any time we gave a speech or wrote a paper, we had to include the phrase "aluminum siding" in it somewhere. | 15:13 |
| fullermd | Ideally in such a way as to not raise eyebrows. It was entertaining. | 15:14 |
| vila | https://code.launchpad.net/~jelmer/bzr/lazy-bzrdir/+merge/52844 makes my head spin :-} | 15:14 |
| jelmer | vila: in what way, just the different registration functions? | 15:14 |
| vila | fullermd: oh, this game is still heavily practiced there, one variation is called ... business loto or something | 15:15 |
| vila | jelmer: the relationships between probers, control dirs, formats, the @classmethods and the base class calls via the class name instead of super() | 15:15 |
| jelmer | vila: basically what's involved here is: | 15:16 |
| jelmer | - The list of control dir formats, used by the test suite (ControlDirFormat._formats) | 15:16 |
| vila | jelmer: I'm sure it's clearer when you're deep in the code ;) | 15:17 |
| jelmer | - The list of known BzrDir formats (e.g. everything that has a unique string for .bzr/format) (BzrProber.formats) | 15:17 |
| jelmer | - controldir.network_format_registry | 15:17 |
| jelmer | and then there's BzrDir.register_format() which is a convenience wrapper to register a new bzrdir format, which takes care of registering it in the prober and in the control dir. | 15:18 |
| vila | haa | 15:18 |
| vila | worth a dev doc then (which is what I'm asking in my review ;) | 15:18 |
| fullermd | Nah, just ship jelmer in the tarball ;> | 15:20 |
| vila | no way | 15:21 |
| vila | a clone may be ? | 15:21 |
| fullermd | Some people might accidentally make a checkout instead of a clone and wind up changing the original... | 15:21 |
| vila | jelmer: hmm, but what do we really need ? A helper and a doc or a better doc and no helper ? | 15:22 |
| jelmer | fullermd thinks I should be treated like a wild-west criminal? :-P | 15:22 |
| jelmer | tar and feathers.. | 15:23 |
| fullermd | Just so, my fine feathered friend O:-) | 15:23 |
| jelmer | vila: I think the helper is useful, it gets called in quite a few places (even though it's just two lines) | 15:23 |
| fullermd | (actually, tarring and feathering was an Eastern thing...) | 15:24 |
| jelmer | fullermd: not according to the Lucky Luke comics I read! | 15:24 |
| vila | jelmer: I'm trying to think like a newcomer here... (which I'm not... or am I ?) | 15:25 |
| jelmer | fullermd: Or are you going to claim they're not historically accurate? | 15:25 |
| fullermd | Ah, well then. Far be it from me to gainsay such authority. | 15:25 |
| vila | fullermd: +1 on jelmer readings | 15:25 |
| jelmer | vila: hmm | 15:25 |
| jelmer | vila: I wonder if we could perhaps do away with the ControlDirFormatRegistry | 15:26 |
| jelmer | ehm | 15:26 |
| vila | jelmer: it may just be a public/private thing to disambiguate but I;m not sure | 15:26 |
| jelmer | the ControlDirFormat._formats registry | 15:26 |
| fullermd | It was practiced during the Whiskey Rebellion, frex, which predated the existence of the West by some time. | 15:26 |
| fullermd | Thus endeth fullermd's Random Historical Digression for the day :p | 15:27 |
| jelmer | fullermd: :) | 15:29 |
| jelmer | vila: so, I see to alternatives to make the current situation simpler | 15:29 |
| jelmer | vila: we could either add Prober.known_formats() and use that to discover the available control dir formats | 15:29 |
| jelmer | or perhaps kill the helper in BzrDirFormat.register_format() and just have BzrDirProber.register_format() do what that helper does at the moment. | 15:30 |
| jelmer | or moving BzrProber.formats to BzrDirFormat.subformats and killing any helpers on BzrProber | 15:30 |
| vila | how many probers exist ? | 15:31 |
| jelmer | vila: there's one that covers all local bzr formats, one that covers all bzr remote formats, one for local svn, one for remote svn, one for git, one for hg | 15:32 |
| vila | right, so a given format can be associated with only one prober | 15:32 |
| jelmer | my only concern with adding BzrProber.known_formats() is that a prober isn't necessarily that tightly coupled to a particular format | 15:32 |
| jelmer | vila: exactly | 15:32 |
| vila | and the main aim of a prober is to create format *objects* from a given transport | 15:33 |
| jelmer | yep | 15:34 |
| vila | So I'll tend to make it the main (or even only) entry point ro register a format | 15:34 |
| vila | hmm | 15:34 |
| jelmer | (well, currently from a given transport. In the future it could perhaps support creating format objects from a HTTP options reply, etc) | 15:34 |
| vila | yeah | 15:35 |
| vila | that was my 'hmmm' content ;) | 15:35 |
| vila | I was thinking about tests too | 15:35 |
| vila | so may be we should keep a separate registry and build the prober from the registry | 15:35 |
| jelmer | I'm not sure I follow | 15:36 |
| jelmer | we already have a registry for the available probers | 15:36 |
| vila | and in that case, registration should transit via the prober | 15:36 |
| vila | format registration | 15:36 |
| jelmer | ah, so basically Prober.known_formats() ? | 15:36 |
| vila | may be, I'm not sure I understand the implications | 15:37 |
| jelmer | reconsidering this, I think that might indeed be the sanest solution | 15:38 |
| jelmer | as it would in fact remove the need for both ControlDirFormat.register_format and BzrDirFormat.register_format. | 15:38 |
| vila | ha ! I like that ;) | 15:39 |
| vila | still not sure I follow every detail but this ^ sounds godd :) | 15:39 |
| vila | jelmer: also seeing BzrDirFormat.register_format directly calls ControlDirFormat.register_format rang a hard-to-override bell | 15:43 |
| vila | jelmer: sorry for the confusing/confused review but this code is really.... delicate | 15:45 |
| jelmer | vila: np, you're absolutely right that this is confusing at the moment so I'm glad we could come up with a way to make it a bit simpler | 15:46 |
| vila | jelmer: the other registries you introduced made the code clearer without doubt, here... this seems... incomplete ? It's hard to express, I feel you're going in the right direction but | 15:46 |
| vila | I don't want to block this mp either if you think it's a good step, may be the whole approach should be rethinked | 15:47 |
| vila | I still have the feeling that there should a simpler way and that this code didn't anticipate all today's usages | 15:48 |
| vila | jelmer: but putting weave into a separate plugin should help anyway, so I'm +42 on your work | 15:49 |
| jelmer | vila: thanks :) | 15:54 |
| jelmer | vila: I've pushed a newer version (minus updated tests, etc). Can you tell me what you think of this alternative? | 16:12 |
| vila | sure | 16:12 |
| vila | jelmer: it leaves a better taste in the mouth now ? | 16:20 |
| vila | err s/now/no/ ? | 16:21 |
| vila | jelmer: why do you need to use a set() in known_formats() ? | 16:21 |
| jelmer | vila: :) | 16:22 |
| jelmer | vila: Just in case more than one prober returns the same format | 16:22 |
| vila | does it make sense or would this be a bug ? | 16:23 |
| vila | yeah, it could make sense | 16:23 |
| jelmer | I think it would make sense. I don't want to tie the formats to particular probers too heavily. | 16:23 |
| vila | even if it doesn't today one can imagine various ways to get to the same format | 16:24 |
| vila | ok, so that needs a comment and some basic tests but I like it far better | 16:24 |
| vila | if only because it removes a comment mentioning a circular import ;) | 16:25 |
| === deryck is now known as deryck[lunch] | ||
| jelmer | vila: Which comment regarding a circular import? | 16:26 |
| vila | -# registered. Putting it in remote.py creates a circular import problem. | 16:26 |
| jelmer | vila: the one with regards to RemoteBzrDirFormat should no longer be valid | 16:26 |
| vila | indeed, you've deleted it | 16:27 |
| vila | or was it already deleted in the previous version ? | 16:27 |
| jelmer | I think there's a communication mismatch here somewhere.. the comment no longer applies so why should it be kept in? | 16:29 |
| vila | jelmer: I said: "I'm glad you deleted that comment" | 16:30 |
| vila | oh, | 16:30 |
| jelmer | ah, " ok, so that needs a comment and some basic tests but I like it far better" was what threw me off :) | 16:30 |
| vila | I'd like you to *add* a comment about why you're using a set in known_formats() | 16:30 |
| vila | yeah, I just realized while re-reading that I was referring to two different comments :) | 16:31 |
| vila | to make matter worse one didn't exist and the other was deleted :) | 16:31 |
| vila | confusion guaranteed ! | 16:31 |
| jelmer | vila: I think the other issue is that of deprecation | 16:33 |
| jelmer | vila: I'd prefer to just get rid of these methods rather than deprecating them first, as it's very hard to provide backwards compatibility and the few users we have of the current mechanism can be patched to do the right thing. | 16:33 |
| vila | yeah :-/ | 16:34 |
| vila | 2.4b1 will get out next week (IIRC) so we need to check bzr-loom too | 16:34 |
| jelmer | bzr-loom shouldn't be affected as it doesn't introduce a new bzrdir format | 16:34 |
| vila | ooh ! right ! | 16:35 |
| vila | so, just get in touch with the bzr-{svn|hg|git} plugin authors then | 16:35 |
| jelmer | :) | 16:45 |
| vila | jokes aside, I'm fine with getting rid of the methods, but it would be better to bring the subject on the list :-} | 16:47 |
| vila | We may still encounter users that will upgrade bzr without upgrading the plugins so *they* need to get at least a proper error message | 16:49 |
| vila | otherwise your karma will suffer (the real one, not the lp one ;) | 16:49 |
| === beuno is now known as beuno-lunch | ||
| === deryck[lunch] is now known as deryck | ||
| jam | vila, jelmer: I would like us to deprecate them in the short term, we can remove them after 2.4b1, that gives a small window for compatbility | 18:06 |
| === beuno-lunch is now known as beuno | ||
| vila | jam: I think jelmer's point is that only bzr-{svh|hg|git} are using them and that he's willing to help the respective authors handle the compat in the plugins themselves (which I suspect is easier) rather than trying to do it in bzr, hence my compromise to at least blow up with a meaningful error message (which should also be easy to implement) | 18:09 |
| vila | all in all, I'm all in favor of minimizing the effort for all parties involved | 18:09 |
| wolfpack | I was working on a project and the main branch is there on launchpad. There is other developer who has branched the code and I have my one branch. I cannot push the branch because of network firewall. I can only upload the patch. How will the syncing of the code will take place as both us will be changing the code ? | 19:19 |
| vila | wolfpack: simple things first: | 19:28 |
| vila | wolfpack: if you can provide a read-only access to *your* branch, then your co-worker can push to lp and read from you | 19:28 |
| vila | wolfpack: that's enough to provide you both access to all the needed data | 19:29 |
| vila | wolfpack: otherwise, you can keep the trunk on lp and send bundles to your co-worker and it publish them on lp (after setting a mirror of your branch where he can apply the bundles) | 19:30 |
| wolfpack | vila: Will this thing work?-> I will pull co-worker's branch after he pushes it, while continuing my work. After that I will upload the patch. | 19:31 |
| vila | wolfpack: bundles are produced with 'bzr send', you send one when you're ready to publish your changes and it will contain all the changes you've made | 19:31 |
| vila | wolfpack: yes, upload my patch == send a bundle | 19:31 |
| vila | except that the bundle can contain merges, commits and all the associated metadata (message, author, revision-ids, etc) | 19:32 |
| wolfpack | vila: So sending bundles does not require ssh connection? | 19:33 |
| vila | wolfpack: bundles are a bit more delicate to deal with if you can't share a public branch, but since you have lp to host multiples branches, you're fine | 19:33 |
| vila | wolfpack: you send a bundle by *mail* | 19:34 |
| vila | wolfpack: or any other mean, it's a text file | 19:34 |
| wolfpack | vila: Thanks | 19:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!