[06:16] <poolie> hi all
[06:16] <poolie> hi spiv
[06:23] <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
[07:36] <vila> helllo !
[10:19] <jelmer> hi jam, vila
[10:19] <jam> hi jelmer
[10:33] <jelmer> jam: is there an easy way to trigger regenerating a particular index?
[10:33]  * jelmer is looking at bug 413430
[10:34] <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:35] <vila> jelmer: I use a script that deletes a .pack and its indices here
[10:36] <vila> jelmer: there are complications in same cases though (especially if you have uncommitted changes)
[10:36] <jelmer> jam: ah
[10:37] <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:38] <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:39] <vila> jelmer: may be out-of-date as a proposal but I think the script is still the same as the one I use
[13:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <jam> so "bzr init A; bzr status; rm -rf A/.bzr/; bzr status"
[13:28] <jam> what *should* that do?
[13:30] <jam> at the moment, it actually treats the final 'bzr status' as not modified
[13:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:40] <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:41] <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:45] <poolie> hi jam, vila
[13:46] <jam> hi poolie
[13:46] <vila> poolie: hey
[14:05] <poolie> vila, jam, you should join us in #ubuntu-uds-arany
[20:35] <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:37] <ovnicraft> how commit and keep the user in my tree?
[21:09] <maxb> ovnicraft: I'm afraid you're not making much sense. Can you try to describe what you want more clearly?
[21:45] <lifeless> jelmer: hi
[21:46] <lifeless> bu
[21:46] <lifeless> h
[22:27] <ovnicraft> maxb, i merge my branch with another
[22:28] <ovnicraft> when i commit i cant see the changes with user who did it
[22:28] <ovnicraft> they are applied with my user
[22:30] <jdobrien> ovnicraft, with bzr merge?
[22:30] <ovnicraft> yes
[22:30] <ovnicraft> i use 2.3.1
[22:32] <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