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

Re: Tree Conflicts and User Interface (was: Re: [PATCH] Tree-conflicts: do_entry_deletion segfault)

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 12 Sep 2008 12:31:29 +0100

On Fri, 2008-09-12 at 13:10 +0200, Stefan Sperling wrote:
> 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.

No, not both. We won't attempt to apply another update or merge once the
node is already in some sort of conflict.

> * Properties can be text conflicted.

Yes, but not if their node is tree-conflicted.

A node is either tree-conflicted (as a victim), or can have (text and/or
prop) conflicts: one of:

  - not in conflict
  - tree conflict victim
  - prop conflicts
  - text conflict
  - text and prop conflicts

> * 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.

Why did you want the notification that 'dir' contains tree conflicts? If
it's so that you can do a non-recursive status on it and still see
there's something wrong with it, then wouldn't you want the indication
to bubble all the way up to the WC root?

I suggest there's no need for reporting 'this contains 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.

Yes. Or, more crucially, when 300 files were updated, there was just 1

> 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.

Let's not allow that. The design we were working to said we would not
allow that, as I recall. It should bail out if we try to update or merge
into something that's already conflicted. If that's not done, we'll fix

(There's a complication in that the new merge-tracking merges are
multi-phase and it's not ideal if they bail out after raising a conflict
on an early phase, but that problem is already present outside of tree
conflict handling.)

> If we only had 'C' and 'V' and two columns, we could encode
> this situation as:

I'll follow up with my own proposal.

- 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-09-12 13:31:49 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.