>when there is a non-conflicting merge of changes
What constitutes conflicting vs. non-conflicting changes?
That really gets to the root of my confusion--I wasn't sure why, when I
created a conflict on purpose to better understand what was going on,
those files sometimes appeared and sometimes didn't. I guess it was
because svn sometimes considered my changes to be conflicting and other
times (e.g. if I added a new line at the beginning of one copy and a
different new line at the end of the other copy) non-conflicting.
thanks,
Bob
On Wed, August 1, 2007 5:20 pm, Karl Fogel wrote:
> "Bob DuCharme" <bob@snee.com> writes:
>> I understand the general scenario of finding out that you have a
>> conflict
>> when trying to commit an out of date foo.txt file, then comparing
>> foo.txt,
>> foo.txt.mine, foo.txt.r7, and foo.txt.r8, fixing foo.txt, and using the
>> resolved command.
>>
>> I can't figure out exactly which step creates the mine, r7, and r8
>> files,
>> and when it does it. Sometimes it seems like the update command does it,
>> but it doesn't always do it when there is a conflict. Can someone tell
>> me
>> exactly what triggers the creation of these extra files? (And the commit
>> command after the resolved command removes them, right?)
>
> Update should always create those when there is a conflict. But when
> there is a non-conflicting merge of changes, then those files are not
> created. I can't remember if 'resolved' or 'commit' removes them; I
> would expect the former, but experimentation could say.
>
> If you can describe precisely what you're seeing, we'll be better able
> to help.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 1 23:39:38 2007