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.
Received on 2012-10-10 22:11:02 CEST