| controversial | bzr versus hg fight -- who wins? | 00:28 |
|---|---|---|
| spiv | clearly bzr, because it has more letters. | 00:29 |
| fullermd | No way, hg has that underhanded hook to sneak up. | 00:31 |
| lifeless | its a noshow, they both get distracted by git on the way to the arena | 00:47 |
| fullermd | How monotoneous. | 00:48 |
| bairui | hi, guys. Is this a place to ask about workspace layout, workflow, releases, etc...? | 00:48 |
| bairui | i have read the user guide and the advanced workspaces section, but i am still a bit vague on some of the mechanics | 00:49 |
| lifeless | fullermd: :P | 00:50 |
| lifeless | bairui: sure it, though I'm running out; I'm sure other folk here will help when you have questions | 00:50 |
| bairui | heh, ok. thanks :) | 00:50 |
| bairui | no. i don't even know enough to ask good questions. :-/ Is there an additional resource I could read? The User Guide feels a bit... sparse to me. | 01:01 |
| bairui | say I have a release target layout (taken from the shared_repository_layouts section of the UG). It has the main trunk/ branch and containers releases/ 0.1/ 0.2/ etc (all in the root of the project repo dir) | 01:06 |
| bairui | the term container for foo branch in the UG means what? Just a regular old directory in the filesystem, right? | 01:06 |
| bairui | well, for eg: "container for release branches" | 01:07 |
| fullermd | bairui: I think so, yes. | 01:18 |
| fullermd | bairui: Don't forget (well, or "don't fail to learn", depending ;) that you can rearrange the branches around inside the repo any time, now or later (just watch out for other branches that might look for their old path). | 01:19 |
| bairui | ok. thanks, fullermd. I have to cook breakfast atm, so I'll be back. :) apologies for the monotony ;) | 01:19 |
| bairui | right - rearranging - that was on the Q list :) | 01:19 |
| fullermd | The only important thing is "stays under the repo's dir". | 01:19 |
| fullermd | The repo doesn't know where the branches are, or vice versa. bzr just looks at the branch and says "is there a repo here? No? How about at $BRANCH/../? No? $BRANCH/../../? ../../../? [etc]" | 01:20 |
| fullermd | So if you mv one of the branches 'outside' the repo, the world will end and fire will rain from the sky (not necessarily in that order). | 01:21 |
| fullermd | But as long as you stay 'inside', it doesn't matter to the branch or repo where it is. | 01:21 |
| bairui | ok, fullermd... that's reassuring. Avoiding fire rain is good. So, if I could now move onto the topic of creating releases... Let's say it's a fresh project with nothing in production yet. Dev away, test and ready to release (small cycle with small changesets). What now? Do I tag it? Do I branch a copy as 1.0 and do I need to somehow "freeze" that branch so it can't get altered? Is that even close to the | 01:29 |
| bairui | right path or am I wandering, lost in the scrub? | 01:29 |
| === krow_ is now known as krow | ||
| bairui | apologies again for the "now you see me; now you don't" - breakfast. bbl | 01:32 |
| fullermd | bairui: Well, that ends up being a question of your flow as much (or more) than a VCS thing. | 01:37 |
| fullermd | At one extreme you have "OK, I'm releasing this as 1.0 now", in which case you Obviously(tm) just tag it. | 01:37 |
| fullermd | At the other you have "OK, let's settle this down toward a 1.0 release in the next couple weeks, while we continue to let speculative stuff go on in head", in which case you Equally Obviously(tm) make a 1.0 branch. | 01:38 |
| fullermd | (or do you have a '1.x' branch, that you then tag 1.0 and 1.1 and ... on? Or do you have a 1.x branch that you branch 1.0 from, work toward 1.0 on that branch, let 1.x keep working toward 1.next, and meanwhile still have the separate trunk moving toward 2.x?) | 01:40 |
| fullermd | There's no in-bzr way to 'freeze' a branch (though of course you could mess with FS permissions or the like to make it require increasingly heroic measures to commit on) | 01:41 |
| jimis | a "freeze" or "lock" feature would be good though | 02:07 |
| jimis | besides releases I've needed it for feauture-branches | 02:07 |
| jimis | let's say one week I hack on 15 different features, each on a separate branch | 02:08 |
| jimis | the *finished* features, I'd like to lock them somehow, to warn me against further changes | 02:08 |
| jimis | and also to be seen as status: locked, so that I know that this feauture is merged and I should not work anymore on this branch | 02:09 |
| jimis | At present I do it with all caps files at root dir, like branchname_IS_LOCKED | 02:10 |
| bairui | thanks, fullermd. That makes sense... I just have to choose a path. I'll experiment to make sure my understanding matches reality. | 02:18 |
| bairui | and yes... a lock would be nice and I'll consider an approach like IS_LOCKED, jimis, cheers. | 02:19 |
| bairui | let's talk feature branches... say I have a main (shared) repo at bzr+ssh://server/repos/project with a /trunk/ under that. If I bzr branch bzr+ssh://server/project/trunk bzr+ssh://server/project/0.1 to create a 0.1 pool and then I bzr branch bzr+ssh://server/project/0.1 to get a local working copy (into, say, another local shared repo structure). Would I then (locally) bzr branch 0.1 | 02:34 |
| bairui | 0.1-dev (to keep the local 0.1 'pristine')? Or am I now playing with the fairies again? | 02:34 |
| bairui | ok - something in there was not right... after doing bzr branch bzr+ssh://server/project/trunk bzr+ssh://server/project/0.1 and then bzr branch bzr+ssh://server/project/0.1 to create a local branch, going into the 0.1 dir and issuing the command bzr status gives me the error: bzr: ERROR: No WorkingTree exists for that one, mate. | 02:52 |
| spiv | bairui: what does 'bzr info' say? | 03:03 |
| bairui | that it's a repo branch (2a). The shared repo, repo branch and parent branch look sane... the push branch is . | 03:05 |
| bairui | repo branch is . (which I assume is sane) | 03:05 |
| bairui | so, something that has been confusing me is: Do I create a shared repo on both the server AND on each of my local dev boxes? | 03:06 |
| bairui | meh - newbie mistake - I didn't read the FAQ. It said to just do bzr checkout in my local branch (the one that was complaining about bzr status ). | 03:40 |
| bairui | however... now my local branch 'seems' to behave better, but it's not updating its parent when I do bzr push | 03:40 |
| bairui | it says Nothing to do. My local says it's at revision 1 and the remote says revision 0 | 03:41 |
| vila | hi all ! | 06:55 |
| vila | haaa, pqm queue empty, finally ! | 06:56 |
| maxb | Morning vila. 2.4.0 PPA uploads in progress. | 07:02 |
| * vila thanks maxb ! | 07:02 | |
| vila | \o/ o// \\o | 07:02 |
| maxb | Hmm. bzr-builddeb 2.7.7 FTBFS on <= maverick | 07:04 |
| jimis | How come some commands accept branches without full path, but others require it? | 07:10 |
| jimis | for example I can do "bzr switch branch1" | 07:11 |
| jimis | but I have to do "bzr log -rbranch:../root-dir/branch1" | 07:11 |
| vila | jimis: switch has some DWIM magic (iirc) | 07:11 |
| jimis | vila: DWIM? | 07:11 |
| vila | Do What I Mean | 07:12 |
| jimis | :-) | 07:12 |
| jimis | I love that kind of magic | 07:12 |
| vila | http://www.catb.org/jargon/html/D/DWIM.html | 07:12 |
| jimis | Can't -rbranch use that magic? | 07:13 |
| vila | -r uses some DWIM magic too :) So it can conceivably borrow some from switch... I don't know the details well enough | 07:14 |
| jimis | allright, thanks vila | 07:15 |
| vila | jimis: don't hesitate to file bugs when you encounter issues, that's the best way to bring feedback and attention to them | 07:16 |
| jimis | ok, will do | 07:17 |
| jimis | together with some other stuff, I've put it on my TODO list :-) | 07:18 |
| vila | great ;) | 07:18 |
| bairui | oops: bzr: ERROR: exceptions.ValueError: WorkingTree.set_root_id with fileid=None | 07:18 |
| vila | bairui: bzr version ? | 07:20 |
| bairui | 2.3.4 | 07:20 |
| jimis | hmmm, log needs full path too, like "bzr log ../proj-dir/branch1" | 07:21 |
| vila | there was a bug with this kind of symptom, fixed in 2.4x, triggered when merging to an empty tree or empty branch | 07:21 |
| vila | jimis: log will be harder as you can specify a file/dir path | 07:22 |
| bairui | i am trying to learn how to manage distributed workflow with branches. I had made changes to a branch and merged it back into my trunk. Then it said trunk is out of date with respect to its parent; update. On the update I got that error. I did a commit successfully, and then update was a (successful) no-op. | 07:22 |
| bairui | vila: I did exactly that | 07:22 |
| bairui | pacman says 2.3.4-1 is the best I've got for now :-/ what's latest stable? | 07:24 |
| bairui | but on the *bright* side... I *think* I finally get DVCS and bzr's implementation (for small values of 'get') | 07:25 |
| vila | 2.3.4, but 2.4.0 is *just* around the corner (I'm waiting for a bit more available packages/installers before doing the official announce) | 07:25 |
| vila | bairui: what OS are you using ? | 07:25 |
| bairui | arch | 07:25 |
| bairui | er, well, i guess that's a distro, but it answers your q too :) | 07:25 |
| vila | pardon my ignorance, what package manager is used there and who package bzr (and when ?) | 07:26 |
| bairui | i dunno who and when, but the package manager is called pacman | 07:26 |
| vila | oohhh | 07:26 |
| vila | bairui: well, in the meant time, the workaround is to avoid merging to empty branch/trees ;) | 07:27 |
| vila | mean | 07:27 |
| jimis | vila: arch is famous for packaging the latest stable really on-time | 07:27 |
| bairui | heh, thanks, vila :p | 07:27 |
| jimis | vila: if there is a bug in 2.3, proper solution would be to do a small 2.3.5 fix release | 07:28 |
| poolie | hi vila, jimis, maxb | 07:28 |
| vila | jimis: ok, thanks for teaching me ;) | 07:28 |
| jimis | :-) | 07:28 |
| vila | jimis: in theory, yes, in practice, 2.4 *is* the new stable series | 07:28 |
| vila | bah, not therory/practice, sorry, bad english | 07:28 |
| jimis | I'm sure that 2.4 will be packaged by arch very soon after released then | 07:29 |
| vila | jimis: right | 07:29 |
| jimis | vila: Nevertheless if there is a bug on 2.3, remember that many RHEL users will not be able to use that one | 07:30 |
| vila | jimis, bairui : feedback on when 2.4 is available in arch welcome ! | 07:30 |
| vila | jimis: 2.4 ? | 07:30 |
| vila | jimis: because we drop support for python2.4 ? | 07:30 |
| vila | ghaa | 07:30 |
| jimis | vila: yes | 07:30 |
| poolie | vila what's a control.conf? | 07:31 |
| vila | so, the consensus was that getting python-2.5 on redhat/fedora was easy enough | 07:31 |
| jimis | I went through a lot to be able to run, as we were discussing some other time | 07:31 |
| jimis | vila: *only* if you have root access | 07:31 |
| vila | poolie: the most unknown config file used by bzr | 07:31 |
| jimis | if not, it's pretty hard | 07:31 |
| jimis | and RHEL users tend to have an admin over their heads :-) | 07:32 |
| vila | jimis: ghaaa, are you subscribed to the bazaar ml ? | 07:32 |
| poolie | vila "you're in a balloon!" | 07:32 |
| vila | poolie: ??? :D | 07:32 |
| jimis | vila: no, but I read it casually (have also posted once) | 07:32 |
| vila | poolie: control.conf is mainly used by launchpad to provide default_stacked_on | 07:32 |
| poolie | google it | 07:33 |
| vila | jimis: there was a long thread about dropping support for python-2.4 | 07:33 |
| vila | poolie: oh, you mean my first answer was useless ? | 07:34 |
| poolie | a bit | 07:34 |
| poolie | i thought that was it but the cover letter might have been more clear with a reminder | 07:35 |
| vila | yeah, I know, but it took me so long to learn about this file and it's so well hidden, I feel *a bit* relieved that I'm not alone there | 07:35 |
| poolie | ok | 07:55 |
| poolie | perhaps a comment or two would be good | 07:56 |
| vila | in the stack types ? | 07:56 |
| vila | to explain how they are built ? | 07:56 |
| vila | the rationale and so on ? | 07:56 |
| poolie | something like that | 07:56 |
| poolie | yes, in the stack classes | 07:56 |
| vila | right, my next submission will probably be to introduce a stack registry and that's where I intended to explain that but I can as well start here | 07:57 |
| vila | poolie: roughly the idea is that you call the registry with a stack ID and a context, for example: | 08:00 |
| vila | poolie: stack_registry.get('bazaar') # no context | 08:00 |
| vila | poolie: stack_registry.get('branch', branch) | 08:01 |
| poolie | hm | 08:01 |
| vila | poolie: stack_registry.get('locations', url) | 08:01 |
| vila | and you get the right stack for the context | 08:01 |
| vila | branch should chose the appropriate stack depending on 'branch', remote or local | 08:02 |
| vila | or may be the registry gives bask a factory and *then* you provide the context | 08:02 |
| vila | back | 08:03 |
| poolie | so that sounds about right | 08:03 |
| poolie | i do wonder if having a factory function is a bit redundant with also having classes per stack? | 08:04 |
| poolie | also i wonder if it's more a matter of giving it a dict of relevant things | 08:04 |
| poolie | or even a set/list of relevant things | 08:05 |
| poolie | like stack_registry(a_branch, a_transport, etc) | 08:05 |
| vila | yes, the factory is redundant, the classes were an intermediate step | 08:06 |
| vila | ghaa | 08:06 |
| vila | yes, the classes are redundant, they were an intermediate step and the registry will replace them | 08:07 |
| Riddell | hi all | 08:07 |
| vila | Riddell: hey ! | 08:07 |
| vila | Riddell: I'm not sure I was clear yesterday about your babune failure, you encountered a *transient* failure (cause not well understood, workaround: try again) | 08:09 |
| Riddell | vila: got that thanks, the change got merged in | 08:09 |
| vila | ok | 08:10 |
| jimis | Is there a way in launchpad to see a list of bugs I have subscribed to, or marked as affecting me? | 08:19 |
| vila | jimis: https://bugs.launchpad.net/~ | 08:20 |
| vila | jimis: top right corner gives several links | 08:20 |
| jimis | perfect, thanks vila | 08:21 |
| jam | hi all | 08:27 |
| poolie | jimis: no link for bugs affecting you yet | 08:27 |
| poolie | hi jam | 08:27 |
| poolie | bad news on your hpss branch i'm afraid | 08:27 |
| jam | poolie: what's that? | 08:27 |
| poolie | it's still doing the initial pull of gcc-linaro after several hours and it's running one step at atime | 08:28 |
| nigelb | I wanted to try out an easy bzr bug, but not of the "easy" bugs seemed easy | 08:29 |
| nigelb | I :) | 08:29 |
| poolie | hi nigelb | 08:30 |
| nigelb | hey poolie :) | 08:30 |
| jam | poolie: I don't quite understand what you mean by "one step at a time" | 08:30 |
| jam | My fix was about initial discovery of revisions. | 08:30 |
| jam | If it has passed about 2MB transferred, it should have gotten the revs. | 08:30 |
| poolie | it's doing many, individually small, get_parent_map calls | 08:30 |
| poolie | with 19MB transferred | 08:31 |
| poolie | nigelb: https://bugs.launchpad.net/bzr/+bug/328910 should be genuinely easy and useful | 08:32 |
| ubot5 | Ubuntu bug 328910 in Bazaar "ugly traceback when sftp server drops connection" [Medium,Confirmed] | 08:32 |
| poolie | it has a note about where to start but you're super welcome to ask more about it here, or on the bug | 08:32 |
| jam | poolie: so I just tested my branch as of right now, and things look fine, it got to "Using fetch locgic" in 79s | 08:33 |
| nigelb | poolie: hehe, thanks :) | 08:33 |
| poolie | so i did init-repo, then bzr branch lp:gcc-linaro/4.6 into there | 08:33 |
| jam | poolie: do you have the .bzr.log for me to look at? | 08:33 |
| jam | poolie: well, I'm doing "lp:gcc-linaro" just trunk, not a stacked branch. That may be the difference | 08:33 |
| nigelb | heh, there's something magical about doing bzr branch lp:bzr :) | 08:33 |
| jam | Try that first, see if it helps, and we may need to do more work w/ stacking | 08:33 |
| jam | but yes, trying /4.6 I see that I'm already at 4MB @ 50s | 08:35 |
| poolie | jam: in chinstrap:~mbp | 08:36 |
| jam | poolie: so I see similar behavior from a stacked branch, so I do think there is something we need to look at, but I think that is *in addition to* what I fixed | 08:37 |
| poolie | ok | 08:37 |
| jam | can you try lp:gcc-linaro directly? | 08:37 |
| jam | (I'm at 206s ,and a huge number of round trips) | 08:37 |
| jam | my guess is that the caching provider isn't triggering at the right layer | 08:37 |
| poolie | yes, starting it now | 08:38 |
| jam | so we make a request against StackedRepo find it isn't there, then fallback to StackedOnRepo and find it in the cache | 08:38 |
| poolie | good example of the value of having someone else test i suppose | 08:38 |
| jam | and we do that *for every step* | 08:38 |
| poolie | michaelh just reported a dupe of this today, and his was with /4.6 | 08:38 |
| jam | sure | 08:38 |
| poolie | woo | 08:39 |
| poolie | that looks a lot better | 08:39 |
| poolie | got to 'using fetch logic' in 94s | 08:39 |
| jam | poolie: right, and compare that with bzr.dev | 08:40 |
| jam | so I think my fix is still practical and good, we just need to also fix the "stacked repo gets queried before we check in cache" sort of bug. | 08:40 |
| jam | I could be wrong, but that is what it looks like to me | 08:40 |
| poolie | i think you're right | 08:40 |
| poolie | i'm glad i avoided saying "it's fixed" to them prematurely though | 08:41 |
| jam | poolie: agreed. | 08:41 |
| jam | poolie: So I think I remember spiv poking in this area. Where he realized we were double caching, and moved to expose the cache to the higher levels. | 08:42 |
| jam | It is pretty vague, though. | 08:42 |
| jam | poolie: but yeah, I'm seeing 500s 10MB transferred, and still discovering for a stacked branch. | 08:43 |
| poolie | i'll comment on the bug | 08:46 |
| vila | poolie: I now get mails for list moderation but I'm not able to connect, I suspect it's because you used vila@c.c instead of vila_bzr@c.c, can you try to change that ? | 08:47 |
| vila | grr vila+bzr@c.c | 08:48 |
| vila | It's a bit strange that the login ask only for a password and not for an email, but it probably tries all passwords for all admins... | 08:49 |
| poolie | jam as a workaround we could unstack their 4.6 branch | 08:52 |
| jam | poolie: because they are branching from it a lot? | 08:53 |
| jam | poolie: certainly that will give them an immediate boost if it is something they are active on. | 08:54 |
| jam | (should it be the dev focus if it is the active branch?) | 08:54 |
| poolie | yes | 08:55 |
| poolie | i don't know about that | 08:55 |
| jam | poolie: so the *big* win is that unstacking it will mean they get immediate benefit regardless of what bzr client they are using | 08:58 |
| jam | poolie: so I would recommend for that because it helps them *today*, though I still want to fix this | 09:00 |
| vila | jam: but won't they run into issues when *pushing* if 4.6 is unstacked ? | 09:01 |
| vila | or is that the opposite ? | 09:01 |
| jam | vila: The main issue is that it will have all the history there, but if we do that part then it doesn't matter for them | 09:02 |
| jam | so *if* they bring in a lot of new data from trunk into 4.6 | 09:02 |
| jam | that will get copied when they push to 4.6 | 09:02 |
| vila | 'that part' == unstacking ? | 09:05 |
| jam | vila: yes | 09:06 |
| vila | k | 09:06 |
| jam | it will have to transfer, say 500MB, of history | 09:06 |
| jam | (not sure on the exact amount) | 09:06 |
| jam | but if we get someone close to the datacenter to do it, it should be pretty fast. | 09:06 |
| vila | and how about keeping it stacked but still add the missing revisions ? | 09:07 |
| poolie | vila i doubt they will be regularly merging such large amounts from trunk to 4.6 to outweigh the existing history | 09:08 |
| poolie | jam, ok, it completed in 27m | 09:08 |
| jam | poolie: well, you could stack it and leave the history, it would be a bit odd. And I think I'd just unstack it | 09:10 |
| nigelb | poolie: hm, unsure how to get the right info to raise ShortReadvError. | 09:23 |
| nigelb | Actually, unsure how to get the parameters for it. | 09:23 |
| poolie | biab | 09:23 |
| vila | nigelb: identify one file that is read, remove its content (or part of it, may the first few bytes needs to be there so the file can be identified properly) | 09:24 |
| === hno_ is now known as hno | ||
| vila | nigelb: a pack or a an index file will do | 09:25 |
| nigelb | heh, didn't understand that. let me grep where its used and try to decipher what you wwant | 09:26 |
| vila | ShortReadvError occurs when a file is truncated (it should never happen under normal circumstances) | 09:27 |
| nigelb | ah, so when the ftp does get disconnected, that's what would happen. | 09:28 |
| nigelb | *stfp | 09:28 |
| vila | nigelb: sry, didn't notice your reply | 09:53 |
| vila | nigelb: hmm, so, if you're working on ssh disconnections, that's a bit different | 09:54 |
| vila | nigelb: truncating the file may not be the right way to trigger the problem | 09:55 |
| vila | nigelb: reading bug report | 09:56 |
| vila | right, so what you really want is a test server that will drop the connection, catch that on the client side and (as spiv suggested) turn it into a ShortReadvError (I don't fully understand why spiv suggested that though) | 09:57 |
| vila | ShortReadvError are really serious, when we encounter them it has always been linked to hardware issues (or bad crashes), raising them for network issues seem a but weird | 09:59 |
| spiv | vila: we're talking about FTP? | 10:06 |
| spiv | vila: FTP doesn't have any standard way to tell you how many bytes to expect on your data channel | 10:07 |
| spiv | vila: and it's a separate connection to the control channel | 10:07 |
| vila | spiv: sftp, see bug above | 10:07 |
| vila | https://bugs.launchpad.net/bzr/+bug/328910 | 10:08 |
| ubot5 | Ubuntu bug 328910 in Bazaar "ugly traceback when sftp server drops connection" [Medium,Confirmed] | 10:08 |
| spiv | vila: in that case probably a ConnectionError of some sort is probably a better match | 10:09 |
| vila | spiv: why did you suggest to turn a network error into a ShortReadvError ? | 10:09 |
| vila | ha right | 10:09 |
| vila | k | 10:09 |
| vila | I agree | 10:09 |
| vila | nigelb: ^ | 10:09 |
| jimis | Can I write a message for some changes I just shelved, but forgot -m? | 10:56 |
| vila | jimis: unshelve/reshelve :-/ | 11:00 |
| vila | jimis: not ideal | 11:00 |
| fullermd | vi .bzr/.... ;) | 11:00 |
| fullermd | bairui: Hey, I snuck off to sleep while you were eating. Hope you got on the right track. | 11:02 |
| vila | fullermd: you... what ? | 11:03 |
| fullermd | It's not my fault! I'm sick! | 11:03 |
| fullermd | I mean, physically, this time. | 11:03 |
| vila | ha, ok | 11:04 |
| jml | mgz: hi. how's things? | 11:19 |
| === Mkaysi|ZNC is now known as Mkaysi|ZNC|ZNC | ||
| Riddell | how comes there's no bzr qremove command ? | 11:45 |
| jelmer | Riddell: what would it use qt for? | 11:47 |
| Riddell | well same as bzr qadd I would think | 11:47 |
| jelmer | I wasn't aware there was a qadd either :) | 11:48 |
| * jelmer gives it a try | 11:48 | |
| bairui | fullermd: heh... yes, I did, thanks mate. I read dozens of bzr articles and wiki entries and whatnot... I grok it! Thanks for your pointers this morning - good start to digging further. :) | 12:10 |
| bairui | I'm doing up a dev & mig workflow doc & diag now | 12:11 |
| fullermd | bairui: Oh good. | 12:19 |
| fullermd | If you haven't come across them, some of the SpotDocs I wrote up a little while back may be useful. | 12:20 |
| fullermd | http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs | 12:20 |
| bairui | sweet :) | 12:20 |
| fullermd | Particularly the PiecesInBrief section. | 12:20 |
| fullermd | They're all totally useless as tutorials or introductions. They're made to more fully explain the conceptual models of what happens, once you get used to basically using the system. | 12:21 |
| bairui | nice. i've added them to my read queue. cheers. :) | 12:21 |
| fullermd | (they're pretty rough; haven't had time to do much editing etc :( ) | 12:25 |
| bairui | that's cool... I know where you live if I need to clear anything up ;) | 12:25 |
| poolie | jam, so, anything else you need? | 12:28 |
| poolie | otherwise i might poke at some more jubany failures and then stop | 12:28 |
| jam | poolie: I think I'm good for now, probably time for you to take a break :) | 12:33 |
| === Mkaysi|ZNC|ZNC is now known as Mkaysi_ | ||
| === Mkaysi_ is now known as Mkaysi_|ZNC | ||
| === bigjools-afk is now known as bigjools_ | ||
| jam | vila: ping | 15:00 |
| jam | jelmer_: do you still think you're going to be releasing bzr-svn ? | 15:00 |
| vila | jam: pong | 15:01 |
| jelmer_ | jam: Yep, working on that at the moment. It's way overdue :-/ | 15:01 |
| jam | jelmer_: k, I won't spin up ec2 yet. | 15:01 |
| jam | vila: Thoughts about get_parent_map and caching | 15:01 |
| jam | have some time to chat? | 15:01 |
| vila | always for you :) | 15:01 |
| jam | vila: mumble/voip/skype? I'm thinking it will be faster than trying to type it all | 15:02 |
| === zyga is now known as zyga-afk | ||
| briandealwis | jelmer_: does bzr-git support accessing a repo over http? I'm having problems branching from Eclipse's git repositories: trying 'bzr branch http://git.eclipse.org/c/platform/eclipse.platform.ui.git' results in HTML being spat out, and they don't seem to be running a git smart server | 15:45 |
| jelmer_ | briandealwis, I can't clone that URL with git either, it just hangs | 15:48 |
| briandealwis | oh! It works for me… or at least it was | 15:48 |
| briandealwis | just checked again: it's working from here | 15:49 |
| briandealwis | jelmer_: is there a way to force bzr to look at the URL for bzr-git? There's no git+http scheme | 15:53 |
| briandealwis | (I vaguely recall there being some "+xxx" addition to do something different) | 15:53 |
| jelmer_ | briandealwis: the problem is that that site doesn't return 404 for files that are not found :-/ | 15:54 |
| briandealwis | oh! that's not useful | 15:54 |
| jelmer_ | briandealwis, bzr-git doesn't support smart server access over http to git repositories | 15:56 |
| briandealwis | jelmer_: and it doesn't support dumb access either? :) | 15:57 |
| jelmer_ | briandealwis, it does support dumb access, but I'm not sure if that's enabled on the server | 15:57 |
| briandealwis | jelmer_: they're supposed to be running a smart server (their examples show using the 'git:' protocol too), so I'll bug them about that. | 15:58 |
| jelmer_ | briandealwis, the main problem is the missing 404 though | 15:58 |
| briandealwis | I'll file a bug with them about that. There's no +xxx I can append to force bzr-git to continue on? | 15:59 |
| jelmer_ | briandealwis: no | 16:00 |
| briandealwis | ok. Thanks for the help, jelmer_ | 16:00 |
| === deryck is now known as deryck[lunch] | ||
| === Mkaysi_|ZNC is now known as Mkaysi_ | ||
| briandealwis | jelmer_: sorry to bug you again: would you happen to know what file is being probed for — the file that's returning 200? (In case I'm asked) | 16:31 |
| jelmer_ | briandealwis, *any* file that doesn't exist | 16:32 |
| jelmer_ | briandealwis, e.g. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/.git/foo | 16:32 |
| briandealwis | jelmer_: I understand that — they likely have done that to make things 'easier' for people. They may be loathe to disable that. But they might be willing for a particular file name… | 16:33 |
| jelmer_ | briandealwis: I'm not sure if it's actually worth reporting this just yet | 16:35 |
| jelmer_ | briandealwis: it'll be slow as hell until there is support for the smart server over http in dulwich/bzr-git | 16:35 |
| jelmer_ | briandealwis, any reaosn you're not cloning over git:// ? | 16:35 |
| briandealwis | It's not working. I've reported that to them too :) | 16:36 |
| jelmer_ | briandealwis, seems to be working fine here | 16:36 |
| briandealwis | huh, weird. I get an error. I'll check that I'm running the latest dulwich and bzr-git | 16:37 |
| === Mkaysi_ is now known as Mkaysi_|AFK | ||
| === Mkaysi_|AFK is now known as Mkaysi_ | ||
| === deryck[lunch] is now known as deryck | ||
| === beuno is now known as beuno-lunch | ||
| === medberry is now known as med_out | ||
| === beuno-lunch is now known as beuno | ||
| briandealwis | jelmer_: You mentioned that you were able to clone over git:// from the Eclipse server? I'm now up to dulwich 0.8.0 and tip of bzr-git on bzr 2.4b4, but I'm unable to branch from http://git.eclipse.org/c/platform/eclipse.platform.ui.git/. I get an 'bzr: ERROR: The remote server unexpectedly closed the connection.' -Dtransport doesn't reveal anything in the log | 18:41 |
| jelmer_ | briandealwis, does git:// work for you with git itself? | 18:42 |
| briandealwis | jelmer_: I can pull from github. Though I get a NotImplementedError exception when I try 'missing' | 18:52 |
| briandealwis | jelmer_: sorry — I misread. No, git doesn't work with the URL either. Weird. But it works for you? Maybe I should move to Europe. | 19:00 |
| jelmer_ | briandealwis: "bzr missing" should "work" now (just pushed a fix to lp:bzr-git) | 19:00 |
| briandealwis | great! | 19:01 |
| briandealwis | ah right, now it doesn't error :) | 19:02 |
| === med_out is now known as med | ||
| === med is now known as medberry | ||
| briandealwis | jelmer_: the Eclipse sysadmins note that the 200 behaviour is part of cgit, the web front-end to git that they're using, and it isn't configurable. They do run the git smart-server over http. And I realize I had the wrong URL for the git:// smart server — not sure where I got it from. | 19:28 |
| jelmer_ | briandealwis: ah, cool | 19:33 |
| jelmer_ | briandealwis: so, bzr-git only supports "dumb" http access, but even if that works it'll be pretty slow for projects the size of eclipse | 19:34 |
| briandealwis | jelmer_: they do have working smart servers — it still feels slow as molasses, so I shudder to think of what it would be like to use the dumb access. | 19:35 |
| briandealwis | jelmer_: and thanks for your work with the ",branch=" work. Is this supported in bzr-git? Out of curiosity, is there some more work required for that still? | 19:35 |
| jelmer_ | briandealwis: yeah, should work with current tip of bzr-git and bzr | 19:42 |
| briandealwis | cool! I'll give it a shot. | 19:43 |
| briandealwis | Is there some way to disable or prevent a particular plugin from being loaded from the CLI? | 20:44 |
| cody-somerville | Is there any way to make bzr update atomic? | 20:46 |
| briandealwis | Not sure how I missed it, but BZR_DISABLE_PLUGINS is what I was looking for | 20:58 |
| jelmer_ | cody-somerville: what do you mean by atomic exactly? | 21:04 |
| cody-somerville | jelmer_, ie. if the operation fails (ie. conflicts, etc.) that nothing changes | 21:04 |
| === yofel_ is now known as yofel | ||
| jelmer_ | cody-somerville: it is atomic, there just isn't any support for rollback if the transaction contains conflicts :) | 21:23 |
| jelmer_ | cody-somerville: I agree it makes sense to have an option which can abort and not touch the tree if there are conflicts | 21:24 |
| cody-somerville | yea, I'm basically looking for it to be an atomic transaction | 21:25 |
| thumper | hi people | 21:55 |
| thumper | I have a weird merge problem | 21:55 |
| thumper | I've done a bunch of work in a branch | 21:55 |
| thumper | which ends up being branched from the packaging branch (with distro patches et al) | 21:55 |
| thumper | instead of the upstream mirror | 21:55 |
| thumper | now I want to make another branch | 21:55 |
| thumper | and merge in particular changes to particular files | 21:56 |
| thumper | is there a way to say "merge the changes to this file from that branch" | 21:56 |
| thumper | but not get the revisions? | 21:56 |
| jelmer_ | thumper! | 21:58 |
| jelmer_ | thumper: Do you perhaps just mean "bzr merge" followed by "bzr revert --forget-merges" and reverts of the other changes you don't want? | 21:59 |
| thumper | hi jelmer_ | 21:59 |
| thumper | ah... | 21:59 |
| thumper | that should work | 21:59 |
| thumper | although I'm going to have to revert a bucket load of changes I don't care about | 21:59 |
| thumper | I did "bzr revert .", but it did the opposite of what I wanted and I couldn't remember the syntax | 22:00 |
| thumper | can I just merge changes from a particular file? | 22:00 |
| jelmer_ | thumper: you can, just specify that specific file | 22:00 |
| thumper | kk | 22:00 |
| * thumper tries | 22:00 | |
| thumper | nope | 22:01 |
| thumper | can't specify a file in merge | 22:01 |
| jelmer_ | thumper: "bzr merge ../path/to/branch/file.txt" works here | 22:02 |
| thumper | ah... I was doing two parts | 22:02 |
| thumper | jelmer_: it also appears that just merging a file doesn't have pending revisions to merge | 22:03 |
| jelmer_ | thumper: yep | 22:03 |
| jelmer_ | we don't properly track cherrypick merges of individual files or individual revisions yet | 22:03 |
| thumper | yep | 22:03 |
| thumper | that works for me | 22:03 |
| thumper | ta | 22:03 |
| === medberry is now known as med_out | ||
| maxb | jelmer_: Do you have any plans to release subvertpy 0.8.4 soon? | 22:53 |
| maxb | I had been intending to not obsolete karmic from the ~bzr PPA until after bzr 2.4.0 happened, but there's no bzr-svn/karmic compatible with bzr 2.4, and there won't be unless subvertpy 0.8.4 happens, or I backport that. Which I was hoping to avoid :-) | 22:55 |
| jelmer_ | maxb, sure, I guess I could do a release | 22:57 |
| maxb | If it's not too much effort, great | 23:04 |
| maxb | Otherwise, we can just obsolete karmic now, before bzr 2.4 hits ~bzr/ppa | 23:05 |
| maxb | Which, come to think of it, might be the sensible thing to do anyway | 23:06 |
| maxb | it is over 3 months EOLed | 23:07 |
| idnar | does bzr have anything like mercurial queues? | 23:24 |
| idnar | I guess loom is the thing I need to look at? | 23:25 |
| lifeless | pipelines are closer to queues | 23:25 |
| lifeless | loom versions the stack of patches as a unit, which is useful for distro / collaboration-around-the-queue | 23:25 |
| idnar | ah | 23:26 |
| idnar | I'm not yet sure which approach I want here | 23:27 |
| idnar | (some background: I'm trying to find out what changes I need to make this code run on pypy, so I'm just hacking stuff willy-nilly to get it working; later I want to clean things up and eventually break changes out as separate branches to hopefully be merged into upstream) | 23:29 |
| idnar | I think pipelines may be the easiest way | 23:31 |
| idnar | I guess I can't sync-pipeline to Launchpad | 23:35 |
| lifeless | idnar: pipelines fit that use case | 23:37 |
| lifeless | idnar: sure you can | 23:37 |
| idnar | bzr: ERROR: Permission denied: "~divmod-dev/divmod.org/divmod-on-pypy/.bzr/branches/divmod-on-pypy/": : Cannot create branch at '/~divmod-dev/divmod.org/divmod-on-pypy/.bzr/branches/divmod-on-pypy' | 23:38 |
| idnar | er, the line before that was: Creating new pipe at bzr+ssh://bazaar.launchpad.net/~divmod-dev/divmod.org/divmod-on-pypy/.bzr/branches/divmod-on-pypy | 23:39 |
| lifeless | hmm, where is abentley when you need him :) | 23:39 |
| lifeless | idnar: oh | 23:39 |
| lifeless | idnar: so, what you do is have the pipeline local | 23:39 |
| lifeless | and publish all the pipes to lp as separate branches | 23:39 |
| lifeless | this is a bit different to loom | 23:39 |
| idnar | yeah | 23:39 |
| lifeless | pipelines is a less intrusive plugin :) | 23:39 |
| lifeless | poolie has a plan to merge various bits of guts and make them separate policy layers on a common substrate. | 23:40 |
| lifeless | I'm not sure that the substrate is enough for loom without being in the way of pipeline, but I guess we'll see ;) | 23:40 |
| idnar | I should have looked at pipelines again before now; I read about them a while back, then forgot about them | 23:44 |
| idnar | I did a think the other week that would have been much easier | 23:44 |
| idnar | *a thing | 23:44 |
| poolie | hi all | 23:49 |
| * idnar waves to poolie | 23:51 | |
| poolie | hi idnar | 23:51 |
| poolie | some parts of that unification are now landing | 23:51 |
| poolie | for example 'bzr branches' will tell you about colo branches | 23:51 |
| poolie | it's not connected to pipelines or looms yet though | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!