| poolie | biab | 00:03 |
|---|---|---|
| Stavros | hello | 00:12 |
| Stavros | how can i convert a bzr repo to a git repo by dpushing with bzr-git? | 00:12 |
| jelmer | Stavros, hi | 00:14 |
| Stavros | jelmer: hey jelmer | 00:14 |
| jelmer | Stavros, didn't I help you do that last week ? :) | 00:14 |
| Stavros | you did :( | 00:14 |
| Stavros | i'm missing a step now | 00:14 |
| Stavros | i did git init and git init --bare and dpushed to it | 00:14 |
| jelmer | you need a bzr init as well | 00:14 |
| Stavros | but i keep getting "/mydir" is not a branch | 00:14 |
| Stavros | ah | 00:14 |
| Stavros | that was it, thanks | 00:15 |
| Stavros | bzr init --git | 00:15 |
| jelmer | git init /tmp/foo; bzr init /tmp/foo; bzr dpush /tmp/foo | 00:17 |
| jelmer | there's no need for the --git | 00:17 |
| Stavros | ah, yes | 00:18 |
| jelmer | (if you're creating a branch in a git repository we always create a git branch) | 00:18 |
| Stavros | but if you don't have a git repo in there, you can do bzr init --git and it still works | 00:18 |
| Stavros | ah | 00:18 |
| === lifeless_ is now known as lifeless | ||
| spiv | Good morning. | 01:03 |
| === magcius_ is now known as magcius | ||
| poolie | hi spiv | 02:50 |
| spiv | Hi poolie | 03:02 |
| poolie | hi, how are you? | 03:07 |
| poolie | spiv could you be pilot this week? | 03:08 |
| spiv | Sure! | 03:10 |
| === spiv changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | 2.4b1 is officially out (ppa:bzr/beta needs love) | ||
| poolie | thanks; i updated the rota | 03:11 |
| === spm` is now known as spm | ||
| === wgrant_ is now known as wgrant | ||
| === poolie_ is now known as poolie | ||
| === r0bby_ is now known as robbyoconnor | ||
| === robbyoconnor is now known as r0bby_ | ||
| === r0bby_ is now known as robbyoconnor | ||
| === robbyoconnor is now known as r0bby_ | ||
| === r0bby_ is now known as robbyoconnor | ||
| vila | hi all ! | 07:28 |
| spiv | Hi vila | 07:29 |
| vila | spiv: _o/ | 07:29 |
| poolie | hi there vila, spiv | 07:31 |
| poolie | vila, what's up for you today? | 07:31 |
| vila | poolie: config :) | 07:32 |
| poolie | the whole hog? :) | 07:33 |
| vila | poolie: nope, a minimal set (excluding locking/minimal IOs/option registry) but enough to look at deplying/migrating | 07:39 |
| vila | deploying | 07:39 |
| poolie | you know i'd really like a new caller ui :) | 07:40 |
| vila | poolie: just tell me which ;) | 07:40 |
| poolie | sorry, api, not ui | 07:41 |
| vila | poolie: ... or let's discuss it on my proposal, I think we are roughly on the same page so it shouldn't be too far from what you're expecting | 07:42 |
| vila | poolie: of course if you speak earlier it would be even closer :D | 07:42 |
| poolie | :) i might still have a mail starred to reply to | 07:42 |
| poolie | i have a call in 20m but perhaps i can do it after that | 07:42 |
| poolie | i thought i did reply | 07:42 |
| vila | poolie: I'm processing my inbox so I may not have seen it yet | 07:43 |
| vila | oh, hmm, just noticed the PP update, I won't be able to do it the whole week (vacations), who should I switch with ? | 07:44 |
| poolie | i haven't replied after your last mail | 07:44 |
| poolie | whoever | 07:44 |
| poolie | you're not up this week | 07:44 |
| poolie | can swap with me i think | 07:44 |
| poolie | for some reason i really prefer .config_stack; i feel there's already going to be some risk of confusion about particular files vs stacks | 07:45 |
| poolie | maybe not though | 07:45 |
| poolie | why do you put "sections (read-only and mutable)" first? | 07:45 |
| vila | poolie: I'm talking about *next* week, and I can't switch with you either as I won't be there from 2011-04-13 to 2011-04-27 ;) | 07:47 |
| vila | poolie: bottom-up | 07:47 |
| vila | poolie: TDD is easier for me when implementing from the lower levels first | 07:49 |
| vila | poolie: regarding .config vs .config_stack, the only cases where you want to use the config file directly is to modify it and even there you could do it via the stack, so somehow, devs shouldn't manipulate config files directly, only the user should really see them as an entry point (like command-line options or env vars) | 07:53 |
| vila | poolie: I can be persuaded otherwise but I think that if we change the API now, it's to also change the mental model, and configs should be seen as stacks rather than files | 07:55 |
| spiv | vila: are they always files? I would expect that e.g. bzr-svn branches may provide some config-like values without having a config file. | 07:56 |
| poolie | ok | 07:57 |
| vila | spiv: indeed, they are stacks built from stores (the first store will be based on ConfigObj) but other stores can be implemented as long as they can give us sections | 07:57 |
| poolie | actually i don't strongly prefer it anymore ; i did on friday but not now | 07:57 |
| vila | really, I don't think I'm reinventing wheels here, just shuffling the design a bit around what we already do while getting rid of many hackish parts | 07:59 |
| poolie | i think so too | 07:59 |
| poolie | i can see why afc thought it was complex | 07:59 |
| vila | it may appears I'm not, but really, that's my intent | 08:00 |
| poolie | i do still kind of feel smaller steps are possible | 08:00 |
| vila | how small ? | 08:00 |
| vila | or rather, | 08:00 |
| vila | at which point does the cost of wiring the smaller steps become higher than leapfrogging a couple of them ? | 08:01 |
| AfC | U+200D ZERO WIDTH JOINER small! | 08:01 |
| vila | AfC: :) | 08:01 |
| poolie | for example just changing the internal api not to construct global configs all over | 08:01 |
| vila | ha, and how do you ensure you won't have to do that twice ? | 08:02 |
| vila | or do it without adding stuff we'll delete later ? | 08:02 |
| poolie | i don't | 08:07 |
| poolie | it's a risk | 08:07 |
| poolie | on the other side you have to weigh the risk of doing preparatory stuff that's not actually delivering value yet | 08:07 |
| poolie | so if i was reading that list properly, what's first? | 08:08 |
| vila | poolie: you mean section/abstract store/stacks ? | 08:08 |
| poolie | yes | 08:09 |
| vila | so section are first | 08:09 |
| vila | I already have some stuff tested/coded for sections and stacks, I blocked a bit on store Friday for the locking part, so I wrote some thoughts about it and will focus on using the existing scheme | 08:10 |
| poolie | so just to make sure i understand | 08:11 |
| poolie | when you say section, this is about letting the stack choose to use just one section from inside a particular file? | 08:11 |
| vila | s/wrote some thoughts/wrote some thoughts about the new locking scheme allowing allowing minimal IOs/ | 08:11 |
| poolie | like in looking at locations.conf it'll pick out the relevant sections and slot them in? | 08:12 |
| vila | a selection of sections yes, like matching_sections does today for locations.conf | 08:12 |
| vila | but allowing that for any store | 08:12 |
| vila | nothing fancy either for now, only what exist: globs (which is mainly used as just paths today) | 08:13 |
| vila | oooh, col*l*ocated ! | 08:15 |
| vila | is that indeed the correct spelling ? | 08:15 |
| poolie | i think there would be one | 08:16 |
| poolie | co-located | 08:16 |
| vila | hmm, so using 'colocated' is just stripping the '-' in identifiers ? | 08:17 |
| vila | err, as in python identifiers or paths | 08:17 |
| poolie | yes i think so | 08:17 |
| poolie | did i spell it the other way somewhere? | 08:17 |
| vila | k, will do that then | 08:17 |
| vila | poolie: not you, ispell | 08:17 |
| vila | (0) co located (1) co-located (2) collocated | 08:18 |
| poolie | i know of 'collated' | 08:18 |
| poolie | http://en.wikipedia.org/wiki/Collocation | 08:19 |
| poolie | interesting | 08:21 |
| vila | right, this page only used 'located' once in collocated, I can go with co-located if you prefer | 08:21 |
| spiv | I think that's jargon that isn't referring to a particularly similar concept | 08:22 |
| vila | or may be we just don't care :D | 08:22 |
| poolie | which page? | 08:22 |
| vila | http://en.wikipedia.org/wiki/Collocation | 08:22 |
| spiv | And that page links to http://en.wikipedia.org/wiki/Colocation_%28disambiguation%29 which links to http://en.wikipedia.org/wiki/Colocation_%28business%29 | 08:22 |
| poolie | "go with co-located if you prefer" where? | 08:22 |
| poolie | vila, can you either take, or assign to yourself, one or more bugs about config | 08:23 |
| vila | poolie: certainly | 08:23 |
| vila | poolie: thanks for the reminder, I should have done that long ago | 08:23 |
| spiv | http://en.wiktionary.org/wiki/colocation suggests that with or without the hyphen are both used. | 08:23 |
| vila | spiv: excellent ! There is even (and indeed) http://en.wiktionary.org/wiki/colocated | 08:24 |
| vila | jelmer: hi | 08:25 |
| poolie | vila, for our stuff, 'colocated | 08:25 |
| vila | poolie: yup, I've already reverted to that | 08:26 |
| spiv | jelmer: I just gave you a review, of sorts, finally: https://code.launchpad.net/~jelmer/bzr/move-interbranch-fetch2/+merge/54958 | 08:28 |
| poolie | vila, so at the end of this, what sections will we have | 08:48 |
| poolie | just locations, or also others? | 08:48 |
| vila | sections anywhere and their definition should be file specific, but for bzr itself, urls (as of today) for bazaar.conf/locations.conf (or only paths/globs there) and probably relative paths for others | 08:50 |
| vila | some plugins may want to use different schemes for sections (window names for GUIs for example ?) | 08:51 |
| vila | or hosts for authentication.conf (which uses arbitrary section names today and relies on their definition order rather than matching) | 08:52 |
| vila | I don't intend to modify authentications.conf until we need too though | 08:53 |
| vila | but the point is that sections are a different way to look at partitioning the options and it's best to leave that part open if you can | 08:54 |
| vila | err if we can | 08:54 |
| jam | morning vila, getting yourself out of PP rotation I see ? | 08:57 |
| vila | jam: hehe, pushing down the stack yeah :D | 08:57 |
| vila | sorry I didn't realize that earlier | 08:57 |
| vila | poolie: by the way, stacks were somehow implemented in bzrlib/rules.py too | 08:58 |
| poolie | ok | 09:09 |
| poolie | i might stop for today | 09:09 |
| * vila cries, compiz shortcuts gone again.... | 09:13 | |
| === mkv is now known as m4v | ||
| === Peng__ is now known as Peng | ||
| * spiv stops for the day | 09:55 | |
| jelmer_ | vila is skipping patch pilot duty ? :) | 11:59 |
| vila | jelmer_: yup, and to add insult to injury, he's taking vacations, what a shame :D | 12:00 |
| === jelmer_ is now known as jelmer | ||
| jelmer | (-: | 12:01 |
| === ScottK2 is now known as ScottK | ||
| === beuno is now known as beuno-lunch | ||
| DeeLay | I have a feature branch that has been merged into trunk, I need to undo that merge continue working on the feature branch, and then re-merge the feature branch back into trunk at some point in the future. Any suggestions on the best approach? | 12:17 |
| vila | DeeLay: depends on two things: is the trunk public, do you still have your pristine feature branch | 12:35 |
| vila | if you still have your feature branch before the merge, just keep working on it | 12:35 |
| vila | you'll merge it to trunk later, only additional changes will appear on trunk at that point | 12:36 |
| vila | for the trunk, there are two ways: either it's public and people already have pulled from it so you need to merge a reverse of your changes | 12:36 |
| DeeLay | vila: trunk is not public, but it is the branch we release from. The feature got cancelled at the last minute, so we need to pull it from trunk, so that other features can be released without needing to do cherry picked releases | 12:37 |
| vila | it's not public or nobody had pull from it (always hard to ensure but) you can just push --overwrite -r<revno-before-the-merge> | 12:37 |
| vila | s/^/if/ | 12:37 |
| vila | DeeLay: is the above clear enough or do you need more details ? | 12:38 |
| DeeLay | vila: yeah I think that makes sense, I'll give that a go, thanks | 12:39 |
| vila | DeeLay: if your merge is the last commit on trunk, you can also 'bzr uncommit' there and 'bzr revert [--no-backup]' or 'bzr clean-tree' to get rid of the *~ files created by revert | 12:39 |
| DeeLay | vila: unfortunately not, and the last time I uncommitted a merge, it didn't re-merge the changes later | 12:40 |
| vila | DeeLay: right, so you have other commits on top of your "faulty" merge, more care needed | 12:41 |
| vila | DeeLay: you probably need to revert this merge explicitly then 'bzr merge -r<revno>..<revno>-1' <revno> being your merge | 12:42 |
| vila | DeeLay: and commit the result with a message explaining the issue for future references if some other dev built on top of your merge *including* parts you wanted to remove, | 12:43 |
| vila | DeeLay: you *should* be able to detect such cases when you merge the reverted change, but evil is in the details... | 12:44 |
| DeeLay | vila: yeah that was my first attempt, but that means merging trunk into the feature branch (to keep it upto date) would remove the changes from the feature branch | 12:44 |
| vila | DeeLay: no, you can do that on the trunk itself | 12:45 |
| vila | DeeLay: it will be clearer there for everybody involved (hopefully) | 12:45 |
| DeeLay | yeah, that's what I mean, so if I bzr merge -r <revno>..<revno-1> in trunk, I can effectively remove the changes introduced by the feature branch | 12:46 |
| DeeLay | in the meantime dev work will continue, so i will need the feature branch to keep up to date with other changes being merged to trunk | 12:46 |
| vila | DeeLay: now, on your feature branch, you can add more changes and merge the overall in trunk again when needed, you may encounter conflicts then though | 12:47 |
| DeeLay | but from the feature branch, bzr merge trunk, will remove the changes that the feature branch introduced to trunk from the actual feature branch | 12:47 |
| vila | haa, that, yeah | 12:47 |
| vila | well, the sooner you merge trunk to your feature branch, the sooner you'll address the possible conflicts | 12:48 |
| DeeLay | also tried bzr revert -r <revno-1> in trunk, which gets round the commit of the reverse merge issue | 12:48 |
| DeeLay | but in that scenario, re-merging the the feature branch comes back with "nothing to do" | 12:48 |
| vila | DeeLay: well, revert will also revert all subsequent commits so probably not what you want | 12:49 |
| vila | DeeLay: the reverse merge is called a cherry-pick, it doesn't track the ancestry so it finds no new *revision* to merge | 12:50 |
| DeeLay | vila: yeah, but I can live with that if it worked, as the other changes could be re-merged. The essential problem is that trunk will always remember that the reverted commits happened, so it won't re-merge them | 12:50 |
| vila | DeeLay: that's why you need to merge trunk again after that into your feature branch: to ensure that your branch carries the right changes | 12:50 |
| maxb | <DeeLay> but from the feature branch, bzr merge trunk, will remove the changes that the feature branch introduced to trunk from the actual feature branch | 12:51 |
| maxb | There's a way to avoid this, let me explain: | 12:51 |
| maxb | Step 1: Merge the revision of trunk immediately prior to the revert commit as normal | 12:51 |
| maxb | Step 2: Merge the revert commit and *only* the revert commit from trunk, and do "bzr revert .", and commit that | 12:51 |
| maxb | At this point you now have a feature branch which says "I know trunk reverted these changes, but *I* am going to keep them" | 12:52 |
| maxb | And I believe they should even merge sensibly back into trunk when you have another attempt to land the feature. | 12:53 |
| === beuno-lunch is now known as beuno | ||
| jelmer | vila: have you heard anything more about the SRU? | 12:53 |
| vila | jelmer: no :-/ | 12:54 |
| DeeLay | maxb: if I merge trunk, then revert, there will be nothing to commit, won't there?? | 12:54 |
| maxb | Note carefully: "bzr revert .", not "bzr revert" | 12:54 |
| DeeLay | maxb: ah, nice | 12:54 |
| maxb | This will revert all the tree changes, whilst keeping the "I have merged revision X" metadata | 12:54 |
| DeeLay | maxb: that totally worked, reverse cherry picked from trunk, merged trunk to feature branch, and then tried a dry run of re-merging the feature branch into trunk and the changes come across again | 13:02 |
| DeeLay | thanks guys | 13:02 |
| idnar | so, this is sort of related to the conversation from earlier | 13:41 |
| idnar | -c 123 is equivalent to -r 122..123; is there any equivalent to -r 123..122 ? | 13:41 |
| jam1 | idnar: no shorthand form, though X..before:X works for all types of X | 13:41 |
| idnar | yeah... bleh | 13:41 |
| idnar | was writing an automated script, and my revisionspec is already 10 pages long :P | 13:42 |
| === jam1 is now known as jam | ||
| maxb | Yes, a backwards -c would be very useful | 13:43 |
| maxb | Subversion uses a negative number for this, but that's already taken in bzr. Took me a while to un-train my fingers from that one. | 13:44 |
| jam | vila, jelmer: testing question. I'm working on bug #740932, and I want to test that we cache the correct packed-stat value even though Transform does stuff like renaming the file after it is created. | 14:15 |
| ubot5 | Launchpad bug 740932 in Bazaar "building working tree doesn't update sha cache" [High,Confirmed] https://launchpad.net/bugs/740932 | 14:15 |
| jam | The specific problem is that the time to create and rename the file runs in under 1s | 14:16 |
| jam | which is the granularity of our sha cache test. | 14:16 |
| vila | touch the file with a specific time ? | 14:17 |
| jam | I'm trying to find a tasteful way to test it | 14:17 |
| jam | vila: so the point is that Transform is creating the file | 14:17 |
| jam | how do I touch it | 14:17 |
| jam | (where/when?) | 14:17 |
| vila | from the test ? hmm or from some hook triggered by a test decorated class ? | 14:17 |
| vila | that's not the first time I'd like to better control the clock, but here you want to observe a fs behaviour which is trickier | 14:18 |
| jam | vila: yep | 14:18 |
| jam | it does call os.rename | 14:18 |
| jam | which I could hack into | 14:18 |
| jam | but that is pretty ugly | 14:18 |
| vila | how about reducing the 1s to 1us ? | 14:18 |
| vila | for tests I mean | 14:18 |
| jam | vila: not optional | 14:18 |
| vila | make it so :) | 14:19 |
| jam | Dirstate's packed-stat is integers only | 14:19 |
| vila | ouch | 14:19 |
| vila | hmm | 14:19 |
| vila | how about changing its scale then | 14:19 |
| vila | again, for tests | 14:19 |
| vila | or may be you should have different tests for the different effects you want to observe | 14:20 |
| jam | vila: I *really* don't think we want to be hacking into compiled code and adding if checks in our tight-loop functions | 14:20 |
| jam | vila: the issue is that in the real world, it can take several seconds from the time we start creating files until we've finished the last one. which gives us plenty of files whose state we can cache | 14:21 |
| jam | but we have to be careful because we also rename the top-level ones right before we finish | 14:21 |
| jam | I wonder if I need to worry, because that rename is probably never going to be outside our 3-second window | 14:21 |
| vila | what do you want to test ? | 14:21 |
| jam | it doesn't help that Dirstate caches's its threshold time to the first time it checks | 14:22 |
| jam | vila: this is what I have so far | 14:22 |
| jam | at the point where we have Transform.create_file | 14:22 |
| jam | I store the sha1 and stat value of the file | 14:22 |
| jam | at the point that we have finished creating all of these files | 14:23 |
| jam | I then call Tree._observed_sha1 for everything I cached | 14:23 |
| jam | there is one step inbetween, where Transform renames all the files into place | 14:23 |
| jam | thus changing their 'ctime' | 14:23 |
| jam | but we could be saving the sha1 value with the new ctime | 14:23 |
| vila | huh ? renaming change the ctime of the containing dir not of files itself right ? | 14:23 |
| vila | err, mtime | 14:24 |
| jam | vila: renaming the *file* changes the ctime of the *file* | 14:24 |
| vila | ctime as 'creation time' ?? | 14:24 |
| jam | vila: stat | 14:24 |
| jam | ctime == last meta-info changed time | 14:24 |
| jam | on *windows* == creation time | 14:24 |
| jam | on Linux something different | 14:24 |
| jam | (we've talked about not paying attention to ctime, but we currently do) | 14:24 |
| vila | and you want to avoid calculating the sha1 for files that were only renamed ? | 14:25 |
| jam | vila: *today* after doing 'bzr co' the next 'bzr st' will re-read every file to check if it is up to date, and re-sha the content | 14:27 |
| jam | which is affecting eg linaro, because it takes >1m to re-sha the whole tree | 14:27 |
| jam | so bzr branch-for-feature ; bzr st; bzr commit; takes longer than it should | 14:27 |
| vila | yeah, I've read your analysis | 14:28 |
| vila | and you want to avoid calculating the sha1 for files that were only renamed ? | 14:28 |
| vila | or touched by the transform | 14:28 |
| jam | vila: I already have code that handles the 'create_content' part | 14:28 |
| vila | rhaa, calculate only for files modified, yeah, create_content | 14:28 |
| jam | I can easily add code that handles the "and the files are renamed into place" part | 14:28 |
| jam | vila: but I don't know how to test it | 14:28 |
| vila | ISTM you're trying to test from too high, get closer to the code that you want to test | 14:29 |
| jam | note, I just realized my changes need some updating, but I have a handle on that | 14:29 |
| jam | vila: so step through TreeTransform.apply inlined into a test case and assert the dict values? | 14:29 |
| jam | I really don't want to rewrite the apply function | 14:29 |
| jam | because of drift, etc. | 14:30 |
| vila | err, no, I thought about where you establish that a file need to be re-hashed | 14:30 |
| jam | vila: well, with my first fix, the test accidentally succeeds, because the file doesn't look like it needs to be rehashed | 14:32 |
| jam | because the timestamp didn't actually tick over 1 second | 14:32 |
| jam | because the 'rename' happened within 1s of the creation | 14:32 |
| jam | which doesn't happen in reality | 14:32 |
| jam | because creation can take a minute for large trees | 14:32 |
| vila | because you exercise too much code to properly test what you care about (is what I'm trying to explain :--/) | 14:33 |
| vila | if you go closer to tiny part you care about, you should be able to be more precise | 14:33 |
| vila | or is this code inlined in a compiled extension ? | 14:34 |
| jam | vila: the code that compares to see if a file is up to date goes through packed_stat which truncates to 1s resolution. | 14:34 |
| jam | (we compare packed_stats) | 14:34 |
| vila | inject them | 14:34 |
| vila | you're telling me that you can't have a test with sleep(3s) right ? | 14:35 |
| vila | so you have to change at least one constraint succeed :) The clock seem too hard, so that leaves faking the data based on this clock | 14:36 |
| jam | vila: I could detect it with a sleep(1) | 14:36 |
| vila | well, sleep(1) is bad :) | 14:36 |
| jam | or hacking os.rename to add a os.utime to mutate mtime to fake the ctime change | 14:36 |
| vila | sleep() is bad | 14:36 |
| jam | since you can't directly touch ctime | 14:36 |
| LeoNerd | I'm not sure you're -guaranteed- to notice a ctime tick using sleep(1) | 14:37 |
| LeoNerd | sleep(1) asks to sleep for no more than 1000ms. | 14:37 |
| jam | LeoNerd: while round(time.time()) == orig_time: time.sleep(...) | 14:37 |
| vila | as long as it's explained in the test *that* sounds better but involving os.rename() in your test seems like enlarging the scope of the tested code too | 14:38 |
| vila | jam: said otherwise: you seem to be writing a blackbox test when a unit test could be more precise | 14:39 |
| vila | "blackbox" with quotes | 14:39 |
| vila | jam: blackbox as in: not allowing to observe directly what you want to test | 14:42 |
| jam | vila: testing that 'bzrlib.transform.build_tree" has the sha hash values correct doesn't seem particularly 'black box' to me. | 14:42 |
| jam | and the lifetime of the caching has to be across the TreeTransform.apply stage. | 14:42 |
| jam | because you don't want to try to save the sha1 until you're done, to give it the best chance to be outside the 3s window | 14:43 |
| vila | jam: given that this function is more than 100 lines... it's hard to *not* consider it as an opaque box with a lot of side effects | 14:43 |
| vila | jam: the aim is good but it doesn't mean you can't test a building block | 14:44 |
| vila | ow, and it uses a 50 lines _create_files() too... | 14:45 |
| jam | vila: a fair amount of it is if blocks that you can avoid. by not setting accelerator_tree, etc. | 14:46 |
| vila | right, I'm beginning to feel your pain :-/ | 14:47 |
| vila | jam: can't you split out the part you're interested in ? | 14:48 |
| vila | jam: how many existing direct tests for _build_tree ? | 14:49 |
| jam | vila: by re-writing Transform.apply | 14:49 |
| vila | jam: good luck with that :-( | 14:49 |
| jam | and I still don't really know how to handle making sure we get the correct time for top-level files | 14:49 |
| vila | jam: anything smaller ? | 14:49 |
| jam | anyway, I have a couple other bits to fix now anyway. | 14:49 |
| vila | jam: you may be just be facing a hole in the test suite :-/ | 14:50 |
| jam | vila: so I could fake TreeTransform state, call one of the functions on it, and assert the after state | 14:50 |
| jam | but TT state is pretty big, too | 14:50 |
| vila | jam: a known one for that matter | 14:50 |
| vila | ok, so, best effort would indeed be to write blackbox tests here :-/ Sadly that means adding more tech debt... | 14:51 |
| vila | what {worries me|makes me sad} is that you end up talking about TT when you care about a packed_stat which TT doesn't even know about | 14:52 |
| === wgrant_ is now known as wgrant | ||
| vila | jam: from the you-wish-you-did-it-long-ago dept: use an in-memory fs and control its clock ! :-} | 14:55 |
| === JayFo is now known as JFo | ||
| jelmer | jam: hi | 15:20 |
| jelmer | jam: do you know how significant the memory usage improvements between 2.2.3 and 2.3.1 are in terms of fetch performance ? | 15:21 |
| jam | jelmer: you'd have to read the release-notes. I don't think it is huge, though. | 15:22 |
| jam | jelmer: stuff that accesses all chk pages can be quite a bit cheaper, I guess | 15:22 |
| jam | jelmer: "bzr ls -R" dropped from 400MB to 250MB, which is roughly equivalent to fetching a reasonable amount of data | 15:23 |
| jelmer | jam: ah | 15:23 |
| jelmer | jam: the fix you did after the gcc performance analysis hasn't ended up in a release yet right? | 15:24 |
| jam | jelmer: that is the "iter_entries_by_dir()" change? | 15:25 |
| jam | I don't think that has been released | 15:25 |
| jam | jelmer: actually, according to release-notes it is in 2.4b1 | 15:26 |
| jelmer | ah, cool | 15:26 |
| vila | jam, jelmer: according to the https://launchpad.net/bzr/+milestone/2.4b1 changelog, it is not | 15:35 |
| vila | jam: did I copy the wrong changelog or did you merged in the wrong section ? | 15:35 |
| jam | vila: lp only counts things that you target the bug to | 15:36 |
| vila | jam: I'm talking about the changelog the RM copied at the time the release was frozen | 15:36 |
| jam | vila: ah | 15:36 |
| jam | it landed in 5730 | 15:37 |
| jam | it certainly could have been merged into the wrong section | 15:37 |
| jam | since that happens *by default* | 15:37 |
| vila | and 2.4b1 is 5727 | 15:37 |
| vila | jam: no worries, just wanted to make sure jelmer got the right stuff | 15:38 |
| jam | vila: so I found a better way to poke at it. Use 'os.utime' between the time that we call create_file, and the time that we call .apply | 15:39 |
| jam | it is actually asserting something that doesn't happen, but it would catch a real bug | 15:39 |
| === oubiwann` is now known as oubiwann | ||
| === deryck is now known as deryck[lunch] | ||
| === r0bby is now known as robbyoconnor | ||
| === lamont` is now known as lamont | ||
| === deryck[lunch] is now known as deryck | ||
| === zyga is now known as zyga-dinner | ||
| === zyga-dinner is now known as zyga | ||
| === Ursinha is now known as Ursinha-lunch | ||
| barry | i'm having a problem trying push a branch to launchpad. it seems like bzr and hg are fighting each other for some weird reason. on natty. i get: | 19:52 |
| barry | bzr: ERROR: No such file: /~barry/mailman/restusers/.hg/requires | 19:52 |
| barry | but this is a bzr branch in a shared repo and hg shouldn't enter into it! | 19:53 |
| barry | (there is no .hg directory in this directory) | 19:53 |
| barry | i do have bzr-hg installed however | 19:53 |
| jelmer | hi barry | 19:53 |
| jelmer | barry: That's bzr-hg, although that bug should be fixed | 19:54 |
| jelmer | barry: how do you have bzr-hg installed? | 19:54 |
| barry | hi jelmer. apt-get install bzr-hg | 19:54 |
| jelmer | barry: the one that was synced today, or from earlier? | 19:56 |
| jelmer | barry: can you give the bzr-hg in the bzr daily builds PPA a try? | 19:56 |
| barry | jelmer: from a few days ago. apt-get upgrading now :) i'll let you know if that fixes it | 19:57 |
| bpierre | hi | 20:03 |
| bpierre | is the PQM version used by the Bazaar team the one from lp:pqm? | 20:04 |
| barry | jelmer: that did the trick. thanks! | 20:08 |
| jelmer | bpierre: approximately | 20:09 |
| bpierre | jelmer: :P, patched? | 20:09 |
| bpierre | I have been looking into it | 20:09 |
| bpierre | I managed to make it somewhat work | 20:09 |
| jelmer | bpierre: To be honest, I think we're just using lp:pqm but I'm not sure | 20:09 |
| bpierre | ok | 20:10 |
| bpierre | so do you know if your version work by making a direct lightweight checkout of lp for each merge? | 20:10 |
| bpierre | I see no activity on the lp code page for the project | 20:10 |
| jelmer | I'm pretty sure pqm creates a full branch, and that's what we're seeing too | 20:11 |
| bpierre | and a number of branches marked in developement and not merged... | 20:11 |
| bpierre | so branch lp:bzr, with tree, and then merge? | 20:11 |
| jelmer | bpierre: pqm is pretty much dead upstream; bzr (and launchpad too, IIUC) are looking to move to tarmac long term | 20:11 |
| bpierre | tarmac? | 20:12 |
| bpierre | ok, I'll look into it | 20:12 |
| bpierre | PQM, I add to make a number of patches, and still less than optimal ;( | 20:12 |
| jelmer | lp:tarmac | 20:13 |
| bpierre | yeah, seems to be tied to launchpad ;( | 20:13 |
| lifeless | jelmer: pqm's not dead, just not being changed unless there is a defect | 20:35 |
| lifeless | bpierre: yes, we run trunk of lp:pqm without patches | 20:35 |
| bpierre | lifeless: ok, so unless I missed something, everytime a merge is attempted, pqm does a lightweight checkout of the target branch, right? | 20:38 |
| lifeless | bpierre: yes, clean slate each time | 20:38 |
| bpierre | I see no support for caching | 20:38 |
| bpierre | so for a big working tree, a lot of network traffic | 20:39 |
| lifeless | bpierre: so, what you can do is use a local tree and set the published_to option | 20:39 |
| lifeless | s/tree/branch/ | 20:39 |
| lifeless | it will checkout locally (no network traffic) and do a push afterwards | 20:39 |
| bpierre | mmm, but I still need to update this local tree somehow, no? | 20:39 |
| lifeless | as long as pqm is the way things are landed this works fine; if you manually push to $wherever, then you need to do a manual push to that local branch too | 20:40 |
| lifeless | it would be quite reasonable to file a bug asking for a more transparent cache facility | 20:40 |
| bpierre | ok, I also ran into an issue with the way a working tree name is constructed, plus ploblems with encoding | 20:41 |
| bpierre | I also patched it for merge directive support | 20:41 |
| bpierre | (there is already a branch in lp, but with conflicts, and another I did not see until after making the patch) | 20:42 |
| bpierre | anyway, I wonder if the support for other VCSs is of interest? | 20:42 |
| lifeless | do you have some tests in your branch? I hesitate to incorporate changes which can break silently on future changes | 20:42 |
| bpierre | I understand completly | 20:42 |
| lifeless | the other vcs support is maintained by other vcs folk | 20:42 |
| bpierre | is it used? | 20:42 |
| lifeless | it used to be :) I have no idea now. | 20:43 |
| lifeless | theres no requirement that new features work on all vcses | 20:43 |
| bpierre | because I add to bypass some abstractions, to support merge directive inlined in a mail | 20:43 |
| lifeless | ah | 20:43 |
| bpierre | plus the code looks complicated | 20:43 |
| bpierre | at least to me :P | 20:43 |
| lifeless | it is, it started as a simple script | 20:44 |
| lifeless | and gew | 20:44 |
| lifeless | *grew* | 20:44 |
| bpierre | the lack of documentation also does not help | 20:44 |
| lifeless | code level docs? | 20:44 |
| lifeless | there is a docbook manual for users | 20:44 |
| bpierre | yeah, I'm starting to think it might be simpler to just start from scratch | 20:44 |
| bpierre | I'm problably way understimating the time it will take :D | 20:45 |
| lifeless | thats the usual thing | 20:45 |
| bpierre | the docbook manual in the code is not really helpful | 20:45 |
| bpierre | I add to look at the code and experiment | 20:45 |
| lifeless | so, caching transparently should be easy - have an option, say, 'cache_repository' and when thats set use bzrlib apis to cache the tip revision of the branch | 20:46 |
| lifeless | construct a temp branch in it during the merge - a few lines of code | 20:46 |
| bpierre | yeah, a few lines there, and few lines somewhere else... :P | 20:46 |
| lifeless | for your merge directive support; if it doesn't break other vcses, and you wouldn't mind if I broke it by mistake fixing other things, then it doesn't /need/ tests. | 20:47 |
| bpierre | I can't help to notice that every plugin that need to merge dupplicate parts of the bzrlib code for the merge builtin | 20:47 |
| lifeless | yeah | 20:48 |
| bpierre | *from the | 20:48 |
| bpierre | one question about the bzrlib API: is there a way to get the canonical URL for a branch? | 20:48 |
| bpierre | the only way I found is by opening it and looking at base | 20:49 |
| bpierre | what I mean is correctly expand lp:bzr to bzr+ssh://.... | 20:49 |
| bpierre | or expand my local bookmark bm:something to the real URL | 20:49 |
| bpierre | ? | 20:49 |
| maxb | bpierre: bzrlib.directory_service.directories.dereference(url) ? | 20:51 |
| bpierre | maxb: ok, I'll try | 20:51 |
| ps_jinx | spiv: I am getting this bug http://psjinx.pastebin.com/yxS2PNGm .. what can be the issues | 21:58 |
| jelmer | ps_jinx: That's a known bug related to proxies; it's fixed in newer versions of bzr. | 22:00 |
| ps_jinx | jelmer: but I'm able to pull the code successfully | 22:18 |
| jelmer | ps_jinx: that's a different code path | 22:19 |
| ps_jinx | ok | 22:19 |
| === Ursinha-lunch is now known as Ursinha | ||
| poolie | hi all | 23:19 |
| === JasonO is now known as Guest72019 | ||
| === tchan1 is now known as tchan | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!