Hi, tree-conflict fans.
In any tree conflict (let's say "svn update" wants to modify a file that I've
deleted in my branch), which item is in conflict - the file (the "victim") or
the directory it is in (the "parent")?
The Victim:
$ svn delete dir/foo.c
$ svn update
# (The update tries to modify 'dir/foo.c'.)
C dir/foo.c
$ svn commit
svn: file 'dir/foo.c' is in conflict - aborting commit
$ svn status
C dir/foo.c
$ svn resolve --accept=mine dir/foo.c
The Parent:
$ svn delete dir/foo.c
$ svn update
# (The update tries to modify 'dir/foo.c'.)
C dir
$ svn commit
svn: directory 'dir' is in conflict - aborting commit
$ svn status
C dir
# (And a line for 'dir/foo.c' as well, probably not status 'C'.)
$ svn info dir
# (Shows the details of what is conflicting within 'dir'.)
$ svn resolve --accept=mine dir # optionally with: --victim=foo.c
(When the victim is a directory rather than a file, the examples get less easy
to read but the concept is the same.)
In the tree-conflicts branch, "foo.c" would be called the "victim" of the
conflict, and metadata about the conflict is stored in the parent of the
victim. Presently, this shows up as status "C" on the parent directory, and
generally it is regarded as the parent directory being in conflict.
One good reason for choosing The Parent is by analogy with text conflicts. When
lines of text are in conflict within a file, there are two or more versions of
the file that could be chosen as the final resolution, and it is the file that
we say is "in conflict" or "contains conflicts" and is "resolved" or "not
resolved". Subversion operations deal with the file as a whole rather than
individual conflicts within it. Children in a directory are like lines of text
in a file, so if there are two possible outcomes for whether the file
'dir/foo.c' shall remain present in the directory 'dir', there are (at least)
two possible resolutions for the directory, and we can say the directory 'dir'
is "in conflict" or "contains conflicts", and is "resolved" or "not resolved".
The other side of the coin is that deleting or creating a file could be
regarded as a special kind of modification. We could say that 'dir/foo.c'
underwent one kind of modification (actually: deletion) locally and another
kind (adding a line of text, say) in the repository, and those two changes
result in two possible outcomes for the file. Its parent directory is just
there to hold the file (for as long as it exists), and is no more "in conflict"
than is a directory which is holding a file that has text or property
conflicts. From a simple status code of 'C' in the first column you wouldn't be
able to tell whether is was a tree conflict or a text conflict, but if that's a
problem there are other ways to present the information - a letter 'T' instead,
or another column, for example.
It's easy to say "I think it should be X" or "The implementation clearly leads
to Y" but can anyone think of a persuasive argument for one versus the other,
perhaps that leads to some satisfying degree of consistency?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-28 13:49:31 CEST