[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tree conflicts - who's in conflict?

From: Nico Schellingerhout <nico.schellingerhout_at_philips.com>
Date: Wed, 28 May 2008 18:16:38 +0200

Julian Foad <julianfoad_at_btopenworld.com> wrote on 05/28/2008 01:49:12 PM:

> 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 getless
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 thefile
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?

Hi Julian,

I'm not sure if I have convincing arguments, but I would prefer the
victim to be in conflict rather than the parent:
1. Resolving conflicts on files is easier than on the parent: if multiple
conflicts in the same parent exist, you would have to indicate (using
a --victim switch) what victim to resolve.
2. The parent solution would look strange in a situation where Subversion
tracks moves. The reason is that tree conflicts can become more complex
if Subversion can track moves.

To give an example:
repo: A/B/c -> A/B/c'
wc: A/B/c -> A/B -update-> A/B/c'
               A/c A/c

In the example the user svn moved A/B/c to A/c. The conflict (to the user
who just did the move) is that the location of A/B/c' does not
coincide with A/c. This could be expressed by a conflict on A (the
analogon to the parent solution), or a conflict on A/B/c' and A/c (the
analogon to the victim solution). A conflict on B (or a conflict on
B and A) looks artificial to me.

In conclusion, the victim proposal looks best, provided a tree conflict
is distinguishable from a text or property conflicts.

- Nico

>
> - 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 18:43:35 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.