> > 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
As I said in the other note, I understand that, and I don't expect svn to
even attempt to try to understand them, I'm trying to figure out what would
happen mechanically. I'm guessing that the nature of the changes to the
trunk in this case would control whether 'svn merge' would seamlessy merge
them, or treat them as a conflict.
I think the questions I'm really asking is "After merging the branch to the
trunk, would the trunk code now contain elements that reference the missing
file, or not?"
For instance, let's say the branch starts out using a class,
"TBD.something". After the branch is cut, trunk is changed to no longer
need that class, so not only is the file removed, but other source files are
changed to remove references to it. In the meantime the branch was not
changed to remove those references. Thinking about it, there are two more
possibilities (at least) in the branch. One is that the changes to the
branch don't involve the deleted class at all. The other is that the
changes to the branch require the presence of the class that has been
deleted from trunk.
Hmmm. I suspect the best thing to do would be to set up a test case and
just see for myself, but alas, I can't do that here.
Experimentation time...
Brad
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 24 16:15:57 2005