On Jan 24, 2005, at 8:18 AM, Brass Tilde wrote:
>>> ii) If the file is in the branch:HEAD and WAS in the trunk at the
>>> time
>>> the
>>> branch but has since been deleted in the trunk:WC then add and mark
>>> as
>>> conflict.
>>
>> No. The fact that the trunk is missing the file is irrelevant. If
>> the
>> file didn't change in the branch, then there's no change to apply.
>
> So, if the HEAD of the branch *needs* that file, i.e. none of the
> assumptions about it's presence are changed from the time the branch
> merged,
> then presumably the trunk *did* change with respect to this file,
> correct?
Yes. We're talking about a scenario when one line of development
deletes a file, and another line of development does nothing to the
file.
>
> Will the lack of those changes in the branch, and their presence in the
> trunk, cause a conflict in the trunk working copy, or will the branch
> "non-changes" simply be merged with the trunk in the WC?
'svn merge' marks *syntactic* conflicts, not *semantic* ones. No tool
in the world can prevent semantic conflicts. If one line of
development ignores a file, and another line of development deletes it,
there's absolutely no syntactic conflict. The lines merge smoothly:
the merged line has the file missing.
Presumably, the line which deleted the file also changed *other* files
(like, say, a Makefile) to justify the deletion. And those changes
will be merged too. So most of the time, semantic conflicts don't
happen.
As a counterexample, if one line deletes a file, and another line
changes the same file... then that will result in a conflict upon
merge. A human will need to resolve it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 24 15:39:26 2005