| lamalex | mwhudson: does it look like an ok bug/patch though? | 00:00 |
|---|---|---|
| === RAOF_298 is now known as RAOF_831 | ||
| === RAOF_831 is now known as RAOF_61 | ||
| slangasek | jelmer: any luck? | 00:00 |
| === RAOF_61 is now known as RAOF | ||
| jelmer | slangasek, Yeah, I've managed to reproduce it | 00:00 |
| jelmer | And I think I've got a clue as to why it's failing | 00:01 |
| slangasek | jelmer: so did I screw something up? :-) | 00:22 |
| 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:36 |
| 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:37 |
| 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:38 |
| lexrupy | spiv: thank you, and, I already read the latest documentation... I use Bazaar since version ~ 0.90 I think | 00:39 |
| 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:40 |
| lexrupy | ok, I think you can help-me a little bit more | 00:41 |
| 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:42 |
| 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:43 |
| ubottu | Launchpad bug 295416 in bzr-svn "branch root moving breaks missing and push" [Medium,Triaged] https://launchpad.net/bugs/295416 | 00:43 |
| 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:44 |
| 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:46 |
| lifeless | rockstar: its in trunk | 00:48 |
| lifeless | rockstar: *someone* merged it | 00:48 |
| 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:49 |
| 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:50 |
| 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:55 |
| lexrupy | But I cannot spot that... is each launchpad user a Unix User on server? | 00:56 |
| 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:57 |
| 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:58 |
| 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... | 00:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| lifeless | bbs, lunch | 01:08 |
| 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:09 |
| dryahetzeph | Is it possible to use bzrlib from a standalone bazaar installation on win32? | 01:10 |
| === dryahetzeph is now known as hydrapheetz | ||
| Peng_ | lifeless: Now it's at 4/9. It's definitely much faster. | 01:11 |
| Peng_ | Haha, woah, it's using 400 MB of RAM. I like group_size = 50 better. :P | 01:15 |
| 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:16 |
| 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:18 |
| hydrapheetz | Ah | 01:19 |
| hydrapheetz | I tried doing that and importing it, I haven't tried anything else with it yet | 01:20 |
| lifeless | Peng_: ok, there are two possibilities | 01:25 |
| lifeless | Peng_: I bet its the type detection misfiring | 01:25 |
| 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:26 |
| kumi | Is there any way to update a working tree after a remote client push? The remote client only has bzr+ssh:// access | 01:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:40 |
| lifeless | kumi: why would you need a 2nd ssh key? | 01:41 |
| kumi | I think that's how it would have to work with authorized_keys | 01:42 |
| 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:43 |
| 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:45 |
| lifeless | Odd_Bloke: it won't know what path to update | 01:46 |
| lifeless | a plugin is the best option | 01:46 |
| kumi | It might work if the branch directory is the same as the working tree directory | 01:47 |
| === jamesh__ is now known as jamesh | ||
| === tchan1 is now known as tchan | ||
| === mark1 is now known as markh | ||
| 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:04 |
| lifeless | grettke: its 1.9-rich-root | 04:05 |
| grettke | lifeless: Understood. Thanks. | 04:05 |
| Peng_ | lifeless: BTW, do you have any use for the search indexes I created while timing it, or can I delete them? | 04:18 |
| lifeless | Peng_: unless you suspect a bug, no | 04:22 |
| lifeless | Peng_: but you could keep them, to use :P | 04:22 |
| 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:24 |
| 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:28 |
| lifeless | Peng_: autopacking is small; only 10% hit or so | 04:30 |
| abentley | spiv: around? | 04:38 |
| lifeless | Peng_: also search has a different autopack trigger than bzr | 04:40 |
| lifeless | Peng_: because of slightly different uses | 04:40 |
| spiv | abentley: yeah | 04:43 |
| abentley | spiv: So I tracked down a cause of stacked push over HPSS slowness: RemoteRepository.get_parent_map wasn't stacking. | 04:45 |
| 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:46 |
| 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:47 |
| * spiv nods | 04:48 | |
| abentley | So I figure this has to be done client-side, which is pretty in-tune with lifeless' choices. | 04:48 |
| 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:49 |
| 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:50 |
| abentley | It's doing caching itself instead of using CachingParentsProvider. | 04:51 |
| 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:52 |
| spiv | If I implement a RemoteVersionedFiles class to handle the .revisions (and .texts/.inventories/.signatures) I could just pass that I guess. | 04:53 |
| abentley | spiv: Oh, it's because the caching is happening at a tuple level? | 04:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| spiv | Hmm. | 04:58 |
| spiv | I don't think that's actually what's happening, even if that's what should be done. | 04:58 |
| spiv | There's places like Repository.has_revision and InterPackRepo.fetch that call it directly. | 04:59 |
| 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:00 |
| abentley | Because you get a really easy way to manage the lifetime of the cache. | 05:01 |
| lifeless | abentley: OTOH you have to manage the lifetime, or else differnet parts of bzrlib end up using different caches | 05:02 |
| spiv | get_graph() strikes me as a bit weird, basically because of what lifeless just said. | 05:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| abentley | spiv: No, and it's impossible, because get_graph takes a repo parameter. | 05:07 |
| spiv | There's other, related caching that happens in repository that is managed by lock lifetimes, i.e. index caching. | 05:08 |
| 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:10 |
| 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:11 |
| spiv | But if those extra results sent by the server aren't cached, then RemoteRepository is going to be unnecessarily slow. | 05:12 |
| 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:14 |
| 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:15 |
| spiv | Or at least, "not yet, and changing that will need some careful thought." | 05:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| spiv | abentley: sure. But if we write "def f(): f()" there will be infinite recursion too, and we don't do that either ;) | 05:23 |
| 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:24 |
| 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:25 |
| spiv | Well, it is its own parents provider at the moment, as the implementation of RemoteRepository._make_parents_provider hopefully demonstrates :) | 05:26 |
| 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:27 |
| 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:28 |
| lifeless | abentley: huh? lost me | 05:29 |
| lifeless | abentley: why can't you use SPP with a RR and its fallback repositories | 05:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| jml | thanks | 05:54 |
| jml | lifeless: incidentally, how would you feel about a loom patch that aliased up-thread to "up" and down-thread to "down"? | 05:55 |
| lifeless | jml: fine | 05:57 |
| === abentley1 is now known as abentley | ||
| spiv | abentley: did you have any thoughts on http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081114060525.GJ31377%40steerpike.home.puzzling.org%3E ? | 06:09 |
| === abentley1 is now known as abentley | ||
| spiv | abentley: did you have any thoughts on http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081114060525.GJ31377%40steerpike.home.puzzling.org%3E ? | 06:21 |
| gour | igc: hello. have you seen the latest activity in bug #232177 ? | 06:24 |
| ubottu | Launchpad bug 232177 in bzr-fastimport "Better darcs support needed" [Undecided,New] https://launchpad.net/bugs/232177 | 06:24 |
| gour | darcs-fast-export makes bzr's fast-import really slow in comparison with git's :-( | 06:25 |
| igc | hi gour | 06:27 |
| gour | igc: how are you? | 06:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| igc | gour: create a bug please | 06:31 |
| gour | igc: ok | 06:32 |
| gour | igc: done. bug #298933 | 06:40 |
| ubottu | Launchpad bug 298933 in malone "support for darcs import" [Undecided,New] https://launchpad.net/bugs/298933 | 06:40 |
| igc | gour: thanks | 06:40 |
| gour | igc: do you take care about your diet? | 06:41 |
| igc | gour: very much so | 06:41 |
| gour | igc: good boy ;) that's VERY important... | 06:42 |
| 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:24 |
| army | is it a bzr-svn's bug? | 08:25 |
| asabil | hi all | 09:46 |
| asabil | is there a way to get bzr-git work over http ? | 09:48 |
| 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:50 |
| === jszakmeister|awa is now known as jszakmeister | ||
| Odd_Bloke | asabil: I suspect it involves writing the code to do that. jelmer will know more. | 09:56 |
| asabil | oki thanks | 09:56 |
| 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:03 |
| 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:04 |
| asabil | visik7: I think you can also use bzr replay | 11:11 |
| vila | hi all | 11:27 |
| === jszakmeister is now known as jszakmeister|awa | ||
| lifeless | hi vila, was your flight back pleasant? | 11:40 |
| 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 | 11:56 |
| === sabdfl1 is now known as sabdfl | ||
| === tetha_ is now known as tetha | ||
| === verterok_ is now known as verterok | ||
| 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:00 |
| vila | lifeless: be careful what you wish for... I should not have wish to stay longer in Australia :) | 13:01 |
| 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:03 |
| 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:04 |
| 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:05 |
| * 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:06 |
| vila | spiv: I hesitate to do the same :) I'd like to find back the right schedule :) | 13:07 |
| asabil | would it be possible to have the bzr-svn in the bzr PPA usable ? | 13:24 |
| === lamont` is now known as lamont | ||
| jelmer | asabil, see bug 293009 | 13:43 |
| ubottu | Launchpad bug 293009 in bzr-svn "Bzr-svn conflicts with bzr in the PPA" [Undecided,New] https://launchpad.net/bugs/293009 | 13:43 |
| asabil | jelmer: ok thanks, but what about a fix ? | 13:45 |
| asabil | it is just an | 13:45 |
| 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:46 |
| asabil | hmm ok | 13:47 |
| fullermd | It's all a sneaky underhanded method of tracking how many people the the PPA. | 13:48 |
| 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:51 |
| === mw|out is now known as mw__ | ||
| asabil | is it that hard to maintain ? | 13:55 |
| jelmer | It means 4 uploads to the PPA | 13:58 |
| jelmer | *per package* | 13:58 |
| jelmer | I maintain ~10 bzr-related packages in Debian, so uploading to PPA as well would be quite some overhead | 13:59 |
| cprov | jelmer: have you tried auto-ppa (from jkakar) ? | 14:02 |
| 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:03 |
| cprov | jelmer: also, are you absolutely sure you need rebuilds in all ubuntu series ? | 14:04 |
| 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:05 |
| 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:07 |
| 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:08 |
| cprov | jelmer: maybe we would be good building for dapper and hardy only and copying binaries to intrepid & jaunty | 14:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| cprov | jelmer: the changelog will be target to 'unstable' but you would upload to ~jelmer/ubuntu/hardy/ | 14:15 |
| cprov | jelmer: then oddness would be isolated in the dapper packages, which would probably need tweak in python-central/python-support, anyway. | 14:16 |
| 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:17 |
| cprov | jelmer: great, ping me if you have problems, i'm more than happy to help you solving those issues with bzr-ppa. | 14:18 |
| === cprov is now known as cprov-lunch | ||
| jelmer | cprov-lunch, It seems if I upload a source package to hardy I can no longer upload it to intrepid? | 14:43 |
| james_w | jelmer: correct. you can copy it, but that requires copying the binaries as well. | 14:54 |
| jelmer | james_w: ah, ok - thanks | 14:57 |
| jelmer | seems like a silly restriction to me though... | 15:00 |
| 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:08 |
| 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:10 | |
| 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:11 |
| jelmer | ah, cool | 15:12 |
| 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:13 |
| * jelmer wonders how politically complicated it would be to upload ubuntu-dev-tools to Sid | 15:14 | |
| james_w | hmm | 15:15 |
| === thekorn_ is now known as thekorn | ||
| 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 | 15:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| === kiko is now known as kiko-fud | ||
| derekS | lamalex, jdong: sweet! | 16:03 |
| 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:04 |
| lamalex | http://bazaar-vcs.org/WindowsDownloads | 16:06 |
| 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:09 |
| derekS | lamalex: thanks! | 16:11 |
| 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:15 |
| 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:19 |
| 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:20 |
| jelmer | it's included with the bzr setup on windows | 16:21 |
| 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:27 |
| thrope | it looks very promising - not trying to be negative - just saying its not there yet | 16:28 |
| 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:30 |
| derekS | thrope: i might try it out, i will let you know :) | 16:36 |
| jelmer | Sidnei, It should be very simple - just "bzr push <svn-location>" | 16:41 |
| 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 | 16:42 | |
| === sdboyer is now known as sdboyer|class | ||
| Sidnei | jelmer: great, i re-did it and it worked this time. i think i had messed up some command before. | 17:01 |
| jelmer | cool | 17:02 |
| Sidnei | fwiw, what i did: bzr branch <svn>; bzr merge <bzr-main-branch>; resolve conflicts; bzr svn-push <svn> | 17:03 |
| Sidnei | may or may not be the right way, but achieved what i wanted to do :) | 17:05 |
| === kiko-fud is now known as kiko | ||
| === bac is now known as bac_lunch | ||
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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? | 17:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| visik7 | hmeland: hi I'm still digging with rebase | 18:15 |
| 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:16 |
| 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:17 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:45 |
| 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? | 18:50 |
| rockstar | beuno, do you find that much of loggerhead is overly complicated? | 19:16 |
| 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 | 19:17 |
| === thumper_laptop is now known as thumper | ||
| === bac_lunch is now known as bac | ||
| === mw__ is now known as mw|food | ||
| visik7 | hmeland: if you would help me I'm here :) | 20:28 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| lifeless | jelmer: would getting an iterator in the builder be better for you than having the builder called once for every altered path ? | 20:36 |
| jelmer | lifeless: What exactly do you mean by having an iterator in the builder? | 20:37 |
| 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:38 |
| lifeless | jelmer: builder.here_is_a_delta(tree.last_revision(), tree.iter_changes(tree.basis_tree()) | 20:41 |
| lifeless | vs | 20:41 |
| lifeless | for change in tree.iter_changes(tree.basis_tree()): builder.changed_path(change) | 20:42 |
| 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:43 |
| lifeless | so you'll have to buffer either way I guess | 20:44 |
| lifeless | as iter_changes can jump around | 20:44 |
| 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:56 |
| 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:57 |
| 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:58 |
| jelmer | lifeless, if "delta" is not the full delta at once, I'll indeed have to buffer either way | 20:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:05 |
| lifeless | mwhudson: uggle. Ok, I'll leave it as-is. | 21:06 |
| Sidnei | lifeless: it was a small repo, just stomped-fixed it: svn export; svn rm; svn import | 21:16 |
| === dryahetzeph is now known as hydrapheetz | ||
| === mw|food is now known as mw______ | ||
| jelmer | Sidnei, if the properties are a problem, use "bzr dpush" to import the changes | 21:35 |
| derekS | does anyone have bzr installed throuhg cygwin | 21:42 |
| 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:43 |
| jelmer | Sidnei, Was this with bzr-svn >= 0.4.15 ? | 21:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| lifeless | derekS: I think that that is a 'no' | 21:57 |
| derekS | lifeless: i take it you are right :) | 21:57 |
| Sidnei | jelmer: will you be around in 30? | 21:58 |
| 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 | 21:59 |
| jelmer | Sidnei, cool, thanks | 22:00 |
| derekS | lifeless: when i try to do a push to my sftp server i get: bzr: ERROR: exceptions.IOError: [Errno 0] Error | 22:01 |
| 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:02 |
| 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:04 |
| lifeless | erm no | 22:05 |
| lifeless | /~/ is relative to home | 22:05 |
| derekS | same error with that :) | 22:05 |
| thrope_ | does anywhere other than launchpad offer bazaar hosting? | 22:09 |
| 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:10 |
| thrope_ | LarstiQ: anything like these nice services, github, bitbucket etc (other than launchpad) | 22:11 |
| 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:12 | |
| lifeless | savannah has bzr support | 22:22 |
| lifeless | though they seem, odd, about actually embracing loggerhead etc | 22:22 |
| 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:25 |
| visik7 | a plugin ? I'm not able to do it using rebase ( probably I dunno how to use it) | 22:26 |
| 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:27 |
| mwhudson | (this is blocking 1.9 getting into the next release of lp :() | 22:28 |
| 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:29 |
| 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:30 |
| 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:32 | |
| 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:33 |
| jelmer | visik7, http://people.samba.org/bzr/jelmer/bzr-remove-revisions/trunk/ | 22:34 |
| 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:35 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| * 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:41 |
| 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:43 |
| 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:44 |
| mwhudson | spiv: which doesn't seem rightr | 22:45 |
| 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:46 |
| mwhudson | spiv: yes, that's what i'm finding | 22:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| mwhudson | spiv: https://bugs.edge.launchpad.net/bzr/+bug/299254 | 22:53 |
| ubottu | Launchpad bug 299254 in bzr "when RemoteTransport.mkdir raised PermissionDenied, the path is always None" [Undecided,New] | 22:53 |
| spiv | mwhudson: thanks | 22:54 |
| * spiv heads off to the dentist | 22:56 | |
| visik7 | jelmer: how could be possible that there's a confilt on a file that isn't touched in the 2 commits ? | 22:59 |
| jelmer | visik7, hard to say without looking at the specifics | 23:00 |
| visik7 | mmm | 23:01 |
| 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:02 |
| 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:03 |
| jelmer | jfroy|work, what's the full backtrace? | 23:04 |
| * jfroy|work pasted http://pastie.textmate.org/317310 | 23:07 | |
| jelmer | jfroy|work, was that particular revision perhaps pushed with a bzr-svn prior to 0.4.15 ? | 23:08 |
| jfroy|work | Possibly | 23:09 |
| * Sidnei detects a possible pattern :) | 23:09 | |
| 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:10 |
| 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:11 |
| jelmer | jfroy|work, they should be file properties set by bzr-svn on the branch root | 23:12 |
| jelmer | visik7, yes | 23:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| jfroy|work | It says {svn-v4:be02940b-5f7b-422b-ba6c-1eb93f4884eb:<path>:7882} instead of {<email>-20081015184449-6l6y2bc2tjkl22dg} | 23:16 |
| 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:18 |
| 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:19 |
| Sidnei | jelmer: bzr branch from a bzr branch broke for me | 23:20 |
| jelmer | Hey Ian :-) | 23:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:26 |
| jelmer | Sidnei, so bzr:text-revisions is set but empty? | 23:27 |
| Sidnei | jelmer: yup | 23:27 |
| 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:28 |
| jelmer | jfroy|work, Sidnei: Thanks | 23:29 |
| visik7 | anyway I can't understand why I get the conflict | 23:29 |
| jelmer | visik7, it's hard to say anything about it without looking at specifics | 23:30 |
| 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:31 |
| visik7 | jelmer: I even can't give you a branch becouse of the size of the repo | 23:34 |
| jelmer | visik7, well, what sort of file is ending up in a conflict? When is it changed, etc? | 23:38 |
| visik7 | jelmer: it exists from revision 1 and wasn't change until the conflict | 23:39 |
| 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:40 |
| Sidnei | jelmer: i believe i did a reverse merge to revert it to a previous revision | 23:41 |
| visik7 | jelmer: and the conflict edit the source like that : http://dpaste.com/91601/ | 23:45 |
| visik7 | jelmer: and the diff of the revision that produce the confilct is: http://dpaste.com/91602/ | 23:46 |
| jelmer | visik7, and the revisions you're skipping don't touch *any* of the other files in any way ? | 23:47 |
| jelmer | (bzr log -v on those revisions shows *only* those files?) | 23:48 |
| 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:49 |
| jelmer | visik7, only manually | 23:50 |
| visik7 | :\ | 23:50 |
| visik7 | so | 23:50 |
| 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:51 |
| visik7 | I try | 23:52 |
| jelmer | if not, you should be able to resolve the conflict manually and run "bzr rebase-continue". Hopefully there aren't too many conflicts | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!