| === AuroraBorealis is now known as aurora|shower | ||
| === spiv changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | ||
| poolie | hi all | 06:16 |
|---|---|---|
| poolie | hi spiv | 06:16 |
| aurora|shower | i figured out my problem if its reveleant | 06:23 |
| aurora|shower | turns out it was using a ssh.exe using my PATH on windows, which was one that was used by git (irony?) and for some reason git's copy didnt work with it, so i uninstalled git and it works ifne | 06:23 |
| vila | helllo ! | 07:36 |
| === gthorslund_ is now known as gthorslund | ||
| === hunger_ is now known as hunger | ||
| jelmer | hi jam, vila | 10:19 |
| jam | hi jelmer | 10:19 |
| jelmer | jam: is there an easy way to trigger regenerating a particular index? | 10:33 |
| * jelmer is looking at bug 413430 | 10:33 | |
| ubot5 | Launchpad bug 413430 in Bazaar "ShortReadvError on index file" [High,Confirmed] https://launchpad.net/bugs/413430 | 10:33 |
| jam | jelmer: no | 10:34 |
| vila | hey jelmer ! | 10:34 |
| jam | indexes can contain data that is not stored in the .pack file | 10:34 |
| jam | such as the file_id, revision_id associated with the content | 10:34 |
| vila | jelmer: I use a script that deletes a .pack and its indices here | 10:35 |
| vila | jelmer: there are complications in same cases though (especially if you have uncommitted changes) | 10:36 |
| jelmer | jam: ah | 10:36 |
| vila | jelmer, jam: We should fix that in the next format... | 10:37 |
| jam | vila: we looked into it with the last format, but it bloated the size of .pack by about 10-15% | 10:37 |
| jam | file_ids and revision_ids are not very compressible | 10:38 |
| jam | so if we could shrink the indexes by ~ as much as we bloat the .packs then maybe | 10:38 |
| vila | jelmer: lp:~vila/bzr/697815-repair-repo was my last attempt | 10:38 |
| vila | jelmer: may be out-of-date as a proposal but I think the script is still the same as the one I use | 10:39 |
| === jdobrien is now known as webm0nk3y | ||
| === mbp_ is now known as poolie | ||
| jam | vila, jelmer: I need to get some feedback about WT and TreeReference implementations | 13:18 |
| jelmer | jam: Hi | 13:18 |
| jam | jelmer: so the source of the issues | 13:18 |
| jam | 1) I wanted to change the tree.iter_changes() code | 13:19 |
| jam | so that revert would do wt.iter_changes(wt.basis_tree()) instead of wt.basis_tree().iter_changes(wt) | 13:19 |
| jam | that turned out to reveal a bug wrt TreeReference | 13:19 |
| jam | specifically, WT.iter_changes(wt.basis_tree()) (used by 'bzr status') auto-detects when a file becomes a TreeReference | 13:20 |
| jam | sorry, when a *directory* | 13:20 |
| jam | becomes a TreeReference | 13:20 |
| jam | however, WT.inventory does not | 13:20 |
| jam | so WT.inventory.iter_changes(WT.basis_tree().inventory) was failing on tests about TreeReference | 13:20 |
| jam | 2) I did a simple fix, to change WT._generate_inventory() | 13:20 |
| jam | so that it would see new TreeReferences | 13:20 |
| jam | 3) There was some fallout for code paths that assumed this didn't happen | 13:21 |
| jam | mostly around the split code | 13:21 |
| jam | For example, WT.extract() was grabbing self.inventory[subdir_id] and passing that into a the new Inventory for the created subtree | 13:21 |
| vila | jam: well, AIUI, TreeReference implementation has never been completed, so I'm not surprised there are bugs there | 13:22 |
| jam | I can fairly easily move the Inventory creation logic before the new subtree is created | 13:22 |
| jam | vila: sure, I'm just trying to figure out how to fix it enough | 13:22 |
| jam | to land my revert improvements | 13:22 |
| vila | ok | 13:22 |
| jam | without leaving things as horribly kludges when I'm done | 13:22 |
| jam | (horribly kludged or horrible kludges, take your pick :) | 13:23 |
| vila | jam: target less horrible kludges ;) | 13:23 |
| jam | What is happening now | 13:23 |
| jam | is that I create the new subtree inventory ok | 13:23 |
| jam | I create a parent tree that doesn't have the subdir in it anymore (which suprised me, but ok) | 13:23 |
| jam | (it was how the code did it) | 13:23 |
| jam | But when it goes to update the working inventory it breaks | 13:23 |
| jam | this is because the dirstate blocks themselves still have the old directory *and its children* recorded | 13:24 |
| jam | WT._generate_inventory just skips subdir blocks that didn't have a parent *directory* read | 13:24 |
| jam | and TreeReference isn't a directory | 13:24 |
| jam | so that mostly worked | 13:24 |
| jam | I think now I have to go back and when I see a directory become a TreeReference (in _generate_inventory), I have to update the dirstate to let it know | 13:24 |
| jam | I'm hesitant, because it loses track of child identities | 13:25 |
| jam | but I think that is what 'bzr status' does today | 13:25 |
| vila | hmm | 13:25 |
| vila | I'd start by adding tests myself :-/ | 13:25 |
| jam | vila: except you can't really add a test if you don't know the *desired* behavior | 13:26 |
| vila | To at least demonstrate your diagnosis is correct (the added benefit will be to quickly get failing tests when you start changing the behavior) | 13:26 |
| vila | jam: I meant, starting from a pristine bzr trunk, add tests about the cases you're unclear about | 13:26 |
| jelmer | jam: what do you mean with "it loses child identities" ? | 13:27 |
| jam | jelmer: A TreeReference has no .children attribute | 13:27 |
| jam | so the recursive subtree that used to be versioned under the Directory all disappears | 13:27 |
| jelmer | jam: Ah, I see. | 13:27 |
| jam | consider Tree/A/B/C | 13:27 |
| jam | if A becomes a subtree | 13:27 |
| jam | B and C were versioned, but now are missing | 13:27 |
| jam | so "bzr init A; bzr status; rm -rf A/.bzr/; bzr status" | 13:28 |
| jam | what *should* that do? | 13:28 |
| jam | at the moment, it actually treats the final 'bzr status' as not modified | 13:30 |
| jam | because while it detects a TreeReference, that is never written back to disk | 13:31 |
| vila | first status says nothing, second one says unknown for A ? | 13:31 |
| vila | hmm, no | 13:31 |
| jam | vila: bzr init A says "unknown: a/.bzr/" | 13:31 |
| jam | second says nothing | 13:31 |
| jam | neither talk about A/B or A/B/C | 13:31 |
| jam | I'm pretty sure it is a bit borked | 13:32 |
| jam | but as I said, I don't want to fix all of TreeReference today | 13:32 |
| jelmer | yeah, that seems wrong | 13:32 |
| jam | just get my revert landed | 13:32 |
| vila | right, first says A unknown (while more or less realizing it's a TR not a dir), second one... should also says unkown, realizing A is a dir | 13:32 |
| jam | jelmer: so in the Extract case, it deletes the "A" from the parent inventory, and then calls self._write_inventory(new_inv) | 13:32 |
| jam | which then tries to build a TreeDelta | 13:33 |
| jam | which then sees that we now have a TreeReference there (it calls _generate_inventory again) | 13:33 |
| jam | and builds an inventory delta saying "delete the tree-reference at A" | 13:33 |
| vila | jam: you don't have to fix all the TR bugs, but landing a change in their behaviour withoutknowing whether or not you introduce new bugs.... >-/ | 13:33 |
| jam | however, the dirstate file says, ok, I'll delete A, but not all of its children, because it doesn't have any | 13:33 |
| jam | and then "oops, you asked to delete a directory but not its children" | 13:34 |
| jam | vila: I don't really care | 13:34 |
| jam | we don't support them now | 13:34 |
| jam | my changes won't make them any more supported than the existing tests | 13:34 |
| vila | but they could make them less supported, that's the point | 13:34 |
| jam | I don't have to make things better for TR, and I feel comfortable making it slightly worse | 13:34 |
| jam | people are welcome to file bugs which we can respond to with regular priority | 13:35 |
| jelmer | We're not sure the way tree references work in working trees are necessarily the right way, are we? | 13:35 |
| jam | *right now* it has taken me 3+weeks to land a simple "bzr revert" takes 5s instead of 5min | 13:35 |
| jam | jelmer: *I'm* certainly not thinking the current behaviour is "right" | 13:35 |
| jam | vila: my original fix is *quite simply* a 1 line I' know it is correct change | 13:36 |
| jam | change basis_tree.iter_changes(tree) to | 13:36 |
| jam | tree.iter_changes(basis_tree) | 13:36 |
| jam | and swap the parameters in the next lines | 13:36 |
| jelmer | jam: me neither - I certainly don't think the working tree support for nested trees is complete enough | 13:36 |
| jam | very straightforward, with *tons* of fallout | 13:36 |
| jam | vila: if there is that much fallout from just this, TreeReferences are just plain broken | 13:37 |
| jam | so I don't mind a little regression there | 13:37 |
| vila | jam: my point is that you're at least in a position to write expected failures or file bugs, if you don't that knowledge is wasted | 13:37 |
| jam | vila: anyone who is serious about implementing TreeReference is going to run into everything I've run into quite quickly | 13:38 |
| jam | and will be at a point to make decisions on it | 13:38 |
| jam | IMO | 13:38 |
| jam | filing a "this is broken" is not a helpful bug | 13:38 |
| jelmer | jam: how much treereference-specific code is actually in working trees? I wonder if rather than having the current level of support it makes sense to just rip it out for the moment rather than having something known broken in there. | 13:38 |
| jam | jelmer: there is about 30+ occurences of "tree-reference" in workingtree* dirstate* | 13:40 |
| jam | it isn't particularly trivial | 13:40 |
| jelmer | ah, hmm | 13:40 |
| jam | hmm.. maybe one change is to revert my change to WT.inventory | 13:41 |
| jam | and instead make Inventory.iter_changes(Inventory) (the generic logic) try to do the lookups | 13:41 |
| jam | then at least WT.inventory would be a direct match for WT.dirstate._dirblocks | 13:41 |
| jam | that's probably better | 13:41 |
| poolie | hi jam, vila | 13:45 |
| jam | hi poolie | 13:46 |
| vila | poolie: hey | 13:46 |
| poolie | vila, jam, you should join us in #ubuntu-uds-arany | 14:05 |
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| === Noldorin_ is now known as Noldorin | ||
| === Ursinha-afk is now known as Ursinha | ||
| ovnicraft | hello i merge with a branch my repo was updated but i need keep the commiter name in my tree | 20:35 |
| ovnicraft | how can i keep this ? | 20:35 |
| ovnicraft | how commit and keep the user in my tree? | 20:37 |
| maxb | ovnicraft: I'm afraid you're not making much sense. Can you try to describe what you want more clearly? | 21:09 |
| lifeless | jelmer: hi | 21:45 |
| lifeless | bu | 21:46 |
| lifeless | h | 21:46 |
| === medberry is now known as med_out | ||
| === JasonO_ is now known as JasonO | ||
| ovnicraft | maxb, i merge my branch with another | 22:27 |
| ovnicraft | when i commit i cant see the changes with user who did it | 22:28 |
| ovnicraft | they are applied with my user | 22:28 |
| jdobrien | ovnicraft, with bzr merge? | 22:30 |
| ovnicraft | yes | 22:30 |
| ovnicraft | i use 2.3.1 | 22:30 |
| maxb | You should look at "bzr log -n0" | 22:32 |
| maxb | It is quite correct that the merge revision is attributed to you - you did it | 22:32 |
| === rvba_ is now known as rvba-afk | ||
| === Ursinha is now known as Ursinha-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!