| spiv | Morning folks. | 01:19 |
|---|---|---|
| poolie | hi spiv | 02:28 |
| poolie | my turn to flip from waking at 3 to waking at 10 :) | 02:28 |
| === idnaria is now known as idnar | ||
| spiv | Heh | 02:34 |
| poolie | lifeless: i don't totally understand your comment in https://code.launchpad.net/~gagern/bzr/bug421776-sftp-move/+merge/62708 | 05:44 |
| ubot5 | Ubuntu bug 62708 in bluefish (Ubuntu) "Please sync bluefish_1.0.6-1 from Debian unstable (main)" [Wishlist,Fix released] | 05:44 |
| lifeless | poolie: we don't know the provenance of the existing file | 05:44 |
| poolie | hm | 05:45 |
| poolie | we can safely assume it came from another bzr process? | 05:45 |
| poolie | we don't know whether that process is still running, dead, etc | 05:45 |
| lifeless | right | 05:45 |
| poolie | so...? | 05:46 |
| lifeless | I would be wary of assuming the file matches what we're uploading | 05:47 |
| poolie | if it exists, the process that wrote it thought it was correct at the time it finished writing | 05:47 |
| poolie | it may have been wrong (buggy) | 05:47 |
| poolie | or there might have been file corruption | 05:47 |
| lifeless | true. And either that process failed to link it in, failed to unlink it, died, or raced with us on linking it in and did so immediately before we last read the pack list | 05:48 |
| poolie | but, those possiblities don't seem any more likely here than for any other existing pack file | 05:48 |
| lifeless | well | 05:48 |
| lifeless | Call me conservative :) | 05:48 |
| poolie | if you're asserting for example "a race means it's more likely the file suffered corruption" that's fine, i'm happy to consider it | 05:49 |
| poolie | i just want to understand what you're saying | 05:49 |
| lifeless | I couldn't really put a probability on it | 05:50 |
| lifeless | but I would worry about trusting something that may have crashed when we don't have to | 05:50 |
| poolie | ok | 05:51 |
| lifeless | for instance | 05:51 |
| lifeless | if the machine powered off, without ordering between file renames etc, we might have a zero length file with the right name, not linked into pack-names | 05:52 |
| poolie | yes, that's very possible | 05:53 |
| poolie | it's also possible it would end up showing it mentioned in pack-names and yet also have the wrong content | 05:53 |
| lifeless | yes | 05:53 |
| poolie | so, being extra careful in this case seems a bit odd | 05:53 |
| lifeless | uhm | 05:54 |
| lifeless | this doesn't seem like being extra careful | 05:54 |
| poolie | you say "we should check if the existing file is intact" | 05:54 |
| lifeless | once its in pack names (in the absence of attackers) we know that the prior bzr process completed | 05:55 |
| poolie | i don't understand why we would do that over sftp but not locally | 05:55 |
| lifeless | we don't know if the fs went awol or not | 05:55 |
| lifeless | poolie: we would do it locally too, wouldn't we ? | 05:55 |
| poolie | hang on, "we know that the prior bzr process | 05:55 |
| poolie | completed" --> that's not true if the machine crashed without an ordered journal of renames | 05:56 |
| poolie | aiui this bug is sftp specific, about the general pack upload code not working the same way over sftp | 05:56 |
| poolie | imbw | 05:59 |
| poolie | i'm going to read the general pack code | 05:59 |
| lifeless | poolie: so IIRC locally we rename over the top | 05:59 |
| lifeless | we resolve by assuming our new file is correct - which is the ultimate form of lack-of-trust | 06:00 |
| lifeless | so this case (which for -very- narrow windows win32 might display too) is when we cannot atomically rename over the top | 06:00 |
| lifeless | and we don't have a safe rename-out-of-the-way dance that others could use to handle the file-is-temporarily-missing case | 06:01 |
| poolie | right, we do | 06:01 |
| poolie | ok, so using .move (which really means, force replace) would be most consistent with what we do locally | 06:03 |
| lifeless | yes | 06:03 |
| lifeless | I was suggesting a verification scan (for the pack and the indices) as a workaround to deal with the race condition. | 06:04 |
| poolie | in other words you like his current patch? | 06:04 |
| lifeless | uhm, I think its evolved since I commented | 06:04 |
| poolie | yes | 06:05 |
| poolie | perhaps rather than delete-and-replace we should move the existing pack into the obsolete directory, so if we're interrupted after deleting it, we won't lose | 06:05 |
| lifeless | so move has this race condition | 06:05 |
| lifeless | I don't particularly like that :) | 06:06 |
| lifeless | I don't want to block anyone | 06:06 |
| lifeless | I was trying to highlight the interacting constraints | 06:06 |
| poolie | don't like moving it to obsolete-packs? | 06:07 |
| poolie | thanks for the review | 06:07 |
| poolie | i do appreciate it | 06:07 |
| poolie | am just trying to understand it :( | 06:07 |
| poolie | s//:) | 06:07 |
| poolie | so there is actually an sftp rename operation argument saying what behaviour you want | 06:08 |
| lifeless | ideally we'd make it behave like a local fs :) | 06:08 |
| poolie | hm | 06:09 |
| poolie | seems there is possibly a small race on windows too, if we delete then rename | 06:10 |
| poolie | ok, thanks for that | 06:16 |
| lifeless | its possible to address the race by having a predictable path to look for fallback files | 06:17 |
| lifeless | or even just spin on the path in clients | 06:17 |
| poolie | in the hope it will appear again soon? | 06:17 |
| lifeless | right | 06:18 |
| poolie | right | 06:18 |
| poolie | they're probably separate bugs | 06:18 |
| lifeless | but if its linked in pack-names | 06:18 |
| lifeless | I think you need 2 paths - a normal one and a before-naming-into-place one | 06:18 |
| poolie | for here, i think asking sftp to overwrite, and forcing the overwrite, is probably safe | 06:18 |
| lifeless | so that repo recovery can do something sensible | 06:18 |
| poolie | s/safe/an improvement | 06:18 |
| lifeless | I think we have retry-on-missing-packs now | 06:18 |
| lifeless | I worry about a network interrupt during that race though | 06:18 |
| lifeless | how will the repo be recovered | 06:19 |
| poolie | right, i'm most concerned by the connection dropping (or the server crashing) after it applies the deletion but before the new file moves into place | 06:19 |
| poolie | spiv, teddy, should i actually do a patch for jml's try_import? | 06:26 |
| poolie | it does clean things up and it should make pylint cleaner | 06:26 |
| poolie | bit of an optional yak though | 06:27 |
| poolie | (there are something like 100 'except ImportError' catches at present) | 06:27 |
| jam | poolie: after it deletes but before it renames, is probably before we write pack-names | 07:20 |
| jam | I was concerned at one point, but now... locally we overwrite on posix systems | 07:20 |
| jam | and I think "crash" on Windows | 07:20 |
| jam | it seems fine to overwrite on remote systems *without* validation | 07:20 |
| jam | becuase we justuploaded content *we* are happy with | 07:20 |
| jam | who cares if there is unreferenced garbage that we get rid of | 07:20 |
| jam | corrupted or not | 07:20 |
| jam | we aren't re-instating the pack file that we think was corrupted | 07:21 |
| jam | "might have been" | 07:21 |
| poolie | right | 07:21 |
| jam | we are putting the new hottness there | 07:21 |
| poolie | right | 07:22 |
| poolie | hello btw | 07:22 |
| jam | The only race I can think of is 2 processes both renaming into place, and being ready to update pack-names. p1's rename succeeds so it goes to write pack-names | 07:22 |
| jam | p2 sees the collision, renames out of the way | 07:23 |
| jam | then p1 writes pack-names, and the machine crashes | 07:23 |
| jam | before p2 finallizes its insert | 07:23 |
| jam | poolie: but, a) I think sftp rename dance does try to preserve the old file as a .tmp | 07:24 |
| poolie | so you could possibly manually recover | 07:25 |
| poolie | hm, fancy_rename asserts sftp rename won't let you overwrite | 07:25 |
| poolie | perhaps either we didn't know of that option, or it wasn't supported then | 07:26 |
| poolie | or still isn't supported by servers | 07:26 |
| poolie | so it sounds like you're ok with my last comment | 07:26 |
| vila | hi all | 07:27 |
| jam | poolie: "rename" is intentionally for lock/held directories | 07:27 |
| jam | we don't want to overwrite dirs that aren't empty | 07:27 |
| jam | that happened accidentally on some sftp implementations, like launchpads | 07:27 |
| jam | move is the "rename according to posix" | 07:27 |
| vila | poolie, jam: Sounds like another concurrency testing case, how about trying the no-threads approach there to see how it works ? | 07:28 |
| jam | vila: in this case, a callback at the right time seems very appropriate, because it is *very* sensitive to timing | 07:28 |
| vila | that's why I suggest trying it | 07:30 |
| jam | poolie: I'm checking your comments. | 07:42 |
| jam | vila: I think there is a hole, I'm not sure it is worth fixing | 07:42 |
| poolie | hi vila | 07:42 |
| poolie | i agree using a callback and no threads would be good | 07:43 |
| poolie | vila i will try to reply to your opus | 07:43 |
| jam | poolie: I believe the stardand secsh spec is actually 3, at least back when I was researching it a lot, you couldn't guarantee support for anything newer | 07:44 |
| vila | poolie: not urgetn, I'd rather be unblocked on the reviews (well, unless they are tied) | 07:44 |
| jam | there were some file open apis and some remote hash apis that would have been promising at th etime | 07:44 |
| jam | anyway, if we wanted to change Transport.move() to try to use that flag, i'm for it | 07:44 |
| jam | but *not* Transport.rename | 07:44 |
| poolie | jam btw you're pp this week | 07:44 |
| jam | poolie: yep | 07:45 |
| poolie | vila, i think the reviews are unblocked | 07:45 |
| jam | for sftp we don't want to overwrite a held/info directory that already exists | 07:45 |
| poolie | i would really rather the tests were not threaded | 07:45 |
| poolie | but i won't absolutely block them | 07:45 |
| poolie | otoh it seems easy to change them | 07:45 |
| poolie | jam, right, the directory overwrite behaviour is very important it not change | 07:45 |
| vila | meh, neither one got a vote, am I being too conservative reading the comments ? | 07:46 |
| poolie | vila, i guess i'd put it in a similar case to tests that use subprocesses: use it if you have to, but if we end up doing it a lot something may be wrong, and we don't want to set a pattern of doing it | 07:46 |
| jam | vila: I think the reason I haven't been faster at approving stuff is that I'm still pretty uncomfortable with lots of little bits across the whole stack. Which doesn't give me confidence in any given piece. | 07:48 |
| jam | I do realize that you've had your head in it more | 07:48 |
| vila | I agree with the principle, but I don't feel it applies to a case where tests were copied before you raised the issue | 07:48 |
| poolie | vila, i think i meant them both to be +tweak | 07:48 |
| jam | so I'm willing to defer to your focused insight where it matters | 07:48 |
| poolie | vila i think this is kind of showing the cost of landing goes up more than linearly | 07:48 |
| poolie | with the size | 07:48 |
| poolie | otoh some things perhaps can't be done piecewise | 07:48 |
| jam | I think I like the idea in broad terms | 07:49 |
| vila | poolie: you mean that splitting this work in smaller pieces didn't help ? | 07:49 |
| poolie | hm, not sure | 07:49 |
| poolie | this was a bit like: write one big thing; chop it up; propose all the pieces | 07:50 |
| poolie | as opposed to proposing smaller bits as you go | 07:50 |
| poolie | but perhaps there are hidden costs to that | 07:50 |
| vila | I think we discussed being a bit less risk averse so I'd delighted to see our policy go more in the direction: this bit is controversial, add A FIXME, address it later, rather than: this bit is controversial, let's reach a consensus before landing it | 07:51 |
| jam | vila: I think I've tried to do that, I think the fact that it seems to come up at most stages concerns me | 07:52 |
| vila | especially when there is not enough energy spent on reaching a consensus by all parties involved | 07:52 |
| jam | (10 stages, and 5 of them have "FIXME" seems a bit odd, if only 1 or 2...) | 07:52 |
| poolie | i think the thing is that when there are many related patches in flight the whole thing gets a bit harder to discuss | 07:52 |
| jam | maybe I'm mis-estimating | 07:52 |
| vila | but if they are all in the same patch they are hard (~impossible) to review | 07:52 |
| poolie | well, there is doing without consensus; and then there is also being more willing to get consensus even on something that's imperfect | 07:53 |
| poolie | personally i like the second concept better | 07:53 |
| vila | the above remarks were general, in this specific case, I've been proposing scaffolding code (and tests) that I think shouldn't be reviewed as strictly as code that will stay (especially tests) | 07:54 |
| vila | I can't reach a point where we can discuss on the end result if I had to constantly refine code I intend to throw away in the end, this start discussions on code that is not there to discuss about | 07:55 |
| jam | vila: having code that you are throwing away in the end is odd, and inconsistent with how we usually do it, hence we don't really know how to act on it. | 07:55 |
| jam | I understand your view point | 07:56 |
| jam | just saying it is coming from a place we don't usually look at | 07:56 |
| jam | hence confusion and delay | 07:56 |
| poolie | right | 07:56 |
| poolie | what's a good example of scaffolding here? | 07:56 |
| poolie | are you talking about code to support apis you intend to get rid of? | 07:56 |
| vila | this a good discussion, I'm not throwing stones, I feel there is several issues and no easy solution, so we should discuss | 07:56 |
| vila | _CompatibleStack, the tests with threads are the most obvious ones | 07:57 |
| vila | the Stores (already have FIXME), the xxxStacks (already have FIXME) | 07:57 |
| poolie | hm | 07:58 |
| poolie | i think generally speaking if there's some code that's a bit ugly or inefficient but there's a comment explaining it will be soon deprecated, people ought to take that into account in reviewing | 07:58 |
| poolie | (they might still think it's too buggy or something) | 07:58 |
| poolie | i think generally "I will throw this out in the future" is not very relevant to reviews | 07:59 |
| vila | I don't think I can implement a full deployment, add new features, provide a migration path and only then break into pieces for review without incurring a huge push back... (not to mention the delay just to reach that) | 07:59 |
| poolie | because it's hard to know for sure that you actually will come back to do it | 07:59 |
| poolie | something more important could come up next week, or you could get sick or whatever | 07:59 |
| vila | yup, it's hard to know | 07:59 |
| poolie | so they need to make sense individually | 07:59 |
| vila | which is why I insist on putting a name and a date in FIXMEs | 07:59 |
| poolie | shrug, there are named dated fixmes from years ago | 08:00 |
| poolie | it's a good practice but it is no guarantee they'll be fixed | 08:00 |
| poolie | we should be ok with stepwise refinement; promises it'll be better in future are really not that important imo | 08:00 |
| vila | I think it's better than not putting them | 08:01 |
| poolie | the fixme comments? | 08:01 |
| vila | yes | 08:01 |
| poolie | i agree they're good | 08:01 |
| vila | and my goal for config is to have none of them left in config.py | 08:03 |
| vila | (I just review them and I strongly confirm) | 08:03 |
| vila | so it's hard for me to buy the "you won't fix it" argument there and instead it makes my life harder to fix them *now* | 08:04 |
| vila | which I think is close to the root cause of my frustration there | 08:04 |
| poolie | hm | 08:05 |
| poolie | well, it's good to talk it over | 08:05 |
| poolie | one way to look at it, which might be oversimplified | 08:05 |
| poolie | is that there are things that must be fixed before landing; and things that don't need to be | 08:05 |
| poolie | we should be careful where we draw the line | 08:05 |
| poolie | but, if something really is in the first class, then it actually must be fixed; an earnest intention to do it later is by definition not enough | 08:06 |
| vila | right, I generally tend to fix things I don't fully agree with to make landing easier, if I don't intend to fix quickly, I file bugs or add FIXMEs, the distinction between the two may not be clear enough as sometimes I use FIXME for issues that are so big I don't even have a good answer for them | 08:08 |
| vila | or are so unrelated to the proposal I just punt to avoid falling into yak-shaving mode | 08:09 |
| jam | poolie: correct. Though if enough of "doesn't need to be fixed before landing's it gives some unease about the stack | 08:10 |
| vila | like 'external_url should accepts an optional relpath' where the implications are all over the place | 08:11 |
| vila | ha, no, I filed a bug for this one :) | 08:11 |
| poolie | jam what do you mean "about the stack"? | 08:11 |
| vila | the whole config work | 08:11 |
| poolie | so, i haven't reviewed every branch | 08:12 |
| jam | poolie: the stack of changes that are being proposed. If you have 5 patches pending, and each one has a FIXME or 2, it makes (at least me) concerned | 08:12 |
| poolie | i think on the whole, having a bunch of branches that possibly interacts, or possibly fix some problems in lower layers | 08:12 |
| poolie | it's actually harder to review than just one big patch | 08:12 |
| jam | Sometimes unnecessarily so. | 08:12 |
| poolie | possibly this is partly a bug inlp | 08:12 |
| poolie | jam, right | 08:13 |
| poolie | also it's harder to see what the actual eventual big picture will be | 08:13 |
| jam | poolie: I think it depends on how inter-related the stack of patches is. | 08:13 |
| jam | sometimes layering can easily separate out bits | 08:13 |
| vila | also, the approach I tool was to (try to) minimize the scaffolding so adding each piece can raise its own issues (say: lock remote config files currently ignores control.conf which is used only on lp but doesn't have (AFAIK) corresponding tests to exercise against) | 08:13 |
| poolie | probably | 08:13 |
| jam | but if a later patch modifies *the same code* | 08:13 |
| jam | then it isn't really separated | 08:13 |
| vila | I tried to use devnotes to track the big picture, but the issue here is that it conflates know issues with solutions that requires new features and I'm only at the no-new-features replacement stage :-/ | 08:14 |
| * vila nods about higher threads fixing issues in lower threads | 08:14 | |
| vila | that makes reviewers life hard | 08:14 |
| poolie | i'd like to be tracking it against a doc in the developer guide | 08:15 |
| poolie | i'm not sure which active branch, if any, might be adding or updating that | 08:15 |
| poolie | is there one? or is it landen? | 08:15 |
| vila | on the other hand, the past experience with big patches is there to demonstrate this doesn't work either so I had to try something else which we are debugging right now :-} | 08:15 |
| poolie | also, that's an issue with having a stack of patches | 08:15 |
| poolie | you can't easily see the overall change to some thing | 08:15 |
| poolie | (couldbe fixed with tooling, or even just having an overall integration branch) | 08:16 |
| poolie | vila, so, i don't know | 08:19 |
| poolie | it would be good to work out how to make this less frustrating | 08:20 |
| vila | https://code.launchpad.net/~vila/bzr/new-config/+merge/56887 ? | 08:20 |
| poolie | i feel it's a bit hard to see the big picture | 08:21 |
| vila | right, so, do you confirm you're ok to land the current branches ? | 08:22 |
| vila | The good thing I see in this approach is that we get rid of agreed upon code with some pieces still needing work | 08:22 |
| vila | at least it becomes possible to make independent proposals for these pieces | 08:23 |
| vila | As a reviewer myself, I prefer a smaller followup than a bigger proposal | 08:23 |
| poolie | so to me the thing that seems to work best is to just have one mp at a time, make it self contained (both without introducing new serious problems, and hopefully also improving something) and then do a series of those | 08:23 |
| vila | Sometimes it means *I* should do the followup though... | 08:24 |
| poolie | is new-config current as the overall thing, or have the others moved? | 08:24 |
| poolie | because i feel like that diff is not so big as to be impossible to review | 08:24 |
| vila | argh, but the current series was pushed to the point I could actually present a use case because people weren't seeing how the lower threads will work ! | 08:24 |
| poolie | and it would address this thing of not having an overall picture | 08:24 |
| vila | let me check | 08:25 |
| poolie | hm | 08:25 |
| vila | hmm, it seems to be current (in my local loom) , tip is pushed, but lp diff is bogus :-( | 08:26 |
| poolie | re the issue of not seeing how lower levels will work | 08:26 |
| poolie | i think | 08:26 |
| poolie | it's not necessary to see them used from code | 08:26 |
| poolie | but i would look for, either it makes the current code at that level cleaner by refactoring it | 08:27 |
| poolie | or, at least the cover letter can tell a story about how introducing this will later let us do a particular thing | 08:27 |
| poolie | a prose description of what you're steering for would i think be enough | 08:27 |
| vila | hmm, you mean something with a restricted target compared to devnotes ? | 08:28 |
| poolie | what's a good example | 08:28 |
| vila | of what ? | 08:29 |
| poolie | anyhow "weren't seeing how the lower threads will work" --> I think just a good cover letter should be able to solve this; we don't need hundreds of lines of code | 08:29 |
| poolie | example of not seeing how the lower levels will work | 08:29 |
| vila | well, the weakref branch ? | 08:31 |
| vila | the _compatibleStack ? | 08:32 |
| poolie | can you give me the url? | 08:32 |
| poolie | so your current-config is everything merged in together? | 08:33 |
| vila | https://code.launchpad.net/~vila/bzr/config-lock-remote/+merge/62418 | 08:33 |
| vila | poolie: don't know yet, waiting for lp to refresh | 08:33 |
| vila | right, looks better, n oidea about the conflicts though... | 08:34 |
| poolie | for instance, in that branch, i'd like to know whether there is developer documentation of .unload() | 08:34 |
| vila | is the fact that 5 FIXMEs are in red there saying something ? :D | 08:35 |
| poolie | it's not easy to see whether that's true | 08:35 |
| poolie | well, that's good | 08:35 |
| poolie | i guess i could just ask you | 08:35 |
| vila | there is a doc string for unload() | 08:36 |
| poolie | yes | 08:36 |
| vila | argh, self._save() ??? Wtf | 08:36 |
| poolie | which is good | 08:36 |
| poolie | it's a bit like the conversation with jr at the sprint | 08:37 |
| vila | hmm, which one ? | 08:37 |
| poolie | that docstrings i think aren't so good at giving people an overview of what they'resupposed to know about | 08:37 |
| vila | hmpf, you think the actual ones are better ? Not throwing stones again but... I try to improve and I try to not wait for perfection before proposing :D | 08:38 |
| poolie | which actual ones? | 08:39 |
| vila | hehe, exactly :) | 08:39 |
| poolie | you're saying the developer guide is not better than the docstrings at the moment? | 08:39 |
| poolie | well, i don't think we should block your landings on having a perfect developer guide | 08:41 |
| poolie | i think it's reasonable to ask about it | 08:41 |
| spiv | I don't think better/worse is the way to compare the dev guide to the docstrings | 08:41 |
| poolie | and in fact that developer guide content could be a good way to communicate where this is going | 08:41 |
| spiv | They serve different purposes I think | 08:41 |
| spiv | "guide" vs. "reference manual" broadly speaking | 08:41 |
| poolie | right | 08:42 |
| poolie | the guide should tell you where to begin | 08:42 |
| vila | right, I think issues about unload() would be encountered during tests for new Stores rather than by people using them | 08:42 |
| spiv | Unfortunately I have to log off now due to ill wife, but it's an interesting discussion you've been having. | 08:42 |
| poolie | :) | 08:42 |
| poolie | hope she gets better soon | 08:42 |
| vila | spiv: take care of her, there will be logs ;) | 08:43 |
| poolie | i'm sure she'll find that reassuring :) | 08:43 |
| vila | hehe | 08:43 |
| vila | back to the dev guide, just at this minute, I don't know whether it's good or not | 08:44 |
| vila | It may be a bit too soon to put too much effort into it though since I haven't reach the point where I can say: ok, I've been able to deploy for all actual uses (no new features), the Store implementation is complete | 08:45 |
| vila | But at that point, I will be able to write a doc saying: this is how it works, this is what is needed to implement a new one | 08:45 |
| vila | So I'd say a bug is appropriate to track this | 08:46 |
| vila | hmm | 08:46 |
| poolie | hm | 08:46 |
| poolie | i think it's easier to write as you go along | 08:46 |
| poolie | but perhaps i should do a followon patch that tries to explain it, as i understand it | 08:47 |
| * vila falls to his knees | 08:47 | |
| vila | please do so ! | 08:47 |
| vila | That would be so much more productive as far as I'm concerned ! | 08:47 |
| vila | And probably illustrates how I think the reviews should evolve: many comments should just be : blah, blah, if you dont get the picture, look at lp:~bzr/bzr/blah-blah | 08:49 |
| vila | will avoid a bunch of round-trips | 08:49 |
| poolie | ? | 08:50 |
| poolie | what do you mean? | 08:50 |
| vila | followon patches could be done *during* review | 08:51 |
| vila | to the reviewee (sp?) can just merge them | 08:52 |
| gour | speed improvements are main thing arriving in 2.4? | 08:52 |
| vila | a trivial example is spelling mistakes, it's almost as fast to fix them and push a branch for the reviewer, but it avoids a roundtrip for the reviewee | 08:53 |
| vila | well, roundtrips may be more for less trivial stuff but you get the idea | 08:54 |
| poolie | gour: probably the largest thing: http://doc.bazaar.canonical.com/bzr.dev/en/whats-new/whats-new-in-2.4.html | 08:54 |
| vila | a more involved example would be the tests with threads ;-) | 08:54 |
| poolie | vila, yes, and there too lp could handle it a bit better | 08:54 |
| gour | poolie: thanks...i was looking for such doc, but could not find it | 08:55 |
| poolie | arguably we should make some of these branches team-owned so that other people can directly commit to them | 08:55 |
| poolie | perhaps | 08:55 |
| poolie | vila, i'm reading your doc | 08:55 |
| vila | the devnotes one ? | 08:55 |
| poolie | no, the threads mail | 08:55 |
| vila | oh, start with the followup :) | 08:56 |
| poolie | you can just send it to the list if you want | 08:56 |
| poolie | it's a bit rambly | 08:56 |
| vila | and come back to the main one then | 08:56 |
| poolie | i agree that these tests should mostly look like a sequence diagram | 08:56 |
| poolie | that is a good way to express it | 08:56 |
| poolie | so the question then i guess is, what way of writing the test best expresses the sequence diagram | 08:57 |
| poolie | and, which way of writing it is least likely to have accidental problems | 08:57 |
| vila | yup | 08:57 |
| poolie | i think writing it as tests is no clearer (probably less clear); and much more likely to have bad consequences such as hangs | 08:57 |
| vila | I don't think there is a clear cut to favor one above the other | 08:58 |
| poolie | to me it is clear from our experience so far | 08:58 |
| poolie | there are clear tests for concurrency that work in a single thread | 08:58 |
| vila | I've made significant progress regarding hangs (and there really are several kind of hangs, the babune ones are only one) | 08:59 |
| * gour considers that 2.4 will be one very fine release | 08:59 | |
| vila | s//are only one sort) | 08:59 |
| poolie | well, i'm glad, and i appreciate that | 08:59 |
| poolie | but, it's better if we can just avoid the issue | 08:59 |
| poolie | gour :) me too | 08:59 |
| vila | indeed | 08:59 |
| poolie | for instance if you look at test_lockdir | 09:00 |
| poolie | and perhaps as a single example test_20_lock_contested | 09:00 |
| gour | i'm moving full to bzr now (will migrate some repos from fossil via git) | 09:00 |
| poolie | this *could* be written with threads, but i think it's pretty clear, and much less likely to have weird problems, the way it is | 09:00 |
| gour | *fully | 09:00 |
| poolie | :) | 09:01 |
| vila | poolie: right (nit: addCleanup(lf1.unlock)) | 09:01 |
| poolie | good point | 09:02 |
| poolie | it's a very old test, from before we had that | 09:02 |
| poolie | (though it could have used finally, of course) | 09:02 |
| vila | poolie: sure, it's fine as is | 09:02 |
| vila | What I would love on this thread in test issue is that we go a bit further using the config ones as an example | 09:03 |
| vila | I've looked at them again and frankly, they are old too | 09:04 |
| vila | in the sense that in they were written for a bug which in the end is really addressed by using an atomic write | 09:04 |
| vila | and since it's atomic, the initial issue of having two processes mixing its content is moot and the tests are just... relying on this assumption anyway | 09:05 |
| poolie | hm | 09:06 |
| vila | they *were* useful for me in my actual work as ~blackbox tests ensuring the new code paths were covered | 09:06 |
| vila | but since the new code path *also* assumes an atomic write, the same remark applies... | 09:06 |
| poolie | mm i see what you mean about you copying existing test | 09:06 |
| vila | simply deleting them seems extreme though | 09:06 |
| poolie | ok; i have to talk to jam now | 09:07 |
| vila | poolie: before you left: you didn't answer to the "meh, neither one got a vote, am I being too conservative reading the comments ?" | 09:08 |
| gour | AfC: hiya, is bzr still your preferred dvcs? (/me still remembers your 'orthogonal patches' post) | 09:09 |
| poolie | config-lock is needsinfo | 09:10 |
| * vila blinks | 09:11 | |
| vila | not approved then ? | 09:11 |
| AfC | gour: hello | 09:14 |
| gour | AfC: hiya | 09:15 |
| AfC | gour: yes, I still use Bazaar pretty much exclusively. | 09:15 |
| gour | AfC: that's nice to hear...i did experiment (after leaving) darcs with mtn and fossil for some time, but now i'm moving fully to bzr | 09:16 |
| === hunger_ is now known as hunger | ||
| AfC | gour: that puts me at odds with most of the other hackers I collaborate with, but I don't really care. Our having switched to Bazaar predates their having switched from CVS to Subversion, and their subsequent Git infatuation doesn't impress me much either. | 09:17 |
| gour | he he...i also cannot grok git and use bzr-git in such cases...it's quite good | 09:18 |
| fullermd | I always assume that when I disagree with everyone around me, it's 'cuz I'm right and they're wrong. | 09:18 |
| fullermd | ... of course, when I _agree_ with everyone around me, that's also because I'm right and they're wrong. They're just wrong in more subtle ways. | 09:19 |
| AfC | fullermd: have you ever considered moving to a medium sized mountain top in India and becoming a guru? | 09:20 |
| gour | lol | 09:20 |
| fullermd | Oh, absolutely. But have you priced out decent 'net connectivity on mountain tops lately?! | 09:20 |
| AfC | wisdom is not bought without sacrifice. | 09:21 |
| fullermd | Sure, but couldn't I just trade a firstborn or a limb instead? A man's gotta draw the line somewhere. | 09:21 |
| gour | here is some wisdom from the vedas: "In a place where there are no scholars, even a men of petty knowledge is worshiped just as in the land devoid of trees, even a castor oil plant is considered as a big tree." | 09:23 |
| vila | gour: castor is the new kid in town but I'd rather stick with goats | 09:24 |
| AfC | Goatherds Unanimous | 09:25 |
| phanatic | hi, do you have any suggestions how i could fix an inventory corruption? https://bugs.launchpad.net/bzr/+bug/620684 | 10:05 |
| ubot5 | Ubuntu bug 620684 in Bazaar "ERROR file id "None" is not present in the tree when checking the root entry" [Medium,Confirmed] | 10:05 |
| gour | vila: ;) | 10:06 |
| vila | poolie: just foudn you comment on config-lock-remote with needsinfo (which *is* approved), but I was referring to config-locks and config-lock-branch :-/ | 10:37 |
| poolie | vila, sorry, i want to get these fixed up and landed but it's getting too late here | 10:40 |
| vila | poolie: I'll switch to something else then, enjoy your evening | 10:41 |
| poolie | jam or i or both will concentrate on them later this week and try to get you unblocked | 10:44 |
| jam | vila: actually I'd like to do some phone chatting with you if you want. *right* now I need to go eat some food. | 10:45 |
| vila | hehe, jam (and I) won't be there that much later this week :D | 10:45 |
| vila | Thursday is a holiday here | 10:45 |
| vila | jam: sure, I will eat a bit later though. What subjects do you have in mind ? | 10:59 |
| jam | vila: just to go over your config stuff in a live chat and get it done, rather than high latency email/irc | 11:00 |
| jam | vila: I feel like we had you do a big work on your own, and we need to rectify that. "big" (more than 1 weeks worth of work) should really be a collaboration. | 11:01 |
| jam | for config, you're the only one that really has the state in your head, and we've had disjoint reviewers, etc. | 11:01 |
| jam | so nobody else really understands it. So either we are rubber stamping because we know you're smart, or we are fragmenting on details we don't understand. | 11:02 |
| vila | jam: interesting point of view, I'm glad you discussed with poolie :D | 11:03 |
| vila | Indeed, I should have realized it sooner... | 11:03 |
| vila | I guess it's hard to realize how much people understand without seeing code so the devnotes document wasn't that useful (or too broad or aiming too far in the future) | 11:04 |
| jam | vila: it has been a general issue for us. I've hit it as well when I do major work. It is really hard to get major work landed, if it wasn't a collaboration. | 11:04 |
| vila | That reminds me of the i18n effort too | 11:04 |
| jam | so lets make them collaborations. | 11:04 |
| vila | yup, I welcome that ! | 11:05 |
| poolie | :) hooray, i can sleep soundly | 11:06 |
| poolie | good night, gets | 11:06 |
| poolie | *gents | 11:06 |
| vila | yeah, I corrected the typo before seeing the fix ! | 11:07 |
| poolie | hi jelmer, welcome back | 11:07 |
| jelmer | hi poolie, thanks :) | 11:07 |
| jelmer | things appear to have been busy here last week :) | 11:08 |
| vila | jam, poolie: I thing there are far enough itches there for anybody to find several to scratch... | 11:08 |
| vila | jelmer: yeah, when we woke up from your patch avalanches we realized we had some of our own :D | 11:09 |
| vila | jelmer: but please, keep the snow balls rolling ! | 11:09 |
| poolie | i wonder where jr is | 11:09 |
| poolie | on holiday this week maybe | 11:09 |
| poolie | anyhow, see you tomorrow | 11:09 |
| jelmer | have a good night poolie | 11:11 |
| jelmer | vila: :) | 11:11 |
| === mbp_ is now known as poolie | ||
| * vila lunch time | 11:40 | |
| gour | i'd like to convert all my old fossil repos into bzr. fossil has --git export command which can create fast-import stream...now i wonder if i could do fossil --> bzr in one step? | 11:48 |
| gour | i've tried with the following: fossil export --git -R ~/repos/fossil/admin/cfgfiles.fossil| bzr fast-import - | 11:49 |
| gour | but bzr crashes | 11:49 |
| gour | here is the paste - http://pastebin.com/zT10Re96 | 11:50 |
| fullermd | That sounds like bzr and the fastimport plugin being mismatched. | 11:51 |
| fullermd | Though at least you're using a sensible OS :p | 11:51 |
| gour | :-) | 11:52 |
| gour | here it is https://bugs.launchpad.net/bzr-fastimport/+bug/485788 | 11:53 |
| ubot5 | Ubuntu bug 485788 in Bazaar Fast Import "bzr fast-import fails: AttributeError: 'CHKInventory' object has no attribute 'copy'" [Medium,Triaged] | 11:53 |
| jelmer | gour: looking.. | 12:09 |
| jelmer | gour: still there? Can you try a different fastimport on that fastimport file? | 12:12 |
| gour | jelmer: will do...after lunch | 12:14 |
| gour | jelmer: what do you mean 'different' ? | 12:15 |
| gour | another format? | 12:15 |
| jelmer | gour: latest revision | 12:15 |
| jelmer | see the bug report | 12:15 |
| gour | ok | 12:15 |
| CaMason_ | hi guys. I have a branch with several merges that may be missing some revisions - is there a command to show a list of 'tips' or old commits? | 12:16 |
| jelmer | CaMason_: hi | 12:20 |
| CaMason_ | hello | 12:20 |
| jelmer | CaMason_: bzr heads (from the bzrtools plugin) should be able to help | 12:20 |
| jelmer | in particular, "bzr heads --dead" | 12:20 |
| CaMason_ | thanks. blank. | 12:21 |
| CaMason_ | I might have to take a look through a backup. Thanks | 12:21 |
| mvo | hi, a quick question, if I want to copy a file (not rename) and retain history, is there a way to do that with bzr? i.e. bzr copy gtk2.py gtk3.py and then going wild on gtk3.py | 12:22 |
| jelmer | hi Michael | 12:22 |
| jelmer | mvo: No, there's no way to track files across copies at the moment | 12:22 |
| jelmer | we have some thoughts on how to do so, and bzr is will probably support it in some form or another in the future - but today it's not supported | 12:23 |
| mvo | jelmer: ok, thanks! | 12:23 |
| jam | hey Riddell, just looking at your zlib patch now | 12:53 |
| Riddell | thanks jam, if it's rubbish feel free to tell me so :) | 12:54 |
| gour | jelmer: http://pastebin.com/YReiaLQ0 | 12:56 |
| jelmer | gour: try again? | 12:57 |
| vila | what happened to bzr-2.3.3 for natty ? | 12:57 |
| jelmer | (r319) | 12:57 |
| jelmer | vila: I'm not sure - were we going to do a SRU? | 12:58 |
| vila | same here, searching for poolie's sru page (or was it maxb's page ?) | 12:58 |
| vila | a wiki to keep track of the srus | 12:58 |
| maxb | http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates | 12:59 |
| vila | maxb: you rock :) | 12:59 |
| vila | google: can you beat maxb and mgz for *my* requests ? Bah, of course you can't ! | 12:59 |
| vila | maxb: If I read this page correctly, 2.1.4 is still in the pipe and 2.3.3 hasn't been started, right ? | 13:00 |
| vila | bug #494221 is marked fix released, rmadison still says 2.1.1 for lucid, 2.1.4 for lucid-updates | 13:02 |
| ubot5 | Launchpad bug 494221 in Bazaar 2.1 "KeyError in remove_recursive_id during commit" [High,Fix released] https://launchpad.net/bugs/494221 | 13:02 |
| vila | so the SRU for 2.1.4 is completed no ? | 13:02 |
| gour | jelmer: http://pastebin.com/BS2HbXV1 | 13:04 |
| jelmer | gour: that fastimport stream must be quite unusual :-/ | 13:04 |
| jelmer | gour: is the stream public? | 13:05 |
| gour | jelmer: no, but i can try with another one which is public...wait a minute | 13:06 |
| jam | jelmer: https://code.launchpad.net/~nmb/bzr/merge-force-doc/+merge/62938 | 13:10 |
| jam | you voted approve after poolie asked for some changes | 13:10 |
| jam | was that just delayed email? | 13:10 |
| jelmer | jam: Uhm, yeah, let me retract that | 13:11 |
| jelmer | jam: Done - thanks | 13:11 |
| vila | PP ftw :) | 13:12 |
| maxb | vila: Ah, right, looks like 2.1.4 has been promoted | 13:20 |
| * maxb wonders what the dates symbolise | 13:21 | |
| vila | maxb: last modification of the topic ? | 13:21 |
| maxb | oh. "The date is the upstream source release date." a bit below | 13:21 |
| vila | damn, good catch | 13:22 |
| maxb | I wonder why that's useful | 13:22 |
| vila | I think it gives some rough idea of how long it took to complete the SRU | 13:23 |
| vila | well, rather since when it has started | 13:23 |
| vila | -ish | 13:23 |
| vila | :) | 13:23 |
| vila | . o O (That was really a clear summary, your S/N ratio sky-rockets !) | 13:24 |
| fullermd | Well, if it's TOO clear, it's a full report, not just a summary :p | 13:26 |
| gour | jelmer: i cloned fossil repo available with fossil clone http://www.fossil-scm.org/ myclone.fossil and then try to fast-export/import and got - http://pastebin.com/czLmWLdb. Fossil is available at http://www.fossil-scm.org/download.html and compiles into single-file executable. | 13:29 |
| jelmer | gour: can you upload the problematic fast import file to the bug report? | 13:31 |
| gour | jelmer: you mean git-export format created by fossil? | 13:33 |
| jelmer | gour: yeah | 13:33 |
| jelmer | the bit you pipe into bzr fastimport | 13:33 |
| gour | ok | 13:34 |
| gour | jelmer: it's 471M...shall i compress it somehow? | 13:34 |
| jelmer | gour: can you perhaps see if it's possible to reproduce the issue from a trivial fossil repository? | 13:35 |
| gour | ok | 13:35 |
| maxb | So, yes, it would be appropriate to get the 2.3.3 SRU underway now | 13:38 |
| maxb | bug 616878 is a non-trivial behaviour change which would require particularly careful analysis | 13:39 |
| ubot5 | Launchpad bug 616878 in Bazaar "bzr commit error because of no identity (should look at /etc/mailname)" [High,Fix released] https://launchpad.net/bugs/616878 | 13:39 |
| gour | jelmer: small file is attached to the bug report | 13:39 |
| jelmer | h | 13:40 |
| maxb | We'll need to be particularly careful, as it's not the sort of change normally SRUed | 13:40 |
| jelmer | gour: thanks | 13:40 |
| vila | jam: finally available, are you ? Mumble ? Phone ? Here ? | 13:56 |
| === smoser` is now known as smoser | ||
| jam1 | hey vila, probably about 20min for me | 14:05 |
| jam1 | then mumble or phone | 14:05 |
| jam1 | or sip if you have it set up | 14:05 |
| vila | no, only mumble and phone, but I think I can call you for free | 14:06 |
| vila | mumble leaves both of my hands free though and I suspect I may need them :) | 14:06 |
| jam1 | uhm.... heh heh | 14:10 |
| jelmer | gour: fixed | 14:15 |
| jelmer | gour: though I should note that the way fossil uses fastimport seems really odd | 14:15 |
| === jam1 is now known as jam | ||
| gour | jelmer: let me try...otoh, i just want to convert repos to bzr...one-time event | 14:23 |
| gour | jelmer: drh also complained how git handles it | 14:24 |
| jelmer | gour: drh? | 14:25 |
| jam | vila: logging into mumble now | 14:25 |
| gour | jelmer: dr richard hipp, author of fossil & sqlite | 14:26 |
| jelmer | gour: I agree with him fast-import isn't ideal (it's very git centered), but the way fossil seems to use it is inconsistent with how all other systems (including git, where it originated) use it | 14:27 |
| gour | jelmer: i see...otoh, attempt to import my 'olod' repo gives - http://pastebin.com/CSAZGPfp | 14:29 |
| jelmer | gour: can git import that file without problems? | 14:30 |
| gour | let me try | 14:30 |
| gour | jelmer: it does import | 14:36 |
| jelmer | gour: are you trying to import into a clean bzr branch? | 14:36 |
| gour | jelmer: yes | 14:38 |
| jelmer | gour: in that case I'm out of ideas | 14:39 |
| jelmer | gour: an alternative might be to import via Git | 14:39 |
| gour | that's what i'm trying now | 14:41 |
| gour | import via git fails as well | 14:56 |
| smoser | hm... i had a link to a list of packages that were broken for udd, but i can't find that link. | 15:11 |
| smoser | anyone? | 15:11 |
| smoser | found it. | 15:13 |
| smoser | http://package-import.ubuntu.com/status/ | 15:13 |
| gour | jelmer: i've tried to export git repo and import into fossil & bzr...former works, the latter fails | 15:13 |
| smoser | my next question would be "how does one get a package removed from that list" | 15:14 |
| jelmer | smoser, by fixing the relevant bugs in the package importer | 15:14 |
| jelmer | gour, how does importing into bzr fail? | 15:15 |
| gour | jelmer: http://pastebin.com/CvwEcVaH | 15:15 |
| gour | i used: git fast-export --all | 15:16 |
| jelmer | gour, what version of git? | 15:16 |
| gour | git version 1.7.4.5 | 15:17 |
| jam | vila: http://paste.ubuntu.com/615364/ | 15:18 |
| jelmer | gour, I'm afraid I'm out of ideas in that case | 15:24 |
| jelmer | gour, or perhaps clone the git repository with bzr-git? | 15:25 |
| gour | jelmer: ok | 15:25 |
| gour | jelmer: you can export from git and import into bzr? | 15:25 |
| gour | jelmer: i clone many repos with bzr-git, but i wanted to test whether bzr fast-import cam import from git | 15:25 |
| jelmer | gour, I haven't seen a lot of issues with bzr-fastimport, its testsuite also covers a fair number of corner cases | 15:30 |
| jelmer | that said, you seem to've hit an open bug | 15:30 |
| gour | i've tried from random git repo to export and import into bzr...same error | 15:31 |
| gour | so, it's not just cae with fossil-exported repos | 15:31 |
| jelmer | in that case there might be an external thing | 15:31 |
| gour | ? | 15:32 |
| jelmer | I've never seen that particular error with bzr-fastimport and I've done dozens of imports | 15:32 |
| jelmer | are you using python-fastimport trunk? | 15:33 |
| gour | i just tried with https://github.com/cournape/Bento -same problem | 15:35 |
| gour | yes, trunk version | 15:35 |
| jelmer | gour, what exact command are you running to export that repo? | 15:37 |
| gour | jelmer: git fast-export --all > ../repo.fi | 15:38 |
| jelmer | 15:39:01 Imported 1826 revisions, updating 1 branch and 1 tree in 0:00:19 | 15:39 |
| gour | and then: bzr fast-import ../repo.fi fro mwithin newlly-init bzr repo | 15:39 |
| gour | strange | 15:39 |
| jelmer | gour: trunk bzr-fastimport *and* trunk python-fastimport? | 15:40 |
| gour | jelmer: found what's the problem | 15:41 |
| maxb | Oh, I've been meaning to ask - does this look like a transient error? bzrlib.errors.TooManyConcurrentRequests:<module>:main:import_package:make_db_set:get_branch_parts:open:open:open_from_transport:open:_open:__init__:_probe_bzrdir:_rpc_open_2_1:_call:call:call_expecting_body:_call_and_read_response:_send_request:_construct_protocol:get_request:__init__ | 15:41 |
| gour | the directory which i used for testing was somehoe, initiliazed as shared-repo | 15:41 |
| gour | jelmer: now it works directly piping it from fossil | 15:45 |
| gour | but import is only partial..another problem | 15:47 |
| jelmer | gour, partial in what way? | 15:47 |
| jam | vila: http://paste.ubuntu.com/615380/ | 15:49 |
| gour | jelmer: not all revisions are imported...fossil --> git has all revisions | 15:49 |
| jerryb | Question: I'm learning bazaar after a while with svn. I'm wondering if/how I can do "bzr diff <path>" to show the last set of changes like I can with "svn diff -rprev <path>". | 15:50 |
| gour | now i'll try git --> bzr | 15:50 |
| jam | vila: http://paste.ubuntu.com/615383/ | 15:50 |
| jam | http://paste.ubuntu.com/615384/ | 15:51 |
| gour | jelmer: fossil --> git imported only ~300revisions, while fossil --> git --> bzr all of 'em (~500) | 15:51 |
| gour | s/fossil --> git/fossil --> bzr | 15:52 |
| maxb | smoser: Did you have a particular package in mind? | 15:54 |
| smoser | i dont care a lot about 'nut' i was just doing a merge and saw it broken. | 15:54 |
| smoser | i have to say that doing merges with bzr is a whole lot nicer than with 'grab-merge' | 15:54 |
| jelmer | gour: bzr fastimport only imports trunk, not other branches by default (see its default output) | 15:58 |
| gour | jelmer: i'm aware of it..the problem was that i did tests in ~/ff dir in which i, by mistake did bzr init ., which was supposed to be done in ~/ff/dir and then, everything was done as within bzr repo which was otherwise empty, but having ~/ff/.bzr greatly confused bzr, as you can see | 16:01 |
| gour | jelmer: maybe something can be done to detect it instead of spitting "BadRestart: Bad restart - attempted to skip commit 39 but matching revision-id is unknown" ? | 16:02 |
| === marienz_ is now known as marienz | ||
| jelmer | gour, well, that would require us to know *why* you're getting that error first | 16:08 |
| gour | trying to reproduce it now, but it stubbornly works :-) | 16:15 |
| jerryb | Question: I'm learning bazaar after a while with svn. I'm wondering if/how I can do "bzr diff <path>" to show the last set of changes like I can with "svn diff -rprev <path>". | 16:16 |
| maxb | -c-1 | 16:18 |
| maxb | oh, the last set of changes that touched <path> ? That may not be so easy | 16:18 |
| vila | 'bzr diff -r-1 <file>' works fine | 16:19 |
| maxb | even if <file> didn't change in the last revision in the branch? | 16:20 |
| jerryb | vila: doesn't work. e.g. I got a diff with 'bzr diff -rlast:2 <file>' but nothing with zr diff -r-1 <file> | 16:22 |
| jerryb | maxb: yes | 16:22 |
| vila | oooooh, sorry, missed this bit | 16:22 |
| vila | bzr log -l1 <file> | 16:23 |
| vila | will tell you the rev | 16:23 |
| cr3 | how can I branch just the code from a project with minimal .bzr overhead where I don't intend to make any commits nor pulls | 16:44 |
| maxb | I don't think the bzr remote protocol offers a convenient way | 16:53 |
| cr3 | maxb: something minimal would be fine too | 16:53 |
| === beuno is now known as beuno-lunch | ||
| vila | mgz: around ? | 17:48 |
| mgz | ue. | 17:48 |
| vila | mgz: about cleanups and cycles | 17:49 |
| vila | when the test has run (or fail) the cleanups are run and deleted right ? | 17:49 |
| vila | so any reference in a cleanup method can't be involved in a cycle, still right ? | 17:49 |
| mgz | yup, though it's not always obvious if there are other cycles. | 17:50 |
| mgz | it's safe to pass a bound method as a cleanup callback though | 17:50 |
| vila | right, in my case it's not even a bound method ;) | 17:51 |
| vila | mgz: thanks, that answers my question | 17:52 |
| === beuno-lunch is now known as beuno | ||
| === mnepton is now known as mneptok | ||
| === yofel_ is now known as yofel | ||
| chx | hi. in the past there was a Drupal mirror on launchpad. We built the site based on that. Now Drupal uses git (*weep*) and I am trying to merge. This is not trivial to say the least. How can I tell bzr that the other tree (i created with bzr-git or fastimport, doesnt matter much) revision 14503 is pretty much the same as r17861 here? (It wasnt the same but close enough that merge can work from there) | 21:45 |
| chx | bzr merge -r 14503..-1 gives me a content conflict for every file. | 21:45 |
| jelmer | chx: that's the "parallel import" problem - it's a nontrivial thing to fix | 21:46 |
| chx | Yes. | 21:46 |
| chx | I figured as much. | 21:47 |
| chx | hey you are the guy who write dulwich arent you | 21:47 |
| maxb | Anyone with jubany access got a moment? I'd like a ./requeue_package.py --auto xbl | 21:47 |
| chx | and fastimport too | 21:48 |
| chx | and bzr-git as well? | 21:48 |
| chx | jelmer: Hi! You are my guy that's for sure :D | 21:48 |
| jelmer | chx: Yeah, I'm active in all three projects by coincidence :) | 21:49 |
| jelmer | hey maxb | 21:49 |
| maxb | Hello | 21:49 |
| chx | jelmer: so... are there some docs i should rtfm to deal with the problem? or just give up, roll a monster patch apply and struggle? | 21:50 |
| chx | hehe googling bzr parallel import leads to http://wiki.bazaar.canonical.com/ThreeWishes here where it's one of jelmer's wishes | 21:50 |
| jelmer | chx: I'm not aware of any docs; you should be able to do some sort of fancy rewrite of the old branch to make it use the same file ids as the new (git) branch | 21:51 |
| jelmer | chx: however, there is no command that can do that at the moment | 21:51 |
| maxb | I wonder if it's possible to contrive something useful by means of rm / add --file-ids-from= | 21:52 |
| jelmer | chx: it might be worthwhile to ask on the list, other people might have better ideas | 21:52 |
| chx | jelmer: https://lists.canonical.com/mailman/listinfo/bazaar this? | 21:54 |
| jelmer | chx: yep | 21:54 |
| maxb | chx: Is there an import of drupal's git registered on Launchpad? | 21:55 |
| chx | maxb: no :( | 21:56 |
| chx | maxb: David owns the Drupal branch | 21:57 |
| maxb | Well, I suggest making one, then :-) | 21:57 |
| chx | ok wrote David Strauss an email so we can do that | 21:57 |
| maxb | Do you need to? | 21:59 |
| maxb | The drupal website is pretty unfriendly to people looking for its VCS | 21:59 |
| maxb | Hm. Looks like a bzr-git import may be frustrated by bzr-git's current lack of support for importing anything other than the repository's HEAD branch | 22:04 |
| chx | maxb: i have a fastimport to work from tho | 22:09 |
| maxb | Fastimport is considerably less convenient to incrementally update | 22:11 |
| chx | thats for sure :/ | 22:12 |
| * maxb ponders putting "UDD failure ratchet: 487" in the topic | 22:12 | |
| chx | 487 | 22:13 |
| chx | 487? | 22:13 |
| chx | maxb: well, i can do the bzr rm ; bzr add --file-ids-from dance for sure | 22:13 |
| maxb | chx: So, I'd be inclined to do a bzr-git branch from a local git clone of whichever drupal branch you want to track | 22:14 |
| chx | maxb: and then bzr rm --keep ; bzr add --file-ids-from ? | 22:14 |
| maxb | (487 Ubuntu/Debian packages currently failing to import into Bazaar branches) | 22:14 |
| chx | ah | 22:15 |
| jelmer | maxb: How will "bzr add --file-ids-from" help, it means losing the history of all existing files. In that case, why not simply discard the existing history and rely on the new git history? | 22:15 |
| jelmer | maxb: also, nice work on the UDD progress :) | 22:15 |
| maxb | I was thinking that with some combination of rm / add --file-ids-from / merge / revert . it might be possible to make bzr behave in a roughly desirable manner | 22:16 |
| chx | i am happy to lose core history | 22:17 |
| chx | i have more copies of core history than i can possible care for :P | 22:17 |
| maxb | Though I've had a fair amount of beer, so I might be missing something :-) | 22:17 |
| chx | yeah that's what i am trying to do now | 22:18 |
| maxb | I think it would roughly play out as: | 22:21 |
| maxb | 1) Check out the latest upstream revision in the ancestry of your old site branch | 22:22 |
| maxb | 2) bzr rm --keep everything; bzr add --file-ids-from the-new-import . | 22:22 |
| maxb | 3) bzr merge -r 0..-1 the-new-import; bzr revert . | 22:23 |
| maxb | with a commit after 2) and 3) | 22:23 |
| maxb | 4) bzr merge the result of 3) into the tip of the old site branch; bzr revert .; bzr commit | 22:24 |
| maxb | 5) bzr merge the new upstream import (with fingers crossed) :-) | 22:24 |
| maxb | or something like that | 22:24 |
| chx | maxb: this bzr rm // bzr add --file-ids-from worked beautifully | 22:42 |
| chx | maxb: we dropped from 1042 content conflicts to 31 text conficlits and they are going fast (i am down to 14) | 22:42 |
| poolie | hi maxb, jelmer | 23:09 |
| jelmer | g'morning poolie | 23:11 |
| poolie | i hope you had a good trip | 23:14 |
| jelmer | yeah, it was great - nothing but sun and nature for a week :) | 23:16 |
| jelmer | how was yours? | 23:16 |
| poolie | nothing but motorcycles and mountains and rain for four days | 23:16 |
| poolie | also great | 23:17 |
| poolie | the rain is a mixed blessing | 23:17 |
| poolie | it feels good when you get out of it ;) | 23:17 |
| jelmer | :) | 23:17 |
| jelmer | Just because it's rain, or does it also make for slippery driving? | 23:18 |
| poolie | it's potentially a bit slippery, but i just go gently and it doesn't bother me | 23:18 |
| poolie | it's more just getting cold and wet | 23:18 |
| poolie | i had not reckoned on how much colder andwetter wales was than london | 23:19 |
| poolie | it must have been something like 10C over 200km, without much change in elevation | 23:19 |
| poolie | just more exposed to the Atlantic I suppose, and less human heat sources | 23:19 |
| jelmer | oh wow, that's quite a bit colder indeed :) | 23:20 |
| chx | maxb: OH at https://code.launchpad.net/~vcs-imports/drupal/head | 23:43 |
| chx | maxb: you recreated this? | 23:43 |
| chx | maxb: this needs to be , imo, git:// | 23:44 |
| chx | maxb: or maybe just the trailing slash is wrong? | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!