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

Re: 'svn revert' vs. 'svn resolve'

From: Brian Denny <brian_at_briandenny.net>
Date: 2003-06-11 04:39:11 CEST

On Tue, Jun 10, 2003 at 04:03:42PM -0700, Greg Stein wrote:
> Oh. I was about to say that leaving 'foo.mine' was the right operation, but
> that isn't the case. If the text-base was still at r6, then *yes* -- you
> could continue working with foo.mine since it was "locally branched" (if you
> will) from r6. But the text-base has moved up to r8, so simply shoving
> foo.mine over the top of the working file would be bad. You'd lose the r6:r8
> changes.

Hm. On the one hand, keeping the ".mine" file around preserves your
local changes (at least, the ones you so carefully made by hand), so
that's all you need.

Except that, it would be a pain to have to re-merge them in by hand, so
i guess a ".merged" file is a good thing.

But then, why not go the step further and retain *all* the files
resulting from the conflict? After all, presumably they all got put
there because they were useful.

Of course, if we do that, we might as well go another step and say that
"revert" doesn't actually resolve/revert the conflicted file (unless you
pass --force). ...Which is making more and more sense to me -- after all,
a conflicted file is kinda different from a "local change" -- it's more
of a weird, invalid state which has to be taken care of before you can
do anything intelligent with it.

Or am I just off my rocker?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 11 04:34:08 2003

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.