On Wed, 2008-11-26 at 13:34 -0500, C. Michael Pilato wrote:
> Stefan Sperling wrote:
> > On Wed, Nov 26, 2008 at 03:32:28AM +0100, Branko ??ibej wrote:
> >> Thinking of htis some more ... it appears that "A + C", that is, "added
> >> with history, tree conflict" would be exactly the right state for such
> >> files.
> >>
> >> * Added, therefore the file is not in the repo
> >> * History would indicate that it is, in fact, the same file (never
> >> mind renames, but even those can be tracked from the historic URL)
> >> * The conflict says it can't be committed without some extra work
> >> * Someday one would expect, e.g., "svn info" and interactive
> >> conflict resolution to be able to describe how the file entered
> >> such a state; though that's immediately apparent from "svn log"
> >> anyway. Icing.
> >>
> >> That would give you sane local diffs (I'd expect the text-base to be
> >> unchanged from before the update in this case), and the revert/resolve
> >> path. If you decide to retain the file, the add-with-history is exactly
> >> the right way to resurrect it; sort of equivalent to the reverse-merge
> >> of the deletion plus local changes. (Though I suspect one wouldn't want
> >> to record merge history for this.)
> >
> > Yeah, this sounds like a neat idea.
> > It certainly makes more sense than "M C".
>
> Indeed. And the idea sounds so [notes/tree-conflicts/scratch-pad.txt]
> familiar, even... ;-)
This idea is right except for the "diff" aspect.
The Right Way to handle a tree conflict on Update/switch is definitely
to update the text-base to the new version, and re-schedule the text so
that "svn resolved" would make it how the user had it before the update.
It enables the conflict to be resolved without further updating, which
is the expected behaviour. It is analogous to how proprty and text
conflicts behave.
In this case (incoming delete), this means we would delete the text-base
and re-schedule the file as "A +" so its status is reported as "A + C".
"svn diff" would show an all-lines-added diff. This is Right. It would
be crazy to make a state of "A +" be diffed as "r(Last Base You Had
Before The Update):WORKING" in some circumstances. If the user wants to
see what they had changed relative to that previous version, that's why
we tell them the URL_at_REV of that previous version.
I talked to Mike and Mark about this today but I didn't think of this
"diff" issue then. We agreed that if it makes the user experience vastly
better we should do it, even if we don't yet do the corresponding thing
for the other kinds of tree conflict on update. We can treat this as a
step forward from broken (not noticing a conflict) to good, and the
other cases as a smaller step forward from broken (not noticing) to
better (noticing but being awkward to resolve).
I want to do this now. If we don't get all of the cases done now, we can
then see whether the community thinks it is acceptable to improve the
behaviour of the other cases in a point release, or else do it in 1.7.
- 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-11-26 20:30:28 CET