On Thu, Apr 19, 2012 at 8:51 AM, Andy Singleton <andy_at_assembla.com> wrote:
> Yes, I agree. If merge handles moves, and if merging between branch and
> trunk doesn't require arguments and reintegrate, then it would work in
> enough cases to make people comfortable with the review-and-merge workflow.
>
> It does seem that moves and renames cause a high percentage of user
> complaints. People don't commit moves in the correct way, and they never
> will, and they get merge problems even if they do. It is possible that you
> could eliminate about 90% of these complaints by
> * Putting in an agent that looks for moves and renames heuristically,
> assumes that it is correct when it finds something, uses the information for
> any current merge or update.
> * Add move information to next commit, to make it easier to handle moves and
> history in the future. This step is apparently optional, as git handles
> moves more effectively than subversion using only the heuristic detection,
> without move tracking.
For the record, include move information when committing is a primary
goal of Ev2. We currently send move information in the case of
repos->repos moves on the ev2-export branch, though there is still the
need to store this information on the server and then provide it to
the client when doing a merge. And it will only work for future
revisions, not historic ones, as you say.
While I've not done any experiments, it feel like it might be possible
to heuristically detect some (but not all) moves by looking at copies,
and asking if the source was deleted in the same revision. There are
probably all kinds of corner cases I haven't considered, but at first
blush that seems like it might work.
The client still needs to be taught to actually use this information.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-04-19 16:00:45 CEST