=== jam1 is now known as jam [07:32] moin [08:12] morning! [08:12] sup mgz! [08:13] hi all ! [08:17] jam around yet today? [08:17] he was around in #-kitchen earlier [08:20] ace. [08:21] mgz: /wave [08:44] mgz: do you still happen to have the PQM output for merge-grep? [08:48] forwarded [08:48] and you have too many email addresses with no obvious pattern for when you use which ones :) [08:50] mgz: gracias :) [08:51] Solution: CC all? [08:51] :) [09:05] mgz: hmm, there are also a bunch of tests that fail in a different locale [09:05] hm, I'll branch and see [09:06] I'm running with spanish here - it at least appears to have enough things translated [09:06] you're learning spanish? [09:07] mgz: different computer :) [09:07] laptop is German, desktop is Spanish [09:16] jelmer: IIRC lifeless was using Latin for a while [09:16] that, and vila tried to use French, but found it too confusing [09:16] :) [09:17] * jelmer chuckles thinking of vila being confused by French [09:18] yup, same here ;) [09:19] truth is, to clear confusion, the best way for me is often to translate back to english... [09:20] vila: do you "think" in English when you speak it, or do you translate back to French mentally? [09:21] jelmer: I'm at the point where I sometimes think in English but need to speak in French ;) [09:21] family hate that ;) [09:21] :) [09:21] mostly depends on the topic discussed [09:22] so, for technical matters, I often don't know how to translate idiomatically [09:22] but people around me are helpful ;) [09:27] heh [09:52] mgz: ping me when you're ready to discuss some resolve proposals of yours [09:52] ping! [09:55] I'm looking at the introduction of the auto action and I [09:55] meh [09:55] I'm not sure I agree [09:55] --done seems fine to me to include what you put in --auto [09:56] wait, which one? [09:56] * mgz went a bit overboard with different branches [09:56] I'm back to resolve_auto_refactor [09:56] okay [09:56] back to the basics: merge creates a conflict because bzr cannot decide which action is required [09:57] resolve should be taught to recognize that the user did something and the conflict is not there anymore [09:57] that's what '--auto' seem to do in your proposals [09:57] but in fact, I'd prefer that --done cover that [09:58] so, really 'auto' here is "I've done some changes to the tree, have another look and see if you still think there are conflicts" [09:58] i.e.: the context has changed, bzr does not see a conflict anymore, the conflict object can be deleted [09:58] yup [09:58] which is mostly what people want [09:58] but --done is still needed [09:58] when ? [09:59] otherwise, how for instance, with a conflict that involves a deletion [09:59] do you say "no, really, keep it" [09:59] deleting the object and --auto works, you clearly want the deletion to stick [10:00] say that again in commands executed by the user ? [10:00] * vila tries to get it [10:00] but there's nothing to distinguish "haven't decided if I want this object still" and "want to keep the object" [10:00] eg, I delete d/ [10:00] you add d/f [10:00] I merge your branch [10:01] get a conflict on d/ [10:01] filesystem looks like [d/, d/f] [10:01] * vila nods, that's 'merge' this specific case [10:01] if I want my change to stick, I delete d/ (and maybe move d/f somewhere else) [10:01] if I decide against deleting d/ because you're now using it, I need bzr resolve --done d [10:02] I don't see a neater way out of that [10:02] what does --auto does in this case then ? [10:02] we could alos move d/ to d.conflicted/ and make the user delete or move it back [10:02] but that doesn't seem easier. [10:03] the key is that an action should automate what is manual otherwise, --auto sounds a bit like 'just do the cleanup' which --done is already targeted at [10:03] there's also the "my file has the line '=======' in it" case [10:03] and preferably the action comes in two flavors: favor this or favor other [10:04] auto is bascially just a generalisation of `bzr resolve` which is pretty much all I ever use [10:04] it's unlikely to ever be passed in, it's just a good safe default [10:05] still sounds like a variation of --done rather than a different action [10:05] --done is by definition not safe [10:06] yup [10:06] it's a shut-up-and-believe-me option [10:06] that's what the thread was about IMHO: make it safer [10:06] okay, so I disagree [10:06] when in doubt, requires --force [10:06] we still need the unsafe option [10:06] --done --force [10:07] and I don't see the benefit of `resolve --done` and `resolve --done --force` over using `resolve --auto` and `resolve --done` [10:07] may be we just disagree on the name [10:07] --auto sounds magical: do the right thing (including actions like deleting a file or add'ing it or whatever) [10:07] they're clearly different options, --done already does the right thing, our auto logic already does the right thing just isn't exposed as a flag [10:08] we can name auto whatever, I doubt anyone will ever actually pass it, it's just the default [10:08] it's auto in the existing code is all [10:09] what triggered my question is that you modified existing tests by adding --auto, as if the default behavior (or command-line option default value) has changed === zyga is now known as zyga-afk [10:09] right, the whole point is to change `bzr resolve FILE` to be 'safe' [10:10] but then go back around and make `bzr resolve FILE` still do the right thing [10:10] (by making auto smarter) [10:13] still blurry [10:13] I need to write up some user story type things for the list really [10:13] some conflicts just can't be "checked" without asking tree-transform to rebuild the conflicts [10:13] it doesn't help that a lot of the conflict cases we have are bugs at about three different levels [10:14] yeah, hard stuff [10:14] also, action_* in conflict objects should *always* use a tree transform [10:14] like... not having precious/junk distinction, switch being unsafe, doubling conflicts on deleted directories... [10:14] I made the mistake in the past of using direct actions, that's not robust and may introduce subtle failure modes [10:15] yeah, lots of entangled stuff [10:15] as in, the ones using tree.remove are wrong? [10:15] yup [10:15] there are still some left right ? [10:15] bah, better check myseflf [10:16] yup, and I added a another one because I couldn't work out how to change state 'missing' to unversioned/gone [10:16] basically just want to remove the file_id from the inventory but couldn't find a good way of doing that [10:16] right, DuplicateEntry is wrong and should be rewritten [10:17] right, so tt.unversion() or something [10:17] tree.revert may be ok (if it relies on tt under the hood) [10:17] unversion checks that the file exists [10:19] urgh [10:20] err, are you sure you don't just need to register a trans_id ? [10:21] no, not sure, I didn't try using a tree transform. [10:22] right, then that's an example of why tt should be used ;) [10:24] hmm, I wonder if just building a tt against the current working tree will get rid of the conflicts already resolved by the user... [10:24] hm, and there is a bug in the current auto resolve logic, though earlier than I thought: [10:24] [10:25] with a pristine bzr.dev ? [10:26] yup. [10:27] hmm, sounds like a fallout from a very old fix, here, kind() should just returns None (if the file does not exist anymore, it's kind is None) [10:27] and a similar one with bzr rm rather than rm: [10:29] great :-} [10:29] worth fixing [10:30] * vila still paging in context [10:32] okay, so I think that check wants to be `if not tree.has_id(self.file_id) or tree.kind(self.file_id) != 'file': return` [10:32] in otherwords [10:32] we have a conflict in a text file [10:33] if the user has removed the file - it's resolved, they deleted it [10:33] if the user changed the file into a symlink or directory - it's also resolved, it's not text any more [10:34] otherwise we peek at the bytes on disk looking for conflict markers, if they're gone, it's resolved [10:35] otherwise we should raise ConflictUnresolved or whatever we go for over NotImplementedError [10:35] ideally with contenxt like line number [10:37] "not text anymore" and we never try to keep the file-id when the kind changes, it makes no sense [10:38] * vila agree with ConflictUnresolved of StillThere or whatever [10:38] coming back to the internal 'auto' action" [10:38] s/"/:/ [10:39] when I started working on 'resolve' I first thought that it should have been called 'resolveD'. Then I started added actions which made 'resolve' get some meaning [10:39] but really, 'done' and 'auto' (as internal actions) are still in the 'resolved' realm [10:41] which is also part of my reluctance to accept --auto as an action from the user pov [10:42] in fact, the idea while discussing with poolie at the time was that the user should never have to issue 'bzr resolve --auto FILE' because other parts of bzr will have taken care of the conflict [10:43] another way to look at it is that if --done cannot clean up safely, the user still have to do something. [10:44] If there are multiple choices there, --auto won't be able to decide [10:44] it's ok for the conflict markers because there is a single possible action: remove the markers [10:45] but I fear it won't be true for all conflicts [10:45] hm, `bzr resolve -d g g/f" ... does not work [10:45] the path is taken as relative to the repo [10:45] not cwd. [10:45] is that the normal form for -d? [10:46] ha ha, and that's not mentioning multiple conflicts that can interact and should be resolved in the proper order :-} [10:46] regarding -d, I think you've just entered unexplored territory :) [10:47] okay, I agree there's a lot of mess in resolve currently [10:48] right, which is why I'm unclear about whether --auto is legit or would just add to the confusion [10:48] but... the current state is we have a number of broken common cases [10:49] which are not actually hard to fix, and the code basically supports doing it in a sane manner [10:49] in other words: if you were talking about enhancing 'resolveD' I'll be +1, for 'resolve'... it's less clear [10:50] but the content of your auto_* methods are certainly valuable [10:50] I don't see the benefit in the kind of procrastination over details, like in that bazaar mailing list thread [10:51] right [10:51] when we can just make the code a bit better and get most of the pain resolveD [10:51] right too [10:51] how about just rewriting auto_resolve then and don't touch the command itself yet ? [10:51] I'm not attached to the name 'auto', but the behaviour from `bzr resolve` is useful and is worth generalising [10:52] seem we are in agreement ? [10:52] doing that takes me back to this just being a code refactor [10:52] 'that' 'this' /me lost :) [10:53] without also making auto understand when other kinds of conflict are done with, we need the unsafe --done or --all far more often [10:53] so the extra pain of requiring that isn't worth the interface breakage for users [10:54] so you still agree with turning auto_resolve into conflict.action_auto kind of refactor ? [10:55] that may not be enough to address all multiple conflict cases but neither does the actual code [10:55] yes. there's a nice mechanism for removing conflicts, using that rather than having a seperate method on tree clearly makes sense. [10:55] great [10:56] lunch here but after that I'm still available to discuss or even help writing tests and/or code [10:56] I understood 'just rewriting auto_resolve' as you not wanting bzrlib/conflicts.py touched. [11:03] jelmer: so, I didn't get any different failures in another locale with -d bp.grep, do they only show up when the other failures are fixed? or can you give me a test that fails and the traceback? [11:19] mgz: those were other bzr tests [11:25] okay, will do a full test run over lunch [11:28] mgz: back, indeed, I do want to pursue the efforts in conflicts.py [11:30] okay, bb.test_debug.TestDebugBytes.test_bytes_reports_activity is broken [11:30] needs to either not install translations or not check for the english string [11:30] I expect there are a few others like that [11:31] a way to force english messages (as expected by tests) sounds like a useful resource [11:32] we've got one :) [11:32] I assumed all the blackbox tests used it, but apparently it's just some of them [11:33] jelmer: is it ok if we push back our call by a couple of minutes? [11:34] like at 2:30? [11:34] (I have a 3:30 with Francis, so I still need to finish on time.) [11:35] ...I thought Francis was on holiday still? [11:35] mgz: I think he is in Isle of man this week, and he was still hoping to get ahold of me [11:35] at least, he still has our meeting scheduled [11:35] ah, yes, that might be it. [11:36] mgz: it is possible that *next* week is Isle of Man, though. [11:36] I think it's this week, but then he's off next week as well. [11:38] jelmer: anyway, I'm going to go for a quick run, I'll check back in when I get back. [11:43] jam: sure, that's okay for me [11:46] mgz: damn, according to bug #688506 I've changed my mind... [11:46] Launchpad bug 688506 in Bazaar ""bzr help conflict-types" suggests incorrect "bzr resolve --auto" command line" [Undecided,Confirmed] https://launchpad.net/bugs/688506 [11:47] * vila goes back to the attic to find the read-my-own-mind-in-the-past machine [11:47] I'm far too polite to point such things out... [11:48] but yes, you wrote all the code to make this easy. [11:49] so at one point I considered that the disctinction auto/done was valid, why I don't get that feeling *now* is... either irrelevant or indicates a source of issues ;) [11:51] on the other hand, I was knee-deep in the code at the time and may have missed the distinction I'm making today: --auto carries the idea that suddenly bzr knows how to resolve the conflict (that's wrong because bzr wouldn't have generated a conflict in the first place otherwise). [11:53] mgz: and I think you captured the right idea with: `bzr resolve` followed by `bzr resolve --done FILE` if the auto resolution fails for something in particular [11:53] which doesn't require auto to be an action the user can specify === zyga-afk is now known as zyga [11:54] in summary: let's make auto an internal action used by `bzr resolve` or in other places (bzr rm), keep --done for the cases where it fails [11:55] and may be rename it to carry the idea that the intent is to get rid of the conflict is there enough evidence that the user did what was needed [11:56] mgz: are we still in agreement ? [13:00] vila: so, mulling over that while I had much lunch [13:00] I think we basically agree on the implementation? [13:01] that's my feeling as well [13:02] I don't see the benefit in having three choices for actions to remove conflict markers, and a fourth that's only selected if you don't specify one of the others [13:03] err, which choices ? [13:03] generally with pick-one options, we include all the options, even if one is a default and won't normall be passed [13:03] indeed [13:03] we have --done, --take-this and --take-other [13:04] I don't see why it's important to avoid adding a new option if that's how the underlying implementation actually works [13:04] and it wouldn't get in the way of future ui reshuffling should anyone want to take that on. [13:18] because --done is already an alien and adding another one makes this even more confusin [13:18] g [13:20] okay, but I don't think it's less confusing having a magic differen behaviour when there's no --action [13:20] some people don't even understand that they need to resolve the conflicts, give them --auto... and they will complain that it doesn't resolve the conflict ;) [13:20] at least with a flag it can be documented in the help. [13:21] because as you argue, `bzr resolve` will clean up what it can [13:23] both done and auto should not be needed in an ideal world, auto would be called as soon as bzr it involves and --done shouldn't be needed at all [13:23] s/bzr it/bzr is/ [13:24] I don't mind keeping done, adding auto seems to go in the wrong direction though, if it's auto, why the hell should I tell you ?? [13:25] vila: because bzr is not a daemon [13:25] fewer cases [13:26] in presence of conflicts you can imagine 'bzr st' calling 'bzr resolve' [13:26] what will be left then ? [13:26] or `bzr commit` for that matter. [13:27] not much, but that doesn't really matter. we have a legacy command to deprecate that happened to grow a name for a default switch more recently. [13:27] and in the mean time, things at least reflect the current state of the code. [13:28] which default switch ? [13:28] `bzr resolve --auto` as a new alias for `bzr resolve` [13:29] huh ? This didn't land right ? [13:29] sorry, confusing you with tenses [13:30] I was using the past, but from imagining a future state where we make `bzr st` and other things remove resolved conflicts [13:30] so, *when we land better conflict handling*, we *would* have a legacy command... [13:31] ha right, which is why I arguing (and thought you agreed) to keep things as they are but internally add action_auto [13:31] this kind of thing is much easier in german... [13:31] i.e. do not add --auto [13:31] okay, so that's the disagreement [13:31] I think changing the internals to use the fanciness in conflict is good [13:31] which you also think [13:31] yyes [13:32] but think it makes sense for the ui to reflect the implementation, given it's a small but real change [13:32] simplest thing and all that. [13:34] well, I say it's confusing and doesn't provide additional feature. Simpler to explain: if you don't know: `bzr resolve`, if you know `bzr resolve --action=xxx ITEM` [13:34] and 'bzr resolve` is getting better [13:34] but the docs will be the same regardless [13:36] magic is bad, but refusing to name it doesn't make it any better [13:38] then you should be able to give a better explanation between auto and done [13:38] that would be good indeed [13:38] and the help in general would benefit from some polish [13:38] because, really, my reluctance to document auto is that I can't describe what it does (especially because it's currently undefined for most of the existing conflicts) :) [13:39] whereas done, well, as brutal as it is, is clear [13:39] it tries to detect conflicts that have been manually resolved and marks them as such [13:40] for a given conflict [13:40] fitting that in a flag description isn't terribly easy it's true [13:40] but they are cases where several conflicts can be involved which there is still hope to address as a whole [13:43] if --auto were --check or something innocent like that evoking a non-destructive action (as far as user data is concerned), that will be different [13:45] 'resolved --auto' makes sense 'resolve --auto' implies that bzr will magically resolve the conflict, that's the part that I dislike [13:47] 'resolved --done' makes sense, 'resolve --done', well, is acceptable [13:52] check doesn't seem bad [13:52] any other suitable names? [13:53] cleanup ( less good IMHO) [14:04] --refresh ? [14:28] have we got a less lame way of creating a branch in memory than bzrlib.branchbuilder? [14:33] no [14:34] mgz: don't feel bad writing less than perfect tests for conflicts, that would still be better that the actual lacking tests ;) [14:34] I mean, missing ones [14:35] mgz: and keep in mind you are starting a new kind: action between merge and resolve, none of them exist IIRC [14:52] hello everyone. I was wondering if I could get some help on fixing an issue I'm consistently having with bzr pipelines: every time I pump changes in the pipeline, the pipes get broken with a "IndexError: list index out of range" (full traceback here http://pastebin.ubuntu.com/1119547/ ) [14:53] I asked about this a couple of weeks ago, I was told to run bzr repair-workingtree, and if I run it with --force it fixes the IndexError, but I would like, if possible, not to have to run the repair eveyr time after a bzr pump [14:59] nessita: is there a bug against bzr-pipeline for creating the dirstate corruption in the first place? [15:00] if you can reliably reproduce it, I'd try to get as minimal a case as possible [15:00] mgz: makes sense, will try to do so [15:04] the pyx and py versions look much the same, so you could also try running in a clean bzr source dir with BZR_PDB=1 set then poking around the entry that's broken [15:08] mgz: got a minimal example, will file the bug now, what project shall I file it against? bazaar? (or is there a pipeline specific project?) [15:09] bzr-pipeline [15:12] there's possibly a core issue as well as we should really let plugins break dirstate, but it's easy to add tasks and move things later [15:13] * mgz branches the source and looks at what pump actually does [15:17] ...various aarony magic, but basically switch/merge/commit repeated [15:21] mgz: bug filled at https://bugs.launchpad.net/bzr-pipeline/+bug/1030923 [15:21] Ubuntu bug 1030923 in bzr-pipeline "After bzr pump, "next" pipelines have a broken dirstate (got IndexError: list index out of range)" [Undecided,New] [15:21] mgz: let me know if I can help debugging any further [15:21] mgz: shall I also attach the "/var/crash/bzr.1000.2012-07-30T15:07.crash" that the bzr st reported? [15:47] Hi ... I have a question. I thought my branch was bound and I made a bunch of commits that turned out to be local. I did bzr bind. I did bzr update which made my local commits show up as a pending merge. But I don't want it to show as a merge, I wanted to bzr push instead. [15:47] I see that my head is still in the repo. [15:47] Hold on I skipped a step. [15:48] I then did bzr revert and I'm back to before I started my commits. [15:48] I can see that my revision is still in the repo by doing bzr heads --all. [15:48] But I don't know the command to make that dead head the head of my branch. [15:52] I found it: bzr pull . -r revid:blahblahblah [16:14] Dan_: out of trouble ? Looks like you understood what happened and did what was needed :) [16:34] Yes, I figured it out ... thanks ... I just couldn't find the answer with google very quickly and thought IRC might be faster. :) I just uncommitted a revision because I know it prints out some message like, "You can restore the revision you just uncommited by using this command." [16:36] yeah, also, you could have done the pull earlier and just push [16:37] with a valid use case for 'bzr revert --no-backup' (which I never recommend otherwise) [16:38] and finally, I'm pretty sure 'bzr missing' would have ring a bell about the commits while unbound [16:38] never heart to use bzr missing [16:39] or 'bzr config' even === deryck is now known as deryck[lunch] [17:28] vila: when I created a branch, added files, then I ignored a folder... however then I decided to move this ignore into bzr user config file (bazaar\2.0\ignore)... but when I remove ignore from .bzrignore in branch 'bzr status' shows unknown folder (the one I wanted bzr to ignore) [17:35] vila: well that's weird - Bazaar Explorer (I believe correctly) doesn't show that folder as unknown (in working tree I see that it's ignored)... however 'bzr status' shows that folder as unknown [17:46] * vila blinks at mnn [17:47] mnn: even if you quit/start explorer ? [17:52] vila: still the same [17:52] isn't this a bug? I mean bzr must be using bazaar\2.0\ignore because it works on my other repo/branch === deryck[lunch] is now known as deryck [17:54] bzr add obviously isn't helping (adds whole directory and its children) [17:57] you can test your ignore file with 'bzr ignored [17:57] grrr [17:57] you can test your ignore file with 'bzr ignored' and 'bzr add --dry-run' [17:57] yeah ... 'bzr ignored' returns nothing [17:58] bzr add --dry-run wants to add supposedly ignored folder [18:00] I can't imagine why explorer differs... but if 'st'and 'add' agree, then there is something fishy there... [18:00] dinner time here, file a bug giving as much context as you can [18:01] ok, thanks for the help in the meantime [18:06] I can't reproduce it :( [18:07] ... on a new, clean repo/branch [18:13] already added files are not taken into account when dealing with ignored files, this matters only for 'bzr add'ing unversioned files [18:14] well... I removed the folder: 'bzr remove --keep folder' [18:14] I must have broken something here [18:24] > when dealing with ignored files, this matters only for 'bzr add'ing unversioned files [18:24] I believe that ignored files should be taken into account by 'bzr status' as well, right? [18:42] mnn: right, but displayed as unknowns there *iff* they are unversioned [18:45] so basically there's no way to make bzr ignore these files without adding them to .bzrignore? [18:45] *this folder [18:45] Hi. Is bzr-fastimport-0.13.0 incompatible with bzr-2.5.1? At least I get "ImportError: cannot import name error" at "from bzrlib.trace import error, note" in bzrlib/plugins/fastimport/branch_updater.py and checking bzrlib.trace in the 2.5-branch, there's indeed no error function. [19:21] mnn: err, the way to make nzr ignore these files *is* to add them to .bzrignore OR add the right regexps in ~/.bazaar/ignore [19:21] s/nzr/bzr/ [19:23] well they already are in %AppData%\bazaar\2.0\ignore (I'm using WinXP)... and the same ignores work for other repos/branches [19:23] the problem is that I removed the ignores from .bzrignore and added them to global ignores (in bazaar\2.0\ignores) [19:24] and now bzr is showing them as unknown (Bazaar Explorer doesn't show them) [19:24] doesn't make sense, so I should be missing some info [19:24] or there is a bug [19:24] if you can't reproduce in a clean branch, something is going on in your branch [19:26] wait I might just have reproduced it... need to try it again [19:33] vila: sorry for bothering you - when I discovered this "bug" I was using different BZR_HOME path than normal in %AppData%... when I used regular one in %AppData% unknowns doesn't show up [19:33] but thanks for help anyway [19:34] doh, then of course you don't find the right ignore file, no worries, thanks for giving the answer to this puzzle :) [19:34] yeah, I'm aware of that... just didn't notice it :( [19:39] Hey folks, I recently upgraded to OS X Mountain Lion and it borked my bzr install. Upon running any bzr * command, it tells me bzrlib is not in my pythonpath. How can I add it back? [19:46] in mac ignorance, just reinstall it? [19:46] DrDynamic2: better file a bug against bzr-mac-installers on launchpad (https://bugs.launchpad.net/bzr-mac-installers), I don't have osx ML to test so I can't tell which python version is provided nor where your bzrlib is installed [19:46] or rather was installed nor whether it's compatible with your installed python [19:49] vila: It's 2.7 that is provided, that seems to be the cause. [19:49] Alright I'll file a bug and reinstall :( [20:05] hi, is bazaar recommended to be a DAM ? [20:06] I want to get Versioned a Maya project, and I know git is not very keen on big files, so I am looking for a native support (git-annex) [20:14] bzr has the same issue git does === iBasic is now known as BasicOSX [22:21] could someone explain to me, when does iter_changes() returns (None, None) for kind? [22:21] because right now it seems that it does for delete directories... but I noticed that just now [22:24] also what are the exact meaning of versioned tuple? it's all fuzzy to me, what's written in InterTree.iter_changes() [22:46] really? nobody? oh, come on... :( [22:51] the two tuple from iter_changes? [22:52] it's like the others, first item is state in the old tree, second is state in the new tree [22:52] ah, you'd quit [22:52] yeah, it shut me down [22:52] did you wrote something? [22:53] by versioned tuple you mean the 2-tuple that's the fourth item in iter_changes results? [22:53] it's like the others, first item is state in the old tree, second is state in the new tree [22:53] yeah [22:53] ah [22:53] yes, thanks [22:53] but note aloo want_unversioned defaults to False [22:55] because my auto-rename-fix has failed on one autorenaming a few hours back and now I want to reproduce it and got into situation where kind is (None, None) (which I really didn't anticipate) [22:56] also why is kind (None, None) - both for old tree and new tree? [22:56] it does seem a little suprising [22:57] could it be because it's a directory that's ignored? [22:58] I suspect it could happen if a file was added in this revision [22:58] but is then removed from disk [22:58] so, 'missing' state with no parent in the last revision [23:01] yes, exactly that. [23:26] wgz: thanks for approving auto-rename-fix, but that was a bit to early... I mean I just reported that it does not work on the situation described above [23:31] I also put it up for another review at the same time :) [23:31] I should have added a text string as the review time to emphasise I've not actually thought about the logic in it yet [23:31] *review type [23:32] adding more failing test cases for things that break is a good way to proceed I'd say if you're still having issues [23:34] well first I need to wrap my head around whole iter_changes() and its return values for various tree states [23:36] maybe grep for some tests that use iter_changes and add some variations on your test that also check its output maybe? [23:36] ...anyway, I need to go to bed before I get any more cross-eyed [23:36] I will go as well [23:36] thanks for help and guidance [23:36] good night [23:38] night!