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