[00:00] <lamalex> mwhudson: does it look like an ok bug/patch though?
[00:00] <slangasek> jelmer: any luck?
[00:00] <jelmer> slangasek, Yeah, I've managed to reproduce it
[00:01] <jelmer> And I think I've got a clue as to why it's failing
[00:22] <slangasek> jelmer: so did I screw something up? :-)
[00:36] <lexrupy> hello all...
[00:36] <lexrupy> I read in some documentation that bzr serve "is" an in development feature.....
[00:36] <lexrupy> but those docs are outdated I mean.. about version 0.16
[00:37] <lexrupy> is this now fullfeatured and functional?
[00:37] <lexrupy> I am using 1.9 of course
[00:37] <spiv> Current docs are at http://doc.bazaar-vcs.org/latest/
[00:37] <lifeless> lexrupy: its not finished, but then software never is
[00:38] <spiv> bzr serve is certainly functional, and everything that works with direct file access should work via a bzr server.
[00:38] <lexrupy> yes I know, but I can use it in production as well?
[00:38] <spiv> It's still in development, but so is the rest of bzr ;)
[00:38] <spiv> Yes, it's ready for production use.
[00:39] <lexrupy> spiv: thank you, and, I already read the latest documentation... I use Bazaar since version ~ 0.90 I think
[00:40] <lexrupy> 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] <lexrupy> ok, I think you can help-me a little bit more
[00:42] <lifeless> lexrupy: launchpad hosts bzr using bzr-serve
[00:42] <lexrupy> in my tests I got bzr+ssh about 20% faster than sftp... these numbers are reliable or you have more precise numbers?
[00:42] <evarlast> we have been using serve in production at work for months.
[00:43] <spiv> lexrupy: it depends on a lot of variables, like the latency of your network connection.
[00:43] <lexrupy> spiv: ok, in my tests I use my laptop in a LAN environment with server
[00:43] <jelmer> slangasek, it seems it's similar to bug 295416
[00:44] <slangasek> hmm, ok
[00:44] <spiv> 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] <jelmer> 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] <lexrupy> spiv: humm
[00:44] <jelmer> slangasek, it shouldn't be too hard to fix, let me have a look
[00:44] <lexrupy> spiv: I tested checkout and branch commands
[00:46] <spiv> The optimisations so far have mostly focused on those and on push.
[00:46] <rockstar> lifeless, I didn't merge the branch, but it's good to have around.
[00:46] <lexrupy> 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] <spiv> 20% certainly sounds believable, but I can't give you a single number that will be universally true :)
[00:46] <lexrupy> ok
[00:48] <lifeless> rockstar: its in trunk
[00:48] <lifeless> rockstar: *someone* merged it
[00:49] <rockstar> lifeless, yea, I asked beuno to merge it.
[00:49] <rockstar> Was it not ready to be merged?
[00:49] <lifeless> it was
[00:50] <lifeless> it would be nice not to disable concurrent request processing
[00:50] <lifeless> but I need to know more about the paste contract to do that
[00:50] <lifeless> it would also be nice to record the url
[00:50] <lifeless> e.g. trunk_changes_foo_bar-1-stats.callgrind
[00:55] <rockstar> lifeless, yea, I also think that, now that I've been inspecting results.
[00:55] <rockstar> The number isn't so helpful.
[00:55] <lexrupy> I was thinking about how launchpad manage that groups of Developers to have access to a branch
[00:56] <lexrupy> But I cannot spot that... is each launchpad user a Unix User on server?
[00:57] <lifeless> lexrupy: no, they are not
[00:57] <rockstar> lexrupy, nope.
[00:57] <lifeless> rockstar: its a start; better than embedding callgrind data in a .jpg :)
[00:58] <lexrupy> huh, so How can I setup my server to behave like that?
[00:58] <rockstar> lifeless, :)
[00:58] <rockstar> lexrupy, behave how specifically?
[00:59] <lexrupy> I can for example create a branch on server belong my user.... bzr push sftp://myserver/~/mybranch
[00:59] <lexrupy> at this poiint mybranch will belong to my user on server...
[01:00] <lexrupy> and another user cannot push changesets there if I not..... forget
[01:00] <lexrupy> I have pointed that now
[01:00] <lexrupy> :)
[01:00] <lifeless> lexrupy: you need to use a replacement ssh server to do this; or use bzr+http and use apaches auth support
[01:00] <lexrupy> I put my ssh public key on server.... I have forgot that :)
[01:00] <lifeless> lexrupy: bzr works fine with groups; just have both users in the same group
[01:01] <lexrupy> I in fact can have a bzr user on server and create all repos in that account
[01:01] <lexrupy> then authenticate users via ssh public key
[01:02] <lexrupy> sorry, it was a "stupid" question
[01:02] <rockstar> lexrupy, I put my branches in /var/lib/bzr/<project>/<branch-name>
[01:02] <Peng_> lifeless: In bzr-search, did you mean to change group_size from 2500 to 50?
[01:02] <lifeless> Peng_: yes
[01:02] <Peng_> That lowers memory use, right?
[01:02] <rockstar> lexrupy, So I make the <project> folder owned by a group called developers, which I am a member of.
[01:03] <lifeless> Peng_: yes
[01:03] <Peng_> lifeless: Does it affect speed?
[01:03] <Peng_> (effect? bah)
[01:03] <lifeless> Peng_: somewhat
[01:03] <lexrupy> and you have an user for each develpper at yhour server?
[01:03] <Peng_> lifeless: How long is it supposed to take to index a copy of bzr.dev?
[01:03] <lifeless> Peng_: a few minutes
[01:04] <Peng_> lifeless: I've had it running for 20 minutes and it's barely halfway done. :)
[01:04] <lexrupy> 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] <lifeless> Peng_: hmm, roll back the push and try again; I'd like to know if it is faster for you
[01:05] <rockstar> lexrupy, yes, each developer on the system is a member of developers.
[01:05] <Peng_> You mean waste 20 minutes of work? Heh.
[01:06] <lifeless> Peng_: yes
[01:06] <lexrupy> 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] <Peng_> FWIW, the copy of bzr.dev is using btrees, and I ran it with -Dmemory, but that shouldn't have an impact.
[01:07] <lexrupy> 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] <lifeless> 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] <lifeless> bbs, lunch
[01:09] <Peng_> 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] <dryahetzeph> Is it possible to use bzrlib from a standalone bazaar installation on win32?
[01:11] <Peng_> lifeless: Now it's at 4/9. It's definitely much faster.
[01:15] <Peng_> Haha, woah, it's using 400 MB of RAM. I like group_size = 50 better. :P
[01:16] <Peng_> 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] <hydrapheetz> Hm, I wonder if I can just use the bzrlib module from the sources instead.
[01:18] <Peng_> hydrapheetz: Sure, you can. Some things will be a bit slower if you don't compile the extensions, but it'll work.
[01:18] <Peng_> (As long as it can find its dependencies.)
[01:19] <hydrapheetz> Ah
[01:20] <hydrapheetz> I tried doing that and importing it, I haven't tried anything else with it yet
[01:25] <lifeless> Peng_: ok, there are two possibilities
[01:25] <lifeless> Peng_: I bet its the type detection misfiring
[01:26] <lifeless> Peng_: put the patch back, then bump the batch size up, if you would
[01:26] <lifeless> Peng_: I bet its still slow
[01:28] <kumi> Is there any way to update a working tree after a remote client push? The remote client only has bzr+ssh:// access
[01:29] <Peng_> kumi: Does it have plain-old-ssh access?
[01:29] <Peng_> kumi: Well, anyway, the push-and-update plugin might work.
[01:29] <kumi> nope, just bzr
[01:29] <Peng_> lifeless: Will do
[01:29] <kumi> push-and-update require plain old ssh access
[01:29] <lifeless> Peng_: thanks - appreciate this
[01:30] <lifeless> kumi: bzr+ssh is layered on plain old ssh
[01:30] <kumi> yeah but the remote client is limited to the 'bzr' command
[01:30] <Peng_> push-and-update just runs "bzr update".
[01:31] <Peng_> So unless it's limited to "bzr serve", it should work.
[01:31] <Peng_> Anyway, try it out. It only takes 30 seconds.
[01:31] <kumi> It's using the bzr_access script, it won't work
[01:31] <Peng_> Oh.
[01:32] <Peng_> lifeless: It's running now. I'll get back to you in 7 minutes, I guess.
[01:32] <spiv> 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] <lifeless> Peng_: thanks
[01:32] <kumi> not many of the built-in hooks are server side, maybe pre_change_branch_tip
[01:32] <kumi> post*
[01:32] <Peng_> lifeless: Actually, it's already on step 2/9, so it seems to be going pretty fast.
[01:32] <kumi> I'll check that ouut
[01:32] <spiv> Or you could configure a cron job on the server to run "bzr update".
[01:32] <lifeless> Peng_: oh
[01:32] <kumi> spiv: yeah maybe that too
[01:33] <spiv> kumi: with new enough client and server (1.7?) post_change_branch_tip (or whatever it's called) will occur server side.
[01:33] <Peng_> lifeless: Yeah, it's definitely not going to take 20 minutes.
[01:33] <lifeless> Peng_: so tip with batch_group of 50 is slow, with 2500 is fast?
[01:33] <lifeless> Peng_: ok. I was hoping to reduce the massive memory spike mysql causes
[01:33] <kumi> spiv: I've got 1.9 on both ends
[01:33] <Peng_> lifeless: group_size, yes.
[01:33] <spiv> kumi: ok, that's definitely new enough :)
[01:34] <Peng_> Too bad. I was hoping to reduce memory usage too!
[01:34] <spiv> kumi: or tweak the bzr_access script to allow "bzr update"?
[01:40] <kumi> 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] <lifeless> kumi: why would you need a 2nd ssh key?
[01:42] <kumi> I think that's how it would have to work with authorized_keys
[01:43] <kumi> 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] <lifeless> kumi: ah, I see
[01:45] <lifeless> I thought it was more like sudoers
[01:45] <kumi> the authorized_keys command parameter only accepts one argument
[01:45] <Odd_Bloke> It wouldn't take much hacking to allow the script to optionally call 'bzr update' after the 'serve' was done.
[01:46] <lifeless> Odd_Bloke: it won't know what path to update
[01:46] <lifeless> a plugin is the best option
[01:47] <kumi> It might work if the branch directory is the same as the working tree directory
[04:04] <grettke> 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] <lifeless> grettke: its 1.9-rich-root
[04:05] <grettke> lifeless: Understood. Thanks.
[04:18] <Peng_> lifeless: BTW, do you have any use for the search indexes I created while timing it, or can I delete them?
[04:22] <lifeless> Peng_: unless you suspect a bug, no
[04:22] <lifeless> Peng_: but you could keep them, to use :P
[04:24] <Peng_> 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] <Peng_> That wouldn't help performance.
[04:28] <Peng_> 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] <lifeless> Peng_: autopacking is small; only 10% hit or so
[04:38] <abentley> spiv: around?
[04:40] <lifeless> Peng_: also search has a different autopack trigger than bzr
[04:40] <lifeless> Peng_: because of slightly different uses
[04:43] <spiv> abentley: yeah
[04:45] <abentley> spiv: So I tracked down a cause of stacked push over HPSS slowness: RemoteRepository.get_parent_map wasn't stacking.
[04:46] <spiv> abentley: ah!
[04:46] <abentley> spiv: Yeah, that caused it to try to push ~ the whole history.
[04:46] <spiv> So the walk_to_common_revisions would walk a *long* way...
[04:46] <spiv> Hmm.
[04:47] <abentley> spiv: I have a fix that does the stacking on the client side in RemoteRepository.
[04:47] <Hydrogen> walk five thousand miles...
[04:47] <spiv> You mean the server-side is doing the wrong thing, or the client?
[04:47] <abentley> 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] <abentley> So I figure this has to be done client-side, which is pretty in-tune with lifeless' choices.
[04:49] <abentley> i.e. that we don't want to require stacking on the server side.
[04:49] <abentley> spiv: I'm looking at RemoteRepository.get_parents, and I don't understand why it's implemented that way.
[04:50] <spiv> RemoteRepository.get_parent_map, you mean?
[04:50] <abentley> spiv: yes.
[04:50] <spiv> 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] <abentley> It's doing caching itself instead of using CachingParentsProvider.
[04:52] <spiv> I suppose it could, although it'd require a bit of mucking about to create a suitable object to construct it with.
[04:52] <abentley> Is there a reason for that?  Or a reason not to do it in _make_parents_provider?
[04:53] <spiv> If I implement a RemoteVersionedFiles class to handle the .revisions (and .texts/.inventories/.signatures) I could just pass that I guess.
[04:54] <abentley> spiv: Oh, it's because the caching is happening at a tuple level?
[04:55] <abentley> There's nothing about CachingParentsProvider that requires the keys to be strings.  Tuples should work just fine.
[04:55] <spiv> Short answer: no particular reason.
[04:56] <abentley> spiv: Okay, I'll hack on it tomorrow and there should be a patch on the ML when you wake up.
[04:56] <spiv> Although I don't think any other Repository uses CachingParentsProvider in its implementation of get_parent_map.
[04:57] <spiv> 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] <abentley> spiv: Nothing should be using get_parent_map directly.  They should be using get_graph, and other repos use it for that.
[04:58] <spiv> Hmm.
[04:58] <spiv> I don't think that's actually what's happening, even if that's what should be done.
[04:59] <spiv> There's places like Repository.has_revision and InterPackRepo.fetch that call it directly.
[05:00] <abentley> spiv: Doing it directly kills opportunities for optimization.
[05:00] <spiv> 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] <abentley> Because you get a really easy way to manage the lifetime of the cache.
[05:02] <lifeless> abentley: OTOH you have to manage the lifetime, or else differnet parts of bzrlib end up using different caches
[05:03] <spiv> get_graph() strikes me as a bit weird, basically because of what lifeless just said.
[05:04] <poolie> hello friends
[05:04] <abentley> lifeless: This is a memo, not a true cache, so we can't keep using it for the whole bzrlib lifetime.
[05:04] <abentley> poolie: hi.
[05:05] <lifeless> hi poolie
[05:05] <spiv> 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] <lifeless> abentley: because it will grow too big?
[05:05] <abentley> spiv: There are as many graphs as you create.
[05:05] <abentley> lifeless: yes.
[05:06] <lifeless> 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] <spiv> 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] <abentley> lifeless: I am talking about CachingParentsProvider, not the cache in RemoteRepository.
[05:06] <lifeless> abentley: oh right
[05:07] <abentley> spiv: No, and it's impossible, because get_graph takes a repo parameter.
[05:08] <spiv> There's other, related caching that happens in repository that is managed by lock lifetimes, i.e. index caching.
[05:10] <spiv> Hmm.  The other thing with RemoteRepository.get_graph is that it expects to receive more results than it asked for.
[05:10] <abentley> 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] <spiv> I suspect that returning those extra results, rather than just filling a cache with them, would break some callers in surprising ways.
[05:11] <spiv> It's too easy to assume that "if len(foo.get_parent_map(keys)) != len(keys): # something must be missing" will work.
[05:11] <abentley> get_graph just returns a Graph.
[05:12] <spiv> But if those extra results sent by the server aren't cached, then RemoteRepository is going to be unnecessarily slow.
[05:14] <spiv> 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] <spiv> 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] <abentley> spiv: So this means that RemoteRepository can't be its own parents provider.
[05:15] <abentley> And the original reason that repositories had get_parent_map was so that they could act as parents providers.
[05:16] <spiv> Or at least, "not yet, and changing that will need some careful thought."
[05:17] <lifeless> abentley: why can't it be its own parents provider?
[05:17] <spiv> Why do you say that?  I'm not sure what part of the contract it doesn't satisfy?
[05:17] <spiv> (Is there a written description somewhere?  A quick grep isn't finding one for me.)
[05:18] <abentley> 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] <spiv> 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] <lifeless> what spiv said
[05:19] <abentley> spiv: Calling get_parents_map would give infinite recursion.
[05:20] <spiv> Huh?
[05:20] <lifeless> abentley: cached provider -> rr -> cached provider (remote content only)
[05:20] <abentley> RemoteRepository.get_parents_map -> CachingParentsProvider.get_parents_map -> RemoteRepository.get_parents_map.
[05:21] <spiv> But there is no "RemoteRepository.get_parents_map -> CachingParentsProvider.get_parents_map".
[05:21] <lifeless> abentley: ah I see
[05:21] <lifeless> 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] <abentley> spiv: If we use CachingParentsProvider to implement RemoteRepository.get_parents_map, there will be.
[05:23] <spiv> abentley: sure.  But if we write "def f(): f()" there will be infinite recursion too, and we don't do that either ;)
[05:24] <spiv> I mean, obviously we can't make RemoteRepository.get_parent_map use a CachingParentsProvider(self).
[05:24] <spiv> But there are other ways to reuse that caching logic without doing that infinite recursion.
[05:24] <abentley> spiv: in other words, it can't be its own parents provider.
[05:25] <spiv> (refactor CachingParentsProvider slightly, or provide another object than self to CachingParentsProvider that will fetch the data)
[05:25] <abentley> The other object will be the parents provider.
[05:26] <spiv> Well, it is its own parents provider at the moment, as the implementation of RemoteRepository._make_parents_provider hopefully demonstrates :)
[05:27] <abentley> 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] <spiv> But RemoteRepository already is a parents provider, as I understand the term.
[05:28] <abentley> spiv: Yes, but it's one that doesn't stack.
[05:28] <spiv> It is an object that implements get_parents_map, what else is there?
[05:28] <abentley> And adding stacking would ideally be done using _StackingParentsProvider
[05:28] <abentley> But it's the same story as CachingParentsProvider.
[05:29] <lifeless> abentley: huh? lost me
[05:29] <lifeless> abentley: why can't you use SPP with a RR and its fallback repositories
[05:30] <abentley> lifeless: I thought we weren't supposed to do server-side stacking.
[05:30] <lifeless> abentley: on the client
[05:30] <abentley> lifeless: Misunderstood.
[05:30] <spiv> Why wouldn't _StackedParentsProvider([remote_repo, other_repo]) work?
[05:30] <abentley> lifeless: You can't do SSP with a RR and its fallback repositories, because that will give infinite recursion.
[05:31] <abentley> spiv: The StackedParentsProvider must be used in the implementation of RR.get_parent_map
[05:31] <spiv> 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] <spiv> Ok.
[05:32] <abentley> spiv: I'm talking about one where we have fixed this problem.
[05:32] <abentley> That stacking is broken.
[05:32] <spiv> Until the patch is published, it's hypothetical ;)
[05:32] <abentley> And ideally, killed the duplicate code.
[05:33] <abentley> spiv: Are you saying you don't want me to discuss how to fix this problem?
[05:33] <lifeless> 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] <spiv> So it seems to me that it's unnecessarily inconvenient to construct a FooParentsProvider from a callable.
[05:33] <abentley> lifeless: The common thread is a lack of use of existing ParentsProvider code.
[05:34] <spiv> 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] <abentley> spiv: It's an interface.
[05:34] <lifeless> 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] <spiv> Which seems more like a flaw in the *ParentsProvider(...) APIs than RemoteRepository.
[05:35] <spiv> That said, it's easy to construct a helper to adapt a callable to an object with that attribute.
[05:35] <spiv> Robert's suggestion sounds fine as well.
[05:38] <spiv> 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] <abentley> 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] <spiv> 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] <spiv> 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] <abentley> 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] <lifeless> 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] <spiv> 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] <spiv> lifeless: right
[05:43] <spiv> (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] <jml> hi
[05:47] <jml> igc:  hello :)
[05:47] <igc> hi jml
[05:47] <jml> lifeless, abentley: I have a loom problem.
[05:47] <jml> I just did combine-thread on the wrong thread
[05:47] <jml> how can I undo this?
[05:48] <lifeless> jml: is your loom recorded?
[05:48] <jml> lifeless: I probably hit record some time in the distant past
[05:48] <lifeless> jml: ok then thats not so easy
[05:49] <lifeless> jml: plan b, create-thread to recreate the thread you deleted
[05:49] <lifeless> and use pull -r to reinstate its top
[05:49] <spiv> 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] <lifeless> *tip*
[05:49] <spiv> Wow, lifeless's accent is now leaking on to IRC ;)
[05:50] <jml> spiv: heads doesn't find it.
[05:50] <lifeless> spiv: its not a head
[05:50] <lifeless> jml: log --show-ids on the thread above
[05:51] <jml> lifeless: it was the top thread.
[05:51] <lifeless> jml: if it was the top thread it will be a dead head
[05:51] <spiv> lifeless: oh right, he probably had it merged into the parent loom
[05:51] <spiv> s/loom/thread/
[05:51] <jml> ahh there we go.
[05:51] <spiv> s/parent/higher/
[05:54] <jml> thanks
[05:55] <jml> lifeless: incidentally, how would you feel about a loom patch that aliased up-thread to "up" and down-thread to "down"?
[05:57] <lifeless> jml: fine
[06:09] <spiv> abentley: did you have any thoughts on http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081114060525.GJ31377%40steerpike.home.puzzling.org%3E ?
[06:21] <spiv> abentley: did you have any thoughts on http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081114060525.GJ31377%40steerpike.home.puzzling.org%3E ?
[06:24] <gour> igc: hello. have you seen the latest activity in bug #232177 ?
[06:25] <gour> darcs-fast-export makes bzr's fast-import really slow in comparison with git's :-(
[06:27] <igc> hi gour
[06:27] <gour> igc: how are you?
[06:28] <igc> gour: so bzr-fast-import is working, just slow, is that it?
[06:28] <igc> gour: not too bad at the moment thanks
[06:28] <gour> igc: yes, i tried it with smaller repo, cause it took too long for e.g. darcs-unstable
[06:28] <gour> *repos
[06:29] <igc> gour: almost recovered from one lot of surgery with another lot coming later this week
[06:29] <gour> igc: i'd like that LP people add darcs import to LP
[06:29] <gour> igc: i'm glad you are doing fine. we pray that everything will be good
[06:29] <igc> gour: be sure to raise that then as a bug against LP
[06:29] <igc> gour: thanks
[06:30] <gour> 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] <gour> igc: is question enough or better to create a bug?
[06:31] <igc> gour: create a bug please
[06:32] <gour> igc: ok
[06:40] <gour> igc: done. bug #298933
[06:40] <igc> gour: thanks
[06:41] <gour> igc: do you take care about your diet?
[06:41] <igc> gour: very much so
[06:42] <gour> igc: good boy ;) that's VERY important...
[08:24] <army> 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] <army> is it a bzr-svn's bug?
[09:46] <asabil> hi all
[09:48] <asabil> is there a way to get bzr-git work over http ?
[09:50] <visik7> 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
[09:56] <Odd_Bloke> asabil: I suspect it involves writing the code to do that.  jelmer will know more.
[09:56] <asabil> oki thanks
[11:03] <hmeland> 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] <hmeland> 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] <asabil> visik7: I think you can also use bzr replay
[11:27] <vila> hi all
[11:40] <lifeless> hi vila, was your flight back pleasant?
[11:56] <tetha_> oh dear. someone pushed me into really crazy ideas -- extending literate programming to large software using event streams and dotfiles to chain things together
[13:00] <vila> 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] <vila> lifeless: be careful what you wish for... I should not have wish to stay longer in Australia :)
[13:03] <spiv> vila: heh
[13:03] <spiv> vila: bad weather at Brisbane?
[13:03] <vila> lifeless: so, pleasant... yes, but having only slept ~12h (cumulated) since last Friday ...
[13:03] <spiv> Ouch!
[13:03] <spiv> Go to bed :P
[13:04] <vila> 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] <spiv> That's pretty crummy.  I'm glad you eventually made it home!
[13:05] <vila> 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] <vila> 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] <vila> spiv: I hesitate to do the same :) I'd like to find back the right schedule :)
[13:24] <asabil> would it be possible to have the bzr-svn in the bzr PPA usable ?
[13:43] <jelmer> asabil, see bug 293009
[13:45] <asabil> jelmer: ok thanks, but what about a fix ?
[13:45] <asabil> it is just an
[13:46] <asabil> organization issue
[13:46] <jelmer> asabil, not sure, John is doing most of the PPA uploads
[13:46] <asabil> I guess it would make everyones life easier if the uploads were made in sync
[13:46] <jelmer> asabil: The releases of bzr and bzr-svn aren't made in sync
[13:47] <asabil> hmm ok
[13:48] <fullermd> It's all a sneaky underhanded method of tracking how many people the the PPA.
[13:51] <fullermd> WTF?  s/the/use/.  Who stole my typing fingers?
[13:51] <jelmer> Perhaps we should pull bzr-svn from the PPA unless somebody volunteers to maintain it
[13:51] <jelmer> s/unless/until/
[13:55] <asabil> is it that hard to maintain ?
[13:58] <jelmer> It means 4 uploads to the PPA
[13:58] <jelmer> *per package*
[13:59] <jelmer> I maintain ~10 bzr-related packages in Debian, so uploading to PPA as well would be quite some overhead
[14:02] <cprov> jelmer: have you tried auto-ppa (from jkakar) ?
[14:03] <jelmer> cprov, Yes, but it has several issues that would need to be fixed first
[14:03] <cprov> jelmer: uhm, are they *hard* ? maybe I could help you guys.
[14:04] <cprov> jelmer: also, are you absolutely sure you need rebuilds in all ubuntu series ?
[14:05] <jelmer> cprov, Yeah, it's a nontrivial amount of work to fix autoppa
[14:05] <jelmer> cprov, the bzr PPA itself has builds for all Ubuntu series
[14:07] <cprov> 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] <jelmer> 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] <cprov> 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] <cprov> jelmer: right, dapper is quite old compared to hardy
[14:09] <cprov> jelmer: maybe we would be good building for dapper and hardy only and copying binaries to intrepid & jaunty
[14:10] <cprov> jelmer: we could do the test in a separate PPA, I'm sure users would spot problems very quickly if they exist.
[14:10] <jelmer> yeah, that would certainly help, but still means it's a nontrivial amount of work
[14:11] <johncc> 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] <johncc> It doesn't work with the current format of the help output
[14:12] <johncc> It's pretty hideous anyway :)
[14:12] <cprov> jelmer: half of the non-trivial work if we don't need to rebuild for intrepid & jaunty.
[14:12] <cprov> jelmer: also consider that the debian source can be uploaded as it is to hardy.
[14:13] <cprov> jelmer: leaving the non-triavial work only for the dapper packages.
[14:13] <jelmer> cprov: Doesn't the version string have to be fixed?
[14:13] <cprov> jelmer: no, if you are not rebuilding
[14:14] <cprov> re-upload debian source to hardy, wait it to build, copy source and binary to intrepid & jaunty.
[14:14] <jelmer> cprov: Ah, ok - that's new?
[14:14] <jelmer> cprov, How does PPA know what series an upload is targetted?
[14:14] <cprov> jelmer: dput upload path
[14:15] <cprov> jelmer: the changelog will be target to 'unstable' but you would upload to ~jelmer/ubuntu/hardy/
[14:16] <cprov> jelmer: then oddness would be isolated in the dapper packages, which would probably need tweak in python-central/python-support, anyway.
[14:17] <jelmer> cprov: I think I'll leave dapper alone for now, uploading hardy and friends should already make a lot of people happy
[14:17] <jelmer> cprov, Thanks!
[14:18] <cprov> jelmer: great, ping me if you have problems, i'm more than happy to help you solving those issues with bzr-ppa.
[14:43] <jelmer> cprov-lunch, It seems if I upload a source package to hardy I can no longer upload it to intrepid?
[14:54] <james_w> jelmer: correct. you can copy it, but that requires copying the binaries as well.
[14:57] <jelmer> james_w: ah, ok - thanks
[15:00] <jelmer> seems like a silly restriction to me though...
[15:08] <james_w> jelmer: it's a requirement of the pool structure, which is vital for real archives. PPAs don't have to use that structure though.
[15:10] <jelmer> james_w, ah, makes sense
[15:10]  * jelmer isn't a big fan of web interfaces, would be nice to see that be a bit more flexible for PPAs
[15:11] <jelmer> james_w, while you're here... :-)
[15:11] <jelmer> james_w, any bzr-builddeb news ? :-P
[15:11] <james_w> have you looked at the launchpad API?
[15:11] <james_w> it's not there yet, but will satisfy all your needs eventually I expect
[15:11] <james_w> not yet, sorry. I should have the time to do all the merges this week.
[15:12] <jelmer> ah, cool
[15:13] <jelmer> james_w, It would be nice if ubuntu-dev-tools had a tool for that sort of thing, using the Launchpad API
[15:13] <james_w> I'm sure it will in time
[15:14]  * jelmer wonders how politically complicated it would be to upload ubuntu-dev-tools to Sid
[15:15] <james_w> hmm
[15:59] <derekS> hello all. i have a really n00b question. I am looking through this and _something_ doesn't look right. is it true that i don't need a true bazaar server, i can just use my sftp server?
[15:59] <derekS> it will only be me checking in and out...
[15:59] <derekS> so i don't care _that_ much about permissions
[16:00] <lamalex> derekS: that is true
[16:00] <derekS> lamalex: is there any downside to it?
[16:00] <lamalex> downside to what
[16:00] <derekS> to only using an sftp server?
[16:01] <lamalex> no..? I mean, there's no such thing as a "true bazaar server"
[16:01] <lamalex> that's the whole point of dvcs
[16:01] <lamalex> if more people are working on it, then having a centralized location can be handy, but it's not required
[16:02] <jdong> derekS: if there's a "downside" it's that it's not quite as fast for network operations.
[16:02] <lamalex> so the only downside to using sftp is it's a little bit slow iirc
[16:02] <jdong> but that's a really minor downside compared to the convenience
[16:02] <jdong> bzr is really one of the last VCSes that support serverless operation well
[16:02] <jdong> and that's one of the things that makes it my favorite VCS
[16:03] <derekS> lamalex, jdong: sweet!
[16:04] <derekS> now, i guess kinda important, i use windows for home, linux for work, how well is windows support? i have the cygwin version, is there a gui type client
[16:06] <lamalex> http://bazaar-vcs.org/WindowsDownloads
[16:09] <thrope> are you supposed to be able to add files with tortoisebzr? I only have a very few options on existing files (diff) - no option to add a new file
[16:11] <derekS> lamalex: thanks!
[16:15] <derekS> lamalex: 2 last questions... i use tortoisesvn, how does tortoisebzr compare? is it as stable? Also, is there an easy svn to bzr conversion?
[16:19] <lamalex> derekS: you can use bzr to talk to svn via the bzr-svn tool, I also think you can convert svn to bzr easily, but im not sure
[16:20] <lamalex> i have no idea how tortoisebzr is, I don't use windows
[16:20] <jelmer> derekS, you should be able to convert from svn to bzr with bzr-svn's "bzr svn-import" command
[16:20] <derekS> lamalex: thanks :)
[16:20] <derekS> jelmer: i assume i have to install a plugin?
[16:20] <jelmer> derekS, yes, the bzr-svn plugin
[16:21] <jelmer> it's included with the bzr setup on windows
[16:27] <thrope> derekS: I haven't had much luck with tortoisebzr
[16:27] <thrope> I was hoping to use it to collaborate with some windows users, but I don't think it is in a usable state
[16:28] <thrope> it looks very promising - not trying to be negative - just saying its not there yet
[16:30] <Sidnei> hello there, i remember seeing a tutorial about how to keep your main branch in bzr and mirror it to subversion, but google can't find it, anyone remembers where that is?
[16:36] <derekS> thrope: i might try it out, i will let you know :)
[16:41] <jelmer> Sidnei, It should be very simple - just "bzr push <svn-location>"
[16:42] <Sidnei> jelmer: i get "bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
[16:42] <Sidnei> '
[16:42] <jelmer> Sidnei: You can't push to the repository root, only to /trunk
[16:42] <jelmer> Sidnei: For the first push, use 'svn-push'
[16:42] <jelmer> bzr svn-push, that is
[16:42]  * Sidnei tries
[17:01] <Sidnei> jelmer: great, i re-did it and it worked this time. i think i had messed up some command before.
[17:02] <jelmer> cool
[17:03] <Sidnei> fwiw, what i did: bzr branch <svn>; bzr merge <bzr-main-branch>; resolve conflicts; bzr svn-push <svn>
[17:05] <Sidnei> may or may not be the right way, but achieved what i wanted to do :)
[17:55] <rockstar> beuno, now it's leaking about 4 mb/request
[17:55] <bkuhn> Is it ok to show up and ask newbie questions here?
[17:55] <beuno> rockstar, so caching isn't to blame?
[17:55] <beuno> bkuhn, it absolutely is!
[17:55] <beuno> we love easy questions
[17:56] <rockstar> beuno, this is a vanilla checkout.  No changes at all, except my implementation of the MemoryMiddleware
[17:56]  * Sidnei doesn't want to know what's leaking 4mb/request 
[17:56] <bkuhn> I am trying to set up a bzr instance that many developers can push and pull from.  I have it working so that zr branch bzr+ssh://user@HOST/PROJECT works.
[17:56] <rockstar> Sidnei, loggerhead
[17:56] <bkuhn> but I cannot get it to push
[17:56] <bkuhn> It says: "Transport operation not possible: readonly transport"
[17:56] <rockstar> bkuhn, do you have write permissions in the folder?
[17:56] <bkuhn> I find conflicting information online about whether or not bzr+ssh can be used for pushing.... it seems like it can.
[17:56] <bkuhn> yes.
[17:57] <rockstar> bkuhn, it can be used for push, yes.
[17:57] <bkuhn> I'm using a single uid currently.
[17:57] <bkuhn> BTW, it's bzr 1.3.1-1ubuntu0.1
[17:57] <bkuhn> (on both client and server)
[17:57] <beuno> rockstar, it went from 100kb to 4mb?
[17:57] <kumi> that's a pretty old version
[17:57] <beuno> bkuhn, that should work
[17:57] <bkuhn> kumi: it's what's in hardy. :)
[17:57] <beuno> bzr+ssh isn't a readonly transport
[17:58] <beuno> unless the user can't write
[17:58] <bkuhn>  ah, this may be pertinent:  Cannot lock LockDir(chroot-140973836:///PROJECT/.bzr/branch/lock)
[17:58] <bkuhn> the appropriate UID has write on that dir though
[17:58] <beuno> bkuhn, right, so it can't write
[17:58] <bkuhn> (in fact, it's the owner)
[17:58] <rockstar> beuno, well, I think the 400k was the kernel doing some clever things to change reporting, but the RSS increases 4 megs every request.
[17:58] <beuno> bkuhn, can you ssh into it and try to write that exact same fil?
[17:58] <rockstar> beuno, it'd be nicer if I could read directly form /proc/<pid>/mem
[17:59] <bkuhn> beuno: I don't want the user to be able to get a shell generally, so I was having it call the bzr command directly with command=.  I should have mentioned that.
[17:59] <bkuhn> I will try it without the command=
[17:59] <kumi> are you using bzr_access?
[18:00] <bkuhn> kumi: not yet, but I want to.  Is there a package that builds easily for hardy for it?
[18:00] <kumi> bzr_access is just a python script
[18:01] <bkuhn> kumi: URL?  (net.search doesn't seem to give a canonical place in the first few hits...)
[18:01] <Sidnei> rockstar: if you are using some sort of caching there, making sure your cache key is computed correctly would be my guess. i've been bitten before by computing a cache key that would change for every request.
[18:02] <bkuhn> beuno: ok, so I turned off command= ... if I log in, these commands work fine:
[18:02] <bkuhn> touch /path/to/project/.bzr/branch/lock/test
[18:02] <kumi> I'm just using bzr_access from the bzr.dev branch. In the contrib/ folder
[18:02] <bkuhn>  
[18:02] <bkuhn> rm /path/to/project/.bzr/branch/lock/test
[18:02] <bkuhn> kumi: thanks
[18:03] <beuno> bkuhn, maybe it's trying to write to the wrong paths?
[18:03] <kumi> bkuhn: maybe try "bzr break-lock"
[18:03] <jelmer> bkuhn: The path in the URL is interpreted relative to the fs root
[18:03] <rockstar> Sidnei, I don't think it's a cache issue now.  I see the kernel doing its best to clean up memory, so, while the number is generally climbing, it drops now and then.
[18:03] <bkuhn> jelmer: yeah, I tried to fix that by using bzr serve --directory /path/to in the command= in authorized_keys
[18:03] <rockstar> There's a leak somewhere.
[18:04] <visik7> anyone who know how to use rebase ?
[18:04] <bkuhn> I wish there were a tutorial somewhere about setting up one's own server.
[18:04] <rockstar> Usually, the kernel cleans it up after a jump of 32Mb in one request.
[18:05] <jelmer> bkuhn, I suspect that bit just works if you make it run on a specific TCP/IP port
[18:05] <Sidnei> rockstar: maybe you have some sort of cycle that is preventing objects from being garbage collected? that's common with in-memory caching too.
[18:05] <bkuhn> jelmer: how does it do auth in that case?
[18:06] <jelmer> bkuhn, It doesn't, that's usually just used for readonly access
[18:06] <jelmer> bkuhn: Are you specifying --allow-writes ?
[18:06] <jelmer> bkuhn, that may actually be it
[18:08] <bkuhn> jelmer: yeah, it seems to work, now, actually, but I still get this error: his transport does not update the working tree of: bzr+ssh://USER@HOST/PROJECT/. See 'bzr help working-trees' for more information.
[18:08] <lamalex> bkuhn: because you're pushing to a working tree vs. a repo
[18:08] <beuno> bkuhn, that is correct
[18:08] <kumi> I don't think that's an error
[18:09] <beuno> remote trees don't get updated
[18:09] <beuno> remote _working_ trees that is
[18:09] <bkuhn> lamalex: ah, how do I make it a repo on the server?  I just bzr init...
[18:09] <beuno> bkuhn, just pushing it
[18:09] <beuno> it won't create a working tree
[18:09] <beuno> create it locally, and push it
[18:09] <lamalex> indeed
[18:09] <lamalex> bzr rules :)
[18:10] <bkuhn> beuno: so you are saying, do a bzr init on the client side, then push it?
[18:10] <jelmer> bkuhn, or on the server, run "bzr remove-tree" toi remove the working tree
[18:11] <derekS> hi guys, another question, is it possible to branch subfolders/files, but not a whole checkout?
[18:11] <jelmer> derekS, not yet
[18:11] <Sidnei> is there any kind of caching on the client-side of bzr? i moved a branch around in my remote server to the location of another branch i just deleted and now trying to branch on my local machine I get 'ERROR: no such file' for one of the files
[18:12] <derekS> jelmer: hmm ok, is that coming in the near future?
[18:12] <kumi> Sidnei: bzr info -v will show you the cached locations
[18:13] <bkuhn> jelmer: thanks, remove-tree worked great!
[18:13] <jelmer> derekS, it is planned, not sure how soon though
[18:13] <derekS> jelmer: thanks!
[18:15] <visik7> hmeland: hi I'm still digging with rebase
[18:16] <kumi> Hm... BzrLog is a cute little app
[18:16] <visik7> hmeland: I've followed your advice:"bzr branch -r 3 big-branch new-branch; cd big-branch; bzr rebase -r 5..7 ../new-branch; bzr rebase -r 9.. ../new-branch"
[18:17] <visik7> hmeland: but on the last command I get bzr: ERROR: Requested revision: u'12' does not exist in branch: BzrBranch6('file:///home/visi/Desktop/big-branch/')
[18:17] <visik7> hmeland: don't worry I've backups but I can't get forward
[18:24] <bkuhn> Thanks everyone, I have things working now well with bzr+ssh:// using bzr_access.  Now, to figure out how to give anonymous http:// access w/ apache.  If anyone has a tutorial URL handy, I would appreciate it. :)
[18:24] <beuno> bkuhn, use loggerhead
[18:24] <beuno> launchpad.net/loggerhead
[18:25] <jelmer> bkuhn, If you mean anonymous access to clone the bzr branch, just make sure the branch is accessible over http somehow, no special configuration required
[18:25] <beuno> ah, right
[18:25] <bkuhn> jelmer: yes, perfect!
[18:25] <beuno> that's probably what he meant  :)
[18:26] <bkuhn> beuno: loggerhead looks interesting, but I'm already working with Trac and am used to it.  I've been looking at the Trac Bzr plugin.
[18:45] <bkuhn> Thanks again for all your help.  You got me up and running: http://code.softwarefreedom.org/projects/podjango/wiki/WikiStart
[18:45] <bkuhn> later
[18:50] <Sidnei> not good. i think i messed up my repo :(
[18:50] <Sidnei> is there a way to clean up all bzr:xxx properties from an svn repo and start fresh?
[19:16] <rockstar> beuno, do you find that much of loggerhead is overly complicated?
[19:17] <beuno> rockstar, sometimes, but I guess I don't get as lost now
[19:17] <beuno> I really had a hard time at first
[19:17] <beuno> it's not so much complicated as it is a bit spread around
[20:28] <visik7> hmeland: if you would help me I'm here :)
[20:31] <lifeless> jelmer: ping
[20:31] <jelmer> lifeless, pong
[20:31] <lifeless> I'm making changes to commit again
[20:31] <lifeless> I'd like to know what will work better and worse for you, from my options
[20:32] <lifeless> Sidnei: I don't know, jelmer may know.
[20:32] <lifeless> jelmer: so, the change I'm starting is to stop touching all paths
[20:32] <lifeless> jelmer: and instead have an entirely delta orientated interface
[20:33] <jelmer> Sidnei: the bzr: properties are used by bzr-svn
[20:33] <jelmer> lifeless: Cool
[20:33] <lifeless> jelmer: internally, xml inventory commit builders will need to touch all paths
[20:33] <jelmer> lifeless,  if the interface is designed properly, bzr-svn won't have to
[20:33] <lifeless> jelmer: I don't know what bzr-svn will need to do
[20:34] <lifeless> jelmer: the reason xml ones have to, is to set last-changed fields during merges.
[20:34] <jelmer> so that could be a nice performance improvement for large trees
[20:35] <lifeless> conceptually they don't actually touch every path, rather its delta(p1, p2) and delta(p1,p3) etc, and then for every different path do a ancestry check
[20:36] <lifeless> jelmer: would getting an iterator in the builder be better for you than having the builder called once for every altered path ?
[20:37] <jelmer> lifeless: What exactly do you mean by having an iterator in the builder?
[20:38] <jelmer> providing an iterator with the changes to the builder?
[20:38] <jelmer> It's easiest for me if I can discover the changed paths
[20:41] <lifeless> jelmer: builder.here_is_a_delta(tree.last_revision(), tree.iter_changes(tree.basis_tree())
[20:41] <lifeless> vs
[20:42] <lifeless> for change in tree.iter_changes(tree.basis_tree()): builder.changed_path(change)
[20:43] <jelmer> the first would be preferred
[20:43] <jelmer> since the order in which I have to report changes to SVN is somewhat strict
[20:44] <lifeless> so you'll have to buffer either way I guess
[20:44] <lifeless> as iter_changes can jump around
[20:56] <mwhudson> lifeless: so what did you want to say about paste?
[20:56] <lifeless> mwhudson: s/say/know/
[20:56] <mwhudson> 'talk about'
[20:56] <lifeless> mwhudson: lsprof seems to be working fine on single requests
[20:57] <lifeless> but we miss the top of the stack because we profile a bit of middleware; and we have to exhaust the generate from the app below us
[20:57] <lifeless> if we take a single thread lock and define close, it seems to me that we could let the generator be
[20:58] <lifeless> but what would the framework do
[20:58] <lifeless> would it try to reenter a new request in the same thread
[20:58] <lifeless> etc
[20:58] <lifeless> etc
[20:58] <mwhudson> paste's httpserver is a one-thread per request with a threadpool thingy
[20:59] <jelmer> lifeless, if "delta" is not the full delta at once, I'll indeed have to buffer either way
[21:00] <mwhudson> lifeless: so i guess you'd mess up the ability to be processing more than one request at once, but hey, cpu bound anyway
[21:01] <lifeless> jelmer: iter_changes(selected=foo) will give you foo, but then jump to bar, or in corner cases even jump to to the root
[21:02] <lifeless> jelmer: it is the full delta at once, but its an iterator not a list
[21:02] <lifeless> mwhudson: the debug middleware uses a lock
[21:02] <jelmer> lifeless: right, so that means buffering
[21:02] <lifeless> mwhudson: so its single threaded
[21:05] <mwhudson> lifeless: i guess another fun thing is that loggerhead doesn't return a generator anyway, it calls the 'write' function returned from start_response
[21:06] <lifeless> mwhudson: uggle. Ok, I'll leave it as-is.
[21:16] <Sidnei> lifeless: it was a small repo, just stomped-fixed it: svn export; svn rm; svn import
[21:35] <jelmer> Sidnei, if the properties are a problem, use "bzr dpush" to import the changes
[21:42] <derekS> does anyone have bzr installed throuhg cygwin
[21:43] <Sidnei> jelmer: don't quite get what that means. the problem was that i had some ghosts and missing parents due to trying different things, so i could checkout or branch from the svn repo but trying to branch from that branch would complain about missing files or revisions
[21:44] <jelmer> Sidnei, Was this with bzr-svn >= 0.4.15 ?
[21:45] <Sidnei> jelmer: latest from ppa, so i guess yes
[21:45] <jelmer> Sidnei, latest from PPA from a couple of hours ago?
[21:45] <jelmer> otherwise it's a much older version
[21:46] <Sidnei> jelmer: about 6 hours ago i think
[21:46] <Sidnei> svn 0.4.15dev0
[21:46] <Sidnei>     Support for Subversion branches
[21:46] <jelmer> Sidnei, Can you be a bit more specific wrt to  the errors you were getting? What errors after which commands, etc?
[21:47] <Sidnei> jelmer: let me see if i can get it back into failing, hold on
[21:47] <markh> Sidnei: hi! :)
[21:47] <Sidnei> hey markh !!
[21:57] <lifeless> derekS: I think that that is a 'no'
[21:57] <derekS> lifeless: i take it you are right :)
[21:58] <Sidnei> jelmer: will you be around in 30?
[21:59] <jelmer> Sidnei, not in 30, but probably in about an hour from now
[21:59] <Sidnei> jelmer: ok. i will try to get some more info for you
[22:00] <jelmer> Sidnei, cool, thanks
[22:01] <derekS> lifeless: when i try to do a push to my sftp server i get: bzr: ERROR: exceptions.IOError: [Errno 0] Error
[22:02] <lifeless> derekS: interesting; please file a bug, you can get a backtrace from the end of ~/.bzr.log
[22:02] <derekS> lifeless: let me look around a little more :) then i can file a bug AND fix it
[22:04] <lifeless> ok
[22:04] <derekS> lifeless: i am wondering if it is the format of my sftp statement. I have bzr push "sftp://[user]@[domain]/[directory]"
[22:04] <derekS> that _should_ work
[22:04] <lifeless> derekS: that looks fine
[22:04] <derekS> should the directory be relative?
[22:04] <derekS> because it is relative to my home
[22:04] <lifeless> yes, thats fine
[22:05] <lifeless> erm no
[22:05] <lifeless> /~/ is relative to home
[22:05] <derekS> same error with that :)
[22:09] <thrope_> does anywhere other than launchpad offer bazaar hosting?
[22:10] <LarstiQ> thrope_: anything where you can upload files in principal
[22:10] <thrope_> LarstiQ: I mean with a nice interface for diffs etc. as well
[22:11] <thrope_> LarstiQ: anything like these nice services, github, bitbucket etc (other than launchpad)
[22:12] <LarstiQ> thrope_: I'd assume so, but I don't know.
[22:12] <LarstiQ> maybe I should start one if they don't exist, hmm
[22:12]  * LarstiQ goes to bed now though
[22:22] <lifeless> savannah has bzr support
[22:22] <lifeless> though they seem, odd, about actually embracing loggerhead etc
[22:25] <mwhudson> spiv: something has gone wrong here, right? http://pastebin.ubuntu.com/73525/
[22:25] <visik7> anybody knows how to remove a file inside the bzr repo ?
[22:26] <visik7> a plugin ? I'm not able to do it using rebase ( probably I dunno how to use it)
[22:27] <dobey> bzr delete file?
[22:27] <spiv> mwhudson: sure looks like it
[22:27] <spiv> mwhudson: please file a bug
[22:27] <visik7> dobey: no I mean from the repository
[22:27] <mwhudson> spiv: any chance of a fix today?
[22:28] <mwhudson> (this is blocking 1.9 getting into the next release of lp :()
[22:29] <spiv> mwhudson: It's probably easy to fix, although that said the code looks correct at a glance...
[22:29] <mwhudson> hm, i think launchpad is probably constructing permissiondenieds a bit strangely
[22:29] <spiv> mwhudson: ah, hmm
[22:30] <spiv> mwhudson: the code expects ('PermissionDenied', 'path', 'extra info in English') on the wire
[22:30] <mwhudson> also...
[22:30] <mwhudson> mwh@grond:a$ bzr -Dhpss push bzr+ssh://localhost/hope
[22:30] <mwhudson> bzr: ERROR: Permission denied: "None": : [Errno 13] Permission denied: '/hope'
[22:30] <spiv> You seem to be sending the last two parts reversed.
[22:30] <spiv> Right.
[22:30] <mwhudson> that isn't striking in it's beauty
[22:32] <spiv> The serialisation and deserialisation in 1.9 seem to agree that the order should be ('PermissionDenied', path, extra).
[22:32]  * mwhudson tries some things
[22:33] <spiv> Are you sure you're constructing your PermissionDenied exception correctly?
[22:33] <mwhudson> no
[22:33] <visik7> jelmer: where is your bzr-remove-revisons plugin ? I can't find it on your samba.org
[22:34] <jelmer> visik7, http://people.samba.org/bzr/jelmer/bzr-remove-revisions/trunk/
[22:35] <spiv> mwhudson: I'm pretty sure the code in bzr is correct, so at this point I think the confusion is in your code.
[22:35] <mwhudson> spiv: the Permission denied: "None" think is odd though
[22:35] <mwhudson> (and that doesn't require launchpad to be involved)
[22:37] <visik7> jelmer: is empty
[22:37] <visik7> jelmer: and branching from it return an error
[22:37] <jelmer> visik7, it's a bzr branch
[22:37] <visik7> oh
[22:37] <jelmer> visik7, works fine here
[22:37] <visik7> in another branch there was the log so I thought that was the same for this
[22:38] <visik7> jelmer: does remove-revision clean up my .bzr ?
[22:38] <jelmer> visik7, no, it allows you to remove explicitly mentioned revisions from your repository
[22:39] <visik7> yes, I mean: I've a huge file erroneously committed
[22:39] <spiv> mwhudson: hmm, that is odd.
[22:39] <jelmer> visik7: You don't want to use it on a revision that's still part of branch history, since bzr's ghost handling has some issues atm
[22:40] <mwhudson> spiv: where is the deserialization code?
[22:40] <jam> spiv, lifeless, poolie: Sorry I missed the standup. Today was mostly about catching back up with mail, etc after getting back home.
[22:40] <visik7> jelmer: :(
[22:40] <spiv> mwhudson: bzrlib/remote.py
[22:40] <spiv> mwhudson: apparently a "if len(err.error_args) >= 2" needs to be "... >= 1".
[22:41]  * spiv goes off to find the gap in the multiple unit tests that already exist for this code path
[22:41] <mwhudson> spiv: well, no?
[22:41] <mwhudson> depending on what get_path() does
[22:43] <spiv> mwhudson: get_path is an independent issue to the optional extra info.
[22:43] <visik7> jelmer: could you suggest me a way to remove a huge commit of files introduced at revno x and removed at revision x+7 ? the whole commit includes only the files I want to remove the are no changes at other files
[22:43] <spiv> mwhudson: the server may return just a ('PermissionDenied', path), or a ('PermissionDenied', path, extra).
[22:43] <jelmer> visik7: Simply uncommit those revisions?
[22:44] <visik7> jelmer: but I'm at revizion x+84
[22:44] <visik7> revision
[22:44] <Sidnei> jelmer: sent via email
[22:44] <mwhudson> spiv: it seems that context in _translate_error is {'path': None}
[22:44] <spiv> mwhudson: and the client deserialiser might ignore the path if it already knows it from the context passed to _translate_error (which should be most of the time now, except when PermissionDenied happens very unexpectedly)
[22:45] <mwhudson> spiv: which doesn't seem rightr
[22:46] <spiv> Ah, so it is.  That seems to be a bug in RemoteTransport
[22:46] <jelmer> Sidnei, thanks
[22:46] <visik7> jelmer: and if I run bzr uncommit -r x it will uncommit from now to x-1
[22:46] <spiv> RemoteTransport didn't exactly handle PermissionDenied gracefully before 1.9 either...
[22:47] <mwhudson> spiv: yes, that's what i'm finding
[22:48] <mwhudson> mkdir calls _call2 calls _translate_error without passing on relpath
[22:48] <jelmer> visik7, you can use rebase or replay to replay all revisions except for the problematic ones
[22:48] <mwhudson> spiv: anyway, clearly a client problem, SEP field activated :)
[22:49] <mwhudson> spiv: want me to file a bug though?
[22:49] <spiv> mwhudson: please do, but your server is still sending crack
[22:49] <mwhudson> spiv: not in my local copy it's not :)
[22:50] <visik7> jelmer: I'd try but I don't understand how I've tried to run this sets of commands suggested by hmeland " bzr branch -r 3 big-branch new-branch; cd big-branch; bzr rebase -r 5..7 ../new-branch; bzr rebase -r 9.. ../new-branch"
[22:51] <jelmer> visik7, I would suggest something like:
[22:51] <jelmer> bzr branch -r3 big-branch new-branchj
[22:51] <visik7> jelmer: but on the last command I get the error saing that big-bransh has no revno 9
[22:51] <jelmer> cd new-branch && bzr replay -r9.. ../big-branch
[22:53] <mwhudson> spiv: https://bugs.edge.launchpad.net/bzr/+bug/299254
[22:54] <spiv> mwhudson: thanks
[22:56]  * spiv heads off to the dentist
[22:59] <visik7> jelmer: how could be possible that there's a confilt on a file that isn't touched in the 2 commits ?
[23:00] <jelmer> visik7, hard to say without looking at the specifics
[23:01] <visik7> mmm
[23:02] <jelmer> visik7: you'd want different revisions than in my example though if you want to exlucde just two commits
[23:02] <visik7> sure
[23:02] <jfroy|work> jelmer: I was hoping a clean checkout (with clean caches) of a svn branch I could not branch from would fix the problem, but unfortunately not. I still get a missing revision exception.
[23:03] <jfroy|work> bzr: ERROR: Revision {<user email>-20081015184449-6l6y2bc2tjkl22dg} not present in "6604@be02940b-5f7b-422b-ba6c-1eb93f4884eb:<path>".
[23:03] <jelmer> jfroy|work, also in a new repository ?
[23:03] <jfroy|work> This occurs when I try to push the branch into a different repository, or when I try to use qbrowse from bzr-qt
[23:03] <jfroy|work> jelmer: yes, brand new everything, pretty much
[23:03] <jelmer> jfroy|work, and directly branched from svn ?
[23:03] <jfroy|work> correct
[23:04] <jelmer> jfroy|work, what's the full backtrace?
[23:07]  * jfroy|work pasted http://pastie.textmate.org/317310
[23:08] <jelmer> jfroy|work, was that particular revision perhaps pushed with a bzr-svn prior to 0.4.15 ?
[23:09] <jfroy|work> Possibly
[23:09]  * Sidnei detects a possible pattern :)
[23:10] <visik7> jelmer: but should I reply also revisions from after the introduction of big files until removed and then after the commit where I remove them ?
[23:11] <jelmer> jfroy|work, does the branch path perhaps have bzr:text-parents set but not bzr:test-revisions ?
[23:11] <jfroy|work> No idea what those are -- I wouldn't have set those manually, in any case.
[23:12] <jelmer> jfroy|work, they should be file properties set by bzr-svn on the branch root
[23:12] <jelmer> visik7, yes
[23:13] <jfroy|work> jelmer: interesting, flushed the svn-cache directory, subversion.conf file, and made a new checkout without a repository.
[23:13] <jfroy|work> e.g. a standalone branch
[23:13] <Sidnei> jelmer: that seems to be the case on my repo
[23:13] <jfroy|work> Trying to push that also failed, but the bad revision is different
[23:14] <jelmer> Sidnei, and that particular revision was pushed with pre-0.4.15 bzr-svn ?
[23:14] <jfroy|work> Actually no, I take that back.
[23:14] <jfroy|work> The revision number (the number before the @) is the same, and so is the UUID (or is it a checksum?)
[23:15] <jfroy|work> The <path> component of it is different however
[23:15] <Sidnei> jelmer: 0.4.15dev0 afaict
[23:15] <jfroy|work> But the left-hand side is different
[23:16] <jfroy|work> It says {svn-v4:be02940b-5f7b-422b-ba6c-1eb93f4884eb:<path>:7882} instead of {<email>-20081015184449-6l6y2bc2tjkl22dg}
[23:18] <jelmer> Sidnei, ah, "bzr diff" broke for you?
[23:18] <jelmer> jfroy|work, It looks like you're using bzr-svn trunk again
[23:18] <jfroy|work> jelmer: bzr:text-revisions is set to an empty string
[23:18] <visik7> I can't get rid of those commits
[23:18] <jfroy|work> jelmer: I am not, using 0.4
[23:18] <visik7> I'm going mad
[23:18] <jelmer> jfroy|work, only trunk will write svn-v4:.. style commits
[23:19] <jfroy|work> That may have been in the past
[23:19] <jfroy|work> I did make a few pushes / commits with bzr-svn trunk a month ago or so
[23:19] <igc> morning all
[23:20] <Sidnei> jelmer: bzr branch from a bzr branch broke for me
[23:20] <jelmer> Hey Ian :-)
[23:21] <jelmer> jfroy|work: That's most likely the cause of this :-(
[23:21] <jfroy|work> jelmer: best option would be to wipe all bzr:* properties from the repository
[23:21] <jfroy|work> *would probably be to
[23:22] <jelmer> jfroy|work, Yeah
[23:22] <jfroy|work> But yes, also bzr:text-parents is set, while bzr:text-revisions is empty (but present)
[23:23] <Sidnei> jelmer: i *might* have checked in with 0.4.14 on that revision
[23:23] <Sidnei> jelmer: but im mostly confident it was 0.4.15dev0
[23:24] <jelmer> Sidnei, The issue with "bzr diff" is a known bug in bzr
[23:24] <jelmer> Sidnei, does that particular revision have bzr:text-parents set but not bzr:text-revisions?
[23:24] <Sidnei> jelmer: yes
[23:24] <Sidnei> http://paste.plone.org/24999
[23:26] <rockstar> abentley, is there a test class in the bzrlib test suite that will give me a branch with more than a few revisions?
[23:27] <jelmer> Sidnei, so bzr:text-revisions is set but empty?
[23:27] <Sidnei> jelmer: yup
[23:28] <visik7> jelmer: no way .bzr becomes huge despite reply
[23:28] <visik7> replay
[23:28] <Sidnei> was about to say that
[23:28] <jfroy|work> jelmer: I'm seeing that too
[23:28] <jelmer> visik7: After you've run this, you need to clone the branch to get rid of any unreferenced revisions
[23:28] <jfroy|work> If that's of any help :p
[23:28] <visik7> jelmer: oh
[23:29] <jelmer> jfroy|work, Sidnei: Thanks
[23:29] <visik7> anyway I can't understand why I get the conflict
[23:30] <jelmer> visik7, it's hard to say anything about it without looking at specifics
[23:31] <jelmer> jfroy|work, Sidnei: does either of you perhaps have an easy way to reproduce this problem?
[23:31] <visik7> jelmer: how could I do ?
[23:31] <jfroy|work> jelmer: I don't even know what the problem is :p
[23:31] <visik7> jelmer: how could I show you the repo ?
[23:31] <Sidnei> jelmer: not easy no
[23:34] <visik7> jelmer: I even can't give you a branch becouse of the size of the repo
[23:38] <jelmer> visik7, well, what sort of file is ending up in a conflict? When is it changed, etc?
[23:39] <visik7> jelmer: it exists from revision 1 and wasn't change until the conflict
[23:40] <jelmer> Sidnei, this particular file (models.py), what happened to it during that particular revision? was it changed in some way, merged from another location?
[23:41] <Sidnei> jelmer: i believe i did a reverse merge to revert it to a previous revision
[23:45] <visik7> jelmer: and the conflict edit the source like that : http://dpaste.com/91601/
[23:46] <visik7> jelmer: and the diff of the revision that produce the confilct is: http://dpaste.com/91602/
[23:47] <jelmer> visik7, and the revisions you're skipping don't touch *any* of the other files in any way ?
[23:48] <jelmer> (bzr log -v on those revisions shows *only* those files?)
[23:49] <visik7> jelmer: let me check for the 4th time :)
[23:49] <visik7> I was using diff , log -v is much better
[23:49] <visik7> yes there is a modification
[23:49] <visik7> any way to import it ?
[23:50] <jelmer> visik7, only manually
[23:50] <visik7> :\
[23:50] <visik7> so
[23:51] <jelmer> (this particular modification, that is)
[23:51] <jelmer> after you've applied that modification manually on top of r3, you should be able to replay the rest
[23:51] <visik7> so I make a commit before the reply from X+1 Y-1 ?
[23:51] <jelmer> yes
[23:51] <visik7> ok
[23:52] <visik7> I try
[23:54] <jelmer> if not, you should be able to resolve the conflict manually and run "bzr rebase-continue". Hopefully there aren't too many conflicts