On Fri, Sep 12, 2008 at 12:44:11AM +0200, Neels Hofmeyr wrote:
>
>
> Julian Foad wrote:
> > Bear in mind that "reported as" and "stored as" are two completely
> > different things. I'm not intending to change the storage, only the
> > reporting. The storage can stay in the parent directory.
>
> Oh, I see. In that case...:
This discussion is important!
Please keep in mind that the current way we're reporting tree
conflicts is nearly useless. I don't want it to end up in a
release like this. This is the most urgent problem on the
tree-conflicts branch IMO. We really need to fix this!
> One day, stsp and I were discussing the _reporting_ of tree conflicts, and
> thought that maybe victims and storage holder (i.e. parent directory) should
> have distinct markings; C for parent dir, as in "conflicted", and V for an
> actual victim node where the conflict manifested.
>
> We also thought it would be nice to have an additional column for tree
> conflicts, to be able to still see the other markings on the
> tree-conflict-marked files.
I'm still not entirely convinced about that third column.
There is a bit of a problem with the way Subversion currently
displays information during update/status, and how to encode
tree conflict information in a compatible way.
To recap, what we currently have (in 1.5 and trunk) is two columns.
One column for displaying information about files/directories,
and one for displaying information about properties.
Files and properties can be text conflicted (signalled by 'C'),
directories cannot be conflicted.
Enter tree conflicts:
* Files can now be text conflicted, or be victims of a tree conflict,
or both.
* Properties can be text conflicted.
* Directories can now contain tree conflict victims, or be tree
conflict victims themselves, or both.
Currently, on the tree-conflicts branch we're only displaying
information about directories which contain tree conflicts.
This works sort-of well, by showing a 'C' in the first column
of the status output for a directory.
For example:
CM foo.c (a file with text conflict and property mod)
C dir (a directory containing tree conflict victims)
To get information on individual victims inside a directory,
the user has to run 'svn info' on that directory, and will
then get a display like this:
Tree conflicts:
The update edited the file 'bar.c'.
You have deleted 'bar.c' locally.
Maybe you renamed it?
This UI is less than ideal. It's fine for use during development
to see whether victims have been detected correctly, but it is
not something I'd like to use when actually working with Subversion.
I'd rather have something like this:
$ svn update
CM foo.c (a file with text conflict and property mod)
C dir (a directory containing tree conflict victims)
V dir/bar.c (a tree conflict victim)
Updated to revision 42.
There was 1 text conflict and 1 tree conflict.
$
Note the conflict summary display which should be rather handy
once those numbers get big. Imagine not getting a summary when
you actually run into something like this:
There were 33 text conflicts and 20 tree conflicts.
But there is a problem. What if dir/bar.c was text conflicted,
had property conflicts, and are also the victim of a tree conflict?
Note that such a condition may be the result of multiple updates
or merges without conflict resolution done in between.
If we only had 'C' and 'V' and two columns, we could encode
this situation as:
CC dir/bar.c (hides the tree conflict)
VC dir/bar.c (hides the text conflict)
CV dir/bar.c (ambiguous -- does the 'C' in the first column indicate
text or property conflict? And inconsistent: the second
column is used for something other than information
about properties -- or the first column is used for
something other than files, depending on what 'CV'
should mean)
VV dir/bar.c (Bah, no one will grok this.)
So imagine we had a third column to show tree conflict status:
$ svn update
CM foo.c (a file with text conflict and property mod)
C dir (a directory containing tree conflict victims)
V dir/bar.c (a tree conflict victim)
Updated to revision 42.
There was 1 text conflict and 1 tree conflict.
$
We can now encode every conflict individually and unambiguously.
Encoding all three types of conflict at once is easy:
CCV dir/bar.c (a file that is text conflicted, has property
conflicts, and is the victim of a tree conflict)
CV dir/dir2 (a directory which has property conflicts, and is
the victim of a tree conflict)
CC dir/dir2 (a directory which has property conflicts, and contains
tree conflict victims)
However, I see two drawbacks:
a) For easy parsing, the 3rd column would always have to be present
in the output, even if no tree conflicts are reported. This wastes
a single charater and possibly breaks some wrapper scripts, but
it's not that big of a problem.
b) The 3rd column would only ever show status about conflicts.
The only letters that could appear there would be 'C' and 'V'.
No 'U', not 'M', etc. As such, adding this column breaks with
the current design of the UI (one column for *anything* about
files, one column for *anything* about properties).
And by the way, I think that a proper description of all conflicts
should be printed when the user tries to commit:
$ svn commit
Commit failed (reasons follow):
foo.c is text-conflicted.
dir/bar.c is a tree conflict victim:
dir/bar.c has been edited in the repository.
You have deleted dir/bar.c locally.
Maybe you renamed it?
$
This is only a rough idea, though. We could also sort output by type
of conflict, change the wording, etc. The point is that svn should
become more verbose, to accurately explain complex conflict situations
to the user. Just printing "'foo.c' remains in conflict" as we do now
is not gonna help people much. This is a big chance to improve the
user interface wrt conflicts, we should use it.
Also, an additional way of getting at this information without trying
to commit would be nice. I don't really think that using 'svn info'
for this is right, but I don't have any better ideas either:
$ svn conflicts (new subcommand, name sounds odd)
$ svn show-conflicts (new subcommand, too long to type)
$ svn status --verbose or svn status -v (important information hidden
behind some option switch,
not good)
$ svn resolve --show-conflicts=tree (too long to type, user might not
want to resolve yet)
Hmmm... :-/
> What do you (all) think?
>
> ~Neels
What he asked :)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-12 13:10:33 CEST