I hope this explanation helps
G foo File foo received new changes, but also had changes of your own
to begin with. The changes did not intersect, however, so Subversion
has merGed the repository's changes into the file without a problem.
C foo File foo received Conflicting changes from the server. The
changes from the server directly overlap your own changes to the file.
No need to panic, though. This overlap needs to be resolved by (you).
That is when 3 files are added in your WC
On 8/1/07, Bob DuCharme <bob@snee.com> wrote:
> >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
>
>
--
Gaurav Kothiyal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 2 00:04:18 2007