[00:28] bzr versus hg fight -- who wins? [00:29] clearly bzr, because it has more letters. [00:31] No way, hg has that underhanded hook to sneak up. [00:47] its a noshow, they both get distracted by git on the way to the arena [00:48] How monotoneous. [00:48] hi, guys. Is this a place to ask about workspace layout, workflow, releases, etc...? [00:49] i have read the user guide and the advanced workspaces section, but i am still a bit vague on some of the mechanics [00:50] fullermd: :P [00:50] bairui: sure it, though I'm running out; I'm sure other folk here will help when you have questions [00:50] heh, ok. thanks :) [01:01] 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:06] 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] the term container for foo branch in the UG means what? Just a regular old directory in the filesystem, right? [01:07] well, for eg: "container for release branches" [01:18] bairui: I think so, yes. [01:19] 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] ok. thanks, fullermd. I have to cook breakfast atm, so I'll be back. :) apologies for the monotony ;) [01:19] right - rearranging - that was on the Q list :) [01:19] The only important thing is "stays under the repo's dir". [01:20] 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:21] 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] But as long as you stay 'inside', it doesn't matter to the branch or repo where it is. [01:29] 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] right path or am I wandering, lost in the scrub? === krow_ is now known as krow [01:32] apologies again for the "now you see me; now you don't" - breakfast. bbl [01:37] bairui: Well, that ends up being a question of your flow as much (or more) than a VCS thing. [01:37] At one extreme you have "OK, I'm releasing this as 1.0 now", in which case you Obviously(tm) just tag it. [01:38] 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:40] (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:41] 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) [02:07] a "freeze" or "lock" feature would be good though [02:07] besides releases I've needed it for feauture-branches [02:08] let's say one week I hack on 15 different features, each on a separate branch [02:08] the *finished* features, I'd like to lock them somehow, to warn me against further changes [02:09] 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:10] At present I do it with all caps files at root dir, like branchname_IS_LOCKED [02:18] thanks, fullermd. That makes sense... I just have to choose a path. I'll experiment to make sure my understanding matches reality. [02:19] and yes... a lock would be nice and I'll consider an approach like IS_LOCKED, jimis, cheers. [02:34] 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] 0.1-dev (to keep the local 0.1 'pristine')? Or am I now playing with the fairies again? [02:52] 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. [03:03] bairui: what does 'bzr info' say? [03:05] that it's a repo branch (2a). The shared repo, repo branch and parent branch look sane... the push branch is . [03:05] repo branch is . (which I assume is sane) [03:06] 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:40] 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] however... now my local branch 'seems' to behave better, but it's not updating its parent when I do bzr push [03:41] it says Nothing to do. My local says it's at revision 1 and the remote says revision 0 [06:55] hi all ! [06:56] haaa, pqm queue empty, finally ! [07:02] Morning vila. 2.4.0 PPA uploads in progress. [07:02] * vila thanks maxb ! [07:02] \o/ o// \\o [07:04] Hmm. bzr-builddeb 2.7.7 FTBFS on <= maverick [07:10] How come some commands accept branches without full path, but others require it? [07:11] for example I can do "bzr switch branch1" [07:11] but I have to do "bzr log -rbranch:../root-dir/branch1" [07:11] jimis: switch has some DWIM magic (iirc) [07:11] vila: DWIM? [07:12] Do What I Mean [07:12] :-) [07:12] I love that kind of magic [07:12] http://www.catb.org/jargon/html/D/DWIM.html [07:13] Can't -rbranch use that magic? [07:14] -r uses some DWIM magic too :) So it can conceivably borrow some from switch... I don't know the details well enough [07:15] allright, thanks vila [07:16] jimis: don't hesitate to file bugs when you encounter issues, that's the best way to bring feedback and attention to them [07:17] ok, will do [07:18] together with some other stuff, I've put it on my TODO list :-) [07:18] great ;) [07:18] oops: bzr: ERROR: exceptions.ValueError: WorkingTree.set_root_id with fileid=None [07:20] bairui: bzr version ? [07:20] 2.3.4 [07:21] hmmm, log needs full path too, like "bzr log ../proj-dir/branch1" [07:21] there was a bug with this kind of symptom, fixed in 2.4x, triggered when merging to an empty tree or empty branch [07:22] jimis: log will be harder as you can specify a file/dir path [07:22] 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] vila: I did exactly that [07:24] pacman says 2.3.4-1 is the best I've got for now :-/ what's latest stable? [07:25] but on the *bright* side... I *think* I finally get DVCS and bzr's implementation (for small values of 'get') [07:25] 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] bairui: what OS are you using ? [07:25] arch [07:25] er, well, i guess that's a distro, but it answers your q too :) [07:26] pardon my ignorance, what package manager is used there and who package bzr (and when ?) [07:26] i dunno who and when, but the package manager is called pacman [07:26] oohhh [07:27] bairui: well, in the meant time, the workaround is to avoid merging to empty branch/trees ;) [07:27] mean [07:27] vila: arch is famous for packaging the latest stable really on-time [07:27] heh, thanks, vila :p [07:28] vila: if there is a bug in 2.3, proper solution would be to do a small 2.3.5 fix release [07:28] hi vila, jimis, maxb [07:28] jimis: ok, thanks for teaching me ;) [07:28] :-) [07:28] jimis: in theory, yes, in practice, 2.4 *is* the new stable series [07:28] bah, not therory/practice, sorry, bad english [07:29] I'm sure that 2.4 will be packaged by arch very soon after released then [07:29] jimis: right [07:30] 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] jimis, bairui : feedback on when 2.4 is available in arch welcome ! [07:30] jimis: 2.4 ? [07:30] jimis: because we drop support for python2.4 ? [07:30] ghaa [07:30] vila: yes [07:31] vila what's a control.conf? [07:31] so, the consensus was that getting python-2.5 on redhat/fedora was easy enough [07:31] I went through a lot to be able to run, as we were discussing some other time [07:31] vila: *only* if you have root access [07:31] poolie: the most unknown config file used by bzr [07:31] if not, it's pretty hard [07:32] and RHEL users tend to have an admin over their heads :-) [07:32] jimis: ghaaa, are you subscribed to the bazaar ml ? [07:32] vila "you're in a balloon!" [07:32] poolie: ??? :D [07:32] vila: no, but I read it casually (have also posted once) [07:32] poolie: control.conf is mainly used by launchpad to provide default_stacked_on [07:33] google it [07:33] jimis: there was a long thread about dropping support for python-2.4 [07:34] poolie: oh, you mean my first answer was useless ? [07:34] a bit [07:35] i thought that was it but the cover letter might have been more clear with a reminder [07:35] 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:55] ok [07:56] perhaps a comment or two would be good [07:56] in the stack types ? [07:56] to explain how they are built ? [07:56] the rationale and so on ? [07:56] something like that [07:56] yes, in the stack classes [07:57] 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 [08:00] poolie: roughly the idea is that you call the registry with a stack ID and a context, for example: [08:00] poolie: stack_registry.get('bazaar') # no context [08:01] poolie: stack_registry.get('branch', branch) [08:01] hm [08:01] poolie: stack_registry.get('locations', url) [08:01] and you get the right stack for the context [08:02] branch should chose the appropriate stack depending on 'branch', remote or local [08:02] or may be the registry gives bask a factory and *then* you provide the context [08:03] back [08:03] so that sounds about right [08:04] i do wonder if having a factory function is a bit redundant with also having classes per stack? [08:04] also i wonder if it's more a matter of giving it a dict of relevant things [08:05] or even a set/list of relevant things [08:05] like stack_registry(a_branch, a_transport, etc) [08:06] yes, the factory is redundant, the classes were an intermediate step [08:06] ghaa [08:07] yes, the classes are redundant, they were an intermediate step and the registry will replace them [08:07] hi all [08:07] Riddell: hey ! [08:09] 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] vila: got that thanks, the change got merged in [08:10] ok [08:19] Is there a way in launchpad to see a list of bugs I have subscribed to, or marked as affecting me? [08:20] jimis: https://bugs.launchpad.net/~ [08:20] jimis: top right corner gives several links [08:21] perfect, thanks vila [08:27] hi all [08:27] jimis: no link for bugs affecting you yet [08:27] hi jam [08:27] bad news on your hpss branch i'm afraid [08:27] poolie: what's that? [08:28] it's still doing the initial pull of gcc-linaro after several hours and it's running one step at atime [08:29] I wanted to try out an easy bzr bug, but not of the "easy" bugs seemed easy [08:29] I :) [08:30] hi nigelb [08:30] hey poolie :) [08:30] poolie: I don't quite understand what you mean by "one step at a time" [08:30] My fix was about initial discovery of revisions. [08:30] If it has passed about 2MB transferred, it should have gotten the revs. [08:30] it's doing many, individually small, get_parent_map calls [08:31] with 19MB transferred [08:32] nigelb: https://bugs.launchpad.net/bzr/+bug/328910 should be genuinely easy and useful [08:32] Ubuntu bug 328910 in Bazaar "ugly traceback when sftp server drops connection" [Medium,Confirmed] [08:32] it has a note about where to start but you're super welcome to ask more about it here, or on the bug [08:33] 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] poolie: hehe, thanks :) [08:33] so i did init-repo, then bzr branch lp:gcc-linaro/4.6 into there [08:33] poolie: do you have the .bzr.log for me to look at? [08:33] poolie: well, I'm doing "lp:gcc-linaro" just trunk, not a stacked branch. That may be the difference [08:33] heh, there's something magical about doing bzr branch lp:bzr :) [08:33] Try that first, see if it helps, and we may need to do more work w/ stacking [08:35] but yes, trying /4.6 I see that I'm already at 4MB @ 50s [08:36] jam: in chinstrap:~mbp [08:37] 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] ok [08:37] can you try lp:gcc-linaro directly? [08:37] (I'm at 206s ,and a huge number of round trips) [08:37] my guess is that the caching provider isn't triggering at the right layer [08:38] yes, starting it now [08:38] so we make a request against StackedRepo find it isn't there, then fallback to StackedOnRepo and find it in the cache [08:38] good example of the value of having someone else test i suppose [08:38] and we do that *for every step* [08:38] michaelh just reported a dupe of this today, and his was with /4.6 [08:38] sure [08:39] woo [08:39] that looks a lot better [08:39] got to 'using fetch logic' in 94s [08:40] poolie: right, and compare that with bzr.dev [08:40] 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] I could be wrong, but that is what it looks like to me [08:40] i think you're right [08:41] i'm glad i avoided saying "it's fixed" to them prematurely though [08:41] poolie: agreed. [08:42] 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] It is pretty vague, though. [08:43] poolie: but yeah, I'm seeing 500s 10MB transferred, and still discovering for a stacked branch. [08:46] i'll comment on the bug [08:47] 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:48] grr vila+bzr@c.c [08:49] 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:52] jam as a workaround we could unstack their 4.6 branch [08:53] poolie: because they are branching from it a lot? [08:54] poolie: certainly that will give them an immediate boost if it is something they are active on. [08:54] (should it be the dev focus if it is the active branch?) [08:55] yes [08:55] i don't know about that [08:58] poolie: so the *big* win is that unstacking it will mean they get immediate benefit regardless of what bzr client they are using [09:00] poolie: so I would recommend for that because it helps them *today*, though I still want to fix this [09:01] jam: but won't they run into issues when *pushing* if 4.6 is unstacked ? [09:01] or is that the opposite ? [09:02] 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] so *if* they bring in a lot of new data from trunk into 4.6 [09:02] that will get copied when they push to 4.6 [09:05] 'that part' == unstacking ? [09:06] vila: yes [09:06] k [09:06] it will have to transfer, say 500MB, of history [09:06] (not sure on the exact amount) [09:06] but if we get someone close to the datacenter to do it, it should be pretty fast. [09:07] and how about keeping it stacked but still add the missing revisions ? [09:08] vila i doubt they will be regularly merging such large amounts from trunk to 4.6 to outweigh the existing history [09:08] jam, ok, it completed in 27m [09:10] 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:23] poolie: hm, unsure how to get the right info to raise ShortReadvError. [09:23] Actually, unsure how to get the parameters for it. [09:23] biab [09:24] 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) === hno_ is now known as hno [09:25] nigelb: a pack or a an index file will do [09:26] heh, didn't understand that. let me grep where its used and try to decipher what you wwant [09:27] ShortReadvError occurs when a file is truncated (it should never happen under normal circumstances) [09:28] ah, so when the ftp does get disconnected, that's what would happen. [09:28] *stfp [09:53] nigelb: sry, didn't notice your reply [09:54] nigelb: hmm, so, if you're working on ssh disconnections, that's a bit different [09:55] nigelb: truncating the file may not be the right way to trigger the problem [09:56] nigelb: reading bug report [09:57] 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:59] 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 [10:06] vila: we're talking about FTP? [10:07] vila: FTP doesn't have any standard way to tell you how many bytes to expect on your data channel [10:07] vila: and it's a separate connection to the control channel [10:07] spiv: sftp, see bug above [10:08] https://bugs.launchpad.net/bzr/+bug/328910 [10:08] Ubuntu bug 328910 in Bazaar "ugly traceback when sftp server drops connection" [Medium,Confirmed] [10:09] vila: in that case probably a ConnectionError of some sort is probably a better match [10:09] spiv: why did you suggest to turn a network error into a ShortReadvError ? [10:09] ha right [10:09] k [10:09] I agree [10:09] nigelb: ^ [10:56] Can I write a message for some changes I just shelved, but forgot -m? [11:00] jimis: unshelve/reshelve :-/ [11:00] jimis: not ideal [11:00] vi .bzr/.... ;) [11:02] bairui: Hey, I snuck off to sleep while you were eating. Hope you got on the right track. [11:03] fullermd: you... what ? [11:03] It's not my fault! I'm sick! [11:03] I mean, physically, this time. [11:04] ha, ok [11:19] mgz: hi. how's things? === Mkaysi|ZNC is now known as Mkaysi|ZNC|ZNC [11:45] how comes there's no bzr qremove command ? [11:47] Riddell: what would it use qt for? [11:47] well same as bzr qadd I would think [11:48] I wasn't aware there was a qadd either :) [11:48] * jelmer gives it a try [12:10] 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:11] I'm doing up a dev & mig workflow doc & diag now [12:19] bairui: Oh good. [12:20] If you haven't come across them, some of the SpotDocs I wrote up a little while back may be useful. [12:20] http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs [12:20] sweet :) [12:20] Particularly the PiecesInBrief section. [12:21] 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] nice. i've added them to my read queue. cheers. :) [12:25] (they're pretty rough; haven't had time to do much editing etc :( ) [12:25] that's cool... I know where you live if I need to clear anything up ;) [12:28] jam, so, anything else you need? [12:28] otherwise i might poke at some more jubany failures and then stop [12:33] poolie: I think I'm good for now, probably time for you to take a break :) === Mkaysi|ZNC|ZNC is now known as Mkaysi_ === Mkaysi_ is now known as Mkaysi_|ZNC === bigjools-afk is now known as bigjools_ [15:00] vila: ping [15:00] jelmer_: do you still think you're going to be releasing bzr-svn ? [15:01] jam: pong [15:01] jam: Yep, working on that at the moment. It's way overdue :-/ [15:01] jelmer_: k, I won't spin up ec2 yet. [15:01] vila: Thoughts about get_parent_map and caching [15:01] have some time to chat? [15:01] always for you :) [15:02] vila: mumble/voip/skype? I'm thinking it will be faster than trying to type it all === zyga is now known as zyga-afk [15:45] 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:48] briandealwis, I can't clone that URL with git either, it just hangs [15:48] oh! It works for me… or at least it was [15:49] just checked again: it's working from here [15:53] jelmer_: is there a way to force bzr to look at the URL for bzr-git? There's no git+http scheme [15:53] (I vaguely recall there being some "+xxx" addition to do something different) [15:54] briandealwis: the problem is that that site doesn't return 404 for files that are not found :-/ [15:54] oh! that's not useful [15:56] briandealwis, bzr-git doesn't support smart server access over http to git repositories [15:57] jelmer_: and it doesn't support dumb access either? :) [15:57] briandealwis, it does support dumb access, but I'm not sure if that's enabled on the server [15:58] 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] briandealwis, the main problem is the missing 404 though [15:59] I'll file a bug with them about that. There's no +xxx I can append to force bzr-git to continue on? [16:00] briandealwis: no [16:00] ok. Thanks for the help, jelmer_ === deryck is now known as deryck[lunch] === Mkaysi_|ZNC is now known as Mkaysi_ [16:31] 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:32] briandealwis, *any* file that doesn't exist [16:32] briandealwis, e.g. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/.git/foo [16:33] 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:35] briandealwis: I'm not sure if it's actually worth reporting this just yet [16:35] briandealwis: it'll be slow as hell until there is support for the smart server over http in dulwich/bzr-git [16:35] briandealwis, any reaosn you're not cloning over git:// ? [16:36] It's not working. I've reported that to them too :) [16:36] briandealwis, seems to be working fine here [16:37] huh, weird. I get an error. I'll check that I'm running the latest dulwich and bzr-git === 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 [18:41] 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:42] briandealwis, does git:// work for you with git itself? [18:52] jelmer_: I can pull from github. Though I get a NotImplementedError exception when I try 'missing' [19:00] 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] briandealwis: "bzr missing" should "work" now (just pushed a fix to lp:bzr-git) [19:01] great! [19:02] ah right, now it doesn't error :) === med_out is now known as med === med is now known as medberry [19:28] 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:33] briandealwis: ah, cool [19:34] 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:35] 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] 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:42] briandealwis: yeah, should work with current tip of bzr-git and bzr [19:43] cool! I'll give it a shot. [20:44] Is there some way to disable or prevent a particular plugin from being loaded from the CLI? [20:46] Is there any way to make bzr update atomic? [20:58] Not sure how I missed it, but BZR_DISABLE_PLUGINS is what I was looking for [21:04] cody-somerville: what do you mean by atomic exactly? [21:04] jelmer_, ie. if the operation fails (ie. conflicts, etc.) that nothing changes === yofel_ is now known as yofel [21:23] cody-somerville: it is atomic, there just isn't any support for rollback if the transaction contains conflicts :) [21:24] cody-somerville: I agree it makes sense to have an option which can abort and not touch the tree if there are conflicts [21:25] yea, I'm basically looking for it to be an atomic transaction [21:55] hi people [21:55] I have a weird merge problem [21:55] I've done a bunch of work in a branch [21:55] which ends up being branched from the packaging branch (with distro patches et al) [21:55] instead of the upstream mirror [21:55] now I want to make another branch [21:56] and merge in particular changes to particular files [21:56] is there a way to say "merge the changes to this file from that branch" [21:56] but not get the revisions? [21:58] thumper! [21:59] 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] hi jelmer_ [21:59] ah... [21:59] that should work [21:59] although I'm going to have to revert a bucket load of changes I don't care about [22:00] I did "bzr revert .", but it did the opposite of what I wanted and I couldn't remember the syntax [22:00] can I just merge changes from a particular file? [22:00] thumper: you can, just specify that specific file [22:00] kk [22:00] * thumper tries [22:01] nope [22:01] can't specify a file in merge [22:02] thumper: "bzr merge ../path/to/branch/file.txt" works here [22:02] ah... I was doing two parts [22:03] jelmer_: it also appears that just merging a file doesn't have pending revisions to merge [22:03] thumper: yep [22:03] we don't properly track cherrypick merges of individual files or individual revisions yet [22:03] yep [22:03] that works for me [22:03] ta === medberry is now known as med_out [22:53] jelmer_: Do you have any plans to release subvertpy 0.8.4 soon? [22:55] 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:57] maxb, sure, I guess I could do a release [23:04] If it's not too much effort, great [23:05] Otherwise, we can just obsolete karmic now, before bzr 2.4 hits ~bzr/ppa [23:06] Which, come to think of it, might be the sensible thing to do anyway [23:07] it is over 3 months EOLed [23:24] does bzr have anything like mercurial queues? [23:25] I guess loom is the thing I need to look at? [23:25] pipelines are closer to queues [23:25] loom versions the stack of patches as a unit, which is useful for distro / collaboration-around-the-queue [23:26] ah [23:27] I'm not yet sure which approach I want here [23:29] (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:31] I think pipelines may be the easiest way [23:35] I guess I can't sync-pipeline to Launchpad [23:37] idnar: pipelines fit that use case [23:37] idnar: sure you can [23:38] 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:39] 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] hmm, where is abentley when you need him :) [23:39] idnar: oh [23:39] idnar: so, what you do is have the pipeline local [23:39] and publish all the pipes to lp as separate branches [23:39] this is a bit different to loom [23:39] yeah [23:39]