Stefan Sperling <stsp_at_elego.de> wrote on 03/11/2008 09:28:40 AM:
> Hey Nico,
>
> On Tue, Mar 11, 2008 at 01:48:09AM +0100, Nico Schellingerhout wrote:
> > I agree, a move should be treated as a first class citizen: for
> > detecting
> > conflicts it doesn't matter, but for resolving them
> > (semi)automatically, it
> > does.
>
> It does matter for detection. Detection would be much, much
> easier already if we had an update editor callback like
> move_file(source, target);
>
> See the section "TREE CONFLICT DETECTION WITH TRUE RENAMES" in
> http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts/detection.txt
Hi Stefan,
I have read through the section you mentioned, and I am not sure what
you mean by "true renames". The way I see it is that Subversion has all
the concepts in place to achieve what we want. By simply inspecting
logs on source and target branches, it is perfectly possible (albeit very
expensive, currently) to trace the location and a name of the file, and
unambiguously correlate a file in the source branch to a corresponding
file in the target branch (there are exceptions: a file could be cloned
on the target branch, but that could be considered a corner case, for
which tool-support is less strong). This is actually what our integrators
are doing now by hand on a daily basis to resolve "tree conflicts"
(quoted because the "tree conflict" concept does not exist as such in a
Subversion release yet).
The real problem appears to be twofold:
(1) the fact that the client is not given the chance to do this, because
the server omits the copy-from information for adds, leaving the client
in the dark about the user intentions.
(2) there is no API call "whereis", defined as follows:
whereis(URL:rev, targetbranchURL:rev), tells you where a file
identified by URL:rev (on a source branch, for example), can be found
in the targetbranch (note: whereis may return [0:N] URLs because of
possible cloning on the target branch). (Note that this requires
the ability to search "forward" through the logs efficiently, a
feature that Subversion does not provide right now AFAIK.)
If (1) and (2) were there, the client could - in principle - replay
"moves" on the source branch to corresponding "moves" on the target
branch. Note that (1) and (2) do not require additional metadata to
be stored in the server (true renames would require that, I guess),
Subversion would just be using the metadata it keeps more "smartly"
to implement the simple heuristic of
"delete with associated add-with-history constitutes a move"
Now, I have no clue about performance impact of these extensions, and I
may be missing ugly consequences, but to me this looks like a path
worth investigating to not only detect and raise tree conflicts, but to
handle them as well.
Of course, for the initial phase of tree conflicts (raising conflicts,
not resolving them), we will have to make do with what Subversion
provides, and make the best of it. However, I do not understand the
point in detection.txt that the update editor would have to have the
complete list of all adds with history just to _detect_ tree conflicts:
UC1 and 3 are triggered simply by trying to change or delete an absent
file. That should be enough to flag this as a tree conflict, right?
- Nico
Received on 2008-03-20 21:06:21 CET