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.
Yes.
> 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
victims'.
> 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
conflict.
> 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
it.
(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