| jam | morning poolie | 00:00 |
|---|---|---|
| poolie | hi spiv, feeling better? | 00:00 |
| spiv | Yeah, I am. | 00:01 |
| spiv | Sleeping lots seems to have helped. | 00:01 |
| lifeless | hi igc | 00:05 |
| igc | hi lifeless | 00:06 |
| lifeless | igc: when you're up to it, we should talk about tree rules stuff | 00:07 |
| lifeless | where talk is irc|email|voice | 00:07 |
| rudylattae | spiv feeling better now? | 00:28 |
| spiv | rudylattae: yeah, hopefully it lasts. | 00:30 |
| rudylattae | spiv: good going | 00:31 |
| igc | lifeless: that would be great. Monday morning/lunch on IRC and/or phone suits me best | 00:44 |
| lifeless | ok, cool | 00:45 |
| lifeless | jelmer: http://goran.krampe.se/blog/Squeak/BzrOnDebian.rdoc | 00:49 |
| lifeless | jelmer: there is a issue with normalisation in there, from bzr-svn | 00:50 |
| lifeless | jelmer: do you think its a bzr bug or bzr-svn bug? | 00:50 |
| jelmer | lifeless, this is a blog post from december last year | 00:51 |
| lifeless | yes | 00:51 |
| jelmer | lifeless, My memory of what bugs I've fixed doesn't go back that far :-) | 00:52 |
| lifeless | I don't think its necessarily fixed | 00:52 |
| * jelmer tries | 00:54 | |
| jelmer | lifeless, we did fix some normalization-related issues a while ago | 00:58 |
| === abadger19991 is now known as abadger1999 | ||
| poolie | lifeless: were you still planning to come over this arvo? | 01:30 |
| lifeless | poolie: yah | 01:42 |
| lifeless | poolie: I forgot about that, one minute | 01:42 |
| lifeless | did spiv confirm dinner ? | 01:42 |
| poolie | not yet | 01:43 |
| poolie | depends how he's feeling today i guess | 01:43 |
| alsuren | is there some way to make bzr automatically recognise when I've moved files around and done nothing else to them? | 01:43 |
| lifeless | http://michael.ellerman.id.au/bzr/plugins/auto-rename | 01:44 |
| lifeless | poolie: so its a bit of a miserable day outside | 01:44 |
| lifeless | spiv: ping | 01:45 |
| poolie | yes i'd just been noticing that :) | 01:45 |
| jelmer | lifeless, just confirmed, that repo checks out fine here | 01:48 |
| jelmer | well, *seems* to be | 01:48 |
| lifeless | jelmer: cool | 01:48 |
| * alsuren wonders whether there is a plugin installer plugin, or whether that would be a bit too meta :P | 01:48 | |
| poolie | alsuren: there should be :) | 01:49 |
| poolie | there is a bit of a start towards it with the missing-plugin stuff | 01:49 |
| poolie | lifeless, we can take a rain check (cheque?) | 01:49 |
| lifeless | poolie: sure thing | 01:49 |
| poolie | i would like to talk to you on the phone if not in person sometime | 01:49 |
| lifeless | perhaps a rain CHK | 01:50 |
| poolie | but preferably not til later to preserve my concentration | 01:50 |
| poolie | such as it is | 01:50 |
| alsuren | bzr branch http://michael.ellerman.id.au/bzr/plugins/auto-rename/ hangs for me | 01:53 |
| alsuren | *goes to bed, and thinks about it tomorrow* | 01:53 |
| poolie | alsuren, it may just be a slow-over-http format | 01:54 |
| === mw is now known as mw|out | ||
| lifeless | alsuren: its an old format branch | 01:56 |
| lifeless | poolie: sorry if I'm bad for concentration :P | 01:56 |
| lifeless | poolie: later is fine | 01:56 |
| abentley | jam: back now. | 02:25 |
| lifeless | lol? http://linux.softpedia.com/get/Programming/Version-Control/bzr-search-40745.shtml | 02:58 |
| mwhudson | lifeless: boggle | 02:59 |
| bob2 | hopefully they can certify it as virus free soon | 03:08 |
| markh | lifeless: bug 264679 is suggesting that info about 'bzr help configuration' be listed in the output of 'bzr help' | 03:16 |
| ubottu | Launchpad bug 264679 in bzr "expose configuration help in cli" [Undecided,New] https://launchpad.net/bugs/264679 | 03:16 |
| lifeless | god no | 03:17 |
| markh | if it didn't have info about branch config etc it would make more sense. 'bzr help user-config' or similar... | 03:19 |
| lifeless | markh: why? | 03:23 |
| markh | to give a new user that they might want to run 'whoami', for example | 03:24 |
| markh | well - a clue to follow to find that out ;) | 03:24 |
| lifeless | uhm | 03:26 |
| lifeless | I don't think this makes sense; users may not run help at all | 03:27 |
| lifeless | they may assume they know how to use it | 03:27 |
| markh | heh | 03:27 |
| markh | so who is it for? ;) | 03:27 |
| lifeless | or they might be on a new machine | 03:27 |
| lifeless | 'bzr help' is not 'I am a new bzr user' | 03:28 |
| markh | so you are against putting potentially useful information in "bzr help" because users may not run help? | 03:28 |
| lifeless | no | 03:29 |
| markh | someone who is not a new user to bzr doesn't need much of the info on the 'bzr help' screen at all | 03:29 |
| markh | they already know 'bzr help commands' | 03:29 |
| lifeless | I'm against making 'bzr help' which is already too long, longer, without actually solving the asserted root problem | 03:29 |
| lifeless | a windows user won't run 'bzr help | 03:29 |
| markh | of course they will! | 03:29 |
| lifeless | someone following a guide someone else wrote probably won't run 'bzr help' | 03:30 |
| markh | I do, and ofcourse its one of the first bzr commands I ever typed! | 03:30 |
| lifeless | no they won't, they'll right click somewhere and start with the first popup screen | 03:30 |
| markh | that is a gross generalization ;) | 03:30 |
| markh | "linux users will never use the mouse" ;) | 03:30 |
| lifeless | likewise an eclipse user | 03:31 |
| poolie | are you saying the core change is that 'bzr help' top level output should point to 'help configuration' or is it something else? | 03:31 |
| markh | but - I'm not avdocating for that - just trying to understand your reasoning | 03:31 |
| poolie | markh, the mouse is used to choose the xterm to type in ;-) | 03:31 |
| markh | that was the assertion a user made, and lifeless said he didn't understand the proposal. I was just trying to help clarify it for lifeless. | 03:31 |
| lifeless | markh: if the problem is that 'you have to run bzr whoami to be able to use bzr sensibly', then we should put effort into fixing that | 03:31 |
| markh | I see it potentially has merit | 03:32 |
| markh | and I assert a new user of bzr *will* type 'bzr help' very early on | 03:32 |
| markh | but I really don't care ;) | 03:32 |
| lifeless | well, I'm not against a pointer to the config in the top level help | 03:32 |
| lifeless | I am against embedding al the content there | 03:32 |
| markh | why? Surely that's for the new user too? | 03:32 |
| lifeless | markh: why not delete the top level help and point to the tutorial? | 03:33 |
| markh | because IMO 'bzr help' is useful to the new user, and should be targetted at the new user. | 03:33 |
| markh | ISTM you are the one saying otherwise? | 03:33 |
| markh | I think bzr help is very good atm for exactly those reasons | 03:34 |
| lifeless | from experience, people get scared off a first help screen that is more than ~ 1 page | 03:34 |
| lifeless | the config documentation is many many pages | 03:34 |
| markh | I think a single line 'bzr help config - show info about how to customize bzr for your preferences" *might* be beneficial for new users | 03:35 |
| lifeless | sure, I have no objection to that | 03:35 |
| lifeless | we should remove 'bzr check' too | 03:35 |
| markh | that is the proposal!! | 03:35 |
| lifeless | markh: I though it was to copy the contents of bzr help configuration -> bzr help | 03:36 |
| markh | god no ;) | 03:36 |
| lifeless | markh: which is what I said | 03:36 |
| markh | so, I hope I've help clarify the proposal in that bug you commented on ;) | 03:37 |
| lifeless | abentley: we must be talking past each other or something, on the bug discussing rev specs | 03:40 |
| markh | the 'whoami' question is interesting in its own right. The default value will rarely be exactly what the user would choose to type for that value. So the argument could be made that you *do* need to run whoami to have it work sensibly. the first few bzr checkins I made had 'inappropriate' values for the user (certainly 'skip@eden | 03:41 |
| markh | ') isn't that useful | 03:41 |
| markh | poolie: how was the trip? Your bum recovered? | 03:44 |
| poolie | it was great thanks | 03:44 |
| * markh hopes people don't take that the wrong way ;) | 03:44 | |
| poolie | heh | 03:44 |
| markh | bike went well? | 03:44 |
| poolie | actually it was more my neck that got sore from crosswinds | 03:44 |
| lifeless | markh: better that poolie doesn't take it the wrong way either :P | 03:45 |
| markh | :) | 03:45 |
| poolie | markh, the front shock and forks started leaking after a day of fairly rough roads | 03:45 |
| poolie | not catastrophically, and they'll be replaced soon under warranty | 03:45 |
| markh | bugger - they lasted ok though? | 03:45 |
| poolie | yes | 03:45 |
| poolie | it was a bit disturbing to see oil all over the front of the bike | 03:46 |
| poolie | but fine | 03:46 |
| poolie | the mechanic said "if i'd been punished like that all day i'd be weeping too" :-) | 03:46 |
| markh | yeah, I bet! Did you notice the suspension suffer? | 03:46 |
| markh | heh :) | 03:46 |
| markh | I'd guess you'd lose dampening? | 03:46 |
| poolie | no, i just put a bit more preload on to (possibly) make it easier on it | 03:46 |
| poolie | i guess i would eventually but it probably has not lost enough oil to make a difference | 03:47 |
| poolie | i actually got much more relaxed on that ride about rough surfaces, dirt, big trucks, wind, etc | 03:47 |
| markh | yeah, I shit myself on dirt still :) | 03:47 |
| poolie | http://flickr.com/photos/mbp_/2824615378/ | 03:48 |
| lifeless | markh: so, bzr design principles - we try to make mistakes easy to recover from; having to read more to be insulated from mistakes strongly suggests to me that we have a too-hard-to-recover-from situation | 03:48 |
| markh | it would help if I had a bike designed to go off the tarmac though :) | 03:48 |
| lifeless | markh: and I'm *much* more interested in fixing that that | 03:48 |
| poolie | i saw two roos go across the road in front of me | 03:49 |
| poolie | not close enough to be a problem but it does make you think | 03:49 |
| markh | lifeless: I think we are agreeing in general. However, I do see value in assuming a new user is likely to run 'bzr help' early on, and best I can tell, the existing help on that page is targetted at a new user. further, pointing such a new user at config options early on may have value too. | 03:50 |
| markh | poolie: how close? | 03:50 |
| poolie | the first one, i braked at about 70% effort and had plenty of room | 03:51 |
| poolie | the second i just backed off and watched him go | 03:51 |
| markh | ack - I bet the first one worried you briefly! You have abs though? | 03:52 |
| lifeless | markh: well, like I said, I'm not against tweaking 'bzr help'. It doesn't enthuse me though - the shed is blue, mmk? (compared to reducing the curve by making mistakes more recoverable). | 03:53 |
| poolie | i do | 03:54 |
| poolie | i've never had it activate except when practicing braking | 03:54 |
| poolie | which is probably good | 03:54 |
| poolie | nice to know it's there | 03:54 |
| poolie | so some people on the trip washed their bikes every night, then put covers over them | 03:55 |
| poolie | each to their own but i found that kinda creepy :-) | 03:55 |
| markh | heh - the ducati trips are very much like that ;) | 03:55 |
| poolie | i bet | 03:55 |
| markh | quite amazing | 03:55 |
| markh | I admit I wiped the bugs from the front most nights though ;) | 03:55 |
| markh | but left a streaky mess in its place :) | 03:56 |
| poolie | i did wash the screen, lights, etc | 03:56 |
| poolie | the rest of it looks better with some dirt | 03:56 |
| lifeless | back soon | 03:57 |
| markh | your enjoyment suffers when you are too anal about things like that | 03:57 |
| poolie | so, about half our trip overall was just up and down the bruce hwy | 03:58 |
| poolie | there is a lot of sugar cane | 03:58 |
| poolie | there were some pretty amazing roads in between | 03:58 |
| markh | I bet | 04:01 |
| markh | poolie: back to those tests - how should we proceed on silencing the lock contention test failures? | 04:50 |
| poolie | you're talking about the outright failures rather than xfail i presume | 04:50 |
| markh | yeah | 04:52 |
| markh | it seems xfail already catches some of those errors | 04:52 |
| markh | we just try and arrange for xfail for all of them? | 04:52 |
| poolie | so that would be the laziest way to do it | 04:53 |
| poolie | at least then we'd detect if anything new breaks | 04:53 |
| poolie | i think it would be worth trying to work out why they are failing | 04:54 |
| poolie | for instance | 04:54 |
| poolie | - is it just a bug in the test that eg it has two objects pointing at the same file | 04:54 |
| poolie | in which case ideally we'd fix the test | 04:54 |
| poolie | - or is it something that is kind of broken by design on windows | 04:54 |
| poolie | - or is it something that we could fix but that'll be nontrivial | 04:55 |
| poolie | that kind of thing | 04:55 |
| poolie | i suspect there are some in the first category and it would be nearly as easy to fix them as to block out the tests | 04:55 |
| markh | There are a couple of cases where we try and take a readlock and a writelock on the same directory | 04:55 |
| markh | I'll try and find the thread - give me a few... | 04:55 |
| markh | It was in IRC. "[09:05] <markh> I'm tracking down LockContention on Windows and I don't understand how it is supposed to work. I've instrumented 'do_merge' and can prove that in some cases, self.this_tree._dirstate._filename == self.base_tree._dirstate._filename" | 04:57 |
| markh | so - many of the test failures stem from that. It should be quite easy to instrument any platform to check for that condition | 04:58 |
| poolie | ok, i recall that from before i left | 04:58 |
| markh | on Linux, you *can* lock like that, on Windows you can not | 04:58 |
| poolie | so i'd want to know - are the dirstate objects the same? if so, are the tree objects the same? | 04:58 |
| markh | apparently yes | 04:58 |
| markh | lifeless says there are a number of valid use cases for that | 04:59 |
| poolie | hm | 04:59 |
| lifeless | bzr merge . for instance | 04:59 |
| lifeless | which is why I proposed a relatively trivial tweak to dirstate that avoids this | 04:59 |
| lifeless | but it seems to be stalled | 04:59 |
| lifeless | and it won't fix WT4 regardless | 05:00 |
| poolie | so i want to avoid having "xfail os locks are not process-wide" when that is only the proximate cause | 05:00 |
| markh | how about a "Feature"? | 05:02 |
| markh | I'm not sure how these solutions would impact the output of the test run though | 05:02 |
| fullermd | Hm. There are some minor long-standing test failures on my system... | 05:03 |
| markh | IIUC that would make them a "skip" or something though... | 05:03 |
| lifeless | markh: skip isn't appropriate for something that can't be fixed | 05:03 |
| fullermd | But I got a stack of others while trying to reproduce them. Figures. | 05:03 |
| markh | Features seems like the easiest implementation though ;) | 05:03 |
| poolie | so | 05:04 |
| poolie | if the object is already locked, why are we trying to lock the same file through a different file handle? | 05:04 |
| markh | I think the answer is "because we can" :) | 05:05 |
| poolie | it wasn't about feature vs xfail, rather that if we're going to say "it's not really a failure" i'd like to be clear about what is causing it | 05:05 |
| markh | an option I proposed was simply to detect we already have a write lock and don't bother with the read lock. lifeless suggested that wasn't really an appropriate fix and he had ideas for the correct fix | 05:05 |
| lifeless | markh: I mailed my proposal to the list | 05:06 |
| lifeless | markh: its not a good fix because its very incomplete | 05:06 |
| markh | lifeless: understood, but there is a dependency issue | 05:06 |
| poolie | lifeless, you're talking about the proposal to rename the file? | 05:07 |
| poolie | i guess i just don't see why this would need any on-disk changes | 05:07 |
| poolie | why can 'bzr merge .' not work with our current format? | 05:07 |
| markh | do we want to wait for that fix before we try and make tests give reasonable output? There is only one of you ;) , so doing something in the meantime makes some sense | 05:07 |
| lifeless | markh: theres no need for me to do the deeper fix; and I haven't suggested waiting on addressing the tests issue | 05:08 |
| markh | lifeless: understood - was just explaining myself :) | 05:08 |
| lifeless | poolie: bzr merge . is something the test suite does; bzr diff while a bzr commit window is open is a more common occurence of the same defect | 05:08 |
| poolie | they're different because in the first case there is only one process in play | 05:09 |
| poolie | the second is a known bug, sure | 05:09 |
| poolie | the first one seems to me to be accidentally failing | 05:10 |
| markh | poolie: when you say "accidentally failing", you mean "bzr is accidentally taking more lock than it needs" or "test suite is in error"? | 05:11 |
| poolie | it could be either | 05:12 |
| markh | a one line hack to do_merge will reproduce the problems for you | 05:12 |
| poolie | i mean 'accidentally' because the design limit that affects the second case should not be causing this to fail afaics | 05:12 |
| markh | just fail whenever the 2 paths are the same and run the test suite | 05:12 |
| lifeless | bug 114528 | 05:24 |
| ubottu | Launchpad bug 114528 in bzr "dirstate locks don't work on Apple AFP network mounts" [Medium,Confirmed] https://launchpad.net/bugs/114528 | 05:24 |
| lifeless | another example o f the same thing | 05:24 |
| poolie | lifeless: to me it looks like that's just saying that file locks don't work at all in some environments | 05:28 |
| lifeless | poolie: yes, and the ongoing problems with dirstate are due to that | 05:39 |
| markh | poolie: the test related patch in the queue I referred to is at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C019a01c8fe73%2427a26f30%2476e74d90%24%40com.au%3E - John has already voted 'approve' | 05:56 |
| * markh didn't think the patch was *that* scary... | 05:58 | |
| poolie_ | i'll look | 05:58 |
| mwhudson | who would be the person to ask about bzr's sftp transport? | 06:02 |
| poolie_ | anyone really | 06:02 |
| mwhudson | in particular, is there any likelyhood it sends the "realpath" sftp command? | 06:02 |
| lifeless | spiv, poolie, I, jam, vila, have all had sustantial interactions with it | 06:02 |
| lifeless | unlikely I think | 06:03 |
| mwhudson | that's what i thought too | 06:03 |
| lifeless | which is why your server is bust :P | 06:03 |
| mwhudson | yeah | 06:03 |
| mwhudson | well | 06:03 |
| mwhudson | it's why our server can be bust and still host bazaar branches without exploding | 06:04 |
| mwhudson | (realpath returns url-encoded paths atm) | 06:04 |
| poolie_ | markh, it looks fine to me, i'll merge it | 06:05 |
| markh | poolie_: thanks! | 06:12 |
| lifeless | poolie_: call time ? | 06:32 |
| poolie_ | woo, passing | 06:33 |
| poolie_ | what a great time for a call :) | 06:34 |
| vila | goood morning bazaar | 06:57 |
| gour | morning vila | 06:59 |
| vila | mwhudson: I highly doubt we use the realpath command in our sftp client, paramiko may though | 07:02 |
| === thekorn_ is now known as thekorn | ||
| spiv | poolie_, lifeless: I don't think I'll be doing dinner with you guys tonight, I'm still not quite 100%. | 08:49 |
| poolie_ | spiv, sure, we're not either | 08:50 |
| spiv | poolie_: great ;) | 08:53 |
| poolie_ | spiv, can you look quickly at my partial patch on bug 261315 | 09:03 |
| ubottu | Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,In progress] https://launchpad.net/bugs/261315 | 09:03 |
| * spiv looks | 09:05 | |
| spiv | It looks like I have a fix for the ObjectNotLocked bug that affects 'bzr cat bzr://...' etc, just waiting for tests to pass. | 09:06 |
| spiv | It *might* let me delete some cruft, too. | 09:06 |
| spiv | poolie_: that looks ok to me | 09:11 |
| poolie_ | thanks | 09:11 |
| poolie_ | it'd be nice to eliminate these things of having two objects representing the same thing | 09:11 |
| spiv | poolie_: the obvious way to avoid that forcing _ensure_real on every branch open would be by having a new Branch.open RPC that returns the stacked_on URL, I guess. | 09:12 |
| poolie_ | Branch does seem like a good place to start in removing real objects | 09:12 |
| spiv | Yeah, keeping two different objects representing the same entity in sync is the source of lots of hpss bugs. | 09:13 |
| spiv | Including the ObjectNotLocked one. | 09:13 |
| poolie_ | i might try that soon | 09:18 |
| poolie_ | maybe not tonight | 09:18 |
| poolie_ | i should finish off LockableFiles too... | 09:18 |
| poolie_ | i was also looking at the locking gc warning thing | 09:19 |
| poolie_ | it seems to me that every case we currently warn is in a test for lock-breaking or similar | 09:19 |
| poolie_ | where we really are meaning to have the lock object leak | 09:19 |
| poolie_ | so i guess we could explicitly mark them as abandoned or something, and then suppress the lock leak | 09:21 |
| poolie_ | but it seems like diminishing returns | 09:21 |
| === mvo__ is now known as mvo | ||
| spiv | Ooh, it looks like I *can* finally delete some cruft from RemoteBranch.lock_write | 10:59 |
| spiv | I think I just figured out part of the confusion that had stopped me doing that earlier: it was possible for the code to overwrite the _real_repository object sometimes. Debugging hilarity ensues. | 11:00 |
| * spiv goes on a XXX-deletion spree | 11:02 | |
| spiv | Among other things, RemoteBranch.lock_write doesn't force _ensure_real any more :) | 11:03 |
| spiv | jam: RemoteBranch.lock_read fix sent to list | 11:49 |
| spiv | jam: it includes some bonus extra sanity on top of just fixing the immediate bug :) | 11:50 |
| * spiv wanders afk | 11:51 | |
| cjwatson | I'm trying to use bzr import-dsc on the history of a non-native Debian package, and running into some trouble: namely, it works if I just run it in an ordinary branch, but not if I create a repository first. What would you need in order to debug this? | 12:11 |
| cjwatson | oh, I forgot James was on holiday, ok | 12:18 |
| Odd_Bloke | cjwatson: I'd suggest pasting the appropriate part of your .bzr.log somewhere. | 12:20 |
| cjwatson | http://paste.ubuntu.com/43603/ | 12:24 |
| Odd_Bloke | cjwatson: Hmm, yeah, that's something I can't really help with. | 12:27 |
| Odd_Bloke | Doing it in a branch and then branching into your repository should work around it though. | 12:27 |
| cjwatson | right, that's what I did | 12:28 |
| cjwatson | it's perfectly reproducible, so I'll grab James about it when he gets back | 12:28 |
| Odd_Bloke | cjwatson: File a bug? | 12:28 |
| cjwatson | yeah | 12:28 |
| === jelmer is now known as Guest51940 | ||
| LeoNerd | So..... | 12:53 |
| LeoNerd | 'find -name .bzr \( -prune -printf "%h\n" \)' runs in about 0.5seconds and uses hardly any memory while doing so. Whereas, 'bzr branches' eats looooads of memory and spends a great deal longer time finding out the same information... | 12:54 |
| LeoNerd | Oh and it chews a great amount of CPU too | 12:56 |
| Peng_ | 'branches' is that bad? Hmmm. | 12:58 |
| LeoNerd | real 0m0.022s <= 'find | sed'. real 0m13.015s <= 'bzr branches' | 12:59 |
| Peng_ | Jeepers, you're right. It hit 112 MB of RAM by the time it was done. | 12:59 |
| LeoNerd | Mhm :) | 12:59 |
| Peng_ | I'm running it on a VPS, so I think I just dumped the entire disk cache, but at least I didn't swap. | 13:00 |
| LeoNerd | Perhaps I should post to the mailinglist? | 13:00 |
| Peng_ | Sure. | 13:00 |
| Peng_ | Oh, I just realized that my little script doesn't use "bzr branches" anyway. | 13:01 |
| Peng_ | It uses subprocess.Popen(['find']). Cough. | 13:01 |
| LeoNerd | Hehe | 13:01 |
| LeoNerd | Ya.. I use: | 13:01 |
| LeoNerd | find -name '.bzr' \( -prune -printf "%P\n" \) | sed -e 's,/\.bzr$,,' | 13:01 |
| Peng_ | Heh. I just use 'find' to get a list of all directories and then loop through it. | 13:02 |
| === vk5foss is now known as kgoetz | ||
| jakobb | to anyone: there used to be a bug regarding errors that occur when redirection takes place, does anyone remember the # by accident? | 13:21 |
| awilkins | LeoNerd: Heh, I have a powershell script for the same reason | 13:22 |
| === AnMaster_ is now known as AnMaster | ||
| LeoNerd | mmmm | 13:23 |
| LeoNerd | Sounds like 'bzr branches' needs some work then | 13:23 |
| awilkins | ls | where { $_.PSIsContainer } | ls -force -inc .bzr | where { ($_.Name -eq ".bzr") } | foreach { $_.Parent } | 13:23 |
| awilkins | It doesn't recurse, but some of my trees are .. large, and I don't want to recurse them | 13:24 |
| LeoNerd | That's what the -prune is for | 13:25 |
| awilkins | I'm not very skilled with "find" as yet | 13:25 |
| Peng_ | Hmm, replacing my 'find' hack with os.walk was quite easy. Yay. :) | 13:37 |
| Peng_ | (I've never used os.walk before.) | 13:37 |
| abentley | Peng_: There's a bug in the svn bindings that can cause ludicrous memory consumption, if you have bzr-svn. But branches uses bzr transports, and they're not very efficient for this. | 13:50 |
| Guest51940 | abentley: What exactly is triggering that? | 13:51 |
| Jc2k | hi jelmer/guest51940 :p | 13:52 |
| abentley | Guest51940: I don't know. | 13:52 |
| Guest51940 | abentley, Just a regular pull/push with bzr-svn doesn't use more memory than usual these days | 13:53 |
| abentley | Guest51940: That's with the new bindings? I'm talking about the old ones. | 13:54 |
| Guest51940 | abentley, ah, ok | 13:54 |
| abentley | And I'm talking specifically about the 'branches' command. | 13:54 |
| abentley | Which uses BzrDir.find_branches. | 13:54 |
| Peng_ | abentley: I do have bzr-svn installed, but none of the branches in question use it in any way (though some are copies of svn imports). | 13:55 |
| abentley | Peng_: Doesn't matter whether they use it. | 13:56 |
| LeoNerd | I'm not using svn at all | 13:56 |
| RAOF_ | Ah. You're talking about the 'bzr multi-pull consumes 1GB resident' funness? | 13:57 |
| abentley | LeoNerd: Are you seeing ludicrous memory consumption? | 13:57 |
| LeoNerd | Yup | 13:58 |
| LeoNerd | In fact, if I run 'bzr branches' from my $HOME, it throws everything else out to swap, then OOM killer bites | 13:59 |
| lamont | Format <RepositoryFormatKnit1> for file:///home/lamont/stuff/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance | 13:59 |
| lamont | what check (short of a bzr command) can I use to see that this warning is going to come out, I wonder? | 13:59 |
| abentley | LeoNerd: Please file a bug, then. So far, every case of this has been solved by uninstalling bzr-svn. | 14:01 |
| LeoNerd | Ahright :) | 14:02 |
| abentley | lamont: I don't think there's anything you can do without running a bzr command. The list of deprecated formats will be different depending on your bzr version. | 14:03 |
| lamont | right. specifically, 1.6 vs knit, or "is there a way to tell that I have a knit1 format by just checking a file or its contents?" | 14:04 |
| abentley | lamont: you can "cat $PATH_TO_REPO/.bzr/repository/format" | 14:05 |
| lamont | cool | 14:05 |
| Peng_ | Wait...my os.walk() code is completely broken. | 14:05 |
| === robtaylor is now known as robtaylor-test | ||
| Peng_ | Anyway, off-topic. | 14:06 |
| === robtaylor-test is now known as robtaylor | ||
| === fta_ is now known as fta | ||
| Peng_ | Weird...I seem to have poked one of my bzr branches over http. | 14:35 |
| === mw|out is now known as mw | ||
| awilkins | ls | 14:53 |
| awilkins | oops | 14:53 |
| Pieter | . .. docs movies warez xxx | 14:56 |
| * awilkins wonders if Pieter executes any other commands | 15:00 | |
| awilkins | rm -rf /dev/brain | 15:00 |
| Pieter | rm: command not found | 15:01 |
| === Guest51940 is now known as jelmer | ||
| mitchchapman | Using bzr 1.6 on Windows XP, I am suddenly getting this error on every operation: "bzr: ERROR: invalid header line: ''" My dirstate file appears to be empty. | 16:06 |
| mitchchapman | Does anyone know how to recover from this situation? | 16:06 |
| abentley | mitchchapman: do you have any changed files? | 16:06 |
| mitchchapman | Yes. | 16:07 |
| abentley | Move all your files except .bzr into a temp directory | 16:07 |
| abentley | delete .bzr/checkout and its contents. | 16:08 |
| abentley | run "bzr checkout ." | 16:09 |
| abentley | That should give you a tree in the state you last committed. | 16:09 |
| abentley | Then copy your working tree files back in place. | 16:09 |
| abentley | If you had added or moved any files, you'll have to do that again. | 16:09 |
| mitchchapman | abentley: That did the trick, thank you very much! | 16:28 |
| abentley | mitchchapman: You're welcome. | 16:28 |
| chadmiller | Hi all. In bzrlib, what's the best way to find if a revisionid exists in a branch? All the ways I see in bzrlib.branch work only if the revision also has an integer revno. | 16:28 |
| abentley | chadmiller: bzr log -r revid:$REVISION_ID | 16:32 |
| abentley | If that shows the entry, it's in the branch. If it raises an exception, it's not. | 16:32 |
| chadmiller | abentley: Okay. I'll reverse-engineer what "log" does. Surely there's a smarter way. Note my "In bzrlib," preposition. | 16:36 |
| abentley | chadmiller: Oh, then "best" is highly variable. | 16:37 |
| chadmiller | cheapest? "if revid in some_hash:"... | 16:37 |
| * chadmiller greps around for NoSuchRevision | 16:38 | |
| abentley | Cheapest would be branch.repository.get_graph.iter_ancestry([branch.last_revision]) | 16:38 |
| abentley | Or I guess branch.repository.get_graph().is_ancestor(candidate, branch.last_revision()) | 16:40 |
| abentley | However, *any* operation that can answer your question will scale badly if the answer is "no". | 16:41 |
| abentley | So I would reconsider trying to do that. | 16:41 |
| chadmiller | abentley: Well, I'm trying to use Graph.find_unique_ancestors(), which lists every rid if the exceptions list contains only an invalid rid. | 16:44 |
| chadmiller | Arguably, it should raise an exception. I can't wait, though. | 16:45 |
| abentley | chadmiller: I think that anything that can answer your question will take at least as long as find_unique_ancestors if there is an invalid revision-id. | 16:47 |
| abentley | The only way to know if a revision_id is present in a branch is to walk the ancestry of the last revision in the branch. | 16:48 |
| abentley | until either you find it, or you reach the graph origin. | 16:48 |
| chadmiller | Right. I'm not worried about time for missing revid. I must raise a warning though, in the case where someone gives me an invalid revisionid. | 16:49 |
| abentley | Invalid revision ids are those that end with a single ':' | 16:50 |
| chadmiller | I wouldn't mind taking the graph origin as an error. I'll look at that. I can test if the set Graph.find_unique_ancestors() contains the origin, I suppose. Hrm. Now, to get the origin.... | 16:52 |
| chadmiller | abentley: When I say it, I mean "invalid" to be "not present in the history at all" | 16:52 |
| abentley | chadmiller: No, you mean "not present in the ancestry at all". If it's present in the ancestry but not the history, it doesn't have an integer revno. But you said you wanted to allow things without integer revnos. | 16:56 |
| chadmiller | abentley: Thank you. bzr internals argot is still new to me. | 16:56 |
| jam | abentley: well technically you can walk both ancestries, and if you find them converge | 17:32 |
| jam | then you only need to search some of the ancestry | 17:32 |
| jam | (things that are descendents of the common point) | 17:32 |
| jam | I use that sort of logic in the lazy revno code I've been putting together | 17:33 |
| jam | and it is also somewhat how "Graph.find_distance_to_null()" works. | 17:34 |
| jam | chadmiller: the 'origin' is "NULL_REVISION" | 17:34 |
| jam | but that is going to be common to all revisions | 17:34 |
| jam | so won't show up in "find_unique_ancestors()" | 17:34 |
| jam | Actually, I would be surprised if "find_unique" returns the complete set | 17:34 |
| jam | unless the ancestries are completely separate | 17:34 |
| jam | chadmiller: http://rafb.net/p/M1l6OR91.html | 17:36 |
| jam | there is also "Graph.find_difference()" | 17:36 |
| jam | which can give you the difference on each side | 17:36 |
| jam | if one side is empty | 17:36 |
| jam | then that revision is in the ancestry of the other. | 17:36 |
| chadmiller | jam: Hrm. "...the difference on each side"? I have only a revisionid and one branch. I don't see how find_difference() can help. | 17:40 |
| jam | chadmiller: Branch.last_revision() | 17:40 |
| jam | left_unique, right_unique = graph.find_difference(Branch.last_revision(), old_last_revision()) | 17:41 |
| jam | if len(right_unique) == 0: | 17:41 |
| jam | then old_last_revision is in the ancestry of the current tip | 17:41 |
| jam | because it has no unique ancestors | 17:41 |
| jam | Otherwise left_unique == graph.find_unique_ancestors(Branch.last_revision(), [old_last_revision]) | 17:42 |
| jam | chadmiller: does that help? | 17:42 |
| jam | find_difference() computes the symmetric difference | 17:42 |
| jam | (what is in A that isn't in B, and what is in B that isn't in A) | 17:42 |
| jam | find_unique only computes 1 side | 17:42 |
| jam | (because in the general case it is cheaper to compute 1 side if you don't care about the other side) | 17:42 |
| jam | vila: ping | 17:47 |
| vila | jam: pong | 17:47 |
| jam | vila: I notice you updated the status of a lot of bugs without updating their importance. Is there a reason? | 17:47 |
| vila | not really, I don't think I update major ones though, just trying to clear the New queue | 17:48 |
| vila | I generally affect an importance when I get enough understanding of the consequences to do so | 17:50 |
| jam | So, IMO, if you are triaging it to confirm it, then it should have an importance rating. | 17:50 |
| jam | Obviously Wontfix/invalid don't need them | 17:50 |
| jam | And sometimes "incomplete" doesn't | 17:50 |
| jam | that depends on if there is enough information to give a severity indication. | 17:50 |
| jam | But certainly "Confirmed" sounds like we should know how important the bug is. | 17:51 |
| vila | and when do you use triaged vs confirmed ? | 17:51 |
| jam | vila: Triaged / Confirmed is ... unclear. I believe I understand how LP wants us to use them. | 17:51 |
| jam | Specifically, Confirmed is for non-bzr devs | 17:51 |
| jam | to say that "I saw this too" | 17:51 |
| jam | (confirmed) | 17:51 |
| jam | Triaged is for project devs | 17:51 |
| jam | to say that there is enough info to give an importance rating. | 17:52 |
| jam | and if someone wanted to work on it, they could | 17:52 |
| jam | Martin always uses Confirmed | 17:52 |
| jam | I've started using Triaged | 17:52 |
| jam | and I don't think we've come up with official project policy. | 17:52 |
| jam | But I will note | 17:52 |
| jam | non project devs can set "incomplete" "invalid" and "confirmed" | 17:52 |
| abentley | jam: Kiko is in favour of *never* using confirmed. | 17:52 |
| jam | you have to be in the ~bzr group to set "Triaged" | 17:52 |
| jam | abentley: hm... I haven't seen that. But I don't hang out on #launchpad. :) | 17:53 |
| jam | Do I misunderstand the idea of the Malone definitions? | 17:53 |
| abentley | jam: It was in the launchpad mailing list. | 17:53 |
| chadmiller | Wow, jam, I step away to get food and you fill my screen! :) | 17:54 |
| * chadmiller reads. | 17:54 | |
| jam | well, a lot of it is not related to you :) | 17:54 |
| abentley | jam: "Triaged" means "confirmed by Someone Important" to kiko | 17:54 |
| jam | abentley: sure, which is why I would use Triaged for ~bzr users, and leave Confirmed to non ~bzr users. | 17:54 |
| vila | abentley: that's how I was using confirmed (humbly though :) | 17:54 |
| jam | vila: sorry, you're Someone Important | 17:55 |
| jam | you gotta step up to that :) | 17:55 |
| * vila tried... | 17:55 | |
| vila | :D | 17:55 |
| jelmer | awilkins, ping | 17:59 |
| jam | vila: do you have any experience with python's xmlrpclib? | 18:00 |
| jam | I was just poking at bug 186920 | 18:00 |
| ubottu | Launchpad bug 186920 in launchpad-bazaar "bzr launchpad does not handle proxy when used for name resolution " [Undecided,New] https://launchpad.net/bugs/186920 | 18:00 |
| jam | And I linked: http://bugs.python.org/issue648658 | 18:00 |
| jam | chadmiller: ping me if you understand/don't understand what I mentioned | 18:01 |
| chadmiller | jam, thanks. I will. | 18:01 |
| vila | jam: no | 18:03 |
| vila | yeah, the main problem is that david has strange setup, I'm following this bug for ages but never find the time to work o nit :-/ | 18:04 |
| vila | s/has/has a/ | 18:04 |
| vila | jam: dinner time here, I may come back later... or not :) | 18:04 |
| jam | david? | 18:04 |
| jam | vila: eat well | 18:04 |
| vila | jam: david cournapeau, the guy who reported the bug, that's not the first one, its DNS is proxied or something weird like that | 18:06 |
| jam | vila: well, xmlrpclib doesn't do proxying either | 18:06 |
| jam | which I thought was the same bug | 18:07 |
| jam | regardless, I was asking about the xmlrpclib side of things :) | 18:07 |
| jam | but still, don't let me interrupt food | 18:07 |
| awilkins | jelmer: bzr-svn is getting my standard baptism of fire ; branching a 13880 revision trunk with over a GB of content | 18:37 |
| awilkins | jelmer: We shall have to see how it manages. | 18:37 |
| jam | vila, is bug 265070 just another 'redirection handling' bug? | 18:37 |
| ubottu | Launchpad bug 265070 in bzr "PathNotChild: Path "http://url" is not a child of path "http://jakob@url": user name mismatch" [Undecided,Fix committed] https://launchpad.net/bugs/265070 | 18:37 |
| jelmer | awilkins, ah, cool | 18:38 |
| awilkins | jelmer: One little thing ; the lib "dav" is "neon" in 1.5 | 18:38 |
| jelmer | awilkins, did you see bug 263570 ? | 18:38 |
| ubottu | Launchpad bug 263570 in bzr-svn "bzr-svn cannot be compiled for Subversion 1.5.* without hand-editing setup.py" [Undecided,New] https://launchpad.net/bugs/263570 | 18:38 |
| awilkins | That's the "dav is now neon" thing | 18:39 |
| awilkins | I hand-edited it and replaced "libsvn_ra_dav-1" with "libsvn_ra_neon-1" | 18:40 |
| awilkins | awilkins: Then I went back and built it for 1.4.6 after you patched it | 18:40 |
| jelmer | awilkins, any chance you can confirm this patch doesn't break anything for you? | 18:41 |
| jelmer | I'd like to apply it for the next release, preferably without breaking anything :-) | 18:41 |
| awilkins | jelmer: I'll run the test suite and post you the log now | 18:41 |
| jelmer | I also fixed compatibility with svn 1.4 on windows, btw | 18:41 |
| awilkins | jelmer: I'm not sure how necessary that is, but it's welcome | 18:42 |
| awilkins | jelmer: The WC library is never used to touch a "real" SVN WC AFAIK, so the nasty "upgrade" doesn't happen | 18:42 |
| awilkins | jelmer: Heh, the "hell branch" has just finished caching metadata | 18:43 |
| awilkins | Fetching the highly nsaty first revision | 18:44 |
| awilkins | This is a really good test corpus because the repo layout has really been screwed around with (or a bad one, depending on your viewpoint :-) ) | 18:44 |
| jelmer | awilkins, if it's not performing well enough, you may want to try trunk | 18:44 |
| awilkins | jelmer: It's not leaking loads of memory, so that's good (so far) | 18:45 |
| awilkins | 6/9699 and rising | 18:45 |
| awilkins | What does trunk do that 0.4 doesn't ? | 18:46 |
| jelmer | it's more performance tuned | 18:47 |
| awilkins | jelmer: 30 revisions and still not many positive memory delta above r 1 ; I'm optimistic | 18:48 |
| jelmer | ah, great | 18:52 |
| awilkins | jelmer: Impressive, it's rock steady - the odd blip for a big revision (eats 140MB plus and then dumnps it all) | 18:52 |
| awilkins | Then right back down to 308,732KB | 18:52 |
| jelmer | back in ~30 min | 18:53 |
| awilkins | I'll switch to trunk and run the test suite again | 18:54 |
| === mw is now known as mw|food | ||
| vila | jam: there is no redirection bug I'm aware of :-) The code has just bitrotten from the days it was used the first access which was always for the branch format. But now the hpss probing changed the context a bit and things are a bit blurry :) | 19:35 |
| vila | I'm missed bug #245964 at the time, but I what is this Michael's change you're referring to ? | 19:36 |
| ubottu | Launchpad bug 245964 in bzr "nosmart+http interacts badly with http redirects" [High,In progress] https://launchpad.net/bugs/245964 | 19:36 |
| vila | s/I'm/I've/ s/I what/what/ | 19:36 |
| jam | vila: your sed expression is harder to parse than the original :) | 19:37 |
| vila | exactly my thought :) | 19:37 |
| vila | see ? redirection is hard for brain :) | 19:37 |
| === mark1 is now known as markh | ||
| jam | and yes, that is the patch I'm talking about | 19:58 |
| jam | The specific bug(s) are than nosmart+... fails to remember "nosmart+" and it seems that "http://user@host" fails to remember the "user@" during the redirect. | 19:59 |
| jam | "are that" | 19:59 |
| jelmer | awilkins, thanks for the update | 20:04 |
| jelmer | I've fixed TypeError: rcvr() takes exactly 4 arguments (3 given) | 20:04 |
| jelmer | in the 0.4 branch | 20:04 |
| awilkins | jelmer: Now at 4912/9699 and detecting some memeory ;leakage | 20:09 |
| awilkins | back in a mo | 20:09 |
| === mw|food is now known as mw | ||
| abentley | jelmer: Do you know what the the current status of gnome-to-bzr imports is? Where it's happening, and who's doing it? | 20:41 |
| jelmer | abentley, jc2k and thumper are the main people responsible afaik | 20:41 |
| jelmer | abentley: it's on http://bzr-mirror.gnome.org/ | 20:42 |
| abentley | jelmer: Cool | 20:43 |
| abentley | Thanks. | 20:43 |
| * Jc2k looks in | 20:44 | |
| Jc2k | abentley: there are 2 independant mirrors, mine is on bzr-mirror.gnome.org (and also does a git and mercurial mirror). bzr-playground.g.o is looked after by canonical | 20:45 |
| Jc2k | abentley: so maidenhead and.. i think london?? for where | 20:45 |
| abentley | Jc2k: "where" meant URL :-) | 20:46 |
| abentley | I'm confused. I thought that Canonical was taking over from you. | 20:46 |
| Jc2k | some how we ended up with 2 mirrors :) | 20:47 |
| abentley | Jc2k: We should straighten this out. I'll poke thumper next time I talk to him. | 20:48 |
| Jc2k | abentley: im meant to be involved in playground somehow (thumper says im meant to have some kind of admin rights on the box) | 20:48 |
| abentley | Jc2k: I ask because someone just wanted to get Launchpad to import http://svn.gnome.org/viewvc/seahorse/seahorse-plugins/trunk | 20:48 |
| abentley | And I figure that would be counterproductive. | 20:49 |
| abentley | Could you set such a mirror up? | 20:49 |
| Jc2k | it will happen automatically on bzr-mirror | 20:49 |
| Jc2k | if it hasnt already | 20:49 |
| Snaury | hey jelmer, so what about my 1.4/1.5 patch? does it have any problems? | 20:49 |
| Jc2k | hmm hasnt already | 20:49 |
| jelmer | Snaury, Nope, it all looks fine to me now | 20:50 |
| jelmer | Snaury, I was hoping awilkins can test it as well, after that I'll merge it | 20:50 |
| Snaury | ah, ok. | 20:50 |
| Snaury | I didn't realize Internet Explorer could screw patch filename like that. :-/ | 20:51 |
| Jc2k | oh | 20:51 |
| eean | how do you checkout a tag? | 20:51 |
| jelmer | Snaury, thanks for these patches, btw! | 20:52 |
| Jc2k | abentley: so, i think its a bzr-svn 'bug'... | 20:52 |
| Snaury | You're welcome. :) | 20:52 |
| jelmer | eean, try "bzr branch -rtag:<name-of-tag> <url>" | 20:52 |
| abentley | Jc2k: May I have your email address so that I can direct Andreas Moog to you? | 20:52 |
| jelmer | Jc2k, ? | 20:52 |
| Jc2k | abentley: there is no mirror of it because bzr-svn only handles trunk/branches/tags... | 20:52 |
| Jc2k | jelmer: seahorse has trunk, branches, tags, seahorses-plugins | 20:53 |
| jelmer | Jc2k, it will handle that by default - are you specifying a branching scheme explicitly perhaps? | 20:53 |
| Jc2k | no... | 20:53 |
| eean | jelmer: can I switch the current checkout? | 20:53 |
| Jc2k | abentley: john.carr@unrouted.co.uk, and #gnome-bzr on irc.gnome.org :) | 20:53 |
| jelmer | eean: "bzr pull . -rtag:<tag-name>" | 20:54 |
| jelmer | Jc2k, strange | 20:54 |
| eean | "No revisions to pull." | 20:54 |
| jelmer | Jc2k, ah, it uses two branching schemes | 20:54 |
| Jc2k | jelmer: yes | 20:54 |
| jelmer | Jc2k: so you'll need two separate svn-import commands | 20:55 |
| Jc2k | jelmer: i'd prefer to do surgery and make seahorse-plugins a seperate repository.. | 20:55 |
| Jc2k | jelmer: because i hate special casing the mirror | 20:55 |
| jelmer | "bzr svn-import --scheme=trunk" and "bzr svn-import --trunk1 svn://svn.gnome.org/svn/seahorse/seahorse-plugins/" | 20:55 |
| jelmer | s/--trunk1/--scheme=trunk1/ | 20:56 |
| Jc2k | :) | 20:56 |
| jelmer | Jc2k, yeah, splitting it out may be a better idea | 20:57 |
| Snaury | jelmer: btw, what bzr rebase does when I have merges in my diverged branch? | 20:57 |
| jelmer | Snaury, in the branch you're rebasing you mean? | 20:57 |
| Snaury | jelmer: yes. I might be wrong, but I think I might have lost some merges in the past by just doing bzr rebase. Poof and merge is gone, only direct commits were left. I'm not sure if I'm not mistaking though, I'll try reproducing it now. | 20:58 |
| jelmer | it will skip merge revisions if the changes they merged were already merged upstream (unless --always-rebase-merges is specified) | 20:58 |
| jelmer | if the revision was not merged in upstream, it will rebase the changes as it does with regular revisions and keep the information about the revisions that were merged | 20:59 |
| jelmer | Snaury, does that help? | 20:59 |
| eean | sheesh checking out a new tag takes like an 10 minutes | 21:01 |
| eean | from locally | 21:01 |
| jelmer | eean, that doesn't sound right, it should just be changing the tree | 21:01 |
| jelmer | eean, did you specify the . ? | 21:02 |
| beuno | eean, you need shared repos | 21:02 |
| eean | I had to do bzr branch -rtag:mysql-5.1.26 mysql-server/ mysql-server-5.1 | 21:02 |
| eean | the bzr pull didn't work | 21:02 |
| jelmer | eean, perhaps specify --force to bzr pull | 21:02 |
| Snaury | jelmer: yes, so maybe I was just mistaken. :) I have pretty weird trees, maybe I applied the same change in both trees, or something else. Weird... | 21:02 |
| eean | logically a pull command wouldn't work | 21:02 |
| eean | its not what a pull is for :P | 21:02 |
| * jelmer wished "bzr switch" would accept a -r argument | 21:02 | |
| eean | bzr checkout should accept a tag | 21:03 |
| eean | that would make sense to me | 21:03 |
| jelmer | eean, I agree | 21:03 |
| eean | your not really switching branches if you checkout a tag | 21:03 |
| jelmer | eean, that would mean switching the master branch to that tag as well though | 21:03 |
| eean | or bzr branching shouldn't be so slow, then it wouldn't matter. | 21:04 |
| vila | jam: I don't think the user should be remembered during a redirect... it could even return an ftp:// url | 21:06 |
| vila | the root problem problem underlined by the FIXME is that we are not able to reliably put back the bzr decorators (http+pycurl and now nosmart) | 21:07 |
| vila | another root problem is that we don't try to reuse the transport at the point (get_transport() with no possible_transports | 21:08 |
| vila | and finally the real root, IMHO, is that nosmart+ was meant to disable the hpss probing under specific circumstances and that people now use it a bit more freely | 21:09 |
| jam | vila: well, smart + bzr-svn interacted poorly, IIRC | 21:10 |
| jam | so people tried no-smart | 21:10 |
| vila | but yes, indeed, there are redirections bugS now | 21:10 |
| jam | as for remembering user@ or not... if it is on the same host, under the same scheme, it seems reasonable to keep it | 21:10 |
| jelmer | jam, nosmart will not work with bzr-svn | 21:11 |
| vila | jam: get_transport() will reuse it indeed.. if possible_transports gives the hint | 21:12 |
| vila | hmm, it may need a bit of help regarding user :-) | 21:13 |
| === jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.6.1 now available ! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| Snaury | jelmer, I was just able to reproduce this. bzr rebase really drops some merges. | 21:35 |
| Snaury | jelmer, try this: http://pastebin.ubuntu.com/43735/ | 21:35 |
| Snaury | by the end of the script myrepo/remote-branch-df will have no trace of any changes to 1.txt (which was in the merge). | 21:36 |
| Snaury | That's what happened to me once. | 21:36 |
| Snaury | I'm using http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/ revno 105 | 21:37 |
| jelmer | Snaury, Thanks, I'll see if it's expected behaviour | 21:43 |
| jelmer | Snaury, Sorry, I was wrong about the merge behaviour | 21:51 |
| jelmer | it will just skip all merges | 21:51 |
| Snaury | :( | 21:51 |
| jelmer | since it's hard to be smart about them | 21:51 |
| jelmer | Snaury, you can use --always-rebase-merges though | 21:51 |
| Snaury | jelmer: just tried that. in my example --always-rebase-merges doesn't change anything. | 21:53 |
| Snaury | jelmer: but it's different now. the merge was rebased, but the revision is completely empty(!) | 21:53 |
| jelmer | Snaury, hmm, I can reproduce that | 21:54 |
| jelmer | Snaury, please file a bug | 21:54 |
| Peng_ | jam: Congrats on the release. :) | 22:00 |
| jam | thanks Peng_ | 22:00 |
| vila | jam: You released 1.7 ? | 22:00 |
| jam | vila: 1.6.1 | 22:00 |
| vila | jam: kidding :-) | 22:00 |
| jam | /topic | 22:00 |
| jam | 1.7rc1 will be monday | 22:01 |
| jam | so I had to get 1.6.1 out the door :) | 22:01 |
| AmanicA | thanks jam for your persistence with 1.6! | 22:01 |
| vila | I *know* :-) I was just finishing reading your mails about your feelings about the 1.6 release ans I was trying to make you smile | 22:01 |
| AmanicA | I also just finised reading that thread :) | 22:02 |
| Snaury | jelmer: see bug #266897 -- I even reduced the test case, it doesn't matter if there's another commit after the merge or not. | 22:04 |
| ubottu | Launchpad bug 266897 in bzr-rebase "bzr-rebase loses merges" [Undecided,New] https://launchpad.net/bugs/266897 | 22:04 |
| Snaury | *test case -> test script | 22:04 |
| jelmer | Snaury, thanks | 22:06 |
| jam | AmanicA, vila: Thanks for your support. Now where were you during 1.6rc3-5? :) | 22:15 |
| vila | jam: hmmm, partly in vacations and partly working like crazy to finish my old job :-D | 22:16 |
| AmanicA | jam: I was away on holiday in europe | 22:16 |
| vila | And even if I have been relatively silent these past days, I *did* work on "broken" (by platform) tests and I did my best to triage bugs (we are close to ~200 new bugs *only <cough>*) (learning a lot in the process. Far more than I can show right now), so I supported you more than you know :) | 22:21 |
| jam | vila: you've been on the 'good' side of the process :) | 22:24 |
| vila | jam: as for the reviews... Well, I plead gulty with mitigating circumstances (sp? blame google :), I didn't feel pertinent enough on the subjects :-/ | 22:24 |
| vila | LOL | 22:24 |
| jam | Though I will say you know a lot more than you think you do | 22:25 |
| jam | and you probably *should* be at least looking at the patches | 22:25 |
| jam | so as to familiarize yourself with it | 22:25 |
| jam | anyway, I'm done for the weekend | 22:25 |
| jam | I'll catch you all on Monday | 22:25 |
| vila | Oh, I looked at many.... | 22:25 |
| vila | sure, enjoy your week-end ! | 22:25 |
| AmanicA | cheers | 22:25 |
| Odd_Bloke | vila: Where are you working now? | 22:38 |
| === Snaury is now known as Snaury[away] | ||
| dato | hi guys, I thought I'd just come by to say farewell. I'm trying to cut down the number of irc channels I'm in, and I think it's time to say good-bye to this one. I'm sorry that I've finally abandoned bzr, but I wish you the best of luck. | 23:25 |
| dato | lifeless: sorry I never got to comment on the thread you asked me to, things have been hectic (in a good way), and I'm afraid I must cross it off my TODO list with "ENOTIME". | 23:26 |
| mwhudson | yay for fixing #237067 | 23:33 |
| AmanicA | bug #237067 | 23:34 |
| ubottu | Launchpad bug 237067 in bzr "RemoteBranch.lock_read() doesn't lock the underlying repository" [High,Fix committed] https://launchpad.net/bugs/237067 | 23:34 |
| AmanicA | (just wanted to see what it is :) | 23:34 |
| jelmer | dato: Sorry to see you leave here :-( | 23:35 |
| jelmer | dato: Keep up the good work, I guess I'll see you around in some other channels :-) | 23:35 |
| AfC | Oh, that's just charming: upgrade the format of a share repository, and then in one its branches `bzr info` reports Repository tree (format: unnamed) | 23:38 |
| mwhudson | i think you get that when the branch format and the repository format together don't have a name | 23:40 |
| AfC | Well is it "bad"? | 23:41 |
| mwhudson | (1.6 == branch7 and packs5, i think) | 23:41 |
| mwhudson | it's unfortunate | 23:41 |
| AfC | uh huh | 23:41 |
| * AfC is getting a little tired of all these formats and variants. Surely a) Bazaar could upgrade itself, and b) it could enable subtrees or rich-root or whatever if it needs it. | 23:42 | |
| AfC | Why should a user ever have to run `bzr upgrade`? | 23:42 |
| nDuff | AfC, users can reasonably want to control when upgrades happen to allow older clients to be supported until their IT departments are ready to upgrade everyone. | 23:54 |
| nDuff | AfC, silently doing upgrades when features require them can create unexpected compatibility issues with other users running older clients. | 23:54 |
| AfC | "IT department"? These are _developers_ we're talking about. This isn't a corporation wide rollout of some office suite. | 23:55 |
| * nDuff was involved in a startup using bzr with a very non-IT-proficient web design staff. | 23:55 | |
| nDuff | AfC, not everyone who uses a revision control system is a developer | 23:55 |
| nDuff | AfC, and (sad as it is) not all developers know how to maintain their own systems (or are granted the rights to do so). | 23:56 |
| AfC | nDuff: so compatibility issues, fine, but it would be nicer for the rest of us if that sort of thing was turned on explicitly, rather than the bulk of the user universe having to deal with the insane mess that is bzr help init-repo | 23:56 |
| nDuff | AfC, anyhow, even if you *were* a developer-only shop, you wouldn't want one person running all the latest RCs to force everyone else to upgrade to an unstable version early, yar? | 23:56 |
| AfC | nDuff: right. So some branch.conf flag says "don't auto upgrade me". Easy | 23:57 |
| AfC | nDuff: (and yes, I would assume transparently taking care of shit like that would only upgrade at releases, etc) | 23:57 |
| AfC | [Reading the 1.6.1 release note blew my mind] | 23:57 |
| AfC | [certainly the fact that it cited "and if you've only been using releases you're ok" is a point in my argument] | 23:58 |
| AfC | [but exposing an argument that is called "--1.6.1-rich-root"? Come _on_] | 23:58 |
| fullermd | Well, it could be worse; it could be called 'star-merge' or something... | 23:59 |
| nDuff | heheheh. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!