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

Re: Tree conflict merry-go-round on update/switch

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 26 Nov 2008 18:28:51 +0000

On Wed, Nov 26, 2008 at 03:32:28AM +0100, Branko ??ibej wrote:
> Branko ??ibej wrote:
> > Mark Phippard wrote:
> >
> >> It might be interesting to investigate a new WC state for an item that
> >> is unversioned but has a tree conflict. Perhaps an item like this
> >> could still live in entries and still have a text-base for diff. svn
> >> resolve would have the option of scheduling the item for addition back
> >> to the repository, or removing it from the WC. svn revert could
> >> remove it from the WC.
> >>
> >>
> >
> > That's an interesting approach ... that state would be a cross between
> > "added" and "locally deleted"; it gets the file-in-wc-not-in-repo part
> > from the first, and the text-base-available part from the second. Plus
> > mark it as "conflicted" which makes it uncommittable. I suggest the
> > state be called [W]eird in svn status. :)
> >
> > Possible resolutions would then be:
> >
> > svn revert: W -> nil, file and text base are gone
> > svn resolved: W -> A+, file and text base remain
> >
> 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".


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 19:29:07 CET

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.