On 3/10/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>
> Let's be really careful here. The fact that a conflict occurs in an
> area of code that is going to be deleted does not mean that the conflict
> can be ignored.
>
> I'm thinking of the situation that in branch B1 a function is modified
> in one revision, and moved to another file in a later revision, while in
> branch B2 the same function is modified in a different way but left in
> place. If branch B1 is merged into B2, then it might seem that a
> conflict between the function modifications can be ignored (giving a
> clean merge) because the function code is expected to disappear later.
> But unbeknownst to svn, the function code isn't disappearing but is
> rather being moved to another file. So presumably the change made in B2
> has to be resolved with the change made in B1 and both of them moved to
> the new file. The conflict is thus necessary to indicate that human
> intervention is necessary.
Unless the function that was moved to a new file in branch B1 was done as
part of a svn rename or copy, how is svn supposed to know that a function
was moved at all?
It seems that, to solve the problem you outline you need to go one step
further. Even if a change to a file that is about to be deleted merges
cleanly, that fact that one branch modifes a file and another branch deletes
it should probably result in a conflict, between a modification and a
deletion, just so the user can make sure that the modification doesn't need
to go someplace else instead now that the file is being deleted.
This of course unless you decide to tell svn about any code moving from one
file to another somehow.
Michael
A similar argument holds even if a whole file is being deleted and its
> contents moved into another file.
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Received on Sun Mar 11 17:00:53 2007