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

Re: Re: 3 propositions for evolutions

From: Ed Hillmann <ed.hillmann_at_gmail.com>
Date: 2007-02-13 03:25:05 CET

On 2/13/07, Scott Nicolson <Scott.Nicolson@oscmar.co.nz> wrote:
> > It seems to me that the actual problem is that while merge conflicts
> > are available for review and possible rejection of updates,
> > successfully merged files are not, yet there are cases when
> > successful textual merge results in semantic conflict.
> > I doubt it is possible to implement in TSVN without Subversion
> > support, but I think correct solution would be to add "Use mine/theirs
> > version" menu item to successfully merged files in update dialog
> > similar to "Resolve using mine/theirs" item for conflicted files.
> > "Use theirs" will be equivalent to "Revert", but "Use mine" should
> > preserve local modifications made before update (which is IMHO the
> > essence to the original poster's wish).
> Bingo. This would solve the problem also. That way we could see the
> changes resulting from the merge.

Hold on. Wouldn't the "Use mine" option of a merge automatically
remove the code that was committed previously? The whole reason the
conflict occurred was that the merge process couldn't deduce which
lines should exist because they conflict one another. You might see
what files were changed, but you'd also be seeing what files just had
legal changes removed by your local changes.

So, when another updated file expects those changes you've just
automatically merged out, you quite likely have a compile error and no
recourse/idea how to resolve it. So you have to do the normal merge,
which defeats the whole purpose of this step in general.

Or, even scarier, you remove the new code which was attempted to merge
in, using your own instead. But nothing else references it, so no
compile error. But the logic which was just merged out no longer
exists. Presuming that fix was committed to fix a bug, and the
developer thought they just committed some fixes which have just been
"merged out" automatically by another developer. Then the bug crops
up 6 months down the line, and someone's got to figure out why the fix
isn't there in the first place.

It just sounds too dangerous to me. Better the devil I know (this
file is in conflict... at least let me see why) vs. the devil I don't.
 Again, my opinion
> Scott
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
> For additional commands, e-mail: dev-help@tortoisesvn.tigris.org

To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Feb 13 03:25:16 2007

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.