On Fri, Jun 21, 2013 at 09:00:11AM +0000, Markus Schaber wrote:
> Hi, Julian,
>
>
> Von: Julian Foad [mailto:julianfoad_at_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.
Received on 2013-06-21 11:19:04 CEST