[00:00] mwhudson: does it look like an ok bug/patch though? === RAOF_298 is now known as RAOF_831 === RAOF_831 is now known as RAOF_61 [00:00] jelmer: any luck? === RAOF_61 is now known as RAOF [00:00] slangasek, Yeah, I've managed to reproduce it [00:01] And I think I've got a clue as to why it's failing [00:22] jelmer: so did I screw something up? :-) [00:36] hello all... [00:36] I read in some documentation that bzr serve "is" an in development feature..... [00:36] but those docs are outdated I mean.. about version 0.16 [00:37] is this now fullfeatured and functional? [00:37] I am using 1.9 of course [00:37] Current docs are at http://doc.bazaar-vcs.org/latest/ [00:37] lexrupy: its not finished, but then software never is [00:38] bzr serve is certainly functional, and everything that works with direct file access should work via a bzr server. [00:38] yes I know, but I can use it in production as well? [00:38] It's still in development, but so is the rest of bzr ;) [00:38] Yes, it's ready for production use. [00:39] spiv: thank you, and, I already read the latest documentation... I use Bazaar since version ~ 0.90 I think [00:40] I am already using via bzr+ssh... I am asking just because I will write an article about this and I want to make sure that it is "stable" [00:41] ok, I think you can help-me a little bit more [00:42] lexrupy: launchpad hosts bzr using bzr-serve [00:42] in my tests I got bzr+ssh about 20% faster than sftp... these numbers are reliable or you have more precise numbers? [00:42] we have been using serve in production at work for months. [00:43] lexrupy: it depends on a lot of variables, like the latency of your network connection. [00:43] spiv: ok, in my tests I use my laptop in a LAN environment with server [00:43] slangasek, it seems it's similar to bug 295416 [00:43] Launchpad bug 295416 in bzr-svn "branch root moving breaks missing and push" [Medium,Triaged] https://launchpad.net/bugs/295416 [00:44] hmm, ok [00:44] lexrupy: and also on which operation you're measuring; some operations are optimised more over bzr serve, others will be about the same as SFTP. [00:44] you didn't have a branch root, but in your case the first revision in svn history is not the first revision in bzr history [00:44] spiv: humm [00:44] slangasek, it shouldn't be too hard to fix, let me have a look [00:44] spiv: I tested checkout and branch commands [00:46] The optimisations so far have mostly focused on those and on push. [00:46] lifeless, I didn't merge the branch, but it's good to have around. [00:46] spiv: in a tree with just some files (3.8Mb) with 152 revisions and I take about 11secs to sftp and about 9 secs to bzr+ssh [00:46] 20% certainly sounds believable, but I can't give you a single number that will be universally true :) [00:46] ok [00:48] rockstar: its in trunk [00:48] rockstar: *someone* merged it [00:49] lifeless, yea, I asked beuno to merge it. [00:49] Was it not ready to be merged? [00:49] it was [00:50] it would be nice not to disable concurrent request processing [00:50] but I need to know more about the paste contract to do that [00:50] it would also be nice to record the url [00:50] e.g. trunk_changes_foo_bar-1-stats.callgrind [00:55] lifeless, yea, I also think that, now that I've been inspecting results. [00:55] The number isn't so helpful. [00:55] I was thinking about how launchpad manage that groups of Developers to have access to a branch [00:56] But I cannot spot that... is each launchpad user a Unix User on server? [00:57] lexrupy: no, they are not [00:57] lexrupy, nope. [00:57] rockstar: its a start; better than embedding callgrind data in a .jpg :) [00:58] huh, so How can I setup my server to behave like that? [00:58] lifeless, :) [00:58] lexrupy, behave how specifically? [00:59] I can for example create a branch on server belong my user.... bzr push sftp://myserver/~/mybranch [00:59] at this poiint mybranch will belong to my user on server... [01:00] and another user cannot push changesets there if I not..... forget [01:00] I have pointed that now [01:00] :) [01:00] lexrupy: you need to use a replacement ssh server to do this; or use bzr+http and use apaches auth support [01:00] I put my ssh public key on server.... I have forgot that :) [01:00] lexrupy: bzr works fine with groups; just have both users in the same group [01:01] I in fact can have a bzr user on server and create all repos in that account [01:01] then authenticate users via ssh public key [01:02] sorry, it was a "stupid" question [01:02] lexrupy, I put my branches in /var/lib/bzr// [01:02] lifeless: In bzr-search, did you mean to change group_size from 2500 to 50? [01:02] Peng_: yes [01:02] That lowers memory use, right? [01:02] lexrupy, So I make the folder owned by a group called developers, which I am a member of. [01:03] Peng_: yes [01:03] lifeless: Does it affect speed? [01:03] (effect? bah) [01:03] Peng_: somewhat [01:03] and you have an user for each develpper at yhour server? [01:03] lifeless: How long is it supposed to take to index a copy of bzr.dev? [01:03] Peng_: a few minutes [01:04] lifeless: I've had it running for 20 minutes and it's barely halfway done. :) [01:04] I already have a setup with asingle bzr user, and each user push and pull from server using something like bzr+ssh://bzr@server/bzr/branch [01:04] Peng_: hmm, roll back the push and try again; I'd like to know if it is faster for you [01:05] lexrupy, yes, each developer on the system is a member of developers. [01:05] You mean waste 20 minutes of work? Heh. [01:06] Peng_: yes [01:06] rockstar: and I already have public keys there so, users no need to enter bzr password on server, but I was thinking about sftp protocol, but since spiv said me before that launchpad use the Fast Server the launchpad setup seems like my setup [01:06] FWIW, the copy of bzr.dev is using btrees, and I ran it with -Dmemory, but that shouldn't have an impact. [01:07] rockstar: but in fact I add a public key for each people I want to do access to *all* branches... and launchpad do it "per branch" [01:07] Peng_: if the index time is substantially different for you before/after that patch, I will fix; if its not, then I'll get you to give me a lsprof trace. [01:08] bbs, lunch [01:09] lifeless: Right now the progress bar is on step 2/9 and it's only been running for 1.5 minutes, so I think it is substantially faster. [01:10] Is it possible to use bzrlib from a standalone bazaar installation on win32? === dryahetzeph is now known as hydrapheetz [01:11] lifeless: Now it's at 4/9. It's definitely much faster. [01:15] Haha, woah, it's using 400 MB of RAM. I like group_size = 50 better. :P [01:16] lifeless: Using the previous revision of bzr-search, it took 7 minutes and 42 seconds to index the whole thing. That's definitely a lot faster. [01:18] Hm, I wonder if I can just use the bzrlib module from the sources instead. [01:18] hydrapheetz: Sure, you can. Some things will be a bit slower if you don't compile the extensions, but it'll work. [01:18] (As long as it can find its dependencies.) [01:19] Ah [01:20] I tried doing that and importing it, I haven't tried anything else with it yet [01:25] Peng_: ok, there are two possibilities [01:25] Peng_: I bet its the type detection misfiring [01:26] Peng_: put the patch back, then bump the batch size up, if you would [01:26] Peng_: I bet its still slow [01:28] Is there any way to update a working tree after a remote client push? The remote client only has bzr+ssh:// access [01:29] kumi: Does it have plain-old-ssh access? [01:29] kumi: Well, anyway, the push-and-update plugin might work. [01:29] nope, just bzr [01:29] lifeless: Will do [01:29] push-and-update require plain old ssh access [01:29] Peng_: thanks - appreciate this [01:30] kumi: bzr+ssh is layered on plain old ssh [01:30] yeah but the remote client is limited to the 'bzr' command [01:30] push-and-update just runs "bzr update". [01:31] So unless it's limited to "bzr serve", it should work. [01:31] Anyway, try it out. It only takes 30 seconds. [01:31] It's using the bzr_access script, it won't work [01:31] Oh. [01:32] lifeless: It's running now. I'll get back to you in 7 minutes, I guess. [01:32] If it's restricted to "bzr serve", then there's not much you can do. You could write a plugin to install on the server that installs a post_branch_tip_changed hook to update a working tree. [01:32] Peng_: thanks [01:32] not many of the built-in hooks are server side, maybe pre_change_branch_tip [01:32] post* [01:32] lifeless: Actually, it's already on step 2/9, so it seems to be going pretty fast. [01:32] I'll check that ouut [01:32] Or you could configure a cron job on the server to run "bzr update". [01:32] Peng_: oh [01:32] spiv: yeah maybe that too [01:33] kumi: with new enough client and server (1.7?) post_change_branch_tip (or whatever it's called) will occur server side. [01:33] lifeless: Yeah, it's definitely not going to take 20 minutes. [01:33] Peng_: so tip with batch_group of 50 is slow, with 2500 is fast? [01:33] Peng_: ok. I was hoping to reduce the massive memory spike mysql causes [01:33] spiv: I've got 1.9 on both ends [01:33] lifeless: group_size, yes. [01:33] kumi: ok, that's definitely new enough :) [01:34] Too bad. I was hoping to reduce memory usage too! [01:34] kumi: or tweak the bzr_access script to allow "bzr update"? [01:40] I don't think I could handle that (unless I have a 2nd copy associated with a 2nd ssh key). I'll try writing a hook [01:41] kumi: why would you need a 2nd ssh key? [01:42] I think that's how it would have to work with authorized_keys [01:43] if ssh key #1 logs in, run the bzr_access (bzr serve) script. If ssh key #2 logs in, run the bzr_access (bzr update) script. [01:45] kumi: ah, I see [01:45] I thought it was more like sudoers [01:45] the authorized_keys command parameter only accepts one argument [01:45] It wouldn't take much hacking to allow the script to optionally call 'bzr update' after the 'serve' was done. [01:46] Odd_Bloke: it won't know what path to update [01:46] a plugin is the best option [01:47] It might work if the branch directory is the same as the working tree directory === jamesh__ is now known as jamesh === tchan1 is now known as tchan === mark1 is now known as markh [04:04] Hi folks. I've got a shared repository of format "rich-root-pack". I would like to upgrade it to the 1.9 equivelant, but I'm not sure if that is "1.9-rich-root" or if, in fact, there is nothing to upgrade path at all. [04:05] grettke: its 1.9-rich-root [04:05] lifeless: Understood. Thanks. [04:18] lifeless: BTW, do you have any use for the search indexes I created while timing it, or can I delete them? [04:22] Peng_: unless you suspect a bug, no [04:22] Peng_: but you could keep them, to use :P [04:24] Wait.. it creates a new pack each time it hits the group_size? When the group_size is really low, that means it'll do a bunch of autopacks, right? [04:24] That wouldn't help performance. [04:28] What does bzr-search do if not all of the revisions in a branch are indexed? (E.g. I hit Ctrl+C halfway through the indexing.) [04:30] Peng_: autopacking is small; only 10% hit or so [04:38] spiv: around? [04:40] Peng_: also search has a different autopack trigger than bzr [04:40] Peng_: because of slightly different uses [04:43] abentley: yeah [04:45] spiv: So I tracked down a cause of stacked push over HPSS slowness: RemoteRepository.get_parent_map wasn't stacking. [04:46] abentley: ah! [04:46] spiv: Yeah, that caused it to try to push ~ the whole history. [04:46] So the walk_to_common_revisions would walk a *long* way... [04:46] Hmm. [04:47] spiv: I have a fix that does the stacking on the client side in RemoteRepository. [04:47] walk five thousand miles... [04:47] You mean the server-side is doing the wrong thing, or the client? [04:47] spiv: Server-side doesn't have fallback repositories, so it can't be expected to do the right thing. [04:48] * spiv nods [04:48] So I figure this has to be done client-side, which is pretty in-tune with lifeless' choices. [04:49] i.e. that we don't want to require stacking on the server side. [04:49] spiv: I'm looking at RemoteRepository.get_parents, and I don't understand why it's implemented that way. [04:50] RemoteRepository.get_parent_map, you mean? [04:50] spiv: yes. [04:50] There's a bit of ugliness there to handle falling back to less optimal methods, but I'm not sure if that's what you're referring to. [04:51] It's doing caching itself instead of using CachingParentsProvider. [04:52] I suppose it could, although it'd require a bit of mucking about to create a suitable object to construct it with. [04:52] Is there a reason for that? Or a reason not to do it in _make_parents_provider? [04:53] If I implement a RemoteVersionedFiles class to handle the .revisions (and .texts/.inventories/.signatures) I could just pass that I guess. [04:54] spiv: Oh, it's because the caching is happening at a tuple level? [04:55] There's nothing about CachingParentsProvider that requires the keys to be strings. Tuples should work just fine. [04:55] Short answer: no particular reason. [04:56] spiv: Okay, I'll hack on it tomorrow and there should be a patch on the ML when you wake up. [04:56] Although I don't think any other Repository uses CachingParentsProvider in its implementation of get_parent_map. [04:57] It seems to be used via _make_parents_provider by get_graph. And get_parent_map is the primitive that that is built on. [04:57] spiv: Nothing should be using get_parent_map directly. They should be using get_graph, and other repos use it for that. [04:58] Hmm. [04:58] I don't think that's actually what's happening, even if that's what should be done. [04:59] There's places like Repository.has_revision and InterPackRepo.fetch that call it directly. [05:00] spiv: Doing it directly kills opportunities for optimization. [05:00] Why not allow get_parent_map to cache automatically, rather than forcing things to go via get_graph? Because that gives us more room to tweak the caching policy in future? [05:01] Because you get a really easy way to manage the lifetime of the cache. [05:02] abentley: OTOH you have to manage the lifetime, or else differnet parts of bzrlib end up using different caches [05:03] get_graph() strikes me as a bit weird, basically because of what lifeless just said. [05:04] hello friends [05:04] lifeless: This is a memo, not a true cache, so we can't keep using it for the whole bzrlib lifetime. [05:04] poolie: hi. [05:05] hi poolie [05:05] There's only one graph per repository object (or should be...), because the data should be cached just once. So it's not a very separate object. [05:05] abentley: because it will grow too big? [05:05] spiv: There are as many graphs as you create. [05:05] lifeless: yes. [05:06] abentley: so I think there are two separate things here; the cache does reset when the lock count drops to 0, so its not entirely a memo, but as you say there is no ejection policy [05:06] Hmm, I thought I'd seen a get_graph somewhere that returned the same graph object, or at least effectively the same one. [05:06] lifeless: I am talking about CachingParentsProvider, not the cache in RemoteRepository. [05:06] abentley: oh right [05:07] spiv: No, and it's impossible, because get_graph takes a repo parameter. [05:08] There's other, related caching that happens in repository that is managed by lock lifetimes, i.e. index caching. [05:10] Hmm. The other thing with RemoteRepository.get_graph is that it expects to receive more results than it asked for. [05:10] spiv: The parents provider for an individual repo *could* be always the same, but isn't because the client was meant to manage that object's lifetime. [05:10] I suspect that returning those extra results, rather than just filling a cache with them, would break some callers in surprising ways. [05:11] It's too easy to assume that "if len(foo.get_parent_map(keys)) != len(keys): # something must be missing" will work. [05:11] get_graph just returns a Graph. [05:12] But if those extra results sent by the server aren't cached, then RemoteRepository is going to be unnecessarily slow. [05:14] So, if the question is "why change RemoteRepository.get_parent_map to reuse the cache logic in CachingParentsProvider?", then sure, we can do that. (it's not a huge amount of code duplication, but reuse is typically a good thing) [05:14] But if the question is "can we make RemoteRepository.get_parent_map not do any caching?", then I think the answer has to be no. [05:15] spiv: So this means that RemoteRepository can't be its own parents provider. [05:15] And the original reason that repositories had get_parent_map was so that they could act as parents providers. [05:16] Or at least, "not yet, and changing that will need some careful thought." [05:17] abentley: why can't it be its own parents provider? [05:17] Why do you say that? I'm not sure what part of the contract it doesn't satisfy? [05:17] (Is there a written description somewhere? A quick grep isn't finding one for me.) [05:18] spiv: In order for RemoteRepository.get_parent_map to use CachingParentsProvider, there must be an object that provides uncached access to parents via a get_parent_map method. Which means it can't be RemoteRepository.get_parent_map. [05:19] I can see that it would be redundant to use CachingParentsProvider with RemoteRepository.get_parents_map, but I don't see why it *can't* use it. [05:19] what spiv said [05:19] spiv: Calling get_parents_map would give infinite recursion. [05:20] Huh? [05:20] abentley: cached provider -> rr -> cached provider (remote content only) [05:20] RemoteRepository.get_parents_map -> CachingParentsProvider.get_parents_map -> RemoteRepository.get_parents_map. [05:21] But there is no "RemoteRepository.get_parents_map -> CachingParentsProvider.get_parents_map". [05:21] abentley: ah I see [05:21] spiv: abentley is saying that the CPP needs a callable to get the backend data over the wire, and that that can't be RR.gpm [05:21] spiv: If we use CachingParentsProvider to implement RemoteRepository.get_parents_map, there will be. [05:23] abentley: sure. But if we write "def f(): f()" there will be infinite recursion too, and we don't do that either ;) [05:24] I mean, obviously we can't make RemoteRepository.get_parent_map use a CachingParentsProvider(self). [05:24] But there are other ways to reuse that caching logic without doing that infinite recursion. [05:24] spiv: in other words, it can't be its own parents provider. [05:25] (refactor CachingParentsProvider slightly, or provide another object than self to CachingParentsProvider that will fetch the data) [05:25] The other object will be the parents provider. [05:26] Well, it is its own parents provider at the moment, as the implementation of RemoteRepository._make_parents_provider hopefully demonstrates :) [05:27] But it is upsetting to me that I need the other object, since the purpose of sticking get_parents_map on repos was to allow the repos to be parents providers. [05:28] But RemoteRepository already is a parents provider, as I understand the term. [05:28] spiv: Yes, but it's one that doesn't stack. [05:28] It is an object that implements get_parents_map, what else is there? [05:28] And adding stacking would ideally be done using _StackingParentsProvider [05:28] But it's the same story as CachingParentsProvider. [05:29] abentley: huh? lost me [05:29] abentley: why can't you use SPP with a RR and its fallback repositories [05:30] lifeless: I thought we weren't supposed to do server-side stacking. [05:30] abentley: on the client [05:30] lifeless: Misunderstood. [05:30] Why wouldn't _StackedParentsProvider([remote_repo, other_repo]) work? [05:30] lifeless: You can't do SSP with a RR and its fallback repositories, because that will give infinite recursion. [05:31] spiv: The StackedParentsProvider must be used in the implementation of RR.get_parent_map [05:31] I think there is a lot of confusion because you're talking about a hypothetical version of RemoteRepository, and we're talking about the current actual RemoteRepository. [05:32] Ok. [05:32] spiv: I'm talking about one where we have fixed this problem. [05:32] That stacking is broken. [05:32] Until the patch is published, it's hypothetical ;) [05:32] And ideally, killed the duplicate code. [05:33] spiv: Are you saying you don't want me to discuss how to fix this problem? [05:33] abentley: so it seems to me that caching in RR is unrelated ot the core issue which is that RR.get_parent_map doesn't know how to retrieve data from fallback repo's [05:33] So it seems to me that it's unnecessarily inconvenient to construct a FooParentsProvider from a callable. [05:33] lifeless: The common thread is a lack of use of existing ParentsProvider code. [05:34] Which means that you can't do e.g. _StackedParentsProvider([remote_repo._private_get_parent_map, ...]), you have to create an object with a get_parent_map attribute. [05:34] spiv: It's an interface. [05:34] abentley: what I'd be inclined to do is consider the current get_parent_map as the binding to the remote server, and rename it to _get_parent_map, then have get_parent_map which is built on a self._pp, which is a SPP([self._get_parent_map, fallback1.get_parent_map, ...]) [05:34] Which seems more like a flaw in the *ParentsProvider(...) APIs than RemoteRepository. [05:35] That said, it's easy to construct a helper to adapt a callable to an object with that attribute. [05:35] Robert's suggestion sounds fine as well. [05:38] Well, I guess lifeless's suggestion still needs to address the "there needs to be an object with a 'get_parent_map' attribute that is the underlying non-stacked get_parent_map" [05:38] spiv: You wouldn't consider the commit code flawed because it expects a branch to have a last_revision_info method. Why would StackedParentsProvider be flawed because it expects a parents provider to have a get_parent_map method? [05:39] But that's easily solved either by making a new class to hold it, or by making an alternative constructor for SPP that takes callables rather than objects with get_parent_map. [05:40] Because it only demands a single attribute of the object, a callable one. So it could just as well take the callable directly, which makes problems like this one less messy. [05:41] I was responding to "it's unnecessarily inconvenient to construct a FooParentsProvider from a callable", and the suggestion that StackedParentsProvider take a callable instead. [05:42] spiv: its easy enough to write CallableParentsProvider, to adapt; though as get_parents_map is critical path for log and other deep history operations that may be problematic [05:42] Man, I make a lot of typos sometimes. "it seems to me that it's unnecessarily inconvenient to construct a FooParentsProvider from *an object when all it needs is a* callable" [05:42] lifeless: right [05:43] (If it's that much of a critical path those classes would be holding references to callables rather than parents providers already, though...) [05:47] hi [05:47] igc: hello :) [05:47] hi jml [05:47] lifeless, abentley: I have a loom problem. [05:47] I just did combine-thread on the wrong thread [05:47] how can I undo this? [05:48] jml: is your loom recorded? [05:48] lifeless: I probably hit record some time in the distant past [05:48] jml: ok then thats not so easy [05:49] jml: plan b, create-thread to recreate the thread you deleted [05:49] and use pull -r to reinstate its top [05:49] You could use "bzr heads" to find the old tip of that thread. The head with a nick of the old thread's name is probably the one you want. [05:49] *tip* [05:49] Wow, lifeless's accent is now leaking on to IRC ;) [05:50] spiv: heads doesn't find it. [05:50] spiv: its not a head [05:50] jml: log --show-ids on the thread above [05:51] lifeless: it was the top thread. [05:51] jml: if it was the top thread it will be a dead head [05:51] lifeless: oh right, he probably had it merged into the parent loom [05:51] s/loom/thread/ [05:51] ahh there we go. [05:51] s/parent/higher/ [05:54] thanks [05:55] lifeless: incidentally, how would you feel about a loom patch that aliased up-thread to "up" and down-thread to "down"? [05:57] jml: fine === abentley1 is now known as abentley [06:09] abentley: did you have any thoughts on http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081114060525.GJ31377%40steerpike.home.puzzling.org%3E ? === abentley1 is now known as abentley [06:21] abentley: did you have any thoughts on http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081114060525.GJ31377%40steerpike.home.puzzling.org%3E ? [06:24] igc: hello. have you seen the latest activity in bug #232177 ? [06:24] Launchpad bug 232177 in bzr-fastimport "Better darcs support needed" [Undecided,New] https://launchpad.net/bugs/232177 [06:25] darcs-fast-export makes bzr's fast-import really slow in comparison with git's :-( [06:27] hi gour [06:27] igc: how are you? [06:28] gour: so bzr-fast-import is working, just slow, is that it? [06:28] gour: not too bad at the moment thanks [06:28] igc: yes, i tried it with smaller repo, cause it took too long for e.g. darcs-unstable [06:28] *repos [06:29] gour: almost recovered from one lot of surgery with another lot coming later this week [06:29] igc: i'd like that LP people add darcs import to LP [06:29] igc: i'm glad you are doing fine. we pray that everything will be good [06:29] gour: be sure to raise that then as a bug against LP [06:29] gour: thanks [06:30] igc: i added comments to https://answers.launchpad.net/launchpad-bazaar/+question/41438 if some of You (bzr devs) think it is good thing, it would be nice to comment [06:30] igc: is question enough or better to create a bug? [06:31] gour: create a bug please [06:32] igc: ok [06:40] igc: done. bug #298933 [06:40] Launchpad bug 298933 in malone "support for darcs import" [Undecided,New] https://launchpad.net/bugs/298933 [06:40] gour: thanks [06:41] igc: do you take care about your diet? [06:41] gour: very much so [06:42] igc: good boy ;) that's VERY important... [08:24] bazaar 1.9 bzr-svn 1.45 , macosx 10.5 macports; bzr checkout from a svn trunk（bzr co http://www.prestashop.com/publicsvn/trunk）；error occured ;bzr: ERROR: footer.php is already versioned [08:25] is it a bzr-svn's bug? [09:46] hi all [09:48] is there a way to get bzr-git work over http ? [09:50] I need to remove some files that lives in my history that are HUGE and when I mean huge I mean 600mb that is not anymore in the tree, they are introduced at revision 4 and removed at revision 8, hmeland told me to use rebase but I really dunno how to do it === jszakmeister|awa is now known as jszakmeister [09:56] asabil: I suspect it involves writing the code to do that. jelmer will know more. [09:56] oki thanks [11:03] visik7: I haven't use rebase much myself, but I think something like this should work: "bzr branch -r 3 big-branch new-branch; cd big-branch; bzr rebase -r 5..7 ../new-branch; bzr rebase -r 9.. ../new-branch" [11:04] If revisions 4 and/or 8 do anything else than add/remove the now-unwarranted files, you'll have to do some manual merge-trickery to retain those interesting bits. [11:11] visik7: I think you can also use bzr replay [11:27] hi all === jszakmeister is now known as jszakmeister|awa [11:40] hi vila, was your flight back pleasant? [11:56] oh dear. someone pushed me into really crazy ideas -- extending literate programming to large software using event streams and dotfiles to chain things together === sabdfl1 is now known as sabdfl === tetha_ is now known as tetha === verterok_ is now known as verterok [13:00] lifeless: Pleasant may too strong a word :) Delayed 7h at Brisbane broke all connections adding a day in Singapore... luckily I avoided French pilots strike [13:01] lifeless: be careful what you wish for... I should not have wish to stay longer in Australia :) [13:03] vila: heh [13:03] vila: bad weather at Brisbane? [13:03] lifeless: so, pleasant... yes, but having only slept ~12h (cumulated) since last Friday ... [13:03] Ouch! [13:03] Go to bed :P [13:04] spiv: not even, some "noremal" delay of 2 or 3 hours at first. but then a verification requiring some pieces to come from Sidney [13:05] That's pretty crummy. I'm glad you eventually made it home! [13:05] It was interesting to see how they were able to find an hotel for the ~300 people concerned and re-book all the flights (with the same numbers 24 hours later) [13:06] * spiv -> bed [13:06] I arrived a couple of hours ago, but my I doubt I will work today (or produce anything deserving to be called work :) [13:07] spiv: I hesitate to do the same :) I'd like to find back the right schedule :) [13:24] would it be possible to have the bzr-svn in the bzr PPA usable ? === lamont` is now known as lamont [13:43] asabil, see bug 293009 [13:43] Launchpad bug 293009 in bzr-svn "Bzr-svn conflicts with bzr in the PPA" [Undecided,New] https://launchpad.net/bugs/293009 [13:45] jelmer: ok thanks, but what about a fix ? [13:45] it is just an [13:46] organization issue [13:46] asabil, not sure, John is doing most of the PPA uploads [13:46] I guess it would make everyones life easier if the uploads were made in sync [13:46] asabil: The releases of bzr and bzr-svn aren't made in sync [13:47] hmm ok [13:48] It's all a sneaky underhanded method of tracking how many people the the PPA. [13:51] WTF? s/the/use/. Who stole my typing fingers? [13:51] Perhaps we should pull bzr-svn from the PPA unless somebody volunteers to maintain it [13:51] s/unless/until/ === mw|out is now known as mw__ [13:55] is it that hard to maintain ? [13:58] It means 4 uploads to the PPA [13:58] *per package* [13:59] I maintain ~10 bzr-related packages in Debian, so uploading to PPA as well would be quite some overhead [14:02] jelmer: have you tried auto-ppa (from jkakar) ? [14:03] cprov, Yes, but it has several issues that would need to be fixed first [14:03] jelmer: uhm, are they *hard* ? maybe I could help you guys. [14:04] jelmer: also, are you absolutely sure you need rebuilds in all ubuntu series ? [14:05] cprov, Yeah, it's a nontrivial amount of work to fix autoppa [14:05] cprov, the bzr PPA itself has builds for all Ubuntu series [14:07] jelmer: yes, I know we do build for all series, my question was if you know that you need to or it was done just because it was easier. [14:08] cprov, I'm not sure, I know we do still get complaints if e.g. something breaks or is out of date for dapper [14:08] jelmer: it's not easier to answer (I'd not be able to do that myself) it requires inspecting the evolution of the build-depedencies. [14:08] jelmer: right, dapper is quite old compared to hardy [14:09] jelmer: maybe we would be good building for dapper and hardy only and copying binaries to intrepid & jaunty [14:10] jelmer: we could do the test in a separate PPA, I'm sure users would spot problems very quickly if they exist. [14:10] yeah, that would certainly help, but still means it's a nontrivial amount of work [14:11] Hello folks. Just to let you know, I think the bzr-bash-completion plugin on the site is rather broken. You may want to move it to the obsolete section [14:11] It doesn't work with the current format of the help output [14:12] It's pretty hideous anyway :) [14:12] jelmer: half of the non-trivial work if we don't need to rebuild for intrepid & jaunty. [14:12] jelmer: also consider that the debian source can be uploaded as it is to hardy. [14:13] jelmer: leaving the non-triavial work only for the dapper packages. [14:13] cprov: Doesn't the version string have to be fixed? [14:13] jelmer: no, if you are not rebuilding [14:14]