On Wed, Oct 10, 2012 at 11:30:22AM -0400, C. Michael Pilato wrote: > - Improved handling of local moves/renames - looks like we're down to > multi-layer move issues right now. Is that correct?
Well... sort of. I've already fixed the way mived-rev moves are represented in the DB schema, and also disallowed mixed-rev moves from happening by default. This gets is somewhere close to having the multi-layer move issues done. However! While we're finally storing move information correctly (at least in terms of the current state of the art), we're not actually *using* it for anything yet! All behavioural changes I had implemented on top of the old moves storage code, which was broken for multi-layer cases, have been reverted. So if we release move support in its current state it won't buy our users much and we might as well not bother shipping this feature. So I'd like to improve handling of some tree conflicts involving moves before release. At the rate we're currently going (and with prospected schedule at $JOB) I suspect that this won't be done before December. If the community decides that this is taking too much time I won't complain and work towards 1.9. After all, I started working on this before 1.7.0 was even released, so I've certainly spent a lot of time on this as it is. And there are other nice new features queued up which I wouldn't want to hold back for this. But I would be happier to release 1.8 with at least some behavioural improvements around conflicts involving moves. A recent IRC discussion between me and Philip about what's still needed starts here: http://colabti.org/irclogger/irclogger_log/svn-dev?date=2012-10-08#l175 It starts a bit earlier actually but it's quite long. If you'd like to read the entire thing please scroll up a bit.
