On Fri, Jun 21, 2013 at 09:00:11AM +0000, Markus Schaber wrote: > Hi, Julian, > > > Von: Julian Foad [mailto:julianf...@btopenworld.com] > > > [...] > > We will preserve backward compatibility between move-aware clients and move- > > unaware repositories, and between move-aware repositories and move-unaware > > clients. In all cases, simple compatibility will be available by falling > > back to copy-and-delete. In some cases, heuristic detection of moves may be > > offered as an option. > > It might be useful to provide an API to hook into that heuristic - clients > embedded into IDEs may have more semantic knowledge about object identity. > For example, CODESYS objects always contain a (per project) unique GUID, and > certain groups of files (Form.cs, Form.Designer.cs, Form.resx) are always > renamed or moved together in Visual Studio.
With a heuristic, it's quite possible that it will be up to the client or IDE integration to ask the user about incoming moves. Most definitely in cases where the move is ambiguous when provided as copy+delete, such as svn cp A B; svn cp A C; svn rm A; svn commit which is currently indistinguishable from svn cp A B; svn mv A C; svn commit and svn cp A C; svn mv A B; svn commit In situations like this, the 'svn' client might decide to ask the user to pick one of the possible moves, or treat them all as copy+delete. It is possible that no user interaction will be required at all in your case. I don't think we'll need a special API feature for hooking into the heuristic. The client will drive conflict resolution, and the client/wc libraries will just do what the client tells them to do. We need to make sure that clients receive all information about the conflict they need to make an informed decision, of course.
