Peter Lundblad wrote:
> Mark Phippard writes:
>> On 3/7/07, Peter Lundblad <plundblad@google.com> wrote:
>>> Mark Phippard writes:
>>>> Finally, in either solution, an inconvenience exists that a user could
>>>> be resolving conflicts in areas of code that are going to be removed in
>>>> later stages of the merge.
>>> Yes, this is a problem that has bugged me for a while.
>>> Maybe this is solvable if there is a way to avoid getting the information
>>> for paths that are going to be deleted. I don't know if svn diff
>>> --summarize
>>> could be used here. Also, the sparse-directories branch has the notion of
>>> depth that could be useful.
>>
>> Yeah, I wasn't even talking about the case where the whole file is deleted,
>> which is obviously even worse. I was just thinking of resolving conflicts
>> in functions or blocks of code that are going to be deleted in subsequent
>> revisions.
>
> Yeah, that's a good point and this is an annoyance.
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.
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 Sat Mar 10 23:36:07 2007