[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: Branko Čibej <brane_at_xbc.nu>
Date: Wed, 26 Nov 2008 03:32:28 +0100

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

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

-- Brane

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 03:33:19 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.